( ESNUG 353 Item 3 ) --------------------------------------------- [5/24/00]
Subject: Cliff Cummings Disagrees With Goering Over C-Based Hardware Design
> From: Richard Goering
>
> In the interests of stirring up a little controversy, I would like to
> briefly state three reasons why hardware designers might be drawn to
> C/C++ language design.
>
> 1) System-on-chip complexity forces a higher level of abstraction.
> RTL is too low for multi-million gate chips.
From: Cliff Cummings
Wrong! RTL with a few instantiated cores works great for multi-million
gates chips. Many of those gates are instantiated cores and memories.
Other gates take the form of 64-bit registers instead of 16-bit registers,
where the only difference in the RTL code is the declaration size of the
variables, the rest of the code remains unchanged. Early abstraction will
not speed up the gate-level simulations at all!
> 2) Increasing percentage of system functionality is in embedded
> software. Hardware and software designers should speak the
> same language, and the software guys speak C/C++.
Concerning hardware and software engineers speaking the same language, will
that help? No!
Software: print ("hello, world!");
Hardware (the C-equivalent of): @(posedge clk) q <= d;
Does not simulate together nor synthesize to anything I am interested in!
Software writers create algorithms that compile to bit patterns that are
loaded into memories that are read and executed by hardware processors.
Asking hardware and software writers to use the same language will not
increase productivity any more than asking hardware and software writers to
do their jobs on the same PCs. Software languages and PCs are tools, not
magic!
The next step: are we going to ask the board-layout people to start
designing all circuit boards using C++? Maybe then we can simulate the
cross-talk effects of our early architectural explorations!! ;-)
> 3) A growing number of systems designers may not even know or care
> if the functionality they're describing will be in hardware or
> software. C is the easiest starting point.
C-language is useful in some applications (such as DSP) for early
architectural exploration. The big problem with architectural modeling is
that testbenches are not reusable on RTL and gate-level versions of the
same design. Verilog has had architectural and queuing system tasks for at
least ten years but almost nobody uses them. Why? Because and testbench
you write for an architectural model is useless at the RTL or gate-level.
Architectural modeling proves a concept but does not advance the generation
of RTL and gate-level verification.
When coding for synthesis you have got to "think hardware" (thanks to Jim
Lewis for the quoted motto). When Verilog engineers code algorithms and the
say "I wonder what this is going to be!!" you know you are in trouble!! You
better have a block diagram when you start coding the RTL.
> I think the movement to C/C++ will be gradual, but will eventually happen.
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
Sunburst Design, Inc. Beaverton, OR
|
|
