[sv-ac] RE: Seeking comments/ideas on Mantis 3385 (assert #0 (bad) else my_task(foo(v));)

Hi Erik,

I am not convinced that the LRM is not clear. It says:
When a deferred assertion declared with assert #0 passes or fails, the action block is not executed
immediately. Instead, the action block subroutine call (or $error, if an assert or assume fails and no
action_block is present) and the current values of its input arguments are placed in a deferred assertion
report queue associated with the currently executing process. Such a call is said to be a pending assertion
report.
The assertion fails when the boolean is false, like an immediate assertion. These are then the current values. It is placed on the queue and if not flushed then scheduled to reactive region to execute. In the example, my interpretation is that the argument function is evaluate at the time assertion boolean is false, saved on the queue, and used iff the entry is not flushed.

Best regards,
ed

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Friday, April 08, 2011 4:06 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] Seeking comments/ideas on Mantis 3385 (assert #0 (bad) else my_task(foo(v));)

Hi guys-

In 3385 (http://www.verilog.org/mantis/view.php?id=3385) we have some debate over whether the restriction of a "single subroutine call" in the action block of a deferred assertion (see 16.4) is meant to prohibit situations like this:

assert #0 (bad) else my_task(foo(v));

As Steve Sharp commented, "the text only says that the immediate values of the variables are used in the evaluation, without saying when that evaluation takes place". There may be problems if foo(v) is not evaluated until the deferred assertion matures; for example, v may be an automatic variable that is gone by then. Several solutions are mentioned in the thread in that Mantis:

1. Strictly interpret the "single subroutine call" to prohibit a nested function call like this. If we go this route, we should probably add this example to the LRM & explain why it's an illegal case.

2. Specify that the "single subroutine call" is only meant to require that a single task or system function is called, and its arguments may be multiple functions. In this case, I think we will need to add the requirement that we evaluate all arguments at the time the deferred assertion is evaluated (==> not waiting until it matures), with the risk that side effects may be glitchy if the assertion is later flushed, while only deferring the top-level subroutine call.

I don't recall our discussion of the original restriction, so I don't have a strong opinion on whether #1 or #2 is best. I am slightly inclined towards #2 if it's OK, as that adds some useful flexibility to deferred assertions.

Do any of you have a strong opinion one way or the other on this issue?

Dmitry, pls put this on the agenda for our next meeting, as I would like some discussion before I attempt to write up a proposal.

--
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.