Subject: Re: SV APIs (Assertion)
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Oct 01 2002 - 14:18:40 PDT
Bassam Tabbara wrote:
> J$çª
> Kev, you cc-ed sv-ec did you mean sv-ac ? (there is a mismatch in your email :-)!). I removed that from my response.
I should have CC'd both.
> 1) Thx for the email, I now understand what you meant on the phone.
>
> 2) This is -already- in SV-AC in fact a primitive form is in 3.0 (see Chapter 11), and it is slated to be done in a DAS 2.0 with an event control mechanism as you suggest. That said, I don't see what this has to do with our work here. Our task is to come up with "VPI" (design + assertions), it is a matter of conveniences that we are calling VPI (design) and API (Assertion-PI :-)!!!!!).
>
> So I'm afraid I again lost your point, we do need some access mechanism provided for external tools/utilities to traverse, read, write ("control") and so on.... Are you and I on the same page or not ?
I agree we need mechanisms to call in/out of SV for bridging to 3rd party tools, however I disagree with the approach
of writing ?PIs for functionality that would be more efficiently handled in the SV simulator. E.g. with assertions, I don't
think it's particularly useful to provide API routines that let you browse through all the assertions in a design, SV should
be able to do that itself (more efficiently), and if it can't we should be adding that functionality.
IMO, we should be working on making compiled SV code portable the way C is so that you can use it instead of C.
Kev.
> Thx.
> -Bassam.
>
> P.S. The calling C <-> SV is indeed slated for this group, again also VPI, and what I called API :-)!!
>
> Kevin Cameron wrote:
>
>> Since a lot of C and C++ functionality has been (or is being) pulled into the SV
>> language, it seems less important to me that we add new APIs. Most C/C++
>> code could probably be translated into SV and probably would compile more
>> efficiently (since it wouldn't have to go through an API).
>>
>> IMO we should concentrate on low-level cross-calling mechanisms (calling
>> C directly from SV, and C back into SV via tasks and functions), so that
>> it is easy to link libraries of SV and C/C++ code.
>>
>> WRT to the assertion API, it would make more sense to me to implement the
>> control functions (enable, diasble, reset etc.) in SV and to do call-backs as regular
>> events in SV, e.g.
>>
>> @(<assertion name>) ....
>>
>> Since the Testbench donation adds new event types beyond the Verilog "one-shot"
>> that mechanism should handle all the assertion states.
>>
>> The Assertion API requirements should be passed on to the AC committee for
>> inclusion in the SV language proper.
>>
>> Regards,
>> Kev.
>
> --
> Dr. Bassam Tabbara
> Technical Manager, R&D
>
> Novas Software, Inc.
> bassam@novas.com
> (408) 467-7893
>
>
This archive was generated by hypermail 2b28 : Tue Oct 01 2002 - 14:20:23 PDT