( ESNUG 390 Item 4 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #3 ) Speed, Business, & Legal Problems Hinder SystemC
> Our experience with C-Level was that the C-Level C++ HDL simulated so
> much faster than Verilog, that having ANY Verilog in the design reduced
> the simulation speed to nearly Verilog speeds.
>
> Let me be clear -- SystemC is NOT the answer. SystemC performance is
> around 1/1000 the performance we were getting with C-Level style C++.
> SystemC is not much better than VCS - if that. If you are going to
> create a new language, which Synopsys did with SystemC, why not address
> the simulation speed issue?
>
> - Dan Joyce
> Compaq Austin, TX
From: Bernard Deadman <bdeadman@sdvinc.com>
Hi, John,
I went back and read in detail Dan Joyce's comments on C-Level's Cycle-C in
ESNUG 386 #10. I have a different view.
C-Level's Cycle-C was regular C with bit slicing and concatenation macro's.
It doesn't take much to create something similar yourself, though it seems
the real point was by using the C-Level Cycle-C simulation coding style, you
were writing C in a style that fitted C-Level's synthesis technology.
Dan's correct about high speed, cycle-accurate, lack of kernel etc., all of
which work where the user really understands what he is doing. However,
like all cycle-accurate simulators, there are evaluation ordering issue
traps for the unwary. There were, as Dan hinted, other issues with C-Level
Cycle-C (at least in the form I saw it a year ago), including it's lousy
hierarchical component instantiation, its inability to accurately model
signals across two clock domains, its lack of tri-state signals, it's
inability to generate VCD files from inside the design hierarchy and the
lack of a testbench solution that would drive a model with multiple,
asynchronous clocks. It's true it could write Value Dump files, ie it
could output huge files with the value of every signal at every clock edge,
however it couldn't make Value Change Dump files because it didn't remember
the last values of signals. Fixing these issues would have slowed Cycle-C.
Where I think Dan is wrong is in declaring SystemC to be slow. I think you
should see SystemC as a not-yet-standardized and still unstable syntax,
just like Verilog & VHDL were at the outset. It's certainly true the
present reference implementation of SystemC is slow, indeed the kernel of
the latest 2.0 release is generally believed to be somewhat slower than the
previous 1.x releases which is not a positive step! It *IS* however
possible to make an implementation of SystemC (just as VCS was a fresh
implementation of Verilog) that will achieve near the same simulation
performance as Cycle-C would have achieved if the ugly issues had been
fixed. Most importantly this can be done while maintaining the SystemC
synthesis route to silicon.
The *BIG* problem IMHO is the business model. How does a vendor get a
return on investing a man year or more of effort in significantly improving
SystemC performance? If they open source the results they have to identify
and develop a complementary product reliant on the enhanced code to make
sense of the investment. Alternatively they have to figure a way to
license their version of the Open Source code, which would be a legal and
technical minefield given the models are built using standard C++
compilers. The closest comparison I can think of is Forte (previously
CynApps) with ESC. Does anyone know their progress?
I understand the theory of Open Source (enhancements for and by the user
community etc.) and I've wondered if one of the big users might make these
enhancements for their own use, and release the results back to the
community for maintenance but, since the SystemC discussion group contains
comments like "I'm not allowed to share how we did that" I fear commercial
secrecy is inhibiting a true exchange, in many cases to their ultimate
disadvantage. Because there's no such thing as a free lunch, one side
effect of Open Source is users are growing internal tools teams, with the
obvious risk of duplicating each other.
Why did Synopsys introduce SystemC? One possibility is C/C++ simulation
was going to happen anyway and they wanted to keep users buying Design
Compiler and related products, the bigger risk being rapid adoption of
CynApps or C-Level synthesis, though I don't imagine the Open Source
decision was cheered by the Cadence, Verisity or even the Synopsys Vera
marketing organizations!
Possibly by design, innovation in simulation performance is now being
stifled, for example, how can the next Chronologic grow up to challenge
Verilog-XL in this climate? And how many synthesis and other back-end tool
users realize they are cross subsidizing front end tools? And how much of
an incentive do Synopsys have to invest in significantly improving SystemC
performance?
In summary, it's technically possible to take big strides in SystemC
performance, but the distortion of the marketplace is restricting this
essential effort.
- Bernard Deadman
SDV, Inc. Austin, TX
P.S. Please warn your readers to beware of the Synopsys "SystemC Design
& Verification Seminar" -- it's a boring 2 hour GUI demonstration
that teaches you *NOTHING* about using SystemC for verification.
|
|
