( SNUG 01 Item 14 ) -------------------------------------------- [ 3/28/01 ]
Subject: Designers Hate SystemC, CynLibs, & C-based HW Design
NO, THANK YOU: Saying "No, thank you" to C-based HW design is putting it
politely. Of the 92 people who responded to my survey, only 3 (yes, that's
3) users had positive things to say about C-based design. One guy wanted
to be anon, another was from Netrake supporting CynApps, and the third
was Dan Joyce of Compaq because his design group had just finished doing a
C-based design using C-Level's System Compiler. He wrote a paper about it
for HDL Con (it got 2nd place, too, in the conference.) But the C-haters
and detractors have come out of the woodword on this! Of special note are
the Motorola engineers who had used SystemC and wrote me signed letters
telling me how bad C-based design work was. And don't forget the anon guy
from Compaq who also writes about his C-hatred. It's all here in the
customer quotes below.
Oddly, perhaps thinking that water reaches its own level, Synopsys has tied
it's cult-tool-at-best Behavioral Compiler to its disliked SystemC
initiative. (Oh, and before I forget, I just love the Synopsys SystemC
propaganda machine, too. They claim ~15,000 users because they got ~15,000
downloads for the SystemC spec on their web site! Don't you just love the
EDA industry!!!)
"Behavioral Compiler failed. Why do you feel that any of these
SystemC/Superlog/C-based tools will be any more useful and/or
successful than currently available behavioral level solutions?"
- Marquis Jones of Motorola
"C sucks for hardware design. It's not concise nor does it offer
parallelism like Verilog without major revisions. The overhead
provided by SystemC or Cynlib is excruciating to design in."
- Gregg Lahti of Intel
"I am against replacing VHDL/Verilog with C, simulation C, or tools
that translate C into VHDL/Verilog for synthesizing. VHDL and
Verilog are specifically built for hardware. Things like driving
signals with multiple sources are allowed in C. All signals in C
would be global unless restrained. The LRM for C would be heavier
than a boat anchor."
- Jayne Meiners of Texas Instruments
"We developed our latest design using SystemC. Compared to Verilog,
we found SystemC to be:
* Harder to read (especially when trying to deciphers
others' code)
* Slower and more clumsy to write
* Harder to debug (we never had the signals we wanted
in the VCD file and following the signal-flow through
the code took longer)
* Less efficient for re-use since all the old code is
in Verilog
* A steep learning curve for all
* In general, a less efficient design flow than Verilog
"In my opinion, if SystemC makes designers less efficient, there will
be a great deal of resistance to use SystemC. What compelling
advantages does SystemC offer that will make designers want to switch
in spite of the above difficulties?"
- John Rinderknecht of Motorola Labs
"I manage a Hardware (FPGA, ASIC) wireless Modem Design team in
Motorola. Accumulated in my team, we have a few hundred man-years
of ASIC experience.
I do not believe that any additional languages are needed, or that
any can be useful. I have been in this game since 1990 when language
based design started. We tried C, Verilog, VHDL, C++, SPW, Vera,
COSSAP, C++ again and back to Verilog again. From all those, VHDL
gave us the best results, followed closely by Verilog. Using C and
C++ for HW design are a disaster. SPW, Cossap and Renoir reduced
productivity."
- Ron Rotstein of Motorola Wireless
"Why should I take the time to work through your new C tools' bugs,
instead of sticking to the bugs I know and hate already?"
- Jeff Deutch of Avici
"This isn't a C vs. Verilog vs. VHDL thing. When you look at the
papers and boil them down, you'll find that everyone doing C based
HW design are using cycle accurate C models. These are all zero
delay register to register behaviors. This is a battle of cycle
based simulators vs. event driven simulators. I don't care for C.
I like VHDL because it's designed to handle concurrency. C doesn't
do this and it's a pain in the ass to try to artificially make C
work."
- Lance Thompson of IBM Server Group
"The C++ issue is just how many Class libraries are needed, or can
they be combined into one hermongous Class Library? Right now
They've identified a Modeling Class Library (SystemC and Cyn-Aps).
The system vendors are now asking for a Test Bench Class Library
(Cadence's Verification Cockpit). And then you need a synthesis
Class library (SpecC)."
- Gary Smith, Senior EDA Analyst of DataQuest
"Well, why would anyone want to use a serial language C to describe a
parallel design conception? Especially when there are already parallel
description languages like VHDL and Verilog?"
- Carl Wakeland of Emu Systems
"CynApps:
This is the C++ language from John Sanguinetti. It is also similar to
Verilog in that there are constructs that resemble the always@(posedge
clk) and always@(sensitivity_list). Like SystemC it also has a kernel.
According to Sanguinetti this kernel is 32k lines of code vs. 96k lines
for SystemC. So he says it is faster than SystemC. We expect it also
to be around 10 times faster than Verilog.
Approximate Simulation Speed vs. Verilog RTL*: ~10x
Simulation Cost: I don't think you have to buy runtime licenses for a
purely CynApps simulation.
Translator Cost: You buy a translator to get to synthesizable Verilog.
Synthesis Cost: Typical Synthesis tools after translation to
synthesizable Verilog or VHDL
http://www.eedesign.com/story/OEG20010301S0043 is a good article from
EETimes on the use of CynApps at Netrake."
- Dan Joyce of Compaq
"I do not see a future with the C based flows. It is not going to be
easy to get a hardware community to adopt a software language. My
focus is on the verification problem - language is not that big of
a concern. I see Vera/Specman as a forced response to today's
verification testbench problem. They however will not succeed in
the long term for one simple reason - PLI. These languages have not
solved the performance bottleneck of the PLI - they have just provided
a layer of abstraction. By the time I constrain the C language to
something manageable for verification and even more so for design I
would of been better off using a design tailored language.
This is what I see for languages - reference modeling done in C/C++,
design done in Verilog and verification in Superlog. For RTL design
the actual coding is not a real bottleneck. We do a lot of up front
planning and "design before entry" work so that when it comes time to
code the actual RTL you are talking a number of weeks - not
significant in the big picture. The real bang for the buck is the
verification infrastructure. Superlog brings it all together in a
single simulator - no PLI bottleneck. This is a real solution. The
obvious concern here is the performance of the Superlog Systemsim
simulator."
- Jerry Vauk of Sun Microsystems
"I don't think there's anything wrong with Verilog. It was designed
specifically to describe hardware, while C wasn't. You can make C do
it, of course. I remember Mentor had something called "M" about ten
years ago, which was a superset of C.
But my question remains: "what is the problem they're trying to solve?"
- Oren Rubinstein of Nvidia
"Session 1 -- Modeling Systems With SystemC
------------------------------------------
I was left wondering exactly what problem SystemC was intended to
solve. SystemC is basically a C++ library which imparts C/C++ with the
necessary functionality to support hardware simulation. There are 4
"levels" of model supported by SystemC -- UnTimed Functional, Timed
Functional, Bus-Cycle Accurate, and Cycle Accurate. As a design
evolves, the theory is that its model progresses through each of these
four stages.
Version 1.0, which was released in 3/2000, supports constructs to
support describing hardware at the RTL level. However, the presenter
told us that if all we were going to do is code at the RTL level, he'd
stick with VHDL/Verilog, because the tools were better and more mature
than for SystemC. He did claim an order of 10x speed up over Verilog
RTL simulations, but SystemC is cycle based, and I can get that same
speed up by going to a cycle based Verilog simulator. It's very
unclear what, if anything, is gained by coding in C/C++ at this level.
Also, if what you wanted to simulate contained any Verilog or VHDL
blocks, you'd have to write a bunch of PL/I code and then be stuck
doing a C/Verilog (or VHDL) co-simulation."
- Rich Conlin of Paradigm Works
"I took a SystemC 2 day class during some slow time last year, trying to
get a feel for where they're going, how it works, etc. I tried to keep
an open mind and learn how to do this stuff. Now understand that I
have never had a C++ or OO class before. But after 2 days I never
wanted to see C++ again. What misery to have to do all that to do my
job, with no real tools to tell me when I'm screwing up typing the same
garbage into 3 files!!! I am so glad Verilog 2000 has gone to ANSI
style declarations - just write everything once. But C++ has you write
not only 2 times, but in different files! I know this is a very small
part, but it seemed indicitive of the rest of it.
I have great hopes for Verilog 2000 and maybe Superlog."
- Paul Gerlach of Tektronix
"HDLCon 2001
SystemC Tutorial
The SystemC tutorial was taught by Mike Baird. He made some comments
about SystemC that were interesting. I'm not sure I agree with all of
this, but it does give an indication of where the experts, and where
perhaps Synopsys thinks SystemC should and will be used.
1) There is no compelling reason to do RTL design in SystemC. It
really should be used for higher level architectural modeling.
- only makes sense at the system level
- direct support for higher level architectural modeling
2) SystemC Behavioral Compiler path to gates is released, but the
RTL path to gates is in beta now!
3) The decision to do Behavioral Compiler depends on how solid your
design is. If you already have a good idea how your architecture
will look, it makes sense to use RTL design. If you're interested
in exploring some design options, BC is very powerful.
4) SystemC is a cycle based simulator.
- But, there are code options available that are similar to
always@(sensitivity_list) in Verilog. I don't understand how
this is implemented in a cycle based simulator. Mike also
said off-line that the code in the always@(sensitivity_list)
segment may be evaluated several times in a single clock.
That does not sound cycle based.
5) Finally, I have heard simulation speed stories about SystemC that
range from slower than a similar Verilog simulation to 10 - 100
times faster than a similar Verilog simulation. It sounds like
the most likely answer is around a 10x speed-up.
6) A signal class is like a reg updated with a non-blocking assign.
Signals are used to communicate between processes.
7) The three code options are:
a) Methods - RTL
b) Threads
c) Clocked Threads - Behavioral
8) SystemC does not have reentrant threads or destructing threads.
BIG BUMMER for testing!
9) Behavioral Compiler will be the same engine for Verilog code as
for SystemC. Does this mean there is no BC advantage to using
SystemC???
VHDL vs. Sequential C Revised:
This was a presentation at HDL Con on a study saying the C++ will only
be about 5 times faster in simulation speed than VHDL. We have found
otherwise. The guy sitting next to me who worked on our C++ simulator
(which is ABOUT 100 times faster than Verilog) was pouring through
their paper trying to figure out why their C++ was so slow."
- Dan Joyce of Compaq
"I'm using one of the C-based methodologies right now. We had a
complete model of the circuit in C++, so it seemed like the logical
progression. The experience for me as a HW designer (MSEE, 10+ years
VHDL/Verilog experience on many large ASICs) was painful, very
painful. At this point I won't go near it again with a ten-foot
pole unless there's a gun on my head. The constraints are crippling,
the tools seem to be made by and for C programmers with only a
fleeting notion of what HW design is really about - it's a very
unnatural way of trying to get "there".
- an anon Compaq engineer
"Still a lot of hype around C/C++ for hardware design. C-Level Design
had one of the largest booths on the DATE exhibition. Co-Design was
a much smaller one outside the main hall.
My experience: coded Verilog for 4 years now. We played a bit with
SystemC. Trying to write some small modules and simulate them. Didn't
work very well. Every time when I see example SystemC code, I don't
see a big difference to normal HDLs. I guess, with some experience,
you can use it for RTL-level code, but you won't raise your
productivity, etc.
Superlog looks much more interesting. Keep your Verilog knowledge, and
extend it step-by-step with advanced constructs. Which language will
prevail? Well, Co-Design is in a mess here. Keeping Superlog under
the hood gives them some time to develop tools and gain some head
start, compared to big EDA companies. But if they wait too long, the
C languages could have grabbed a significant portion of the market
already."
- Lars Rzymianowicz, University of Mannheim, Germany
"No interest in C. NC-Verilog & Verilog-XL are all we use. Don't see
any value in C-based tools."
- David Hollinbeck of LTX Corp.
|
|
