( 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.
|
|
