Subject: Re: SV APIs (Assertion)
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Oct 01 2002 - 10:55:49 PDT
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 ?
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 - 10:56:38 PDT