RE: [sv-ac] Mantis 1756: The LRM does not indicate how the control tasks $asserton/off/kill affect verification statements in initial blocks

Ed-I took a look at this. I'm not sure if I agree with you that the below discussion covers it: if I'm reading it right, this appears to be a proposed change to assertion semantics, where initial block assertions are suspended until the first $asserton, then executed.

However, this looks to me like a potentially dangerous semantic change, so unless someone is strongly advocating for it, I agree that we should close it.

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard Cerny
Sent: Friday, July 09, 2010 1:26 PM
To: sv-ac@eda.org
Cc: Eduard Cerny
Subject: [sv-ac] Mantis 1756: The LRM does not indicate how the control tasks $asserton/off/kill affect verification statements in initial blocks

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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.