Hello,
the mantis item was created early in 2007, before the new semantics of procedural assertions were defined in which case the specification of how the control tasks affect assertions in initial blocks was necessary. However, with the semantics as defined in the LRM, I do not believe that any further explanation is required.
In Clause 20.11, it states:
SystemVerilog provides the following three system tasks to control the evaluation of assertion statements:
- $assertoff shall stop the checking of all specified assertions until a subsequent $asserton. An
assertion that is already executing, including execution of the pass or fail statement, is not affected.
In the case of a deferred assertion (see 16.4), currently queued reports are not flushed and may still
mature, though further checking is prevented until the $asserton. In the case of a pending procedural
assertion instance (see 16.15.6), currently queued instances are not flushed and may still
mature, though no new instances may be queued until the $asserton.
- $assertkill shall abort execution of any currently executing specified assertions and then stop
the checking of all specified assertions until a subsequent $asserton. This also flushes any queued
pending reports of deferred assertions (see 16.4) or pending procedural assertion instances (see
16.15.6) that have not yet matured.
- $asserton shall reenable the execution of all specified assertions.
I think that it covers both assertions in always and in initial procedures.
Let me know if you agree, if yes, I will close the mantis item.
best regards,
ed
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Jul 9 13:26:42 2010
This archive was generated by hypermail 2.1.8 : Fri Jul 09 2010 - 13:26:51 PDT