Subject: RE: Assertions API v0.3
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Jan 14 2003 - 15:46:50 PST
At 10:03 AM 1/14/2003 -0800, Bassam Tabbara wrote:
>Thanks Francoise,
>
>If I may emphasize/bring up a couple of the comments you made:
>
>0. I agree property/assertion have been used interchangeably we need one
>or the other. Given VPI's wording an "assertion" may seem better.
>However please note (see this in light of 1. below) the wording
>"assertion" itself may be flawed, since an "assertion" can be under
>other directives (not just "assert" but "cover", "assume" ....) with
>different meanings. I do not have a proposal on this, I think
>"assertion" is ok, as long as in (1) below we may clear that it can be
>used/applied in different contexts.
I think that we could as Doug says distinguish between the 2 with vpi
property versus
SV property.
>1. I am also not happy with the "exclusive" nature of how the
>"directive" enums are defined/used. Some combinations of directives may
>not make sense, for others it might e.g. "assert" && "cover" attributes
>it might. More importantly for an API to be general these really need to
>be defined and used (in routines) as "attributes" (VPI object properties
>as the document states) since this attribute set is not yet defined in
>AC, and will necessarily never be exhaustive.
You can define the numeric constants for vpiAssert, vpiCover so that
you can interpret the returned integer from the vpi property vpiDirective
to mean
any combination of the directive kinds. however you are limited to 5 bit flags.
Otherwise, you are required to create a VPI property for each of the
directive types
which will return true or false and you have to use several calls of that
vpiDirective
property to determine the set of directives associated with the SV property.
>1.1 A follow-up on (1) is that we need ADDITIONAL control APIs to be
>able to SET an attribute on an assertion. Right now the assumption is
>that the property is defined as : -object property (a.k.a)
>directive- assertion_body_here. The API should control -how- the
>assertion is used i.e. without user changing the source, the assertion
>may be used in different contexts (asserted initially, then "assume"d in
>other runs (to improve performance), used as a "model" in other places
>and so on...). So the "directives" are really an input that the
>(control) API needs to specify. Joao does this make sense ? In OVA these
>directives are in the language but in SV-AC we are staying away from
>putting in the language since they depend on usage (i.e. tool run).
That is not a bad idea that the tool should be able to control how the SV
property
is used by the tool.
>Thanks.
>
>-Bassam.
>
>--
>Dr. Bassam Tabbara
>Technical Manager, R&D
>Novas Software, Inc.
>
>http://www.novas.com
>(408) 467-7893
>
> > -----Original Message-----
> > From: owner-sv-cc@server.eda.org
> > [mailto:owner-sv-cc@server.eda.org] On Behalf Of Francoise Martinolle
> > Sent: Tuesday, January 14, 2003 8:32 AM
> > To: Joao.Geada@synopsys.com; sv-cc
> > Subject: Re: Assertions API v0.3
> >
> >
> > Comments on the last rev.
> >
> > 0. there is a little bit of confusion because are using the
> > word property
> > in 2 different senses.
> > In VPI terminology a property in VPI is like an attribute of
> > an object
> > type. Here the assertion proposal talks about properties as
> > syntactical
> > objects of the SV
> > language. I was wondering if we would not want to use a different
> > terminolgy for the assertion? You use the term assert_hanlde
> > to denote a
> > property type object handle
> > in some parts of the document
> >
> > 1.the numeric ids for the VPI objects types, object
> > properties, callbacks
> > and control constants can all start at 700 because they are used by
> > different VPI functions.
> >
> > 2. VPI distinguish integer/enumeration properties from string
> > properties.
> > I think we should have only an integer property
> > vpiDirective which can
> > return the kind of
> > directive on the property.
> > #define vpiDirective 700
> > which can return vpiAssert, vpiAssume, ....
> > ex: vpi_get(vpiDirective, propObjHdl)
> > The property vpiDirective applied to a handle of
> > type vpiProperty
> > (denoting a property)
> > will return one the the following defined constants:
> > vpiAssert, vpiAssume...
> > where #define vpiAssert 1
> > #define vpiAssume 2 etc...
> > The integer property list should contain
> > #define vpiLineNo // return the source line number of the assertion
> >
> > The object property list should also contain the list of
> > string properties:
> >
> > #define vpiName which can return the property name (used with
> > vpi_get_str
> > therefore
> > the number associated with this string property can be again
> > #define vpiFileName
> >
> > Note that the vpiLineNo, vpiName and vpiFileName properties
> > are already
> > available in VPI
> > for other types of objects and therefore we can use the standard VPI
> > properties we don't ned to redefine them.
> >
> > 3. the object diagram for property access should list the VPI
> > properties
> > which can be
> > applied to a property typed object:
> > vpiDirective, vpiName etc...
> > It should also list the other functions which you can applied
> > to an object
> > hanlde of type
> > vpiProperty.
> > Ex: vpi_get_property_info, vpi_register_property_cb, vpi_control.
> >
> > 4. question: the clk_expression, failed_expression etc... are
> > now vpiHandles. I like this better than providing the string
> > expression but I don't
> > remember the decision.
> > Is this change intentional?
> >
> >
> > At 11:45 PM 1/10/2003 -0500, Joao Geada wrote:
> >
> > >Attached is the update to the assertions API (VPI extensions). This
> > >includes the numeric ids updated as per the feedback from
> > >Francoise/Charles (reserved number range from IEEE VPI
> > working group),
> > >updates to the step api as per discussions with Bassam & updates as
> > >requested from the last review meetings
> > >
> > >Joao
> > >=============================================================
> > =================
> > >Joao Geada, PhD Principal Engineer
> > Verif Tech Group
> > >Synopsys, Inc
> > TEL: (508) 263-8083
> > >344 Simarano Drive, Suite 300,
> > FAX: (508) 263-8069
> > >Marlboro, MA 01752, USA
> > >=============================================================
> > ==========
> > >=======
> >
This archive was generated by hypermail 2b28 : Tue Jan 14 2003 - 15:47:27 PST