Subject: RE: [sv-cc] collection of last comment reviews, issues and questions
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Apr 17 2003 - 09:27:32 PDT
Francoise,
my comments are interspread below (prefixed by JOAO:)
============================================================================
==
Joao Geada, PhD Principal Engineer Verif Tech
Group
Synopsys, Inc TEL: (508)
263-8083
377 Simarano Drive, Suite 300, FAX: (508)
263-8069
Marlboro, MA 01752, USA
============================================================================
==
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
Francoise Martinolle
Sent: Thursday, April 17, 2003 12:01 PM
To: sv-cc@eda.org
Subject: [sv-cc] collection of last comment reviews, issues and
questions
I found some changes and issues which need to be made to the assertion
APIs.
This is a collection of all the changes I have found in the APIs chapters. I
may have sent some individual emails but this one contains everything that I
found.
We should review all these and decide what to do.
I am now workin on the coverae API chapter.
Assertion API:
Figure 27.1:
SHould be updated to say assertion instead of property
Also we should have an iteration from interface to property and an 1 to 1
method
from the assertion back to the interface where it was found.
JOAO: OK
Section 27.2.2:
There is no more directive in the assertion chapter. These properties should
be removed. This entire section should be removed.
However I don't know if thew vpiAssertion object type handle now represent
both an assertion statement and a cover statement. Since there are still
cover statements in the assertion chapter.
Do we create a new object type called vpiCover?
JOAO: Yes, the explicit directive description is no longer in the assertion
chapter; however
there is still the notion of different types of assertion
instantiation:
concurrent assert (17.12), concurrent cover (17.12),
immediate assert (17.3)
So I believe that there is still a need to have a mapping from an
assertion to its "kind".
Possibly "directive" is no longer the correct word, maybe we should
say "assertionType".
However, the relation is still meaningful.
Section 27.3.1:
remove the 4th bullet:
4) /* room for expanding iteration later, filtering based on "object
property" e.g.
itr = vpi_iterate_property(vpiAssertion, /* property_here: e.g.
vpiCheckAssertion*/, NULL);
while (assertion = vpi_scan(itr)) {
/* process assertion *
}
JOAO: I would remove the comment, but preserve the bullet (taking into
account the prior comment re directives)
Note #2: I don't see anything called immediate non-temporal checks in the
assertion chapter; that must be the immediate assertions.
JOAO: this should be reworded to "immediate assertion", as you correctly
note below.
Change:
2—These iterators return both assertions and immediate non-temporal checks.
TO:
2—These iterators return both concurrent and immediate assertions.
Section 27.3.2:
remove:
— Assertion directive
1) assert
2) check
3) assume
4) cover
5) sequence
JOAO: No, as per prior comments re directives
Remove bullet 6) Any assertion updates from the SV-AC.
Bassam agrees.
Realign :
— Assertion source information: the file, line, and column where the
assertion is defined.
— Assertion clocking domain/expression
Change
— Assertion clocking domain/expression
TO:
— Assertion resolved clock expression
Bassam thinks that the wording is correct. clocking domain/expression.
However, I am not sure, what do we do if the assertion sequence does not
have an explicit clock expression. What is returned? This is related to
section 27.3.2.1 which describes all the static data obtained from an
assertion handle.
JOAO: Assertion instances *always* have an associated clocking expression,
explicit or implicit. This clocking expression is what is returned.
Section 27.3.2.1
remove PLI_INT32 directive; /* vpiAssume, ... */
JOAO: keep, change "directive" to "assertionType"
Change
s_vpi_source_info sourceInfo;
s_vpi_assertion_info, *p_vpi_assertion_info;
TO
s_vpi_source_info sourceInfo;
} s_vpi_assertion_info, *p_vpi_assertion_info;
I don't understand this paragraph page 268
Assertions can occur in modules and interfaces: assertions defined in
modules (by using VPI) shall have
instance information; assertions in interfaces shall have a NULL instance
handle. In either case, modname is the definition name.
1) Why would assertion in interfaces have a null instance handle?
when do they have a null instance handle. Which method returns a null
instance
handle?
JOAO: Because VPI as currently defined does not have handles for interfaces
...
We will need to extend VPI to address all the new constructs, but this
has not happened yet.
2) Isn't there a interface definition name for the interface which needs
to be returned as a definition name.
If so , we should change :
PLI_BYTE8 modname; /* name of module/interface containing
assertion */
to PLI_BYTE8 defname; /* name of module/interface containing assertion */
Because there is already a vpi property called vpiDefName in VPi to return
the definition name of a module and this is exactly what is intended here.
The idea is that individual properties should be available to retrieve the
same static information as vpi_get_assertion_info.
JOAO: Again, the problem is that there is no such thing (yet) as a handle to
an interface instance ...
3) by the way does vpi_get_assertion_info also applies to cover statements?
JOAO: Yes, cover assertions are just a type of assertion.
End of section:
Note 1):
1—The assertion clock is an event expression supplied as the clocking
expression to the assertion declaration, i.e., this is a
handle to an arbitrary Verilog event expression.
I thought it would be more interesting to get the resolved clock.
What about if there is no clocking expression in the assertion declaration
and the
clock is either inferred from the procedural context, found from a visible
clocking domain
or is the default clock visible for this assertion? Should we in all these
cases return a NULL?
Section 27.3.2.2 Extending vpi_get() and vpi_get_str()
Change:
vpi_get() can be used to query the following VPI properties from a handle to
an assertion:
vpiAssertionDirective
returns one of vpiAssertProperty or vpiCheckProperty.
vpiLineNo
returns the line number where the assertion is declared.
TO:
vpi_get() can be used to query the following VPI property from a handle to
an assertion:
vpiLineNo
returns the line number where the assertion is declared.
What about adding vpiDefName for:
vpi_get_str()
to accesss the module or interface definition name of the assertion.
Section: 27.4.2 page 270
missing }
Change :
vpiHandle *matched_exprs; /* array of expressions */
p_vpi_source_info *exprs_source_info; /* array of source info */
TO:
vpiHandle *matched_exprs; /* array of expressions */
} p_vpi_source_info *exprs_source_info; /* array of source info */
Note: I think we should change event to reason in this entire section.
This is called the callback reason in VPI.
Change all occurrences of event to reason.
Question:
IN section 27.4.2 Two callback reasons are provided and the comment is made
that the step callbacks are only enabled on a per assertion per attempt
basis.
How do you register that specific callback and specify which thread if you
can only pass a handle to the assertion instance?
reference:
cbAssertionStepSucess
the progress of one “thread” along an attempt. By default, step callbacks
are not enabled on any assertions;
they are enabled on a per-assertion/per-attempt basis, rather than on a
per-assertion basis.
cbAssertionStepFailure
failure to progress along one “thread” along an attempt. By default, step
callbacks are not enabled on any
assertions; they are enabled on a per-assertion/per-attempt basis, rather
than on a per-assertion basis.
Section 27.5.1 Assertion system control
Change:
Use vpi_control(), with one of the following operators and no other
arguments, to obtain assertion system
control information.
TO:
Use vpi_control(), with one of the following operators and no other
arguments, to control the
assertion system.
In the section 27.5 where vpi_control is described
because the assertion system is different from the simulation system (in
which some of the actions such as reset, stop, finish are defined), we may
want to describe what happen to the callbacks which have been registered if
the assertion system is either reset, stopped,etc...
We should try to be as consistent as possible with what happens in the
simulation side to callbacks registered.
Francoise
'
This archive was generated by hypermail 2b28 : Thu Apr 17 2003 - 09:30:04 PDT