Subject: Re: SV APIs (Assertion)
From: Stickley, John (john_stickley@mentorg.com)
Date: Thu Oct 03 2002 - 12:46:45 PDT
Fellow sv-cc'ers,
I'm relatively new to this committee but I'd like to make a
couple of points in support of what Stu is saying here.
I totally agree that the DirectC/Cblend capability should
not go beyond a simple, quick, easy to use function calling
mechanism. We can easily impede progress - I believe
unnecessarily - if we transform the efforts of this committee
this into a large VPI/VHPI like effort.
Here's another way of looking at the DirectC/Cblend capability.
It is "API-less" and therefore simple. There's no API to
couple SV callers to C functions (or possibly vice versa).
Rather the user is defining his or her own API as a set of
custom named function calls in one language that are callable
from the other. The functions have the same name in each
language and are therefore automatically bound to each other
by the compilation and linking infrastructure. No need for
an API.
Yes VPI will eventually have to be extended to support
SystemVerilog but that need not impede the progress
of creating a simple inter-language function call mechanism.
An analogy can be made to the whole concept of foreign function
calls in VHDL vs. the full blown VHPI. Many of the simulator
vendors were using foreign function calls long before the
VHPI existed. The unfortunate thing is that there was never
a standard way of doing foreign function calls other than
using the de-facto 'foreign string attribute in conjunction with
vendor specific syntax in the string itself.
With SystemVerilog we can define such a standard and
do so quickly. Let's seize the opportunity.
-- johnS
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. 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 email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ H Dome ___/ | John Stickley E | a __ ___/ / \____ Principal Engineer l | l | \ / Verification Solutions Group | f | \/ ____ Mentor Grahpics Corp. - MED C \ -- / / 17 E. Cedar Place a \ __/ / / Ramsey, NJ 07446 p | / ___/ | / / mailto:John_Stickley@mentor.com \ / Phone: (201)818-2585 \ / ---------
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 12:50:16 PDT