!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / DAC'00 Trip Report:
_] [_ "The READ ME File DAC"
- or -
"113 Engineers Review DAC 2000 in Los Angles, CA, June 5-9, 2000"
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The READ ME File
----------------
"No! Try not. Do. Or do not. There is no try."
- Yoda
It's interesting how you get to rediscover your world when you have to
explain it to someone else. During and after this year's DAC, I had some
Wall Street analysts ask me why I obsessed over seeing nitty-gritty
customer tape-out stories for the new physical synthesis tools. My reply:
"I don't need tape-outs just for physical synthesis. I don't take *any*
EDA tool seriously until I've seen that someone else has sucessfully used
it to make a real, gone-into-production chip. Those new C/C++ EDA tools
have the same Missing Tape-Out Problem, too. I don't trust them either."
Why?
Because although chip design is a lot like software design in many ways;
there's one very important distinction between the two worlds. Chip design
is a brutally *unforgiving* world. Microsoft software engineers can cut a
release of their O/S, give it to 100's of millions of people worlwide, and
if there are too many bugs, they just cut another release. For the lessor
bugs, you go to the Microsoft website to download specific patches. This
mode of operating is pretty much true for almost all software projects be
it widely used operating systems or esoteric EDA tools.
But when a hardware engineer makes even a seemingly minor mistake on a
chip, his company has to pay a hefty NRE to respin the chip, or worst. The
Pentium Bug? It cost Intel half a billion dollars when all was said and
done to clean it up. And it was just an error that messed up some very
insignificant digits in certain multiplication operations. The U.S.
District court in Texas ordered Toshiba to pay out $2.1 billion dollars to
make ammends for an extremely subtle hardware bug with their floppy disk
controller chip in their laptops. And these are just the hardware errors
that make the civilian news. In the hardcore chip design world, there
are hundreds (if not thousands) of companies that, over the years, have
died or were seriously stunted because of some hardware *design* problem.
I'm talking completely missed market windows, or the times when competitors
got there first, or the thousands of chip that just never made it to fab.
It's in this brutal, unforgiving world that EDA companies peddle their
wares and we chip designers have to bet our farm that their tools will
mostly work as promised. If they mess up, WE'RE the ones who will pay the
piper. Take, for example, the Cadence Vampire story. Back in the early
90's, Cadence made a killing selling a backend guy's linter tool called
'Dracula'. Technically, Dracula was a Design Rule Checker (DRC) that told
you how you inadvertantly screwed up your physical design after you did
that last ECO tweak of the polygons. Great tool. Cadence made a lot of
money off of it. The only problem was that Dracula could only run on flat
designs -- it couldn't do hierarchical DRCs -- and it ran out of steam
beyond a certain point. There rival, ISS, took advantage of this weakness
and created 'VeriCheck', their own hierarchical DRC tool. In the June 20,
1994 issue of EE Times, Gary Smith, then an unknown analyst from Dataquest
said "ISS is significantly taking business from Cadence. Cadence is
vulnerable. After a certain number of gates, Dracula doesn't work."
So, in that Cadence fashion, Cadence started quietly telling their biggest
customers that they were working on a hierarchical DRC tool called
'Vampire'. In Feb. '95, Cadence formally announced and hyped Vampire.
"The current verification systems available are running out of horsepower
for really large designs like 256-kbit DRAMs and microprocessors," said
Linda Mason, product manager for Vampire at Cadence. "This is
strategically a very important move, because we now have a system that
can handle those designs."
IC verification is increasingly critical for deep-submicron designs,
Mason said. She cited the example of one IC manufacturer who didn't use
Dracula and lost $62 million due to a layout-vs-schematic error not
detected until wafer probe.
With its ability to handle hierarchy, Vampire claims to run two to 100
times faster than Dracula, depending on the design problem. ... Its
benchmarks claim Vampire runs schematic netlisting up to 72 times
faster than Dracula, and net-list comparison up to 17 times faster."
- "Vampire Takes A Bite Out Of IC CAD", EE Times, Feb. 6, 1995
Then, 15 months later, Mentor seemed to be foolishly jumping into the very
same hierarchical DRC niche when it announced Calibre at DAC'96. I mean,
gosh, Mentor was going to go against wiley ISS, and Cadence -- the DRC King
which had a 15 month lead on them! Wasn't this an EDA suicide mission by
Mentor???? Not hardly. To make a long story short:
"Uh, we don't have any numbers for Vampire, John. Cadence sold some eval
copies back in '97 and that was it. I can't even think of one customer
who has it. That market is split between Avanti ISS and Mentor these
days. Cadence couldn't get Vampire out the door. My best guess is
engineering problems, but I never got the definitive answer why."
- Gary Smith of Dataquest, in a phone interview from last week
"The Assura product from Cadence is their latest attempt to get back into
the physical verification game. They are obsoleting Vampire (what a
surprise) and plan to run Diva and Dracula clients into this same black
hole."
- an anon engineer response from 3 weeks ago to the DAC survey
Now let's go back in time and make you the CAD Manager at some chip house.
It's Feb. 6, 1995 and you already know Dracula isn't hacking it. Where
would you be *now* if *back then* you decided to stick with Cadence? What
impact did it have on your company that your engineers were wasting their
time debugging Vampire while your rivals were using ISS' VeriCheck?
My point in all this isn't to show how Cadence screwed up. Companies,
especially EDA companies, do this all the time. Remember the purgatory of
the old Mentor frameworks? Or the Cadence/Valid merger? How about the
infamous Synopsys PCI DesignWare fiasco? Or their Dead-On-Arrival Arkos
HW emulator? Or when all the EDA vendors ganged up on Cadence and tried
to force all the U.S. engineers seasoned in Verilog to switch to VHDL?
My point is that EDA companies will gleefully lure chip designers down the
garden path to 1) stop or stall them from buying a viable competitor's EDA
solution, or 2) to get them to debug and/or invest in their own very iffy
new EDA tools. And if those new EDA tools don't work, and you had bet your
project (or your company) on it working -- oh, well!, guess who's screwed?
THIS is why I *INSIST* on at least ONE very painfully detailed technical
customer tape-out story BEFORE I even remotely start taking any new tool
or methodology seriously. Those fucking "Success Stories" reeking of
scripted quotes from customer VPs of Engineering / Management have NO
credibility as far as I'm concerned. I'm not betting *my* farm on *that*
B.S. -- VPs and Management DON'T DESIGN CHIPS. And there's usually some
secret behind-the-scenes deal going on corrupting everything. "Want a
break on those Silicon Ensemble licenses? Then endorse our Ambit-RTL!"
Give me a warts-and-all tape-out story from the actual engineer who sat at
the keyboard and did it himself using your new tool, and then we'll talk.
Otherwise, go away. I have a chip that I'm trying to tape-out right now.
"Shane Robison, president of Cadence's Design Productivity Group, said
the company is very strong in most areas, with the glaring exception of
physical verification, historically one of Cadence's strongest cash
cows. The problems started, he said, when the Vampire hierarchical
verification product was "extremely preannounced" several years ago
and was sold to the wrong market segments.
Robison said that Cadence has a recovery plan that includes flat
verification and extraction derived from Lucent Bell Labs technology,
and that Cadence will field a "comprehensive, integrated" solution early
next year, sold by a new dedicated sales force.
Meanwhile, Robison acknowledged that customers are hearing "a lot of
noise" from startups in the physical design space and that Cadence "may
not have been as responsive to some of that noise" as it should have
been."
- "Cadence Out Of Sync", EE Times, August 18, 1999
" 1. Once you have their money, you never give it back.
19. Satisfaction is not guaranteed.
72. Never trust your customers.
82. The flimsier the product, the higher the price."
- selected quotes from the Ferengi Rules of Aquisition
( DAC 00 Subjects ) -------------------------------------------- [ 7/13/00 ]
Item 1 : C/C++ EDA -- It 'Talks The Talk', But Has Yet To 'Walk The Walk'
Item 2 : C-Level Design, Cynapps, CoWare, and Synopsys 'SystemC Compiler'
Item 3 : Behavioral Compiler, Mentor Monet, Y Explorations, Frontier, Dasys
Item 4 : Datapath from Arcadia Mustang, Sycon, Synopsys Module Compiler
Item 5 : CAE Plus 'Afterburner'
Item 6 : Mentor Seamless, Eaglei & COSSAP, ArexSys, Cardtools, Foresight
Item 7 : Cadence QuickTurn, IKOS, Thara, SimPOD, Axis, Simutech, Physim
Item 8 : Synplicity 'Certify', Synopsys 'FPGA Compiler II'
Item 9 : Mentor Renoir, View/Summit Innoveda, TransModeling, Escalade, XTEK
Item 10 : Cheaper HDL Simulators from Fintronic, Aldec, ZOIX, FTL Systems
Item 11 : Cadence 'NC-Sim', Mentor's ModelTech 'ModelSim', Synopsys 'Scirocco'
Item 12 : Synopsys NDA Suites On VCS, the PLI, and C
Item 13 : Cadence 'Verification Cockpit'
Item 14 : The Superlog Alternative To The C-Or-Verilog/VHDL Wars
Item 15 : Synopsys Vera, Verisity Specman/'e', Chronology RAVE, SynaptiCAD
Item 16 : 0-In '0-In Search', Silicon Forest Research 'Assertion Compiler'
Item 17 : Synopsys NDA 'Verification Analyst', Synopsys NDA 'Ketchum'
Item 18 : Averant/HDAC, iMODL, Real Intent, Valiosys, Levetate
Item 19 : Linters -- TransEDA, Avanti Novas, DualSoft, Veritools
Item 20 : Most Obtuse Presentations -- InTime Software, iModl, SDV
Item 21 : Denali Memory Models & C
Item 22 : Odd Birds -- Derivation Systems, Target Compiler Tech, InnoLogic
Item 23 : Verplex, Synopsys Formality, Avanti Chrysalis, & Mentor FormalPro
Item 24 : Cadence Ambit-RTL, Synopsys Design Compiler, Meropa/Get2chip.com
Item 25 : Static Timing -- Motive, Synopsys PrimeTime, Cadence Pearl
Item 26 : Sequence WattWatcher, Synopsys PrimePower, Summus PowerEscort
Item 27 : Scan/ATPG from Synopsys, ATG, Syntest, Fluence/TSSI, Opmaxx
Item 28 : BIST -- LogicVision, GeneSys TestWare, Syntest
Item 29 : A Cooley Technology 'Find' -- GeneSys 'BISTDR'
Item 30 : Avanti -- Life in the Forbidden City
Item 31 : Huh? -- Avanti & Synopsys Together On 'DesignSphere'?
Item 32 : Magma 'BlastChip' and 'BlastFusion'
Item 33 : Monterey 'Dolphin' and 'SONAR'
Item 34 : Silicon Perspectives 'First Encounter'
Item 35 : Mentor 'TeraPlace', Sapphire 'FormIT/NoiseIT/PowerIT', Incentia
Item 36 : Tera Systems 'TeraForm' & Aristo 'IC Wizard'
Item 37 : A Cooley Technology 'Find' -- Prosper 'HybridMaster'
Item 38 : Relative Customer Rankings Of The 10 Physical Synthesis Tools
Item 39 : Synopsys 'Physical Compiler (PhysOpt)'
Item 40 : Bullish On Cadence & Cadence NDA 'Integration Ensemble'
Item 41 : Prolific, Cadabra, Silicon Metrics, Circuit Semantics, Sagantec
Item 42 : Hercules II, Calibre, Cadence Assura/Dracula, Numeritech OPC
Item 43 : Simplex, CadMos, Sequence 'Copernicus', Cadence 'Assure SI'
Item 44 : Camoflaged Birds -- Embedded Solutions Ltd. (ESL) & AmmoCore
Item 45 : Cheap P&R -- TimberWolf, Pulsic, InternetCAD.com, Matricus
Item 46 : Simplex, Mentor xCalibre, Cadence HyperExtract, Sequence, Avanti
Item 47 : Barcelona, Antrim, NeoLinear, Tanner, ComCad, Silvaco, SPICE
Item 48 : Avanti Lynx-LB, EPIC CoreMill, Circuit Semantics, Cadence TLA
Item 49 : Analog RF Tools -- Cadence 'Spectra RF' & Mentor 'ELDO RF'
Item 50 : Memory Compilers -- Virage, Atmos, Legend, SDS, Nurlogic
Item 51 : Best & Worst DAC Parties, Best & Worst DAC Freebies
( DAC 00 Item 1 ) ---------------------------------------------- [ 7/13/00 ]
Subject: C/C++ EDA -- It 'Talks The Talk', But Has Yet To 'Walk The Walk'
AN UPHILL FIGHT: Yes, the C/C++ EDA tools suffer from a credibility problem
because so far they're all talk and not a single tape-out. Nobody's used
any of this C/C++ stuff to successfuly make even one chip! Skepticism
abounds here with the experienced chip designers.
"They're solutions looking for a problem."
- an anon engineer's response to the survey question about
the many C/C++ EDA tools at this year's DAC
"Oh, so what about these C bullshit tools? Doesn't look like any of
these are ready for prime time. Maybe in a few years. We ran and
still run some C++ models. They're not for the faint of heart."
- another anon engineer's response to the same question
"C = Joke. Also C = New EDA Revenue. That about sums it up.
I really struggle how C is supposed to help me. Yeah, it helps somewhat
with the high level modeling; which, there are plenty of tools for:
Matlab, SPW, and Bones, and Nuthena Foresight. For low level
verification, though, it appears that EDA vendors are not listening to
our whining about the terrible verification crunch we are in. A few
years ago tools like Vera and Verisity came out to solve this issue. I
personally believe that there was much promise in those tools. We saw
verification times drop by a factor of 5 using Vera, but for some reason
they have not caught on in the industry. Instead, EDA companies are
pushing bare-bones C/C++ on us. Great, now I will spend the next 2
years developing/waiting for a set of class libraries to come close to
what Vera or Verisity already offer. It makes no sense!
As one bongo-thumping Cuban once said: Aye Aye Aye Lucy!"
- an anon engineer
"All of them are doing it wrong. None of them excited me in the least
bit. That's all I will say."
- an anon engineer
"Too many C tools covering the same thing: serialized pseudo-concurrent
signaling between modules/objects that have to be constructed just-so.
Verilog was like C anyways.
I kept asking people what the advantage was for C/C++ Cynapps/systemC
modeling and they all said it enabled high level test benches & models.
But nobody seemed to have hard examples of high level testbenches.
They seem to be trying to do "high level" design but they are doing low
level design with artificial subsets of C++ you have to memorize. It's
lacking in ease of use and readability due to how signaling is coded."
- an anon engineer
"NOTE: None of the C verification toolmakers I talked to seemed excited
about SystemC. They say they support it, but give evasive answers when
probed. SystemC defines library code, but each little C house seems to
be still defining its own style. One stardard C-style is needed for
EDA. Not much SpecC buzz."
- Peet James of Qualis
"I teach Verilog PLI courses to hardware engineers, and there is one
dominant characteristic that I have observed. HARDWARE ENGINEERS DO NOT
THINK THE SAME AS PROGRAMMERS -- AND THEY DO NOT WANT TO THINK LIKE
PROGRAMMERS. Without fail, after a few labs of writing C code in my PLI
class, I hear someone mutter "Damn, I sure am glad I'm not a
programmer!", followed by a unanimous affirmation from the rest of the
class. The terminology used is sometimes a bit stronger than what I
quote here. :)
Writing efficient C code, managing memory, avoiding memory leaks,
thinking in abstract pointers, and such is not at all like hardware.
There is a very good reason why we have Hardware Description Languages;
hardware does not work like software. Programming is something I can
do, but hardware design is something I can do very, very well. I don't
think I'm different than most other hardware engineers in that respect.
I like designing hardware. I tolerate spending hour after hour writing
and debugging C code."
- Stuart Sutherland, independent PLI consultant
"I've head some general comments about this entire genre of C tools.
Since it requires a painful change in methodology, starting at the early
architectural stages of the chip design, the rate of adoption will be
very, very slow. Most companies can not afford to commit to this type
of approach on a real chip design, so it requires a parallel effort on
a real design or a seperate test (not real) design to develop the
methodology. Very few companies can afford the luxury of having a
design team work on a non-production chip."
- an anon engineer
"I believe C/C++ exploration will have a niche but will not be the
mainstream. Reminds me of the Behavioral Compiler (BC) craze a few
years ago. Everything was going to be done with BC. BC also has an
important niche, but is far from the mainstream. Synopsys' SystemC
in-part seems to be the reincarnation of BC."
- Cliff Cummings of Sunburst Design (ESNUG 353 #3)
Oh, yes, remember that talk last year of using Java as an HDL? That concept
died this year. LavaLogic filed for bankruptcy.
( DAC 00 Item 2 ) ---------------------------------------------- [ 7/13/00 ]
Subject: C-Level Design, Cynapps, CoWare, and Synopsys 'SystemC Compiler'
IF AT FIRST YOU DON'T SUCCEED: One of the loudest companies in the C/C++
foray last year was C-Level Design. They promised all sorts of great things
like using C/C++ as a behavioral level tool. Their attitude was "Verilog?
VHDL? RTL synthesis?... That's all OK for you chip designing infants.
The *real* systems designers operate at a truely Higher Level by designing
in behavioral C and using our System Compiler(tm) to make a chip!" The
funny thing about DAC claims is they only have a year to make it happen or
it's Egg On Their Face time. And C-Level has Omlette Level egg time now!
A few weeks before this year's DAC, I had a rather interesting conversation
with one of my readers who did a beta with System Compiler. Yes, C-Level's
System Compiler synthesized C into RTL Verilog, but the RTL Verilog wasn't
synthesizable to gates. That is, you couldn't make actual buildable chips
using this tool because it resulted in designs that had state machines with
thousands of states, nightmare datapaths, and hundred layer logic. This
output from System Compiler couldn't ever make timing ever and some of the
RTL constructs it spit out weren't synthesizable at all. In short, it was
a beta nightmare for C-Level.
When I saw them at DAC, I told them about that conversation, and, with much
integrity, they very quickly agreed it was true. They wanted to know if it
was Motorola in Fort Worth or Sony in the UK who told me first. "Last year
we used to talk to customers and we felt that they were snickering at us
when we left the room," said Kevin Hotaling of C-Level. "They knew more
about this problem than us. Now we know more than everyone because we've
done our time in the woods."
This year at DAC, C-Level punted the behavioral C and is refocusing on just
making structural ANSI C synthesizable to Verilog RTL. They claim that you
will still be able to use C's pointers, structs, arrays, unions, objects,
and classes -- but in a moderate way. Users seem to be OK with this, but,
as always, we're all waiting to hear when the first real chip is taped-out
using their tool and the nitty-gritty details it took to get there.
(Be sure to read the 'Behavioral Compiler' part of this report -- it has a
lot of related customer quotes on C/C++ synthesis there.)
"We have C Level Design tools. They work for us now, at least in trial.
We plan to use their tools in an up coming project. We have looked at
many other vendors. In our opinion, C Level Design is that best
available today, but Synopsys will be the best once their tools have the
features we need (by the end of 2000 it looks like). We plan to move to
Synopsys tools when they are ready. I expect it will take 3 to 5 years
before we move from a VHDL flow to a C flow because it will take that
long before all the required tools are available."
- an anon engineer
"C-Level Design
- I finally was explained how they handle concurrency, hierarchy and
time. They fake it by having all input/output to C functions be an
array with 2 locations: one for the input, one for the output. The
output value replaces the input value at the next clock cycle. That
way the order in which functions are called in irrelevant.
- Very intuitive to use at the RTL level but this cycle-based approach
limits the usability & portability at higher levels of abstractions.
My bet is you'll see a LOT of incompatible models written at that
level and the mess will still remain.
- The AE I spoke to eventually agreed that C was not that cool for
testbenches since it did not offer good concurrency & communication
control compared to Specman or Vera.
Their value-add is a yellow brick road between C models and RTL coding
in HDLs."
- Janick Bergeron of Qualis Design (VG 1.13)
"CynApps: Good idea, but they still have some serious issues to resolve
before it's all over. Biggest problem is that their C simulator and
their cynthesized Verilog simulation won't necessarily give you the same
answers if the underlying C++ code suffers from call-order problems.
Also, if you are trying to simulate a design, there's no good simulation
commands to (for example) step 100 cycles, or examine a particular RTL
signal at any level of abstraction. It is good for the stepwise
refinement idea, but isn't really all that friendly otherwise.
SystemC: Has concurrency problems as well. There was a lot of buzz
about SystemC before DAC, so I let others in my group hound the SystemC
guys while I looked at other vendors.
Interesting thing at DAC was that on Monday Cadence announced support
for SystemC, and on Wednesday announced support of CynApps. Playing
both sides of the fence might (or might not!) be the prudent thing to
do. I'll be very interested to see where this all goes."
- an anon engineer
"C-Level's tool could have a place in a design flow. Their ANSI C
compatibility is a plus over Synopsys's SystemC Compiler. The problem
is getting designers to work in C rather than Verilog/VHDL. At 95K per
license it looks pretty steep to my eyes. I don't know what Synopsys
is charging for their similar tool."
- an anon engineer
"Didn't look at C too much. But I don't believe C-Level's 1500x speedup
number. Cynapps admitted their simulation isn't much faster than
something like VCS; they just think everyone wants to design in C++."
- an anon engineer
"Co-Ware -
Their Jay Leno/Bill Gates skit was pretty funny, but their Napkin to
Chip concept was pretty much a repeat of last year's demo from what I
could tell. Their claim is that their tool provides a higher-level
concept visualization and helps the software/hardware partitioning.
It can also output interface code and interface RTL for synthesis."
- an anon engineer
"C-Level
This company provides a C to Verilog or VHDL converter. We could use
this tool for testing the [ design deleted ]. We currently do not have
the ability to test every case for the [ design ]. We have in the past
modeled the [ design ] in C and done some testing. However the VHDL
that was written could be different than what is modeled in C. C
modeling and testing is easier and faster. The C-Level conversion tool
offers ANSI C / C++ compatibility. We could slowly use this tool for
more and more design blocks. Some designers might prefer to write there
code in C. Port drivers could also be done in C. The conversion tool
provides a fully synthesizeable Verilog or VHDL file. So we could use
this as an extra part of our simulation environment. C-Level has
experience with five million gate designs and compile times of
approximately 1 million gates per 2 hours. The software runs on either
NT or Solaris with signal name retention assured. All compiling,
debugging and testing could be done on PC's. A possible drawback is the
cost of the license, approximately $95 K. We would have a hard time
keeping this license busy. License is only for the conversion step."
- an anon engineer
"C Language Simulation/Synthesis
This is an area that was hot last year - a number of companies were
pushing describing your ASIC in a subset of either C or C++, simulating
it there (which is faster than an RTL) and then automatically
synthesizing your RTL from C/C++.
The new SystemC standard that Synopsys is pushing is having its effect
on the established players in this market. Most of the sales pitches
talked about either how similar they were to SystemC or how their flavor
of C or C++ was superior to SystemC.
C-level Design sells a tool that accepts C and outputs RTL. They say
they now recommend using "cycle C" - C with clock cycles in it
explicitly. This is something that editorials have been commenting on
- if you tweak C enough that you can model concurrency and the passage
of time, eventually you just get another RTL, so what's the point in
using C? They say that unlike Cynapps they can simulate with any
standard C/C++ compiler.
Cynapps accepts C++ and outputs RTL code. They say they are superior
to C level because they are at a higher level. Their C++ is similar to
SystemC but they say it is more extensible.
CoWare's N2C tool also translates C into VHDL or Verilog, but claims to
do a lot more. It is aimed at system partitioning and hardware/software
codesign. The designer creates an initial untimed C model of the
system. This is then refined into a cycle accurate model, which is then
implemented in HDL. It is also supposed to make IP use easier. Don't
know if it's really different from the tools above or just marketed
better.
Frontier Design sells tools that sound awfully similar to C-Level."
- an anon engineer
"Most of the C-level tools are still stuck at the RTL or cycle-based
level. What we need is a solution that has the ability to handle
different simulation and design domains, such as synchronous dataflow,
asynchronous dataflow, analog, gate level, cycle based, RF, etc.
The reason why many companies are using C for system level verification
is the speed, cause you can be more than 100 times faster than with an
event driven HDL simulation. The language or tool must give you the
ability to refine your design starting from the system level without
timing information down to a RTL represemtation.
I think CoCentric SystemC Compiler is a step in the right direction."
- an anon engineer
"CoWare:
These guys had a cheezie yet funny skit with a Jay Leno and Bill Gates
look alikes. Was pretty good for a geek show. N2C or napkin to chip
is their tool. Lets you enter C for everything and then play HW/SW
arch trade offs. The hardware then can be translated to RTL. Very
SystemC-ish they say. Still could not get much info with the time I
had. I think they define a C style that can be mapped into an HDL. I
think they support SystemC in that they can hook up to the SystemC
library parts.
C Level:
These guys have a C to Verilog translator. It can be run standalone on
a C compiler based simulator that can even spit out standard dump files
to compare. Their C style has to be learned. Only their C styled code
works for translation to HDL. Not really addressing a C standard for
verification, just use C anyway you want for verif."
- Peet James of Qualis
"CoWare partner demo with IKOS's new emulator was pretty impressive.
A cell phone design, processing conversation (speech samples) right
there on the DAC floor -- now that is what good DAC floor demos are
made of! Of course 'smoke and mirrors' and attractive spokesbimbos
are also what DAC floor demos are made of as well. :-)"
- an EDA salesman
( DAC 00 Item 3 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Behavioral Compiler, Mentor Monet, Y Explorations, Frontier, Dasys
BAD BEHAVIOR: A few years ago, Synopsys did a big push in behavioral
synthesis, claiming that this is where designers would get the big 10X gains
in design productivity. They did their best to make it happen. Even Mentor
tried to ride that wave at DAC'98 with its Monet behavioral synthesis tool.
Summit (w/ Dasys) jumped in, too, along with Meropa. The only thing was
that the whole push towards behavioral synthesis simply never delivered on
its 10X promise, and, as a result, just never made it mainstream. Now
Synopsys BC has a small cult following. Nobody's using Dasys nor mentions
Mentor's Monet tools. Meropa almost went out of business, but switched
products mid stream and has become get2chip.com now. (C-Level tried some
behavioral, too, and got burned -- see the C-Level part of this report.)
Into this field of wounded jumps 'Y Explorations' from last year's DAC and
'Frontier', also from last year's DAC. A number of people burned here tend
to revert to using Synopsys Module Compiler to do their own datapath
synthesis and to use DC to make the control logic.
"Other vendors C-synthesis tools are less mature. For example, CynApps
synthesis ain't nothing but Dasys, which used to be a direct competitor
to BC under the guise of Summit. Dasys was much faster than BC, but had
some issues on single throughput designs. Also estimating delays from
the controller to the datapath had problems. Frontier Design's C
solution is another BC-like approach, but this time without any
estimating of gate delays. When I asked how you fixed timing problems,
the answer was changing your code/algorithm. Maybe (I hope) the guy
just misunderstood my question, but I don't think so.
It amazes me how CEOs will try to fit a square peg in a round hole to
generate revenue!"
- an anon engineer
"I enjoyed the Frontier Design demonstration from a Belgium company (a
spin-off of Mentor). They have Art Builder, which enables you to design
in C and generates a hierarchical Mealy state machine in VHDL or
Verilog. Art Builder gives the designer control over bit widths and
other data path resources.
They also have Art Designer for architectural synthesis. This is a fun
tool to explore architectures. After you write your code in C, you
specify the number and type of functional units the tool can use. It
shows you where your bottle neck is and then you can throw more hardware
at it or redo your algorithm."
- an anon engineer
"For C-Level the behavioral issues seem well thought out. Their idea to
translate behavioral C to DC makes sense. Synopsys is going from the
high-levels down; C-level is going bottom-up. Weird. I think they did
learn a lot from their BC experience. Frontier Design has a simular
tool to C-Level.
Last year for Frontier.
My understanding is that Mentor Graphics is welcome to join the SystemC
steering committee, but as usual can't decide what to do because they
don't have a clue on where the market it going. C-Level Design made it
clear that they will support SystemC."
- an anon engineer
"In the Synopsys suite itself, I was not impressed with Synopsys SystemC
synthesis flows. Basically it appears that Syonpsys has taken BC and
added a C reader to it. As I stated before, we evaluated BC and MC and
found BC to be severely lacking in single throughput designs. In fact,
anytime you had to pipeline the design you were asking for trouble. We
ended up with MC (Module Compiler), because we were able to get our core
stuff done with it. So, I thought it would be great of C plugged into
MC. When I asked questions about MC and other Synopsys tools, such as
Formality, working with C, the answer I got was comical: "We have no
idea, you need to approach MC/Formality/Vera guys and ask them, because
we do not know." Hmm, it seems that for a company pushing C as the next
great solution, they should have answers to this. Very disappointing."
- an anon engineer
"Y Explorations Inc. (yxi.com) has a tool that allows designers to code a
mix of behavioral code, RTL code and IP blocks. It goes before Synopsys
in the flow and provides the inputs for Synopsys to use. The designers
get a list of functions or procedures for which cores are available, and
can add their own functions. These are behavioral; they have no clock,
power-on reset, etc. You can have any number of versions of the same
function. If you have more than one, they graphically show trade-offs
between area, speed and pipeline stages to help you pick which version
you want. The really interesting thing is that they automatically build
a shell around your core to put it in its environment. They will vary
buffer sizing, add registers, and even modify state machines to allow a
core to be inserted. They also generate the Synopsys constraints for the
IP. The tool also understands that arrays in your code represent
memories, so it automatically creates the state machine to control the
memory when you put an array in your code. They say their tool is
superior to creating Synopsys DesignWare because it's easier to describe
a part, it accepts hard cores (cores where you are buying a layout) and
multi-cycle cores, and it does all the glue logic and modification of
state machines for you. They say it is superior to instantiating an
RTL model of your core because their model uses fewer pins (it's
behavioral), does the glue logic on it's own, modifies state machines
as needed and generates Synopsys constraints automatically.
My perception last year was that their success would be dependent on
getting lots of IP vendors to describe their cores with YXI's tool. So
far, they have been unsuccessful in that. The bulk of their customers
are in Japan and most of them are using it to describe their own design
blocks for internal reuse. I checked into describing blocks like
[ design name deleted ] within their tool. One problem is that all
clocks must have a fixed relationship to each other.
At the physical synthesis demos I asked both Synopsys and Cadence if
they have plans to do anything like this. In both cases a light bulb
lit up above the AE's head and they scribbled a note to themselves."
- an anon engineer
"yXplorations? "Y" as in "Why" have a blonde LA actress try to explain
how to get from high level C code down to gates? Now that is my
question... :-)"
- an anon engineer
( DAC 00 Item 4 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Datapath from Arcadia Mustang, Sycon, Synopsys Module Compiler
DATAPATH IS ALIVE & WELL: Although it takes a special kind of hardware
designer to really tweak screaming fast datapaths (usually they work in
graphics chip companies), the advent of behavioral synthesis and other
supposedly higher level types of design have (ironically) done nothing but
*helped* the datapath tool business! People like tried-and-true design
techniques they fully understand over flakey we'll-try-to-do-it-for-you
behavioral. Arcadia Mustang and Synopsys Module Compiler are the old hands
here, with Sycon being the new tenderfoot. Homegrown is big, too.
"Arcadia sells a placer for datapaths. It get path constraints from
Synopsys. It can now do a mix of datapath and random logic. Sycon
sells a tool similar to Arcadia's. They say it is good at identifying
critical structures in your netlist."
- an anon engineer
"I'm glad you didn't even mention Arcadia Mustang in your survey, John!
This company absolutely has no clue. The person giving the demo and
the AE that attended couldn't answer half my questions. It's no wonder
that even though they are the only player in this space, barely anybody
is using them. People from other companies I've talked to wrote their
own tools to do datapaths, because they recognize that Arcadia is going
about this the WRONG WAY!"
- an anon engineer
"At the New Orleans DAC last year, we investigated Meropa (the precursor
to get2chip) and was pretty impressed with their technology. At that
time, Meropa included Behavioral Compiler style synthesis with Synopsys
Module Compiler style optimizations. For throughput of single designs,
which we do a bunch of, this was a key feature. Unfortunately, we did
not get to directly evaluate Meropa, because we moved our entire chip
flow to Module Compiler because it's one of the few EDA tools out there
that works as advertised."
- an anon engineer
"Fortunately, we have not had to enter the Physical Synthesis arena yet,
but my bet is on Synopsys, simply because they are the Great White Whale
and there is no Captain Ahab. I'll tell you John, we're struggling to
figure out how much of this Physical Synthesis stuff is hype and how
much is reality. Last year we completed a trial place and route of a
1M gate chip synthesized with DC and Module Compiler running 150MHz in
0.35u tech. With all the hype, we thought we were screwed. When it
came back from our vendor, we saw 20 some odd nets out with the worst
being less than 1 ns out. We were told by everyone that running so fast
at 0.35u would put us in spin hell, but that's not what happened. Maybe
when we get to 0.25, we will get hit. The truth is out there, and we
need to find it fast!"
- an anon engineer
( DAC 00 Item 5 ) ---------------------------------------------- [ 7/13/00 ]
Subject: CAE Plus 'Afterburner'
BACKWARDS TALKING AM I: Talk about contrarians, while everyone's trying to
get from C/C++ to Verilog to gates, CAE Plus is trying to go *from* Verilog
back to *C*! The reasoning is that C models can execute 1000x faster than
Verilog models, so why not translate your Verilog to C? (Gee, I thought
that's what VCS and NC-Verilog did, no?)
"CAE Plus sells a tool that goes in the opposite direction. If you do
initial design in C and then start coding in RTL, their contention is
that once RTL coding begins, the original C model now falls behind,
making regression very hard. They have a graphical entry tool for
overall event flow (generates C and Verilog), then you do the detailed
Verilog RTL and use their other tool to translate it back to cycle
accurate C code."
- an anon engineer
"CAE Plus 3 stars (out of 3 possible)
Afterburner
CAE Plus makes a tool which takes Verilog code and converts it to a
C-language model. Suggested uses for this tool are for verification
acceleration (this is similar to a compiled code simulator such as
VCS or NC-Verilog) and also for IP delivery. They claim that it
provides a better simulation speedup than VCS. My more immediate
interest was in its ability to deliver IP in a non-Verilog source
code format. CAE plus also provides some related wrapper scripts
which generate a Verilog instantation model for use in a user's
testbench which can then call the C-language functional model. The
generated model is cycle accurate. The conversion is not exactly
pushbutton as it seems to require that any individual memory (SRAM or
DRAM, not register) be replaced by a "synthesizable model" which can
be handed by the conversion tool.
I found this tool worthy of further investigation due to its ability
to deliver IP. I think further investigation by our Applications
Engineering group might be prudent to discover if this tool can be
used to deliver simulation models of our various ASSP products (or
key simulation interfaces) without the need to deliver Verilog source
code. Since our customers are asking for such models & our competitors
are in many cases providing this capability, it is important for us to
come up with some method of delivering functional models to potential
customers for evaluation. This is especially important for [ product
deleted ] due to the multitude of operational modes and complexity.
- an anon engineer
( DAC 00 Item 6 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Mentor Seamless, Eaglei & COSSAP, ArexSys, Cardtools, Foresight
THE OLD C SCHOOL: With all this hoopla about C-based tools flooding DAC,
everyone seems to have forgotten that Mentor's Seamless and Synopsys Eaglei
have been in this niche for quite some time now. The 1998 Dataquest numbers
give these 2 products a combined revenue of $19.1 million with Mentor taking
61 percent and Synopsys taking 37 percent market share. The estimated 1999
Dataquest numbers are $27.9 million with "closer to a 50/50 split".
"Customers ask for a lot when they're evaluating these 2 tools, but after
the buy decision is made, ask them and they'll say the deciding factor
was libraries. Mentor has a more complete C modeling library compared
to Synopsys, so this means Mentor probably won't support SystemC. If
they did, they'd lose their Seamless C model advantage."
- Gary Smith, Dataquest Analyst
"Mentor Graphics - I attended a suite demo on their Platform-based design
concept. From what I could make out, this is a tool which is early in
the planning stages and will not be available for sometime (there was a
demo of some GUI functions). I couldn't quite get the difference
between this tool and Seamless, so I asked the Product Line Manager this
question. His response, albeit a bit vague, seemed to imply that this
Platform-design tool was envisioned to be a front-end for Seamless and
allow for processor and memory subsystem architecture exploration and
connectivity along with other large IP blocks and components such as
processor peripherals, RTOS, verification environment needs, software
components such as protocol stacks, and even some user-defined blocks.
A graphical representation of the system can be built complete with
memory maps and addressing ranges. This could then be used to drive
Seamless in a co-verification environment."
- an anon engineer
"Cardtools sells software to help you pick microprocessors and RTOS (Real
Time Operating Systems) for your system design.
Arexsys sells a backplane and "architecture generator". You enter your
system function in SDL, VHDL, matlab, C or C++, and it allows you to
simulate them all together and helps you partition it into hardware and
software."
- an anon engineer
"Synopsys Eaglei. Mentor has taken the correct approach by purchasing
Microtech a few years back. Will Synopsys buy Wind River? I don't
think so. Will Eaglei prevail in the marketplace? Not without such an
acquisition. Transmodeling - a cool graphical front end to manage
C/RTL distributed simulations, etc. Cadence/Synopsys or someone needs
to buy them."
- an anon EDA salesman
"Foresight Systems (foresight-systems.com) has a high level tool designed
to be an executable spec. You enter your system function as a
hierarchical block diagram with C code behind the blocks, and initially
it's not even clear which blocks will be hardware and which software.
You do hardware/software partitioning and trade-offs within the tool.
The co-simulate with other simulators, such as Modelsim, Visual C++ and
Matlab."
- an anon engineer
( DAC 00 Item 7 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Cadence QuickTurn, IKOS, Thara, SimPOD, Axis, Simutech, Physim
BIG IRON STILL RULES: Although DAC is primarily a software show, one of the
big draws for those with large budgets are hardware emulators/accelerators.
One of the largest players in that field, Cadence's QuickTurn, didn't seem
to have that much to say at this year's DAC. But rivals IKOS and newbies
Thara, SimPod, and Axis more than made up for Quickturn's silence. And
oddly, the old hardware modeling group in Synopsys seems very, very quiet
this year, too. (Few mentioned them this year in their DAC reviews...)
"If you wanna verify analog parts with microprocessors and your HDL
design then use Aptix. If you wanna fast turn-around times use
QuickTurn. If you wanna a known user interface (applies for Modelsim
users) use Ikos."
- an anon engineer
"Ikos's transaction-level interface
- Works with CoWare's C-based environment but not limited to it
- Interface between testbench and design is at transaction level
(ATM cells, video frames, bus cycles) instead of pins/bit levels.
The lower frequency of data transfers improves runtime performance.
- Wish to standardize transaction-based API. There was an ST
sponsored meeting to promote the development of a standard
simulation to/from acceleration/emulation interface.
- How does that impact testbenches that must also work on
non-accelerated models? Must be able to replace calls to
HDL/Vera/Specman/C BFMs with transaction-based API calls.
- Design must be surrounded by emulated/accelerated bus model to
translate the transaction data into actual bus cycles.
Who will provide these models? Accelerators can handle behavioral
code but what if RTL code is required? IP-protection issues?"
- Janick Bergeron of Qualis Design (VG 1.13)
"Historically, Ikos has sold ASIC based hardware accelerators that
simulate with timing. Quickturn has sold FPGA based emulators that are
faster but do functional simulation only (no timing). Ikos and
Quickturn are now invading each other's territory. Ikos now sells an
FPGA based box that does functional verification only and an ASIC based
box that has timing but runs more slowly. Quickturn now has a
processor-based box, but it has no timing.
I got some Ikos lit that I'm not sure I understand. It sounds like you
can now interface with the box at a transaction level, rather than cycle
by cycle. The transaction is broken down into cycles on the box itself.
This allows the box to hum along without syncing up to the workstation
on every clock.
Simutech makes small accelerators that are resold by Quickturn.
Aptix sells boards that are sort of like an emulator, but you can plug
in actual parts as well. For example, if your ASIC is going to contain a
DSP core, you can buy an DSP part identical to the core, and emulate the
rest of your logic in the boards FPGAs. One box can emulate about 4M
gates (Quicturn has more capacity).
Axis sells an emulator box. It can emulate 10M gates plus has gobs of
RAM built in.
Dynalith sells iSAVE, a C language emulator for early algorithmic
verification before RTL is done. It is a very small box with most of
the C being done in a processor, and an FPGA to interface with the
outside world.
Physim sells a cheap board ($2500) that hooks a real part into a Verilog
simulation via PLI.
Tharas systems sells accelerators that use custom processors. They
currently do 2 state functional simulation, with 4 state coming. They
simulate 5K to 100K cycles per second."
- an anon engineer
"Tharas Systems 2 stars (out of 3 possible)
Hammer 50/32
Tharas makes a simulation accelerator box (Hammer 50/32) which works
with your simulator (currently VCS is supported with others to follow
including VHDL support by next year.) Most of the Verilog language
can be mapped into the acccelerator box leaving only a few items outside
that must run on the event-driven simulator running on the host
workstation. Even many non-synthesizable constructs sush as $display
or $monitor statements can be accelerated. The boxes are still somewhat
pricey $200K for a 4Meg gate system; $280K for an 8Meg gate box), but
the cost is better than other accelerator/emulator boxes. Two versions
are sold; one with the capacity for 4 million gates and the other
capable of handling upto 8 Million gates.
The box itself uses a special arrayed processor which is mapped into
handling the various logical tasks. Each box also contains a Gbyte of
memory for handling various memory arrays and registers. The advantage
of Thara is that it uses 3rd party simulators rather than their own
proprietary simulator."
- an anon engineer
"Axis Systems 2 stars (out of 3 possible)
Xtreme and Xcite 2000 H/W
Axis makes a suite of products in the hardware acceleration area and
their newest product Xtreme claims to combine simulation acceleration
with emulation within the same box. Xtreme can handle upto 20 million
gates, but beware of the cost for this capability. The older product
line (called Xcite) consisted of PCI-based cards which could plug into
your SUN workstation along with the necessary partitioning and control
software. The cards would provide a H/W accelerator for synthesizable
parts of your simulation environment.
Newer Xcite versions consist of a standalone box which allows one to
dynamically switch between running all events within the host computer
and moving as many events as possible to their special Re-Configurable
Computing (RCC) elements which provide the acceleration. In this mode,
the non-synthesizable constructs within the testbench remain in the
software simulator and are not handled by the hardware in the box. The
RCC's are synthesized into Altera FPGA's and are used to accelerate
the logic events. The logic is mapped into the RCC's according to an
RTL-level mapping and the simulator retains visibility to all signals
at the RTL level (not the gate level like many emulator boxes). A very
interesting capability that was shown in the demo was the ability to
start a simulation in S/W, switch to the accelerator box after the
initialization sequence, run until an error was found; switch back to
the software simulator, and dump waveforms for specific hierarchy
levels of events that occurred in the PAST without having to save the
entire state of the device to start with. I can't tell how many times
I wish I had had the capability to dump waveforms of critical events
after the timeframe of an error had passed. This capability is called
VCD-On-Demand and works in the simulation, acceleration, and emulation
modes. Target speeds for acceleration are around 10-100K cycles/second
and greater than 300K cycles/sec for emulation mode.
Drawbacks to this product are the reliance on their own version of an
event-driven Verilog simulator which they call Xsim. Some initial
ramp-up time is needed to map the DUT and testbench into these products.
This time could take anywhere from 1 to 10 days depending on the
complexity of the design and testbench. Changes to the design are
quicker thanks to an incremental compile capability. List costs for
these platforms range from an Xcite system for 1Meg gates at $300K;
a 2.5 Mgates Xcite box at $430K, and a 2.5 Mgates Xtreme box $600K."
- an anon engineer
"Oh, nothing world beating here. LogicVision looked good for Memory Bist
and maybe Logic Bist. Chrysalis works and will probably be here for a
while. You didn't mention Axis and they probably have the most
interesting accelerator/debugger at DAC."
- an anon engineer
"Our latest ASIC interfaces to multiple PowerPC microprocessors. In the
past we have used Verilog BFMs to verify our processor interfaces, but
this design is a multi-processor system and we needed a way to verify
the cache coherency. A BFM does not include a cache model or cache
snoop responses.
We chose to use the hardware modeling product from Simpod which uses
the silicon as a model. I'm not going to give all of the info, but
basically it allows us to use a chip just like any other BFM, giving
Verilog task calls like
$read(address, transfer_type);
and
$write(address, data, transfer_type);
from a Verilog testbench. Since it uses the silicon, it has the cache,
we can use it to verify snoop responses from the PowerPC. Besides the
ordinary $read and $write calls the model has a Verilog task interface
to set the state of a specific cache line in the PowerPC. This allows
us to do something like:
$cache_operation(address, state);
to set the cache line to an exclusive, invalid, or modified state. Then
our ASIC can do a bus transaction and we can see the snoop response of
the PowerPC. I don't want to get into a long discussion on cache
coherency, but Simpod gives us the model we need and we don't have to
spend time creating more complex BFMs for multiprocessor cache coherency
testing.
Simpod is an interesting new spin on the old concept of hardware
modeling. Using a hardware model like a BFM is nice because we don't
have to deal with any software the way you do with a full funtional
hardware model. The BFM testbench interface is all you need. I would
highly recommend it, with the following cautions. The company is very
small. They try hard, but if you don't have the bandwidth, things will
start to slip. We experienced delays in getting the hardware when it
was promised. If you understand the size of the company and that you
are dealing with hardware (like one of the engineers was moving the
Simpod system on his desk and the socket which holds the PowerPC broke)
it is a good way to go."
- an anon engineer
"We make extensive use of accelerator tools, mostly Quickturn/Cadence.
Quickturn had nothing new to tell me. IKOS' co-simulation environment
could be useful. The future will tell in our case. I was most
impressed with Axis this year. They make some claims that were
definitely impressive. We are definitely going to be looking into
this company and their acceleration tools."
- an anon engineer
"Biggest Lie? Axis Corp said they guarantee compiles in less than 1
hour. This is part of there demo suite presentation. When you dig a
little deeper you find out how they satisfy this guarantee. They use
a PC farm for their compile. It might only take one hour to compile
but you need 24 PC's for a 3-4 million gate design. Bigger designs
require more workstations if you're going to stay under an hour."
- an anon engineer
"Cadence/Quickturn didn't provide any information that we didn't already
know. I was hoping to hear more about Powersuite but that was not
mentioned. Cadence talked about Cobalt and Radium. We are currently
evaluating the Radium tool with the Powersuite software."
- an anon engineer
"Axis Corporation
This was definitely the most exciting presentation I saw. The Axis
Xcite 2000 should offer us Cobalt speed at one tenth the cost. They
also offer vcd on demand, which would do everything we hoped to get
from Powersuite. They recommend working with the Debussy tools,
which we are currently integrating into our simulation flow. This
tool should definitely help our productivity. Instead of running
simulations over and over for the correct traces we just run once. If
there is a failure the designer can debug from their desk. This was
the hope for powersuite but we have not seen that ability yet. All
things are not a perfect fit for our current simulation flow and this
tool. It would require some work to start using this tool. I think
we should certainly start looking into making this happen."
- an anon engineer
( DAC 00 Item 8 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Synplicity 'Certify', Synopsys 'FPGA Compiler II'
GUILTY AS CHARGED: I messed up. I forgot to ask about FPGA tools in the
survey! Managed to scrounge up two quotes, but I'm ashamed to say that I
couldn't find any Exemplar stuff. It's not their fault -- *I'm* the one who
messed up by not asking! Aargh.
"What about FPGA Synthesis? Bad John! You didn't survey on it! I can
sum it up as this: FPGA Compiler II mostly the same as last year, except
with BLIS (which I have had in DC for years). Synplicity, appears to be
delivering on their roadmap. After seeing the roadmaps this year, I
really question whether FPGA Compiler II will be around (except for it
being a freebie out of the FPGA vendors box). With FPGAs finally
starting to make inroads into ASIC territory, I cannot figure out why
Synopsys continuously ignores this product area. Absolutely crazy!"
- an anon engineer
"Synplicity:
I had a demo regarding the Certify tool. This is used for compiling our
design into multiple FPGA's for prototyping our ASICs. The inputs would
be the RTL and a board constraint file. This is not a simple plug and
chug tool. It would require board design and someone to work on the
compile to FPGA. I think that prototyping is a step we are going to
have to take. Now that we have the CMP architecture we can plug a
prototype into the system and get pre fabrication hardware experience.
We could save lots of money on re-spins and fibs. The current FPGA
technology is approaching our requirements and might have already
arrived. For example 90 MHz clock speed with HSTL drivers. We must
look into this further."
- an anon engineer
( DAC 00 Item 9 ) ---------------------------------------------- [ 7/13/00 ]
Subject: Mentor Renoir, View/Summit Innoveda, TransModeling, Escalade, XTEK
WHAT EVER HAPPEN TO ESDA?: A few years ago, ESDA tools ("Electronic System
Design Automation" -- a fancy acronym for state machine bubble diagram
graphical design entry tools) were all the rage with Summit, Escalade,
i-Logix, Speed Design, and Mentor's Renoir. I even held an ESDA Shootout
a few years ago at a DesignCon. The results were embarrassing and very
interesting at the same time. (Dig in the DeepChip archives if you want a
fun little read.) Now all the ESDA players have all but gone out of
business or mysteriously disappeared. Summit merged with ViewLogic to
create a company called "Innoveda" and the biggest impact that made in the
113 responses I've looked at in the DAC survey is complaints about their
pool noodle giveaway. Nobody discussed their EDA tools and most even forgot
the name of the company giving out the pool noodle! Mentor seems to have
won this war not by skill, but by attrition and customer apathy. At last
year's DAC, rumors flew around that Mentor was pulling all R&D out of
Renoir. This year, Mentor bought a failing Escalade and that was it. Into
this grey dead space, one new start-up, TransModeling has popped up. Only
two people noticed.
"Who on EARTH thought that a 6-foot-log foam "Fun Noodle" would be a
good giveaway?? I don't remember seeing any on my plane ride back home.
Everyone LOVED the volleyballs, but they didn't have a whole lot to do
with C-Level's product."
- an anon engineer
"To me the most ill-thought-out freebie was the chair from Altera or
the pool noodle from Innoveda. Both were useful things, but a pain in
the butt to carry around."
- an anon engineer
"B) Stuff I saw but did not get:
ViewLogic/Summit - those foam tubes for floating in a pool
DAC conference - yellow cooler bag"
- an anon engineer
"Worst: Xilinx Passed out the same stupid freebie it did last year
Most Ill Though Out: The Pool Noodle was cool but very hard to take
on a plane.
Best: I did not see anything that beat the Helicopter from last year."
- an anon engineer
"I thought those styrofoam "noodles" was kind of dumb, although I forget
who gave them out. By Wednesday, I had an irrational desire to get one
of C Level Design's volley balls, after seeing everyone else with them."
- an anon engineer
"We're using Escalade DesignBook 3.8c on Solaris 2.6. This has several
important bug fixes and I would recommend using it rather than the
previous versions. It was available for download from the Escalade
web site. However, in the wake of the recent acquisition of Escalade
by Mentor, the download page is no longer working. You will probably
have to call Escalade support, (408) 654-1600, to get the upgrade."
- John Vincent of Kodak (ESNUG 354 #11)
"TransModeling sells a tool that accepts diagrams like Summit's tool, and
outputs C++ for the CynApps tool. These diagrams are synthesized into
C++, which is then synthesized into Verilog, which is then synthesized
into gates.
X-tek seemed to be trying to do a similar tool to TransModeling, but
really didn't have much of a product yet. Their tool used Perl for the
top level simulation and used a very simple, single type of diagram
(e.g. nothing different between datapaths versus state machines)."
- an anon engineer
"3) Transmodelling
Distributed run-time simulation environment. You capture the
top-level in their GUI and assign various blocks to various
workstations. They handle the communication and synchronization.
Can handle event-driven interfaces but each block must advance with
the same timestep. Best performance is on cycle-based interfaces."
- Janick Bergeron of Qualis (VG 1.13)
"Novus Debussy
Like NC-SIM, the Debussy tool will be integrated into our simulation
flow over the summer. It is a wave viewer as well as debugging tool.
Most EDA venders were proud to announce that they recommend the Debussy
tool for their debugging environment. Some designers are currently
using this tool in [ co. location deleted]."
- an anon engineer
( DAC 00 Item 10 ) --------------------------------------------- [ 7/13/00 ]
Subject: Cheaper HDL Simulators from Fintronic, Aldec, ZOIX, FTL Systems
DEMANDING EQUAL TIME & CONSIDERATION: In the survey I sent out asked about
Synopsys VCS, Cadence NC-Verilog, and ModelTech by name. I forgot some of
the others and one CEO is hopping made at me:
"Unfair! I noted with surprise that you are asking for feedback on
comparing VCS versus NC-Verilog and even about ModelTech's Verilog
simulator when the best Verilog simulator available is Fintronic's
Super FinSim, which you did not mention.
My surprised is caused by (1) the fact that you know Fintronic since
you visited our company in 1994 and (2) the fact that you were on a
panel at DAC in 1996, which discussed Viewlogic's removal of VCS from
an independent benchmark conducted by John Hilawi in London, because
VCS was MUCH slower than Super FinSim.
Since 1996, Fintronic continued to lead the technological progress in
Verilog simulation, and Super FinSim became even better with respect
to its competition:
- Fintronic was the first to introduce 64-bit Verilog simulation
with first sales in the summer of 1996 and simulating 16 million
gates in 1998.
- Fintronic argued and implemented mixed cycle and event driven
simulation at a time (1995) when Cadence and Synopsis were arguing
in favor of pure cycle simulation, only to adopt Fintronic's
position in 1998.
- Fintronic was praised in writing in 1998 by a member of Cadence
Berkeley Labs for presenting in 1997 at the NATO Summer school in
Il Ciocco, Italy, a much better solution for embedded processor
simulation than that developed at Cadence Berkeley Labs. Indeed,
Fintronic and its partner VaST systems announced soon after (before
IVC 1998) the ability to simulate 100 million intructions per
second three days before Cadence announced 5,000 instructions per
second.
- Fintronic was a pioneer in incorporating formal methods as part of
event-driven simulation: dead code elimination, source code
transformation, etc.
Super FinSim, which for a while (perhaps even today) was more compatible
with Verilog XL than NC-Verilog, is used by companies who care about
performance and the quality of their Verilog simulation and who depend
on the success of their products.
Fintronic continued to lead the Verilog simulation field at DAC 2000,
where it introduced a product available today, called FinFarm. FinFarm,
which was announced at DAC 1999, is a simulation farm that allows one
engineer to manage hundreds of simultaneous Verilog simulations, by
providing tools for (1) launching, (2) monitoring, (3) collecting
results, (4) processing results, and (5) notifying the appropriate party
about the results.
It is not by accident that Transmeta Corporation, which announced in
January 2000, its Crusoe chip set, is using numerous licenses of
Super FinSim."
- Alec Stanculescu, President of Fintronic USA
"What would a company named ZOIX make? Remarkably, I was the only one
stopping by the booth who assumed they had a simulator to sell. They
sell a compiled code Verilog simulator (like NC-Verilog) that can
simulate different blocks on different processors. They say that
splitting up a simulation based on modules is just as good as running a
sophisticated min cut set algorithm on it to determine how to partition
it. Their tool is still in beta.
Fintronic sells a cheap Verilog simulator that they claim is faster than
Cadence NC-Verilog. It runs on PCs or 64 bit Solaris.
Aldec sells a super cheap single kernel VHDL/Verilog/EDIF simulator that
runs on NT or Linux. They say a hardware/software co-verification tool
is coming.
FLT Systems also sells a cheap VHDL/Verilog simulator.
Arexsys sells a backplane that allows many simulators to work together."
- an anon engineer
( DAC 00 Item 11 ) --------------------------------------------- [ 7/13/00 ]
Subject: Cadence 'NC-Sim', Mentor's ModelTech 'ModelSim', Synopsys 'Scirocco'
HIGH END VERILOG & VHDL SIMULATORS: As usual, Cadence, Synopsys, and Mentor
strutted their stuff in the Verilog/VHDL simulation markets. These are the
guys who make the big dollars sales in this niche. From a marketshare
viewpoint, Cadence NC-Verilog and Synopsys VCS are in a dead heat with each
other fighting for supreme control of the compiled Verilog market. For dual
language, ModelTech rules, but users are also impressed with Cadence's NC-Sim
product, too. There wasn't much customer reaction to the new Synopsys VHDL
simulator, 'Scirocco', at DAC, either.
"Don't know much about other simulators than ModelSim for VHDL. We can
live with it though it is sometimes painful. Also heard good things
about NC-Sim from colleagues in Sweden."
- an anon engineer
"Modeltech is still the only dual language simulator that really works
and has PLI, VCD. I don't see anything competitive yet."
- an anon engineer
"I see more and more of ModelSim-Verilog at every company I go to.
ModelSim has dominated the VHDL simulation market for years, and they
are now making tremendous inroads in the Verilog simulation market. It
is a good product, and reasonably priced."
- Stuart Sutherland, independent PLI consultant
"Modeltech is nice (Mixed Language) but a bit slow and has a nice GUI.
We are using it now for those reasons. Cadence NC Verilog is the
fastest according to our benchmarks - we will most likely be using it
in the future."
- an anon engineer
"After extensive evaluation, we are moving to Cadence NC-Sim. We are
primarily a VHDL house, but recognize that we cannot live in an
uni-language design world. The closest mixed language competitor was
Modelsim, but in overall performance, NC-Sim was the way to go. FYI,
we looked at Synopsys Scirocco, which we would have gotten for free to
replace our old VSS licenses, but were not impressed with it at all.
Maybe in the future this cycle-based approach will work better, but
right now it has a bunch of issues."
- an anon engineer
"We've been big ModelTech fans for a long time. ModelTech lets you mix
Verilog and VHDL code seamlessly. And it runs on all HW platforms.
We're not looking to change simulators anytime soon."
- an anon engineer
"The Synopsys VCS looks like it's caught up with NC-Verilog and could be
a winner."
- an anon engineer
"Looked at Synopsys' new Scirocco VHDL simulator
- they claim it is as fast or faster 'the competion' in their tests.
- no PC version, but LINUX version is on its way.
- VCS still faster on some stuff, but not all.
- GUI is from Virsim. Has the basic features. Can drag and drop.
Can spread out waveform to see delta cycles like SignalScan
(have to turn on and files are larger). Seemed much more stable
than VSS GUI.
- integrated with Vera, VCS, Eagle and some memory tool. Were
using a Qualis code as an example.
- All new under the hood, not a VSS derivatives.
- VHDL/Verilog combo sim mode.
The demo guys were not sure how the VSS/Scirocco connection worked, but
they say it is single kernal, with two separate license hooks. I asked
how the 4 state (Verilog) to 9 state (VHDL) was handled and they said
they would get back to me. I got an email on it a couple days later and
they said that right now it is hard coded into the kernal, but (maybe
per my suggestion) they were going to move it to a VHDL package
(resolution function) so that it could be modified by the users."
- Peet James of Qualis
( DAC 00 Item 12 ) --------------------------------------------- [ 7/13/00 ]
Subject: Synopsys NDA Suites On VCS, the PLI, and C
PLAYING BOTH SIDES: While there's a nest of new C-based EDA tools still
trying to prove themselves, if you went into the Synopsys NDA suite at
DAC you would have seen how their VCS R&D guys have crafted VCS to be
able to read in C *without* going through the PLI. (Although bypassing
the PLI did seem to piss off one consultant I know...)
"NC-Verilog has caught up with VCS in performance and far surpassed VCS
in reliability. As a consultant and as a trainer on Verilog HDL and
PLI, I work with a lot of companies, both large and small. Some of the
large companies I work with are dropping VCS and switching to NC-Verilog
as their main simulator. Performance is part of the reason for the
switch, but IEEE 1364 compliance is the big reason. Despite all the
marketing and sales bull from Synopsys, VCS is not even close to being
IEEE compliant. VCS was created following the 1990 OVI Verilog
standard, and has never been updated to the IEEE 1364-1995 standard. In
the area of PLI support, VCS is the worst product there is."
- Stuart Sutherland, independent PLI consultant
"I attended Synopsys' DAC presentation describing their new Direct-C
interface being built into VCS. This is long overdue: replacing the
bulky slow PLI interface with a native interface which will allow
calling C or C++ functions directly from Verilog source, allowing easy
string manipulation and file I/O.
Their "CModule" portion allows instantiation of C or C++ modules right
in the Verilog code. They have added sufficient concurrency (such as
"always @") to allow C/C++ system modeling to be used in a hardware
context. Scheduling and building the golden reference will remain a
challenge, but at least this gives us more flexibility and performance.
Synopsys claims these functions will use VCS's direct kernel interface,
be an integral part of VCS, and be delivered as a free upgrade. We
will certainly give these new features a try."
- an anon engineer
"Here are my obeservations about the VCS advanced technology demo.
We are users of Verisity's Specman tool and last time we bought
simulators we did not purchase any more VCS licenses, although we
do use our current VCS licenses. I think to get the simulation
performance to the level that is needed to the next generation
chips, we'll need two things:
* Both the Chip and the Test Environment are in the same
language (C/C++)
* Make the interface between the high level verification
environment language and the Verilog invisible. Both from
a performance and ease of use perspective.
The second item above is what Synopsys' VeriC/DKI interface attempts to
tackle. In a nutshell the new interface extends the Verilog language
(non-standard) to allow the user embed C functions in two ways. One
is to create "extern" functions which can be used to assign to Verilog
registers. The other is the ability to create "cmodule" which is to
have a Verilog module front end (inputs, outputs, inouts) with a C
backend. This allows the user to create pieces of C code that know
about time. Both of these use VCS' Direct Kernel Interface (DKI) which
if I understand this correctly allows C object files to be directly
linked with Verilog objects. They have ported their Covermeter tool to
use this interface and it appears that they have gotten significant
performance improvements over Covermeter with a PLI Interface.
This seems to be a very exciting technology and might be able to give
the people talking about a pure C++ environment a run. Also, as some IP
modules start to be developed VCS now has a very good story on
integration of mixed Verilog/C++.
That being said, I was extremely dissapointed that when I asked if any
outside PLI vendors were looking at porting their tools to use the
VeriC/DKI interface, I was met with blank stares. It was almost
inconceivable to them that someone would use a non-Synopsys verification
tool. I can understand that some of the companies (Verisity) directly
compete with their product offerings, but if they were serious about
finding designers to test out these new technologies, some the outside
tool vendors would be perfect. This would also give them a sales
advantage to say that TOOLX works better with VCS that NC-Verilog. In
general Synopsys seems to think that they have the same advantage in the
verification space as they do in the synthesis space, and without other
PLI tool vendors asking Cadence for a similar interface, they will never
be able to push this foward as a standard.
If Synopsys had said that they were working with outside tool vendors to
get them to use this interface I probably would have voted it one of the
most interesting Suite Presentations at DAC. As it is, that award goes
to Verisity. Last year they presented technology that they delivered in
the form of their interface to Cadence FormalCheck which looks pretty
cool and allows E code to be parced for Assertions for FormalCheck.
This year they presented a tool called Coverage-Maximizer which if it
works will analyze your Verilog source code and your E environment and
do two things: 1) Suggest Functional Coverage points within the design,
and 2) using data collected on those points create an E file that will
constrain your environment in a new test to attempt to hit those points.
This technology is very green and it is unclear how well it will scale
to very large test environments, but it could be really useful to
automate test writing."
- an anon engineer
( DAC 00 Item 13 ) --------------------------------------------- [ 7/13/00 ]
Subject: Cadence 'Verification Cockpit'
A LITTLE HIGHER: Not quite a Verilog/VHDL tool and not quite a pure play
C/C++ tool, Cadence again showed their Verification Cockpit tool at this
year's DAC to high reviews.
"Cadence 3 stars (out of 3 possible)
Verification Cockpit
The Verification Cockpit was first announced just over a year ago. But
with the latest enhancements and the bundling of the tools, I think
Cadence has put together a good story for the verification engineer.
The Cockpit integrates the Signalscan Transaction tools which provide a
higher level of abstraction for bus or protocol transactions, a code
coverage tool, a "lint" tool for RTL purification, and a new tool called
TestBuilder which allows a verification engineer to bind C/C++ testbench
code into the verification environment. TestBuilder supports C++
libraries which have been generated to support the four logic states
for boolean logic. A number of special constructs such as smart queues,
queues, semaphores, and other high-level constructs are also supported.
In addition, another tool called TxE provides so-called functional
coverage metrics which allows the designer to specify certain test
parameters which are monitored during the simulation run and reported as
pass/fail at the end. Some of the GUI reporting methods are a bit of
fluff and can create "manager-ware" charts, but the TxE tools does in my
opinion provide some value to the verification engineer.
Compared to Synopsys' VCS plans, I think the Cadence tool has a bit
better overall infrastructure with the transaction capability and the
built-in "smart" data structures. However, I think the VCS approach for
adding C/C++ code to the simulation environment is a little better than
what Cadence has done with TestBuilder. TestBuilder and the transaction
stuff is currently only supported using the NC-Verilog similator which
is a drawback."
- an anon engineer
"I saw the demo for Cadence's Verification cockpit. It's a combination
of a code coverage tool, a linter, a transaction viewer, a testbench
authoring tool and a "functional coverage" tool. The code coverage
tool is line coverage only - pretty rudimentary. The linter is
currently Verilog only. It is programmable and comes with synthesis
and Reuse Methodology Manual rules. The test bench authoring tool is
currently Verilog only and takes C++ as input. It uses transactors and
C++ code to drive your simulation. The assumption is that a low level
hardware guy enters the transactor data then some high level system guy
enters the C++. The "transaction explorer" displays errors at a higher
level than ones and zeros. For example, it will say where within a
packet an error occurred. The functional coverage tool attempts to tell
you which input to output paths were exercised. If input creation and
output testing were called within the same C++ function, it associates
the two and says that path was tested when that function is used. These
tools are all extra buttons on the existing Simvision GUI."
- an anon engineer
"TestBuilder, a C++ based testbench library within the Cadence
Verification Cockpit, lets users develop hardware testbenches. Cynlib
is a C++ class library, facilitating hardware description directly in
C++. With TestBuilder and Cynlib, you can design and verify the design
in C++. You can then synthesize the design's HDL representation using
CynApps' Cynthesizer for RTL synthesis by standard design tools."
- Jim Lipman of TechOnLine
( DAC 00 Item 14 ) --------------------------------------------- [ 7/13/00 ]
Subject: The Superlog Alternative To The C-Or-Verilog/VHDL Wars
NOT C, NOT VERILOG, IT'S SUPERLOG: Mixed in with the C-or-Verilog/VHDL
wars is a third option that should be noted: Co-Design's Superlog. Superlog
is a new HDL that's an extension of Verilog. Superlog was announced at last
year's DAC and I'll be the first to admit that I was part of the crowd
laughing at the idea of Yet Another Hardware Description Language. I was
in good company. A lot of people doubted the need nor use of a new HDL.
But now that it's become more real, a number of doubting designers are
giving Superlog a decent second look because not a replacement for Verilog,
but a superset of Verilog. That is, Superlog runs legacy Verilog code as
is; Superlog just allows new code to be written that does *more*. Now, the
barrier to acceptance of Superlog has moved on to the more practical
concerns of openness and no tools around to synthesize it.
"I spoke to the Superlog people about C and Verilog. They have a
different approach to C, extending Verilog to give C features. This is
easy from the HW person's perspective, while still letting SW code run
with it. They plan to make it open once they have established some
support with a few customers."
- an anon engineer
"The SystemSim tool from Co-Design looked really cool. I got to see some
real Superlog code, too. It seems like a nice language for doing high
level system design -- the only thing that has me scared is that being a
new language, an INCREDIBLE barrier exists for it to penetrate people's
world -- "where are the tools?" It will suffer from the same problem
VHDL suffers from, namely: "Well, you can *model* that in VHDL, but you
can't synthesize that code." for many years I fear."
- an anon engineer
"We are doing a lot of simulation with Verilog-XL and we were a Beta site
of Superlog. The solutions seams to work fine and even the combination
with our C++ library worked. But they still have to do a lot of work,
especially for making the whole thing synthesizable. I personally
believe that a combination of Verilog and SystemC would have more
benefits, because I think that with Superlog you are still stuck at the
event-driven simulation approach."
- an anon engineer
"I've looked at a number of the C-like EDA products, but have not had an
opportunity to be involved in a project using them yet. But after
looking at what these C-like EDA products have to offer, and at their
syntax and semantics, SuperLog is the only product that I want to try.
SuperLog takes what HDL's do best, and enhances the capabilities,
instead of trying to replace the HDL with C. With SuperLog, I can
model hardware the way hardware works, and if -- and only if -- I need
more abstract programming, I can also access the capabilities of C. I
suspect the next generation of Verilog will take a very similar approach
as SuperLog."
- Stuart Sutherland, independent Verilog PLI consultant
"Superlog is great (Combining VHDL constructs w/ Verilog and simplifying
Verilog for FF's, etc.) We will most likely use it in our next
generation uP."
- an anon engineer
"For modeling, C is not yet fully usable and way to high level for uP/uC.
For Testbenches, C is ideal and for cycle accurate C-models. Superlog
is the best way to go right now (and not too high for most designers.)"
- an anon engineer
"Since we use VCS, I got the update for that, but didn't look at other
simulators. I like where Synopsys is going with VCS. Faster, as
always. Supporting C, for tasks/functions and modules, without PLI.
I think Superlog looks very nice. They cleaned up Verilog in a lot of
good ways. I also like Co-Design's simulator, SystemSim. It integrates
C nicely. It can do interpreted or compiled, but the speed tradeoffs
aren't as bad as normal. However, I don't think it's quite compeling
enough to dump our existing VCS investment here. Now, if I were
starting from scratch at a new company, they'd have a serious shot at
selling to me."
- an anon engineer
"Superlog has some interesting functionality that makes it closer to our
own C++-based simulation environment. As such, it may be a better
middle-of-the-road solution between existing Verilog, and the
SystemC/CynApps approach. I heard a lot of pooh-poohing about Superlog
from other hardcore Verilog users, though."
- an anon engineer
( DAC 00 Item 15 ) --------------------------------------------- [ 7/13/00 ]
Subject: Synopsys Vera, Verisity Specman/'e', Chronology RAVE, SynaptiCAD
THE PERFECT STORM: The three way stormy battle between Verisity's Specman,
Synopsys VERA, and to a lessor extent, Chronology's RAVE, shows no sign of
concluding any time soon. It might moot though, if C/C++ kills off the
whole concept of proprietary functional testbench generator languages.
"I made the mistake of scheduling the Vera and Specman demo's back to
back. I can't for the life of me tell you the differences between
the two tools. They even spent 5 minutes in each "demo" talking about
the Dataquest numbers. Based on these two "demos" the main difference
between the two tools is that the Synopsys people say the Dataquest
report is old and out of date and the Verisity people quote the report
as gospel. Verisity had an alter in the back of the booth where they
burn incense to the Dataquest Gods."
- an anon engineer
"Rumor is that actually Synopsys is backing away from VERA, and putting
emphasis on SystemC (which on it's own will kill VERA). Lets see us
substantiate that. In not so many words a Synopsys pre-sales tech guy
admitted this to me."
- an anon engineer
"I got a real kick out of Synopsys trying to have something to say to
respond to Verisity's claim of a Dataquest 77 percent market share.
Bottom line to Synopsys' claim about having more installed seats of
Vera than Specman is that there are a lot of Synopsys sites with bins
of free licenses floating around. You can have the installed license
specsmanship award, Synopsys, but I'd look hard and long at the product
people are actually spending $$ on.
Beyond the "why I'm best" chest pounding, I still am looking for an
articulation of a solution that allows me in mixed VHDL/Verilog to
verify major functional blocks in unit level test benches, then also
migrates directly to verification at the system (chip or multichip
'board') level. I've yet to see a compelling marketing (or
engineering) presentation of such a solution. A full top-to-bottom
verification solution still seems to require a lot of internal
innovation. I'm waiting to see some reality in all the talk about
virtual verification."
- an anon engineer
"Chronology 2 stars (out of 3 possible)
QuickBench
Quickbench is yet another testbench authoring tool which allows one to
build testbenches at a higher level of abstraction. Quickbench provides
a layered approach whereby Bus Functional models called "transactors"
can be derived from timing diagrams captured by the designer using the
TimingDesigner tool (we already use TimingDesigner for documentation
purposes for drawing waveforms in our databooks). A special language
based on Perl called RAVE can be used to interact with the transactors
and drive stimulus or compare captured results. Most temporal activity
is performed in the transactors while the higher-level 0-time
generation/comparison is done via the RAVE language. The tool seems
comparable to some more well-known solutions from others. However, it
does not yet support C/C++ support but the claim is that it is on their
"roadmap" for future products. No functional coverage capability is
provided yet either. I've rated this tool only 2 stars because of two
things; the lack of C/C++ support and the fact that it requires
TimingDesigner to generate the BFM models. Like other tools, there is
another proprietary language to learn even though it is based on Perl.
But I did like this tool because it appears to me that it could be
useful for block designers in creating a more robust block-level
verification environment.
As chips grow more complex, chip-level testbenches can become huge and
require enormous amounts of CPU power to to run. I believe that in some
cases, we should now look at generating more sophisticated sub-system
testbenches to conduct more of the verification at lower-levels. The
advantage of Quickbench is that more ASIC designers are probably
familiar with Perl than with C++ and it may be easier for them to use
this tool."
- an anon engineer
"The biggest lie I heard at DAC was that VERA is the number 1 test bench
automation tool. It was by a Synopsys sales person with an acompanying
slide in a Covermeter Demo. They never even bothered to offer data
(like VERA had the most sales in Fiji or something), they felt it was
true because they said it was true. Arrogant."
- an anon engineer
"Chronology
- QuickBench will automatically generate bus models and test harness
that follow our methodology from bus cycles captured using a
timing diagram editor (old stuff).
- Rave is their verification language and is an extension to PERL.
Sits on top of the test harness and calls Quickbench-generated
transaction procedures. A nice enforcement of proper testbench
architecture practices.
- Good random generation but no functional coverage. If RAVE can
stand alone, without the QuickBench-generated harness, and
interface to user-written bus-functional models or directory to
the bit-level interfaces (allowing one to write bus models in
PERL), it can be a serious contender to VERA & Specman.
PERL suffers from the same controllability and communication problems as
C/C++ for parallel threads."
- Janick Bergeron of Qualis Design (VG 1.13)
"I don't think any of the new testbench generators, Testbuilder from
Cadence, iControl from iModl, Testbencher Pro from Synapticad, or
Quichbench from Chronology, are quite mature enough yet. We're going
to need something like this soon, and I think we're going to stick with
Specman and Vera for our eval. Testbuilder and Quickbench look like
the best of the new ones, while Testbencher Pro and iControl are simply
not there yet."
- an anon engineer
"Verisity has the majority of this market, with Vera in second place.
Verisity sells Specman, a tool that takes a description of your design
in their "e" language and automatically generates test benches. The e
language was drastically revised last year because it was very hard to
master. The big problems with selling this tool are that your users
have to learn another language and now have two versions of the design
(RTL and e) that they have to keep in sync. Acceptance has been slow.
They have come up with a brilliant new business model. They have teamed
with IP providers. Soft IP (i.e. RTL code) is often designed to be
customizeable by the user. The question is - how do you know you
haven't screwed it up while customizing it? ARM, MIPS, TI and LSI now
ship IP with a free copy of "invisible Specman". The IP provider has
described correct function of the IP in Specman, and the buyer then gets
a limited license to check his modified design. This way, the buyer
doesn't need to learn e or describe the design for the tool. Mentor and
Cadence are now licensing the language - looks like it may become a de
facto standard."
- an anon engineer
"Well, I'm hoping that Vera and Verisity will be around next year, but
I'm not too sure with that whacky C push going on."
- an anon engineer
"Our colleagues in [ deleted ] already use Specman and we are going to
introduce it soon. The fact that Mentor and Cadence are also adapting
tools for the use of the 'e-language' encourages me that this language
is a success. I unfortunately forgot to look at Vera at DAC, though it
was my intention. 'Rave', I would forget about."
- an anon engineer
"Synapticad: Most improved. Last year their stuff was sort of primative.
The Verilog that it spit out was pseudo VHDL with some the negatives of
VHDL. No fork and join and stuff. They have cleaned up and added alot.
Does not quite follow the Client server methodology, but looks like it
could easily be done. I bet the implement it soon. The BRM's have an
entity/arch pair for each abstracted task (write, read) and then those
are put in a package. No upper level vera/E type code to do thing. They
use perl to do stuff at the top level. The do not use records to pass
signals, but they do have a group of signals to pass through info to
sync things up. No VHDL fork and join implementation. Use a harness
and testbench with no I/O."
- Peet James of Qualis Design
"SynaptiCAD - has several useful tools for producing Verilog test benches
from timing diagrams, for translating HP logic analyzer data into
stimulus vectors or timing diagrams, and for generating data sheets.
They also have a Verilog simulator. Pricing is generally a few $K."
- an anon engineer
( DAC 00 Item 16 ) --------------------------------------------- [ 7/13/00 ]
Subject: 0-In '0-In Search', Silicon Forest Research 'Assertion Compiler'
DEFENDING THE WALLS: The mystery date of DAC'98 (where they got everyone's
attention with no product but some awful big promises) was 0-in. Since
then, they've gone through some heavy ups and even more painful downs to now
find themselves in the unexpected position of being the Olde Guard for
formal verification type of tools. Their long time rival, Silicon Forest
Research still seems to be playing catch-up, too.
"0-in was very disappointing this year. They were giving the SAME spiel
that they were giving back in DAC '98 two years ago. Almost no new
features or ideas. Seems to me that it took them a LOT longer to get a
stable tool than they had originally anticipated. Still has a lot of
promise, though."
- an anon engineer
"0-In Design Automation 2 stars (out of 3 possible)
0-In Search
0-In makes a "white-box" formal verification tool which combines
elements of simulation and formal model checking which examines a
simulation trace of a design and explores the potential state-space
which can be reached within N vectors of the simulation trace. 0-In
provides a library of over 50 different checkers which can be
implemented in the code using special comment statements or can be
included via a separate checker control file.
The checkers are used to instrument the code, a simulation is then run,
and the results are then "amplified" by the tool to explore the design
and identify potential problems. VCD waveforms can be generated and
dumped which demonstrate the problem areas identified during the
amplification process. The checkers are implemented using Verilog
source code and typically impose a 15-20% runtime overhead. Of all the
companies promoting so-called assertion checker or formal checking
tools, I found the 0-In tool to be the most mature and have the most
assertion checkers of any of the different vendors."
- an anon engineer
"Silicon Forest Research 1 star (out of 3 possible)
Assertion Compiler
SFR also provides an assertion checking tool called Assertion Compiler.
Their premise is that the most common errors found during debug are not
the ones that require the most debug effort (things like datapath
computation errors, control state logic errors, etc.) Instead, the
bugs which cause the most effort to debug are more subtle and are likely
to belong to one of two groups; (1) race conditions resulting from event
order ambiguity, and (2) simulation/synthesis mismatches. Assertion
Compiler is PLI based and is run as a background operation during a
normal simulation run. Currently, only NC-Verilog and Verilog-XL are
supported albeit VCS support is planned in a future release. Going
through a PLI interface typically adds a 1.5 to 5x performance penalty.
I still struggle to see why simulation is needed for several of the
"bug" classes that are supposed to be detected by this tool.
Furthermore, the quality of the checks are highly dependent on the
quality of the test vectors which are applied during the simulation
run. Examples of some coverage checks are as follows:
- multiple drivers
- floating bus
- read operation while floating bus
- write/write operation without an intermediate read
- Latch an x or z into a state variable
- Read an uninitiated value
Due to the ambuguity in the Verilog spec, race conditions are indeed
often difficult to find and debug. On the other hand, simulation
mismatches with synthesis are often the result of poor coding styles
which can be handled adequately by static lint checkers and other
purification tools which don't require simulation. The tool is still
evolving, but until more sophisticated assertion checkers are available,
I don't have a strong feeling about the capabilities of this tool."
- an anon engineer
"0-In ("zero-in" - www.0-In.com) got a lot of attention from verification
wienies last year. 0-in calls normal functional verification "black
box", since stimulus and response are at the I/O. They call their
technique "white box verification", since they have checkers embedded
in the code. Their claim is that black box checking is the best
technique for finding high level functional problems early in the design
cycle. Later in the design cycle, when people are looking at odd corner
cases, they say their technique is far superior. Their Check program
identifies places where a bug is most likely to first appear, like
registers shared by more than one controller. It adds hundreds of
checkers per 100K gates of control logic. These check for common bugs;
for example, overwriting data without using it. Because the checkers
are internal, they can find bugs that never propagate to the outputs.
There is a library of over 30 checkers, and the user can customize
checking, for example ignoring data loss during pipeline flush. They
are trying to find odd corner cases that are generally caused by two
things interacting, like a FIFO filling up on the same clock as a mode
change. In addition to checking internal states, they generate new
tests using what they call a directed search methodology. They take a
signal trace from a simulation, use a formal verification tool to find
interactions that you almost found between controllers, and generates
new vectors that branch out from your existing traces. It hops back and
forth in time (in your trace file) looking for different controller
interactions, so these incremental simulations are supposedly not very
time consuming. The tool currently only support synthesizeable Verilog.
VHDL is due 3Q2001 (Modeltech only)."
- an anon engineer
( DAC 00 Item 17 ) --------------------------------------------- [ 7/13/00 ]
Subject: Synopsys NDA 'Verification Analyst', Synopsys NDA 'Ketchum'
A LITTLE NDA CONFUSION HERE: If you dove into the Synopsys NDA demo suites
at DAC this year, you might have been confused. Under NDA Synopsys
discussed two related but different tools. The first one was a tool
very much like 0-in called "Verification Analyst" (VA). What VA does is
it has "Temporal Assertions" very much like 0-in's "Checkers" and an
"Observation Based Coverage Engine" (also like 0-in.) And, just like
0-in, you feed it your design, your test suite, and your Assertions, and
then you play the 20-Question Game to see what situations aren't covered
by your test suite, etc. Verification Analyst was the result of an
off-site brainstorming session with the Synopsys VERA, Covermeter, and
VCS R&D guys. VA's main difference from 0-in is that its Assertion
language is supposedly simpler and more power to use over 0-in -- it
can easily traverse hierarchies and handles multiple clock domains
without a problem (or that's at least what Synopsys claims.) Their other
bragging point is that VA will run super fast because it'll have direct
links to the VCS simulator through the Synopsys VeriC/DKI interface that
they discussed under NDA in their demo suite. (Other tools will have to
go through the slower PLI.)
The second Synopsys NDA demo during DAC covered a product called "Ketchum"
(which was named after the Pokemon character "Ketchum" who tries to catch
all other Pokemons.) Ketchum is a semi-formal automatic test generator
that creates functional (not ATPG) vectors. It typically focuses on FSMs
and can craft a small set of functional vectors that will test every state
in your chips internal state machines.
As can be expected, customers are confusing these two related yet very
different Synopsys products.
"I did look at the 'semi-formal' tools, like Assertion Compiler from
Silicon Forest, Verix and Verix Pro from Real Intent, Ketchum from
Synopsys, 0-in Check and Search from 0-in, and Solidify from Averant.
I would definitely like my designers to use something like this. I
think the real key to that is for the tool to be very easy to use
(i.e. it must be very simple to write the pragmas that tell it what
your code is trying to do.) I think 0-in and Real Intent have real
winners here, while Averant's language is much too verbose. Ketchum
is Synopsys' attempt to play catch-up here, and since it won't be out
till next year, they may lose this market segment."
- an anon engineer
( DAC 00 Item 18 ) --------------------------------------------- [ 7/13/00 ]
Subject: Averant/HDAC, iMODL, Real Intent, Valiosys, Levetate
MARKETING 101: Finally, EDA start-up HDAC figured out how stupid their name
was in an industry where the biggest conference is called DAC. HDAC's new
sensible name is "Averant". Now that they've cleaned that up, how do they
stack against their verification competition? Averant's start-up rivals
seem to be (in the eyes of the users) iMODL, Real Intent, Valiosys, and
Levetate.
"Averant: Solidify. Cisco won a best paper award at Design Con 2000
about Solidify. They used a memory controler that lets you write some
simple checkers in this little Verilog-esque language. These guys were
sound and level headed. They said this is for blocks and maybe groups
of blocks, but not large logic. Still need to verify, but it does help
one to quickly verify the block level and will statically do stuff that
you might not think of. The Cisco Design Con paper is a good read.
Solidify looks promising. Their claim to fame is that those who have
tried it have found several bugs quickly that Averant does not believe
verification would have caught. The learning curve on their little
static testbenching language is said to be quick and not steep."
- Peet James of Qualis Design
"Levetate
- Formal theorem/assertion prover on RTL code
- Pretty cool temporal language (more intuitive than Specman's).
You define events and time points to model your RTL. You define
assumptions to model your inputs. You then state expectations
as hypothesis that the checker then proves on the RTL.
- They understand that their tool is block-level only but have
great hopes for its scalability.
- Can generate VHDL testbench to illustrate failures.
I suggested they look into using Specman's temporal expressions but the
language license cost was an obstacle for them."
- Janick Bergeron of Qualis Design (VG 1.13)
"Averant's Solidify is already in use by other groups in [ Company
Deleted ], but we haven't had time to evaluate it for ourselves.
iMODL has an interesting concept that we've been using successfully
for many years now. I think their tool needs to mature a little more,
but it is undeniably a great approach to verification.
Valiosys looks interesting, but I let our Formal guy talk in depth
with them and haven't followed up to see what the results were. They
promise many more state bits than any competitor in the same space, so
if their claims are true then they have a compelling product.
Real Intent seems to be a case of marketing hype rather than real
engineering. Their Verix tool is basically a glorified lint checker,
but their booth makes it sound like a full-blown formal verification
tool. They were EXTREMELY careful in their spiel to avoid the use of
ANY formal verification terms, though. Very clever. I questioned them
on that, and they had to back down quite a bit on their claims. Yeah,
there's some good stuff in their tool, but not enough to make an entire
company out of.
Who won't be around next time? Real Intent. Possibly iMODL if they
don't get any users. Levetate is a small company that promised blue-sky
formal verification coverage, but had absolutely nothing to back up
their claims. If they show up next year with a useable product, I'll
eat my hat."
- an anon engineer
"Real Intent
- The tool they demo'ed on the floor looked like a linter to me. I
think it embeds checkers a la 0-in, too. They claim they derive
"implicit intent" from the RTL code. Sounds like a euphemism for
coding guidelines and detection of bad coding practices (aka
linting). Important but not that revolutionary.
In their suite, they had a beta of what they call "explicit intent"
tool. I did not have time to go see it but it sounded similar to
Levetate. Promising technology..."
- Janick Bergeron of Qualis Design (VG 1.13)
"Levetate said they could handle any size design, regardless of the
number of state bits, in their formal tool suite was the biggest lie I
heard at DAC. They promised automatic testbench generation and full
formal verification coverage, but their demo was a two-latch, five-gate
design scribbled on a piece of paper. Absolutely nothing to support
their claims. A lie, or a case of eyes-bigger-than-their-stomach?
Probably the latter, but marketing hype is a gray area."
- an anon engineer
"Real Intent 1 star (out of 3 possible)
Verix
Real Intent has a tool called Verix which is touted as an Intent-Driven
Verification tool which uses no testbenches. Instead, it implements a
white-box testing scheme employing various model checks which check the
design. Supposedly, the tools can build upon verification runs of
lower level modules. Seems to be similar to some of the assertion
checkers which are now being marketed, albeit this tool just did not
catch and hold my attention well.
Some of the Design Intent that it "verifies" are rules commonly checked
by a lint tool such as Verilint or some other design purifyer."
- an anon engineer
"Intent-o-matic or some name with word Intent in it. This puppy is
suposed to eliminate testbenches completely. It's static, yet it did
show wave forms. Looks like it iterated through 'case' statement loops
and flagged un-fufilled paths. All the examples I saw were small and
could have been caught by a linter. The engineers I was with all walked
off after the guys started arguing that a linter could not catch this
and we all knew that they could. Vaporware or lint-ware.
- Peet James of Qualis
"iMODL is one of a small number of companies providing a Foster bus
model. We were aware of them before DAC so it wasn't something new.
Their bus model is synthesizable but there control mechanism is written
in C. You can't use this model with acceleration. Might work well
with the IKOS co-simulation environment."
- an anon engineer
"Levetate sells a tool that is a combination model checker and theorem
prover.
Valiosys sells a model checker that they say is superior in its
explanation of errors. They say it always gives the shortest
possible explanation of a error if a theorem isn't true. They are
looking for people to OEM the product. Support would be an issue.
They're based in France."
- an anon engineer
( DAC 00 Item 19 ) --------------------------------------------- [ 7/13/00 ]
Subject: Linters -- TransEDA, Avanti Novas, DualSoft, Veritools
LINT IN MY BELLY BUTTON: Last year there were something like 13 different
lint-like tools for Verilog and VHDL source code on the EDA market. The
big controversy then was that Avanti bought interHDL (which had Verilint),
renamed Verilint to Nova and jacked up the $8 K price to $47 K. Caused a
small customer rebellion and inspired a number of lint competitors...
"Avanti's Novas: Not bad - good combination of useful tools if you have
the budget."
- an anon engineer
"BTW, Novas Software has nLint, which is different from Avanti's
Nova-Explore."
- an anon engineer
"DualSoft offered two cheap linters, ReviewVHDL and SuperLint."
- an anon engineer
"Lots of lint-based tools. Not much in the way of real coverage, though.
If I want to know that all PCI system requests have been ACKd, or that
all arcs of my state machine have been covered, there still aren't any
EDA tools out there that can adequately address the problem. TransEDA
was the best bet in this category, though. I think they are farther
along in the areas of coverage and general environment."
- an anon engineer
"I believe we will move into some sort of static HDL checking in the
future via lint. I am not sure which one looks good, but in New
Orleans we were looking at the LEDA's lint, which was sucked up by
Synopsys last year. Guess will have to look at this again when we have
more time.
We currently own TransEDA VHDL Cover. Their new Verification Navigator
was a HUGE improvement over VHDL Cover in terms of ease of use."
- an anon engineer
"I have a nomination for worst DAC giveaway. The so-called "Verification
Methodology Manual" book from TransEDA. I sat through a demo to get
this piece of shit. I read it on the flight home and it is the one of
the most obnoxious and blatant product plugs I have ever seen. They
don't even begin to cover a decent "verification methodology." As far
as they're concerned, all you need is code coverage. I'm sure that all
the other vendors selling verification wares besides coverage tools
agree! Forget testbench generators! Forget lint! Forget equivalency
checking! Forget emulation! All you need is code coverage, and all you
need for code coverage is VN-Cover from TransEDA. Granted, VN-Cover
looks like a decent tool, but they had to write a book to sell it? I
was actually offended that this book has a cover price of $64 and that
somebody might actually waste their cash on this worthless load of
trash. Even if it was free to everyone, it still isn't worth it. They
need to find a way to replace to two hours you spent reading it."
- an anon engineer
"As for the Design Rules Checkers (DRCs), aka linters on steroids, like
ProVerilog from Synopsys and VN-Check from TransEDA, I like the idea,
and they both have nice GUIs, especially VN-Check. My problem here is
that I can't get half my designers to even run lint (we went from
Verilint to Surelint last year), so I don't see these tools taking hold
here."
- an anon engineer
"Two experienced VHDL users in my EDA class wrote a tool a lot like
Veritool's HDL-Lint. Just like C Lint, these tools are very useful,
but they are primitive compared to those available for regular
programming languages. But it certainly is an area where a good tool
could really save a designer a lot of time & avoid design iterations."
- Hank Walker of Texas A&M University
"Sorry, isn't EASE a graphical entry tool? We were supposed to use it
but soon thrown it out of our flow. We had also TransEDA VHDLcover
which has now increased to the 'verification navigator (VN)'. Looks
good and I intend to have a closer look. Other's I don't know really.
Big problem for us is once more the fact that we are using VHDL."
- an anon engineer
"Code coverage: I only had time to look at TransEDA - it is suposed to
have the most bells and whistles and is the most popular. SureCove is
suposed to be the fastest.
Linters: Saw the regular ones that have been out for awhile and these
new ones:
A) Dualsoft Review HDL - Verilog and VHDL - need rules. Right
rules in Java.
B) TransEDA VN Check - Verilog and VHDL - need rules.
The common need on all the linters is the actual rules. They all have
the means to add rules, and check rules , and turn rules on and off, but
they need help with actually making and entering the rules."
- Peet James of Qualis
"Most people hate coverage because it is just such a pain to do. The
reason it's such a pain is that the automatic instrumentation identifies
so many don't cares and not enough really interesting conditions.
Reviewing coverage reports involves sifting through the don't cares, and
a form of code inspection to figure out what the line does that is not
covered. This can be quite painful - especially if the person reviewing
the coverage file is not the designer.
I'm really starting to think that going back to a manual insertion of
the things you want covered (preferably during the design process)
results in the best bang for your buck."
- Dan Joyce of Compaq
"Interra also makes a linter that does both VHDL and Verilog. They felt
that Leda is pro-VHDL and Avanti is pro-Verilog. Their linter also
various types of checks, like whether the code is synthsizeable, whether
it violates any testability rules, whether it complies with the Reuse
Methodology Manual, etc. You can program your own rules in Perl."
- an anon engineer
( DAC 00 Item 20 ) --------------------------------------------- [ 7/13/00 ]
Subject: Most Obtuse Presentations -- InTime Software, iModl, SDV
WHO'S ON FIRST? There's a few companies at this year's DAC that befuddled
almost everyone who saw their demo. My question is why spend the money
giving demos at DAC if you don't have a message to give customers? My "Lost
At DAC" experience came with SDV. I was completely lost as to what SDV sold
or how their supposed tool worked. Their presenter seemed to assume that
everyone knows network protocols like the the back of their hands. I don't,
so I was lost, lost, lost. I spend 20 minutes trying to understand him, but
he couldn't think outside of the network protocol box. Oh, well. I finally
got it when I read:
"SDV makes a "scenario manager". You define bus functional models and
describe how they work either with waveforms or tables, and the tool
then provides stimulus and checks results through PLI for Verilog or
through C with Leapfrog."
- an anon engineer
"Biggest waste of floor space - Intime Software - [ name deleted ] and
I sat through their floor presentation which was about 10 minutes
long. After hearing it, we were no closer to understanding what their
product(s) are than we were before their show. A total waste of time."
- an anon engineer
"iModl - Bus-functional models with control/testbench tool.
Their explanation of how to coodinate data generation, parallel control
streams, and user-defined bus-functional models was not very clear."
- Janick Bergeron of Qualis (VG 1.13)
"* Company presentation that conveyed the least information: InTime"
- an anon engineer
"InTime Software - still can't figure out what their mission in life is."
- an anon engineer
( DAC 00 Item 21 ) --------------------------------------------- [ 7/13/00 ]
Subject: Denali Memory Models & C
"ME, TOO!, ME, TOO!": Along with all the other functional test tools going
into the assertion checker business, memory wrapper vendor Denali is also
jumping into that methodology with both feet.
"Denali, which sells C language memory models, is going into the IP
business. They sell Verilog memory controller IP."
- an anon engineer
"Denali 2 stars (out of 3 possible)
Memory Modeler
Denali's memory modeler is a very useful tool for generating simulation
models of various types of memory's for system & chip-level simulation.
The tool is used to model memory components in C, Verilog, or VHDL. The
specific behavior and key parameters of the memory to be modeled are
defined within a proprietary format called SOMA. From the SOMA spec,
the Memory Modeler tool outputs an HDL source file to be used as a shell
for instantiating the memory within the testbench/RTL. This shell calls
a C-language object during the simulation which is also generated. Such
an approach using a C API to the logic simulator would fit well into a
C-based verification methodology. SOMA files can be obtained from many
memory manufacturers or from Denali and include support for DDR-SDRAM,
SGRAM, SDRAM, EDO-DRAM, RAMBUS, FLASH, SSRAM, RDRAM, FIFO's, and various
types of PROM/EEPROM. Denali customers also have free access to the
http://www.eMemory.com design portal where users can search for memory
parts and other information.
Denali has now joined the stampede of vendors rushing to join the
assertion checker club with their PureData product which allows a user
to set breakpoints and check assertions for certain types of memory
accesses such as memory leaks, redundant reads, etc. But some useful
higher level functions also supported are the ability to manipulate
linked-list pointers, flatten complex interleaving schemes, and
interactive memory content viewing and transaction analysis."
- an anon engineer
"Denali sells C language memory models. The models have configurable
checks and supposedly some clever scheme to use as little actual memory
on your CPU as possible (important if you're modeling, say, a memory
board). They can be hooked into most VHDL or Verilog simulators. James
Lee of Intrinsix, who has written two Verilog books, noted that their
models also had some built-in assertion checks like 0-in. He theorized
that checks like this (for example, declaring an error if you overwrite
data without ever reading it) might one day be standard, just like setup
and hold checks, which were not originally part of Verilog. In the past
year they've added even more sophisticated checks, like checking linked
lists resident in memory."
- an anon engineer
( DAC 00 Item 22 ) --------------------------------------------- [ 7/13/00 ]
Subject: Odd Birds -- Derivation Systems, Target Compiler Tech, InnoLogic
THREE ODD BIRDS: There were two formal tools at this year's DAC that sort
of defied categorization. One was Derivation Systems which offered DRS, an
odd sort of behavioral "synthesis" tool where you enter you design in the
form of either behavioral VHDL or their own proprietary language and then
you contunually partition and repartition the design till you're finally
down to "generic" gates. There are no timing constraints you give it and
it assumes you're making a fully synchronous single clock design. It's not
really a synthesis tool -- it's an architectural play tool -- all the
intermediate stages are fully executable. The idea is to use it to check
out one general design architecture versus another. One strange approach...
The second odd birds were the set of mostly DSP-specific architecture tools.
Talk about a limited sales potential! Exactly how many chip designers
are there exploring trade-offs between DSP architectures???
The last odd bird was InnoLogic "symbolic simulator" (and I'll let the
designers themselves tell you how that strange creature works...)
"Derivation Systems, Inc. sells a tool that uses a formal verification
method called derivation. For normal formal verification, you code up
your RTL, then you create a second description of your design and
compare the two. In this tool, you enter the desired function in a
LISP-like language, then partition it to lower and lower levels until
you reach RTL (or even gates for Xilinx or Actel). Partitioning is
controlled by the tool in such a way that the lower levels are
guaranteed to be equivalent to the original description."
- an anon engineer
"Derivation Systems - primarily a formal synthesis company, now has
LavaCORE JVM FPGA Core, a byte code uprocessor, another competitor."
- an anon engineer
"Target Compiler Tech sells a tool that has models for a variety of DSPs
written in their own language. You can compile C code and try running
it on several DSPs to see which one is best for your application."
- an anon engineer
"InnoLogic
- It is a symbolic Verilog simulator (e.g. "inputs are 'A' and 'B'
then the output is 'A+B'" compared to Verilog's "inputs are '1001'
and '0011 then the output is '1010'")
- Pretty cool stuff. Not limited to RTL and handles full Verilog
but only RTL can be symbollically simulated. You decide which
regs are assigned with a symbolic value and which one carries
regular literals. Symbols can also be used in expressions.
- You can get an exhaustive test with a single dataset but the size
of the simulation is the problem: currently only 50-500 kgates.
- If you could couple this with a Specman/Vera testbench to generate
the non-symbolic portions (the complexity grows exponentially so
|
