Re: Vote on the assertion API

Subject: Re: Vote on the assertion API
From: Bassam Tabbara (bassam@novas.com)
Date: Mon Oct 07 2002 - 16:14:47 PDT

[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.
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. 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. 
-- 
Dr. Bassam Tabbara
Technical Manager, R&D

Novas Software, Inc.
bassam@novas.com
(408) 467-7893
 

This archive was generated by hypermail 2b28 : Mon Oct 07 2002 - 16:18:26 PDT