Subject: RE: Assertions API v0.3
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Jan 14 2003 - 13:21:18 PST
Team,
I'm not very comfortable with reterming Joao's "property"
as "assertion". An assertion is built up based on properties.
For that matter, coverage directives are as well.
We should stick with a composable terminology here,
i.e. use "property" when we are dealing with the property
declaration elements of SV 3.1. It even seems to me that
in some places, Joao could change "assert" to "property"
to really be in line with "composable terminology".
(But I admit I am no expert in properties, assertions,
or coverage)
People will be able to disambiguate the different senses
of the term when they read the spec. Perhaps prefixing
property with "vpi property" when we specifically are
referring to vpi properties would be helpful to readers.
Thanks and regards,
Doug
> -----Original Message-----
> From: Bassam Tabbara [mailto:bassam@novas.com]
> Sent: Tuesday, January 14, 2003 10:03 AM
> To: 'Francoise Martinolle'; Joao.Geada@synopsys.com; 'sv-cc'
> Cc: bassam@novas.com
> Subject: RE: Assertions API v0.3
>
>
> 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.
>
> 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.
>
> 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).
>
> 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 - 13:22:19 PST