Subject: RE: Assertions API v0.3
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Tue Jan 14 2003 - 16:10:50 PST
Bassam,
0: see the reply I sent to Francoise. Primarily I believe it is important to
be consistent with respect to the SV language definition.
1: I am not sure that sv-ac has permitted a property to be given any more
that one directive. In the last spec I was provided this was not the case.
Given that, the 1-to-1 mapping of property to directive should be OK.
Should this change, then this would need to become a 1-to-many mapping,
which by necessity would need to use the vpi_iterate() protocol. As this
is significantly more complex and expensive, I'd prefer to wait until sv-ac
changes their decision before making changes here.
1.1: is such control of assertions directive something that can be done on the fly
*in the middle of simulation* ? That is the effect of extending such
control via VPI. I believe what you want is reasonable, but this is
something that would apply to temporal properties to all consumers
(simulation, coverage, formal tools, hw accelerators, etc), and as
such would appear something best expressed as a design configuration or similar.
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
==============================================================================
-----Original Message-----
From: Bassam Tabbara [mailto:bassam@novas.com]
Sent: Tuesday, January 14, 2003 1:03 PM
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
This archive was generated by hypermail 2b28 : Tue Jan 14 2003 - 16:16:10 PST