Subject: [sv-cc] collection of last comment reviews, issues and questions
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Apr 17 2003 - 09:00:45 PDT
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.
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?
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 *
}
Note #2: I don't see anything called immediate non-temporal checks in the assertion chapter; that must be the immediate assertions.
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
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.1which describes all the static data obtained from an assertion handle.
Section 27.3.2.1
remove PLI_INT32 directive; /* vpiAssume, ... */
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?
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.
3) by the way does vpi_get_assertion_info also applies to cover statements?
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:01:34 PDT