Subject: Re: SV APIs (Assertion)
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Wed Oct 02 2002 - 18:29:14 PDT
At 03:32 PM 10/2/2002, Alain Raynaud wrote:
>Feel free to write whatever you want in SV. But don't force me to rewrite
>the millions of lines of code that we already have. For those, SV still
>requires a way to connect to "legacy" C code. C libraries have been used
>as the backplane of tool interoperability for more decades than I can
>remember.
That is a key reason why SystemVerilog needs DirectC/Cblend capability. I
think everyone is in agreement on that, so I would hope the haggling over
where to start is over and the real work of defining the interface has begun.
>However, I do think you make a very good point: everything we say PLI
>needs, should also be doable in SV in a native form. There is no reason
>that the PLI should have more features than SV itself.
There's that illusive "pie in the sky" again. First, if the SystemVerilog
language can do everything the PLI can do, then the language will be so
convoluted and bloated that no hardware engineer will want to use it. A
major part of my living is made teaching hardware engineers to write PLI
code. I have consistently observed two things: First, most hardware
engineers are not good C programmers--nor do they have any desire to
be. Second, most hardware engineers simply want to use the PLI to call a C
function, with some rudimentary synchronization of that C function to
simulation time.
Most engineers are not interested interested in having their Verilog models
find every delay of every ASIC cell in their 2 million gate design. They
could care less about having their Verilog model find the capacitance
characteristics of some particular node. I have yet to find a hardware
engineer that is really interested in writing a full graphical dubugger
that can trace all the drivers and loads of some signal. Nor have I seen
any hardware designers that want to write their own waveform display. So,
if hardware engineers do not want to do these types of things, why in the
world do we want to have them in a hardware design language. Granted, we
need debuggers, power analyzers, waveform displays, and a myriad of other
tools. But writing those tools is the job of software guru's at companies
like Novas. It is not what hardware engineers, or system engineers, for
that matter, want or need to do.
As a hardware designer, I just want access to enough C to allow my HDL
models and C models to interact, or for my hardware models to emulate
executing a program. That is all the interface to C that SystemVerilog
needs to provide. Leave the API stuff that debug tools and such need to
the PLI.
If I may be just a little blunt... I have not been able to attend any of
the SV-CC conference calls because they are not being held on Mondays, but
I have been reading all the e-mails. Thus far it does not appear to me
from the e-mail that any significant progress or even fundamental decisions
have been made by the SV-CC committee. If the committee does not draw a
line in the sand soon on what will go into SystemVerilog 3.1 and what will
be postponed until SystemVerilog 3.2, the committee will end up still
debating the great pie in the sky when I'm doing the final editing on the
SV 3.1 manual. Remember, you only have until March to be completely
finished defining what you want in SV 3.1.
[switching hats...] I was co-chair of the 1364-2001 standards group PLI
task force. Speaking from that perspective, I would like to recommend the
SV-CC either leave defining that PLI interface to the IEEE 1364 committee,
or create a totally separate SV committee to do that work. Do not try to
have the same committee defining both the DirectC/Cblend like interface and
the VPI-like interface. You will never finish if one committee tries to
tackle too much at once. My experience with the PLI for both 1364-1995 and
1364-2001 is that most of that type of API cannot be defined until AFTER
all constructs that affect the HDL are well defined and stable. For SV
3.1, you will not have that stability from the SV-AC, SV-BC or SV-EC
committees in time to define a VPI-like API for SV 3.1. The same thing
applies to the notion of having a direct SV API that can do everything the
PLI can do. You will not be able to define all that capability until the
SV 3.1 language itself is stable. So just put that idea on a back burner
and concentrate on defining something useful to hardware engineers.
[switching hats, again...] On the other hand, as the editor for the SV 3.1
LRM, I suppose I should be thanking SV-CC committee. The less progress you
make because of trying to do too much at once, the less work I'll have to
do next April. The SV committees that are focused on what hardware
engineers really need will have plenty to keep me busy.
Yatin, please go ahead and remove me from the SV-CC mailing list. It
doesn't look like my services as the editor will be needed for several
months. Even though I have a very deep interest in seeing a perfected
DirectC/Cblend capability in SystemVerilog, I will not be able to actively
participate in meetings that are not held on Mondays. Since that has
disqualified me from having any vote, there is little point to monitoring
the e-mail noise. Besides, I'm sure the committee has tired of my opinion.
Stu
>Alain Raynaud
>Tensilica, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 18:33:43 PDT