Re: SV APIs (Assertion)

Subject: Re: SV APIs (Assertion)
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Oct 01 2002 - 18:20:31 PDT

Your point is quite valid. However, I am not convinced.  Why do we have to re-invent the wheel ? That's the thing with language design, too often it starts out for one thing then gets bloated to the point of no return ....  C/C++ infrastructure for object code interchange is there, there will always be legacy designs in C (try to tell all your embedded SW guys they need to write their code in SV and see where that goes !!), why this headache ?

In any case, I reiterate what I said earlier, let's not digress too much, implementation is different than an API spec (I don't see any code being donated, just the spec, so what does it matter ??? We can implement in more than one way).


-Bassam.

Kevin Cameron x3251 wrote:

> From tarak@athdl.com Tue Oct  1 14:39:38 2002
> From: "Tarak Parikh" <tarak@athdl.com>
> X-Accept-Language: en
> To: "Kevin Cameron" <Kevin.Cameron@nsc.com>
> cc: "Bassam Tabbara" <bassam@novas.com>, sv-cc@eda.org
> Subject: Re: SV APIs (Assertion)
>
> 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

Considering the functional overlap between SV, C & C++ there seems less need
for programming extra functionality in C, hence less need for an API. If all
the required functionality of C is supported in SV, then the issue is what
APIs are need to make the compiled SV code portable between simulators (which
takes me back to the topic of ELF libraries and routine naming conventions).

It might be limiting in the short term, but I think it would make for cleaner
more efficient applications in the long term.

Kev.

> >
> > 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
>
>

-- 
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 - 18:21:48 PDT