Section 27.1.2

LRM-306

Changes (delete entire section):

27.1.2 Nomenclature

 

The following terms are used in this standard.

 

Directive—a type applied to a temporal expression describing how the results of the temporal expression are to be captured and/or interpreted.

 

Assertion clock—the Verilog event expression that indicates to an assertion when time has advanced (and when HDL signals can be sampled, etc.).

 

Assertion Temporal expression—A declarative expression (one or more clock cycles) describing the behavior of a system over time.

Section 27.2.1

LRM-307

Changes:

 

This section lists the object type VPI calls. The VPI reserved range for these calls is 700 - 729.

Section 27.2.2

LRM-308

Changes:

This section lists the object property VPI calls. The VPI reserved range for these calls is 700 - 729.

 

#define vpiAssertionType 700

 

/* Directives as properties Assertion types */

 

#define vpiSequenceAssertion vpiSequenceType    701

#define vpiAssertAssertion vpiAssertType        702

#define vpiAssumeAssertion vpiCoverType         703

#define vpiRestrictAssertion vpiPropertyType    704

#define vpiCoverAssertion vpiImmediateAssertType 705

#define vpiCheckAssertion         705 /* inlined behavior assertion */

#define vpiOtherDirectiveAssertion 706 /* placeholder for other assertion directive */

Section 27.2.3

LRM-309

Changes:

This section lists the system callbacks. The VPI reserved range for these calls is 700 - 719.

Section 27.2.4

LRM-310

Changes:

This section lists the system control constant callbacks. The VPI reserved range for these calls is 730 - 759.

Section 27.3.1

LRM-311

Changes:

In Figure 27-1 replace the word property with the word assertion.

Changes:

Note: Iteration on assertions from interfaces is not shown in Figure 27-1 since the interface object type is not currently defined in VPI. However the assertion API permits iteration on assertions from interface instance handles and obtaining static information on assertions used in interfaces (see Section 27.3.2.1).

 

1) Iterate all assertions in the design: use a NULL reference handle (ref) to vpi_iterate(), e.g.,

LRM-312

Changes:

4) /* room for expanding iteration later, filtering based on "object property" e.g. To obtain an assertion of a specific type, e.g. cover assertions, you should use an approach as follows:

 

vpiHandle assertion;

itr = vpi_iterate_property(vpiAssertionType, /* property_here: e.g. vpiCheckAssertion*/, NULL);

while (assertion = vpi_scan(itr)) {

/* process assertion *

if (vpi_get(vpiAssertionType, assertion) == vpiCoverType) {

/* process cover type assertion */

}

}

LRM-313

Changes:

NOTES

 

1—As with all VPI handles, assertion handles are handles to a specific instance of a specific assertion.

 

2—These iterators return both assertions and immediate non-temporal checks.

 

32Unnamed assertions cannot be found by name.

Section 27.3.2

LRM-314

Changes:

— Assertion directive type

1) assert Sequence

2) check Assert

3) assume Cover

4) cover Property

5) sequence ImmediateAssert

Section 27.3.2.1

LRM-315

Changes (notice change in indent):

typedef struct t_vpi_source_info {

PLI_BYTE* *fileName;

PLI_INT32 startLine;

PLI_INT32 startColumn;

PLI_INT32 endLine;

PLI_INT32 endColumn;

} s_vpi_source_info, *p_vpi_source_info;

typedef struct t_vpi_assertion_info {

PLI_BYTE8 *name;     /* name of assertion */

vpiHandle instance;  /* instance containing assertion */

PLI_BYTE8 modname defname; /* name of module/interface containing assertion */

vpiHandle clock;     /* clocking expression */

PLI_INT32 directive assertionType; /* vpiAssume vpiSequenceType, ... */

s_vpi_source_info sourceInfo;

} s_vpi_assertion_info, *p_vpi_assertion_info;

int vpi_get_assertion_info (assert_handle, p_vpi_assertion_info);

LRM-316

Changes:

Assertions can occur in modules and interfaces: for 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.  the instance field in the s_vpi_assertion_info structure shall contain the handle to the appropriate module or interface instance. Note that VPI does not currently define the information model for interfaces and therefore the interface instance handle will be implementation dependent. The clock field of that structure contains a handle to the event expression representing the clock for the assertion, as determined by Section 17.13

 

NOTE: a single call returns all the information for efficiency reasons.

 

NOTES

 

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.

2—A single call returns all the information for efficiency reasons.

Section 27.3.2.2

LRM-317

Changes:

vpi_get() can be used to query the following VPI propertiesy from a handle to an assertion:

 

vpiAssertionDirective vpiAssertionType

returns one of vpiAssertProperty or vpiCheckProperty vpiSequenceType, vpiAssertType, vpiCoverType, vpiPropertyType, vpiImmediateAssertType.

Section 27.4.2

LRM-318

Changes:

vpiHandle vpi_register_assertion_cb(

vpiHandle,           /* handle to assertion */

PLI_INT32 event reason,    /* event reason for which callbacks needed */

PLI_INT32 (*cb_rtn)( /* callback function */

PLI_INT32 event reason,

vpiHandle assertion,

p_vpi_attempt_info info,

PLI_BYTE8 *userData),

PLI_BYTE8 *user_data /* user data to be supplied to cb */

);

Changes:

where event reason is any of the following.:

Section 27.4.2

LRM-319

Changes:

cbAssertionStepSuccess

the progress one step along one path through the an attempt. By default, step callbacks are not enabled on any assertions; they are enabled on a per-assertion/per-attempt basis (see Section 27.5.2), rather than on a per-assertion basis.

 

cbAssertionStepFailure

failure to progress by one step 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 (see Section 27.5.2), rather than on a per-assertion basis.

LRM-318

Changes:

The callback function shall be supplied the following arguments:

 

1) the event that caused reason for the callback

Section 27.5.1

LRM-320

Changes:

Usage example: vpi_control(vpiAssertionSysReset)

 

vpiAssertionSysReset

discards all attempts in progress for all assertions and restores the entire assertion system to its initial state. Any pre-existing vpiAssertionStepSuccess and vpiAssertionStepFailure callbacks will be removed, all other assertion callbacks will remain.

 

Usage example: vpi_control(vpiAssertionSysStop)

 

vpiAssertionSysStop

considers all attempts in progress as unterminated and disables any further assertions from being started. This control has no effect on pre-existing assertion callbacks.

 

Usage example: vpi_control(vpiAssertionSysStart)

 

vpiAssertionSysStart

restarts the assertion system after it was stopped (e.g., due to vpiAssertionSysStop). Once started, attempts shall resume on all assertions. This control has no effect on prior assertion callbacks.

 

Usage example: vpi_control(vpiAssertionSysEnd)

 

vpiAssertionSysEnd

discard all attempts in progress and disables any further assertions from starting. All assertion callbacks currently installed will be removed. Note that once this control is issued, no further assertion related actions are permitted.