( ESNUG 357 Item 12 ) -------------------------------------------- [8/10/00]
Subject: ( ESNUG 346 #2 ) C-Level "System Compiler" Spanks SystemC/CynApps
> I am starting on a project where a team of architects, familiar with C++,
> are writing all the ASIC functionality in C++ (for simulation speed).
> Then they are handing it off to a team (me and others) to port to Verilog.
> I was wondering if you could provide me with a list of commercially
> available tools that can port C++ to Verilog, and some idea of who has
> the lion's share of the market. Also, any info on strengths/weaknesses
> of these tools would be great.
>
> - Dan Joyce
> Compaq Austin, TX
From: "Dan Joyce" <dan.joyce@compaq.com>
Hi, John,
Back in March of this year, you allowed me to put in this request for
information on Verilog to C++ translators in ESNUG. I gave you one update
with a list of the replies I had received, and which tools I planned to
investigate further. I thought it was time to send you another update as
part of your ESNUG "Social Contract" of sharing what you discover. We have
narrowed it down to one tool, have done two evaluation trials, and have
decided to purchase the tool.
First let me give you some more details about our design problem.
Our project uses an in-house C++ simulation engine that is utilizes lex and
yacc parsers. We write the ASIC code in a "stylized C++". It looks alot
like C++, but has some Verilog looking features (like access to bit fields
within variables, and IO structs that deal with timing between module
interfaces.) It also has some limited capabilities to dump variables to a
waveform tool (ISDB format unfortunately, not VCD). There are some other
powerful features that give us the ability to run with a very flexible set
of test environments that are configurable on a test by test basis.
The lex and yacc parsers transform the "stylized C++" to ANSI C++, then we
can compile and simulate with a C++ executable. Tests are passed in as
input files (nice - no recompile for changes in the tests).
The problem is that to get to gates we have to do a "stylized C++" to
Verilog translation - by hand. Then, we have 2 code bases to maintain.
Most of the simulation is done in the C++. Mixed C++/Verilog simulations
are possible so that the Verilog version of a module replaces the C++
version, and the same tests are run against the Verilog.
- All changes in the Verilog modules (bugs, or redesigns to make timing)
must be moved into the C++ code, if it changes the functionality at a
clock cycle level.
- All changes to the C++ code (bugs or redesigns) must be propagated
to the Verilog if they are to make it into the gates.
We required the following from the tool:
1) Single code base in C++. This requires an automatic path from C++
to gates .
2) Make timing on the gates as well as we would be able to with full
control of the Verilog.
3) Simulation speed similar to what we have with our in-house tool
(thousands of clocks per second with a very large design.)
4) Reasonable Testing and Debug Environment.
5) No simulation licenses, or a reasonably priced site license (we
expect to run as many as 200 simulation runs a night.)
We evaluated:
A.) "SystemC Compiler" from Synopsys
B.) "System Compiler" from C-Level Design
C.) "Cynthesizer" from CynApps
We chose "System Compiler" from C-Level Design.
The main reasons we eliminated "SystemC Compiler" from Synopsys were that
1) Synopsys said SystemC was not ready.
2) SystemC simulations would require a SystemC simulation engine that
would provide simulation speed about as fast, or within an order
of magnitude of their VCS simulator (maybe 3 - 10 times faster than
VCS.) Our in-house simulator gives us about 3 orders of magnitude
simulation speedup compared with VCS when the entire simulation is
in C++ only.
The reason we eliminated "Cynthesizer" from CynApps was
1) We heard from several sources (including someone at CynApps) that
they were about the same as SystemC in simulation speed. They also
have a simulation engine, and the code was not pure ANSI C or C++.
After we were well into our second evaluation with C-Level, we were
told by an AE at CynApps that "with our application", he thought
their simulation speed would be comparable to C-Level or our in-house
solution. We did not investigate this claim since the C-Level tool
was doing so well.
We did two evaluations with "System Compiler" from C-Level Design.
The first was a small module which I had ported to Verilog by hand. My port
took 1 week, but involved some redesign to speed up one path. The C-Level
Apps Engineer ported the "stylized C++" to C-Level C++ in less than a day
(but did not do the redesign on the one path). When synthesized, the
surprising thing was that even when I broke the long path in my re-design,
their tool produced faster gates than mine with much less effort to
synthesize.
The second evaluation involved a very large C++ module (~4000 lines). We
did not have the option to break this up since our simulation environment
didn't allow this at the time. We did most of the port to C-Level style
ourselves in about a week. Within two weeks we had gates and timing was
down to as good as we could get by hand (less than 4 nS).
How did the C-Level tool fare against our criteria:
1) Single code base in C++. Meaning an automatic path from C++ to gates.
Yes. With our process, we have an automatic path from "stylized C++"
to C-Level C++; then System Compiler goes from C-Level C++ to Verilog;
then Synopsys DC_Shell goes to gates. We have the ability to simulate
mixed C++ and Verilog, so we can check the functionality at the pre-
synthesized C-Level Verilog output, as well as the gate level Verilog.
2) Make timing on the gates as easily as we would be able to with full
control of the Verilog. Yes. As good or better timing results with
much less effort than a hand port. There are some limitations to what
we can do with C-Level. Hierarchy is a little bit cumbersome. To get
the simulations to work, no submodule can have both registered paths
and purely combinatorial paths through it. The combinatorial paths
must be broken out into a separate module. This has been OK so far,
even with all our vendor macros (RAMs, LPRAs, etc.). We were also
impressed with the size. As few or fewer gates came out of DC_Shell
using the System Compiler Verilog as our hand coded Verilog.
3) Simulation speed similar to what we have with our in-house tool. Yes.
We have decided to continue to use our in-house simulation engine,
since we have many features invested in it. We have modified our lex
and yacc parsers to output a C-Level style C++ as well as the one with
which we compile to simulate. The experts have told me that our
simulation speed should be within 5% of the C-Level simulation speed.
Right now I am getting 25,000 clocks per second on a test with about
50,000 gates. I have also been told that the C++ simulation should
scale with design size much better than Verilog, so the speedup
comparison will show even more improvement over Verilog when the design
is larger.
4) Reasonable Testing and Debug Environment. Yes and No. With our chosen
process, we are using our in-house C++ simulation environment. We are
not using the C-Level simulation environment. So our simulation
environment is exactly as it would be without System Compiler.
However, it is worth comparing this environment to a Verilog one since
that is the kind I am used to.
Testing Environment: I have found the C++ language to be more powerful
to test in than Verilog. I have attended a Vera class and I believe
Vera gives Verilog users the power of C++, with a cost in simulation
speed. When running on a Verilog design, this cost is not seen as
dramatically because the Verilog is also slow. Testing with C++ gives
you all the power, but the speed is much better.
However, we did have to create some functions in C++ to give us all the
capabilities we were used to. Unfortunately, there are a number of
places where you can get yourself into trouble with C++. Memory leaks,
trashing internal data structures if not coded well, etc. These are
things Verilog and Vera (and I'm sure Verisity and Quickbench) protect
you from.
Debug Environment: We have added some waveform dumping capabilities but
these are not anywhere as easy as in Verilog, and require in-house
support. I would have preferred to use C-Level's process. They are
just now putting in automatic parsing of the C++ code and dumping of
variables and structs to a VCD file. This is also nowhere near to the
point where the Verilog tools are.
5) No simulation licenses, or a reasonably priced site license (we expect
to run as many as 200 simulation runs a night.) Yes. We run with
ANSI C++. We use industry standard C++ compilers to create an
executable. That can be run for free on our UNIX boxes.
Because our design was so big, and the task of verifying a cache protocol
requires so many clock cycles, we absolutely required the simulation speed
of a C++ environment. This left us with the options of
1) two code bases, Verilog and C++
2) one code base with a C++ to Verilog translator.
In this case the C-Level tool appears to give us an effective gain. We are
paying a price due to the fact that there are not many tools that support
HDL design and debug in C++. Waveform viewers, Code Coverage, Linting,
semi-formal verification, are not supported in this environment. (Actually
waveform viewers may be there by the time this is published. This, of
course, is an absolute requirement.)
However, for designs where the simulation speed is needed, this type of
process appears to give some very substantial benefits. Like you, John, I
do not understand why people would switch to another programming language
like SystemC, CynApps, or SuperLog if it did not give a significant
improvement somewhere.
I saw that C-Level got some bashing in your DAC trip report this year. From
what I can tell this centered on their initial attempt to get into both C++
and Behavioral Compiler at the same time. Their BC capabilities had a bunch
of problems. Now that they have reduced their tool to tackle only the
problem of C++ for the benefit of substantial simulation speed, I think it
is a much better product. It may be possible for the BC part of the tool to
be fixed. That would add another capability to the methodology. Right now,
it's not there. I have also been surprised to find out that I prefer coding
in C++ rather than Verilog (despite the fact that all my experience is in
Verilog and I am learning C++ as fast as I can). The code is much smaller
and simpler to write.
I know you said you like a customer tape-out before you believe anything
said about a new type of tool, John. We're not there yet with C-Level, but
I'll write you when it happens.
- Dan Joyce
Compaq Austin, TX
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
