Subject: Re: Vote on the assertion API
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Oct 08 2002 - 06:01:15 PDT
At 04:14 PM 10/7/2002 -0700, Bassam Tabbara wrote:
>[FYI, I had voted on Friday: "...my vote is YES for donated OVA API to be
>a starting point. I would like to request that Synopsys provide the
>updated spec docs (with assertion expression/var/... access) to the
>committee and scrap the old version"]
>
>Salut Francoise, thanks, your comments are so powerful and technically
>valid. Permit me to overlay my thinking and take the edge off the strong
>remarks a bit.
>
>Francoise Martinolle wrote:
>>I am voting NO on behalf of Cadence because I cannot accept a technical
>>proposal for
>>an assertion API *before* the assertion language or System Verilog
>>extensions for assertions are defined.
>It is not fruitful for us to "block" awaiting detailed level info from
>assertion API. Several of us are involved there and know the "high order
>bits" ... in defining an access API (and a basic one at that), so it seems
>reasonable (for SV-CC fork) to build some layer for interaction (granted
>it may be "tf" not "acc" !) that is very useful.
My intent was not to prevent the definition of an assertion API but to say
that it is premature to define the API before the language is settled. We
will end up doing the work twice.
>>Secondly I believe that the assertion API should be defined as VPI
>>extensions if the assertions are part of the language otherwise we would
>>have 2 APIs ( VPI and SV-AssertionAPI)
>>to access the same thing. You should be able to traverse your design
>>using VPI
>>and use also VPI to access the assertions and not switch to a different API.
>>note: that the API that is proposed has the same access mechanisms as VPI
>> (iterators, callbacks, ...) which reinforces my opinion regarding the
>>feasibility of
>>extending VPI to access assertions.
>Totally agreed! However to put a minor twist, I think orthogonalization of
>issues would be suitable here... It makes perfect sense to have a layer of
>API that access only assertions (data). If you want to pull this API into
>VPI, that's fine. In fact yes we can build a separate class/access
>hierarchy for this into VPI.
It was also my view that you would define assertion object classes and
specialized methods to access the assertions.
> I feel throught our discussions we have read too much into a specific
> implementation (a C API implementation) of something, as opposed to
> thinking of it as a spec.
>>
>>Lastly, the assertion API as presented and defined is insufficient in terms
>>of the access that would be needed by 3rd party tools. We should have more
>>detailed requirements for the
>>assertion API.
>Indeed. However we need something to start with (or nothing will get
>done). Once we have a basic shell, everybody can contribute.
Yes, but sometimes it is better to start from scratch or at least from
requirements.
>--
>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 08 2002 - 06:05:14 PDT