Subject: Re: SV APIs (Assertion)
From: Tarak Parikh (tarak@athdl.com)
Date: Tue Oct 01 2002 - 14:17:09 PDT
Hi,
Kevin Cameron wrote:
>
>
> Bassam Tabbara wrote:
>
>> --------------------------------------------------------------
>> 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.
>
This is the important issue here. Are you suggesting that third party
tools (e.g debuggers, code coverage
etc.) write their code using SV instead of writing it in C, C++ and
interfacing with an API. I am not
saying that it may not be possible, but it would be limiting.
Tarak
>
> 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
>>
>>
>
--
Tarak Parikh tarak@athdl.com
VP Products, @HDL, Inc Tel : (408) 441-1317 x 111
Cell: (408) 219-4658
Fax : (408) 453-1721
This archive was generated by hypermail 2b28 : Tue Oct 01 2002 - 14:41:30 PDT