( ESNUG 355 Item 7 ) --------------------------------------------- [7/26/00]
Subject: ( DAC 00 #12 ) Stu Pissed At Cooley; Stu On C/Superlog/PLI/VCS
> PLAYING BOTH SIDES: While there's a nest of new C-based EDA tools still
> trying to prove themselves, if you went into the Synopsys NDA suite at
> DAC you would have seen how their VCS R&D guys have crafted VCS to be
> able to read in C *without* going through the PLI. (Although bypassing
> the PLI did seem to piss off one consultant I know...)
From: Stuart Sutherland <stuart@sutherland-hdl.com>
You've put my foot in my mouth for me, John! It's not so much that you
misquoted me, but you sure changed the context! You have associated a
comment in my report on DAC-2000 with a completely different topic from
what I was commenting about. So, I claim the right to both set the record
straight, plus to say what I really think about this other topic.
The topic you inferred that I was referencing was VCS's new, not-officially-
announced C language extensions to the Verilog language. You stated
"Although bypassing the PLI did seem to piss off one consultant I know...",
followed by my comment that "In the area of PLI support, VCS is the worst
product there is."
My comment was regarding VCS's failure to be IEEE-1364 compliant, and had
nothing to with possible extensions to the Verilog language. And I standby
that comment. VCS is based on the 1990 OVI Verilog standard, and has never
been updated to the IEEE 1995 standard. With the IEEE Verilog-2000 standard
soon to be ratified, VCS is completely obsolete as far as standards are
concerned. If you want to see a Synopsys sales or marketing person do true
parallel processing, just ask them when VCS will support the 1995 IEEE
standard for the Verilog PLI. You will probably get three lies all stated
in one fork-join block: 1) "VCS is IEEE compliant." 2) "Synopsys is
working on implementing the PLI VPI routines." 3) "Nobody wants the VPI
routines, so Synopsys does not need to implement them."
Extending VCS to accept C language constructs directly in the Verilog HDL
has nothing to do with IEEE compliance. The Verilog 1364 standard has no
restrictions on a product adding proprietary extensions to the language.
And no, John, these C language extensions do not "piss me off". To the
contrary, I am in total agreement with adding more C capability to Verilog.
I wish we would have had the time to add more C constructs to the IEEE
Verilog-2000 standard. But, it takes time to add major new features to a
standard, AND make sure that the new features can be implemented in a
practical way. (Theoretically, anything can be implemented, but do we
really want something if it has negative trade-offs, such as killing
simulation or synthesis performance.) We need companies such as Synopsys
and Co-Design (with SuperLog) to prove what extensions to Verilog or VHDL
are really worthwhile before making radical changes to the actual standard.
Though adding C constructs to the Verilog HDL is a good idea, I also think
it is a very bad idea to try to replace the Verilog PLI. If replacing the
PLI is what Synopsys intends to do, then I think they are heading in the
wrong direction at a high rate of speed. There is a distinct difference in
what an INTERFACE does, versus what proprietary language EXTENSIONS do.
Verilog PLI advantages:
o A standard, portable interface. A properly written PLI application
will work with any IEEE compliant Verilog simulator, with no changes
to the code. It sure would be nice if VCS were IEEE compliant :(
o Protection to the internal simulation data structure. The PLI is a
layer between user code and the guts of the simulator, and prevents
user code from corrupting the simulator's internal data structures.
o Source code protection. PLI applications can be delivered as object
files. No Verilog or C source code needs to be provided to the end
user of a PLI application.
Verilog PLI disadvantages:
o OVI's PLI standard was poorly documented. The IEEE 1995 Verilog
standard is better, but still full of errata. These ambiguities mean
PLI applications are not as portable as they should be. For
Verilog-2000, we spent thousands of man hours making the PLI standard
as accurate as possible (I'm co-chair of the PLI standard task force).
o The PLI is slow compared to directly interacting with the simulation
data structure. That is the price of having an interface layer that
protects the data structure and gives portability. The VPI library
in the 1995 PLI standard is designed to be much faster that the older
TF and ACC libraries (too bad VCS does not support the VPI library).
Language extension advantages:
o Better performance compared to the PLI. Language extensions can
bypass the interface layer, but at the cost of no protection to the
data structure. User code can directly corrupt the simulation.
o Tight integration with Verilog HDL constructs. C constructs such as
pointers, structures and enumerated types become HDL constructs.
The PLI allows the usage of structures and such, but exchanging data
between the HDL and a C structure is only possible through the
interface layer.
o The capabilities of the HDL are still available. Time, concurrency,
design structure, digital logic values, arbitrary vector widths and
such are natural to Verilog, but are not natural to C. A PLI
application is pure C, and while it can access the Verilog information
(through the interface layer) a PLI application cannot actually model
with HDL constructs. Extending the HDL gives the best of both worlds.
Language extension disadvantages:
o Proprietary to specific products. Code which uses the extensions will
not be portable to other software products from other vendors. Even
tools such as lint checkers will need to be proprietary.
o No source code protection. The same problem that exists with HDL's
today will continue; End users must have source code to read into
simulation tools, synthesis tools, etc.
o A high risk of corrupted simulation data structures. Give a hardware
engineer pointers, pointers to pointers, addresses of pointers and
all the other levels of indirection that C permits, and there are
going to be unstable models. Add in C's memory allocation and
de-allocation, and hardware models will start having memory leaks,
illegal memory references and all sorts of other issues.
To summarize, C language extensions to Verilog are a good idea, but they do
not replace the need for a PLI. The extensions are great for performance,
abstract bus-functional level models, system level modeling, and test
benches. A procedural interface provides portability, data structure
protection and IP protection. If Synopsys is going to offer both C
language extensions and *FULL* PLI support in VCS, then they are definitely
on the right track and will have a great product. If they are
not... Well, fortunately, SuperLog IS planning to do both.
Back to my original statement, which was quoted out of context: As of
today, "In the area of PLI support, VCS is the worst product there is."
Until VCS supports the full IEEE PLI standard, I will continue to
suggest to my customers that NC-Verilog is a better choice. If C
extensions to Verilog are needed for abstract modeling or testing, then
until VCS is IEEE compliant, I will recommend looking at SuperLog.
- Stuart Sutherland
Verilog PLI consultant Tualatin, OR
|
|
