Clause: 17.2
Description
Currently, LRM mentions that pass action block is executed whenever property returns true. This causes pass actions to be executed for vacuous succeses. This makes pass action blocks unusable in a lot of cases.
Suggested Resolution
Clause 17.13.1, change the following on page 274:
The assert statement is used to enforce a property as a checker. When the property for the assert statement is evaluated to be true, the pass statements of the action block are executed. Otherwise, the fail statements of the action_block are executed. The execution of pass and fail actions can be controlled by using assertion action control tasks. The assertion action control tasks are described in 22.19.
Clause 17.16, change the following on page 287:
When executed, the expect statement starts a single thread of evaluation for the given property on the subsequent clocking event, that is, the first evaluation shall take place on the next clocking event. If the property fails at its clocking event, the optional else clause of the action block is executed. If the property succeeds the optional pass statement of the action block is executed. The execution of pass and fail statements can be controlled by using assertion action control tasks. The assertion action control tasks are described in 22.19.
Clause 17.13.3, change the following on page 276:
In addition, statement_or_null is executed every time a property succeeds without a vacuous or disabled success.
Add the following new section:
22.19 Assertion action control system tasks
|
assert_action_control_task ::= assert_action_control_task [ ( levels [ , list_of_modules_or_assertions ] ) ] ; assert_action_control_task ::= $assertpasson | $assertpassoff | $assertfailon | $assertfailoff | $assertvacuouson | $assertvacuousoff | $assertdisabledon | $assertdisabledoff list_of_modules_or_assertions ::= module_or_assertion { , module_or_assertion } module_or_assertion ::= module_identifier | assertion_identifier | hierarchical_identifier
|
Syntax 22-7—Assertion pass action control syntax (not in Annex A)
SystemVerilog provides eight system tasks to control execution of assertion action block for concurrent assertions:
— $assertpassoff shall stop execution of pass action of all specified assertions until a subsequent $assertpasson. It affects the assertions that are currently executing.
— $assertfailoff shall stop execution of fail action of all the specified assertions until a subsequent $assertfailon. It affects the assertions that are currently executing.
— $assertvacuousoff shall stop execution of pass action of all specified assertions on vacuous success until a subsequent $assertvacuouson. It affects the assertions that are currently executing.
— $assertdisabledoff shall stop execution of pass action of all specified assertions on disabled success until a subsequent $assertdisabledon. It affects the assertions that are currently executing.
— $assertpasson shall enable execution of pass action of all specified. It affects the assertions that are currently executing.
— $assertfailon shall enable execution of fail action of all the specified. It affects the assertions that are currently executing.
— $assertvacuouson shall enable execution of pass action of all specified assertions on vacuous success. It affects the assertions that are currently executing.
— $assertdisabledon shall enable the execution of pass action of all specified assertions on disabled success. It affects the assertions that are currently executing.
When invoked with no arguments, the system task shall apply to all assertions. When the task is specified with
arguments, the first argument indicates levels of the hierarchy, consistent with the corresponding argument to the
Verilog $dumpvars system task. Subsequent arguments specify which scopes of the model to control. These
arguments can specify entire modules or individual assertions.