Subject: Re: SV APIs (Assertion)
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Thu Oct 03 2002 - 10:29:46 PDT
Stuart Sutherland wrote:
> 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.
A vested interest in expanding PLI :-)
> 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.
I think you make my point: why would I want my engineers programming in
C (which is a tricky error-prone language) when they could use a more
efficient safe subset that looks more like their favorite HDL?
> 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.
I'm not designing hardware, I'm doing verification, so I want all the extra
bells and whistles in the language, and since the majority voted for the
testbench donation I presume I'm not alone there.
> 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.
Why are you writing models in C? what benefit do/would you get over writing it
in SV?
> 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.
That's why we're arguing this. Personally I think a lot of what of is being
asked for is now redundant (or will be once the Vera-Lite features are
added), since there is little requirement to go to C/C++ as part of the
design/verification process. Defining low-level cross-calling mechanisms
and ELF library debug formats would probably require less effort than
trying to work out how to get to all the same stuff with a level of indirection
through a "new" API.
> [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.
I'd agree with leaving PLI to the IEEE, IMO the language is not really stable
enough yet.
> [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
Always happy to hear your opinion.
NB: I was not proposing abandoning the existing PLI or suggesting folks
should abandon writing stuff in C to support their Verilog and translate/
rewrite everything in SV, just that if SV does everything that C did for you
you wouldn't need to write in C and hence would not need to develop new
APIs (less work for the committee).
C/C++ do not have APIs for debugging, they use standard code library
formats (ELF,COFF,DWARF etc) and code modules cross-call directly.
The PLI is a by-product of Verilog being a (limited) interpreted language,
now that most simulators are really compilers and produce machine native
code there are hardly any good reasons to continue expanding PLI when
the same functionality can be achieved with methods that regular compilers
and debuggers support - particularly when there is a much larger pool of
expertise for that approach.
Regards,
Kev.
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090> > >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 : Thu Oct 03 2002 - 10:30:38 PDT