( ESNUG 336 Item 9 ) -------------------------------------------- [11/11/99]
Subject: ( ESNUG 335 #9 ) An RTL-C Rival Critiques Synopsys SystemC Idea
> I am interested to know what the design community thinks about the SystemC
> initiative launced recently by Synopsys, Coware and Frontier and a whole
> series of system design companies. For more info see www.systemc.org
From: Andy Freeman <anamax@earthlink.net>
Having actually used C to design hardware a couple of times, I'm not
impressed with SystemC.
The "design with C" tools fall into three categories:
(1) "Let's make C look/behave enough like Verilog/VHDL so that
Verilog designers can use C". SystemC and CynApps are in
this category. This category is distinguished by user-guides
which explain an execution model and explain how to express
non-blocking assignments.
(2) "Let's add something to C to make it a HW design language".
Handel-C is my favorite example - if you're one of the 10k
people who know CSP, it may be the tool for you.
(3) "Let's figure out how to translate a C subset into gates."
Currently, the big player in this area is CLevelDesign.
(I'm getting close to releasing a product which competes
with their RTL-C product.)
Category (1) tools promise faster simulation and easier integration with a
world simulated in C/C++. I don't think that the former advantage is
sustainable - the "fast" HDL simulators can use the same shortcuts. (Things
will get interesting when the C tools start exploiting multiprocessors, but
the HDL simulators can also make that leap.) If I'm correct, the open
question is whether the latter advantage is enough to entice people who are
already comfortable designing with Verilog/VHDL.
Category (2) tools don't have any potential users.
Almost all category (1) and (2) tools require (or at least allow) the
designer to express concurrency. I think that explicit concurrency is a
huge mistake because the semantics for such code is always subtle, so its
behavior is usually surprising, leading to Heisenbugs and "let's run it and
see what happens". Multiprocessor simulation may help/be required to flush
out designer misunderstandings.
Cooley's Oct 11 EE Times article (pg 137-8) quotes someone from Intel making
basically the same point. If these C/C++ dialects share the characteristics
that that make writing Verilog/VHDL "slow", their users can't be
significantly more productive. Moreover, if their users must be somewhat
competent with Verilog/VHDL....
Category (3) is analogous to synthesizable vs "full" Verilog. I've found
that "good" subsets do lead to unbelievable design productivity. (These
subsets do not have explicit concurrency - the execution model is familiar
to C programmers.) These tools won't have any problems making the leap to
multiprocessor simulation, and the results won't change when they do.
I think that the Category (1) tools will have a heyday and lead to better
synthesizers and better RTL analysis tools (because you really can't/don't
want to edit the Verilog they produce). However, I think that Category (3)
tools will eventually be used for most synthesizable design because they're
easier to use AND there are far more C programmers who can design HW with
them than there are Verilog/VHDL programmers, let alone Verilog/VHDL
programmers who want to use C.
The interesting question is how to make money with these tools. I do almost
all of my HW debugging with the C source because the Verilog (for synthesis)
generated from the C is strongly equivalent. Moreover, these compilers (C
to Verilog) are very fast. (They can compile C to Verilog about as fast as
XL can read it in.)
All of these tools do fit into typical design flows because they generate
PLI interfaces for folks who want to mix C and Verilog, Verilog for those
who don't, and VCD for people who want to use waveform viewers.
- Andy Freeman
BTW -- Since Category (3) tools don't have an event mechanism, they may have
a small (25%?) inherent simulation speed advantage over Category (1) tools.
However, that may not be significant. I've got a microcontroller core for
which the C runs over 1 million cycles/second on an obsolete PC. I haven't
bought a new PC to get 2 million cycles/second (or booted up a PC sitting in
the closet to get 2x1 million cycles/second) so I doubt that I'd care much
if it only ran 500k cycles/second.
|
|
