>John, in my opinion Synopsys sales people are barely multi-celled
>organisms. I am continually surprised by their arrogant behavior, but
>one comment from [Named Deleted], our Synopsys Area Sales Manager, still
>rings in my ears. Design Compiler was crashing with no diagnostic
>message. This was right before tapeout and our schedule concerns were
>red hot. [Named Deleted] responded to our situation by saying "Just
>because you're our customer and you've got a problem, doesn't mean that
>*we've* got a problem." Later I independently called the hotline and we
>were quite surprised how Ben Ng bent over backwards to help us. Once he
>understood how critical our situation was, he even came in weekends to
>try to find a fix. Bravo Ben Ng!
Editor's Note: Happy New Year! I'm not running this horror story to
castigate a particular company's EDA sales manager (because I can easily
find similar horror stories with Mentor, ViewLogic, Cadence, etc.) but
to remind you to start out your new year thanking the people you've known
over the past year that either *did* or that you know *would* go that
extra mile to help you out of a mess. All too often, we as customers,
can be quick to complain to the Hotline, Sales and Field Support people
when things go wrong but forget to thank anyone when things go right.
(Imagine what it's like to get this treatment all year round!) Taking
10 minutes to either call or send a thank you card to someone who
you know will help you when the going gets tough is a great way to
start the new year!
- John Cooley
the ESNUG guy
P.S. Because many people are still on vacation, I'm only running Tomoo
Taguchi's "LMC Tale of Woe" and the replies to it in this ESNUG post.
( ESNUG 233 Item 1 ) ---------------------------------------------- [1/5/96]
From: tomoo@sdd.hp.com (Tomoo Taguchi)
Subject: Don't Like LMC's Processor Control Language ( was "LMC Tale of Woe")
// Synopsys Major Flamage On
A year ago we taped out an ASIC that had a bug in because we wrote our own
bus-functional model of the CPU and got the CPU model wrong. To try to not
repeat this problem, we decided to plunk down a few $K and buy a LMC
processor model, figuring that an independent source for the model would be
a better validating procedure.
We really didn't care for the Processor Control Language (PCL) that we had
to use to program the processor model because it was totally independent of
Verilog and there were no easy way to coordinate the Verilog testbench with
the PCL, but we lived with it by jumping through a lot of hoops.
About three weeks ago, we discovered that one of the Verilog interface files
for the processor models contained Verilog tasks which were equivalent to PCL
function and procedure calls. We fiddled with it and got it to work. This
was great, since it allowed us to control the processor models through
Verilog and didn't have to even deal with PCL. Since there was only one
language being used, there were no coordination issues to be dealt with.
But I had a few questions about how these Verilog tasks (called interactive
PCL, (IPCL)) were used, so I called the LMC SmartModel Hotline.
Since this worked so well, we decided convert our whole ASIC verification
strategy over to using IPCL instead of PCL. Everything was fine until I
discovered a rather benign anomoly in the model behavior: the model would
stick in two IDLE states between bus accesses instead of one. So I called
the Hotline again and told them about it just to let them know, since it
really didn't affect my verification.
They called back to tell me that IPCL was not a supported feature of LMC and
that I should not be using it. They went on further to say that in checking
the development records of the model, the IPCL features were never tested.
So, I have an ASIC verification process based on a processor model that was
never tested. The bottom line being that I've lost two weeks of work. AND
I'M REALLY TICKED OFF.
I called LMC to complain that:
1) They sent out a model with unsupported features that are readily
accessible to their customers
2) Their Hotline did not even tell me that I was using an unsupported
feature two weeks ago
I asked them to have someone validate the model so I can have some
confidence in it. Their only response was that they can't spare the
resources and they are sorry but they isn't anything they can do. As a
result of this fiasco, I was behind weeks on my schedule.
I'm just venting right now, but would also like to warn anyone out there
that is using IPCL or is contemplating using it, not to do so.
// Synopsys Major Flamage Off
Finally, for those users of LMC models, I'd like to know what methods you've
used to coordinate PCL and the Verilog testbench. About the only way I've
used is to use PCL as the controlling language and have the Verilog monitor
for certain bus activity to generate non-CPU stimulus. To do this, I defined
a bogus register location that triggers Verilog activity when PCL accesses
it. Another method that I've thought of is to have verilog be the
controlling language and use unused interrupts to control the model. Any
other ideas with their pros and cons would be welcome. Also, does anyone
know of another source of models that can be controlled through Verilog?
Pissed in San Diego,
- Tomoo Taguchi
San Diego Printer Division
Hewlett-Packard Company
---- ---- ---- ---- ---- ---- ---- ---- ----
tomoo@sdd.hp.com (Tomoo Taguchi) writes:
>A year ago we taped out an ASIC that had a bug in because we wrote our own
>bus-functional model of the CPU and got the CPU model wrong. To try to not
>repeat this problem, we decided to plunk down a few $K and buy a LMC
>processor model, figuring that an independent source for the model would
>be a better validating procedure.
From: bouchier@news.eng.convex.com (Paul Bouchier)
For something as complex as a processor, if you had the resources and
the project was important enough, you might have considered plonking down
for a hardware model. That way you get a real device, complete with the
anomalies that were designed into it, and not someone's interpretation
of a databook. And you get to execute real code, at speeds more reasonable
than a gate level model, which would be the next lower level.
Given the execution of real code, you build your tests into code, rather
than a test bench. I believe the inability to branch on condition is the
major flaw in the bus functional model approach, but I'm going on possibly
faulty memory there. You also get to see the system effects of real delays
between different bus operations.
Mind you, the interface to the chip in the H/W modeller isn't guaranteed
either, but faults are usually easy to identify - like it drives the
bus the wrong way, and things don't work.
BTW, I have no connection with Synopsys - I've just used the H/W model
of a complex chip and been pleased with the results.
- Paul Bouchier
Convex Computers
---- ---- ---- ---- ---- ---- ---- ---- ----
tomoo@sdd.hp.com (Tomoo Taguchi) writes:
>Finally, for those users of LMC models, I'd like to know what methods you've
>used to coordinate PCL and the Verilog testbench. About the only way I've
>used is to use PCL as the controlling language and have the Verilog monitor
>for certain bus activity to generate non-CPU stimulus. To do this, I
>defined a bogus register location that triggers Verilog activity when PCL
>accesses it. Another method that I've thought of is to have Verilog be the
>controlling language and use unused interrupts to control the model. Any
>other ideas with their pros and cons would be welcome.
From: janick@qualis.com (Janick Bergeron)
I did a similar thing you did with their PCI Bus Functional Model (BFM.) And
had to rewrite a PCI slave BFM since theirs acts only like a dumb memory.
I wanted to be able to act/react to any bus cycle. Took me 2 good weeks :-(
Whenever I spoke with LMC representatives, I tried to explain why it would be
a good idea to have control from Verilog or VHDL. I do not want to program
in yet-another-language nor want to deal with a multiprocessor programming
problem when there are several such beasts in the same system model.
- Janick Bergeron
Qualis Design
---- ---- ---- ---- ---- ---- ---- ---- ----
tomoo@sdd.hp.com "Tomoo Taguchi" essentially writes:
> [ Editor's condensed version: "We ran into bugs making our own CPU models
> so we bought LMC's model of the very same CPU figuring an independent
> source (LMC) would be a better validation procedure. Later we ran into
> bugs and unexpected hassles with LMC's models -- so there was no real
> advantage to buying models from someone else!" ]
From: mac@verilog.com (Michael McNamara)
Folks, I have to say, that problems like this simply come with the territory.
Our job as design verification people is to ``trust everyone, but cut the
cards.''
When at Ardent Computer, we also taped out an ASIC with bugs, because we
wrote our own bus functional model of an R3000 based on written and verbal
information from AE's from MIPS Computer. It turned out the MIPS chip didn't
do what the MIPS AE's said it did (or perhaps what we understood that the
AE's said; I'm not trying to bash anyone here). So we turned the chip. The
chip had a couple of our own bugs in it as well, which of course we fixed
at the same time.
Lab bring up showed us these bugs pretty quickly. The system we were doing
consisted of 3 gate arrays; two were fine on first tape out; one needed to
be turned. 2 out of 3 isn't too bad.
The next project, we bought a LMC hardware modeler, and used that to verify
our interface (this time to an INTEL i860). The ASIC we taped out worked
perfectly with the i860, but did need to be turned due to some problems with
a cache parity interface to another chip.
Much like anything else, in design verification, there is the temptation to
get caught in ``fighting the last war.'' We were very focused on insuring
that we didn't screw up on this project they same way we did on the last; we
were successful at that; but still, bugs crept in elsewhere. And bugs will
creep in. Our job in D.V. is to turn over every stone in our search for bugs.
I have found that very few bugs exist in areas where you have fully tested
the design. I have found that bugs almost always exist where you have not
tested the design.
--- --- --- ---
So, you have decided to purchased a model for a part from model provider
company. Litigatious types might search out for legal guarantees, where the
model provider incurs some liability should there be a bug traced to the
providers model. Hogwash! You don't want a schedule slip! Treat the
provided model like you would any other hardware description facet of the
design: with a jaundiced eye.
You might give it the treatment you'd give to code written by one of your
senior designers (i.e., *be repectful* when you are sure you've found a bug!)
Basically, my point is just because you made the buy/build decision in the
buy direction for this part of your design, recognize that you still own
the verification problem, and the onus is on you that the whole system
works together.
Here is my off the cuff list on Do's for folks using model providers
Apologies to NARA, the North American Remodelers Association, for any
similarities to their list for what to ask your home remodeling contractor
before you let them attack your house :-)
1) ask the provider for their verification suites. (Get
worried if they don't know what you are talking about)
2) ask the provider how many successful designs have been done
incorporating their model. Recognize that new parts are new
parts.
3) ask the provider for references from other customers that
have successfully used that model, as well as other models
from the provider.
4) Get the spec for the part from the source - either the
appropriate standrds body, or the vendor of the part.
5) allocate some verification time to testing the provided
model. Recognize that your purchase is saving design time,
but that you still need to invest in verification
time. With the spec in hand, you can be the judge weather
discrepencies are real or imagined.
6) Use alternative, complementary verification strategies - if
the chip schedule is make or break for the company, by all
means use a hardware modeler, as well as a third party
model for the part. If the chip schedule isn't make or
break, paln for a turn, and before you tape out the first
version, strive for a design verification goal that the
chip isn't a rock.
- Michael McNamara
Verilog Consulting Services, Inc.
|
|
