( ESNUG 346 Item 8 ) --------------------------------------------- [3/16/00]
Subject: ( ESNUG 345 #10 ) Six More User Letters On C/C++-Based HW Design
> Having actually used C to design hardware a few of times, I'm not
> impressed with Synopsys SystemC. The "design with C" tools fall into
> 3 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 C-Level Design.
> (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.
>
> - Andy Freeman
From: leonid@vnet.ibm.com (Leonid Gluhovsky)
Andy, could you please elaborate on your Category (3)?
I understand that if we take some hardware block, & look at the computation
it does in one cycle, we can express this computation as C functions which
take the block's inputs and current state as arguments, and produces the
block's outputs and next state. Such C function(s) can be written in purely
sequential style, without explicit parallelism.
I don't understand how one proceeds from this point. Suppose there are two
such functions, modelling two neighboring hardware blocks. How is it
possible to hook them together to get a model of the parent block? If at
least one of the blocks is a Mealy machine, it's impossible to compose them
as black boxes and still keep purely sequential style.
Category (1) has a solution for this (& that solution has the many problems
which you mention). What is the solution in category (3)?
- Leonid Gluhovsky
IBM
---- ---- ---- ---- ---- ---- ----
From: Andy Freeman <anamax@earthlink.net>
Leonid,
The problem is comes from part of the "suppose", namely the quest to map
each Verilog module/block onto a single C procedure. The RTL-C paper on
the C-Level Design web site shows how they use multiple C procedures to
model/express a single Verilog module. That example also shows how they
implement a hierarchy.
If you design with registered inputs or registered outputs, this scheme
requires two procedures per module. There are registering schemes which
let you use a single procedure per module. If you let an electron cross
multiple block boundaries between clock events without going through a
storage element, in some cases you get to use more than two procedures per
block.
My solution is not completely different.
- Andy Freeman
---- ---- ---- ---- ---- ---- ----
From: [ Been There, Done That At SUN ]
John:
You might be interested to know that this C++ HW design fad is getting some
support within SUN Microsystems. Things tend to repeat themselves here
because you constantly have young guys coming in and they've never had the
previous experience. And the lessons from one generation often don't get
passed to the next. I have no motivation to tell the young guys what we
learned the first time we tried C-based design because they think I'm an
old fart anyway. They'll just have to learn this mistake on their own.
- [ Been There, Done That At SUN ]
---- ---- ---- ---- ---- ---- ----
From: [ An Ex-Hitachi RISC Designer ]
Hi, John, (anon please)
Several years ago I worked at Hitachi on their RISC processor. Our RTL was
developed in C and the scheduling of modules was done by designer. Our bit
masking was a little different since all our regs were unsigned long and
everything had to be masked for any operations. The design was latch based
and all latches were defined separately from the library. So, the designer
only partitions his design into combinational, or state machine modules and
calls all the RTL modules (functions) in the order of execution.
Many C constructs such as "while", "for", and "case" were not used. Only
nested "if else" constructs were allowed.
It was a fast cycle-based simulator. And all C functions were converted to
PLA and boolean equation which were read in by dc_shell. It was linked and
DC generated a EDIF file.
To me, there is no question of if the future is C cycle based simulator.
It's only a matter of how soon. (But I must add that Hitachi did abandon C
based HW design due to complexity of supporting it for their SH4 processor.)
- [ An Ex-Hitachi RISC Designer ]
---- ---- ---- ---- ---- ---- ----
From: Daghan Altas <daltas@yahoo.com>
Dear John,
We met at the SNUG'99 Boston Conference. We were the lucky team who won the
Play Station in the drawing. I hope you remembered me. I was reading your
comments on C++ based languages. These are my insights. At one point you
mentioned:
"And, yes, these guys tried designing hardware with C years ago."
There is a common misperception about C++ and C. The fact that they start
with the same letter does not mean that they are the same thing. If you
look at http://www.systemc.org, you will realize that object-oriented
programming is the "new continent" waiting to be discovered. I don't think
anyone did any black magic. People just realized the problem and put the
pieces together. Again, it is not C at all. It is C++. We are not talking
about mere syntactical changes, but rather a whole new perception based on
CLASSES. I know it sounds like the "same old story". But, weren't people
making same kind of arguments for VHDL and Verilog 10 years ago?
C++ can be as physical and electrical as it can get. VHDL and Verilog are
also object-oriented languages, though they hide it very well.
- Daghan Altas
McGill University Montreal, Canada
---- ---- ---- ---- ---- ---- ----
From: Tom Coonan <tcoonan@subasic.sciatl.com>
John,
Another point I worry these C/C++ efforts might miss is that it isn't just
the Verilog/VHDL languages -- it's also the supporting tools/utilities that
have grown up along with each of the languages. When I use Verilog, I'm
also using Verilog's VCD capability and associated waveform viewers. When
I use C++, I usually expect a superior source level debugger. Likewise,
when I use MATLAB/Simulink, I don't just want the matrix features in that
language -- I want MATLAB's overwhelming library of existing functions and
its superior ability to plot data in beautiful and complex graphs. So,
it's not *just* the HDL language itself; it's the supporting environment,
tools, and utilities they have. Any unified language must bring along all
these assets, otherwise it's a step backwards and I'd rather continue to
"switch gears" between my MATLAB/C++/Verilog tools.
Hey, let's just rename our old-fashioned MATLAB/C++/Verilog schemes to
something like "Open SoC Hybrid Component-based EDA Solutions" and then
they'll become hip!
- Tom Coonan
Scientific Atlanta
|
|
