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

From: Seligman, Erik <erik.seligman@intel.com>
Date: Fri Apr 08 2011 - 13:05:37 PDT

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, and is
believed to be clean.
Received on Fri Apr 8 13:06:03 2011

This archive was generated by hypermail 2.1.8 : Fri Apr 08 2011 - 13:06:09 PDT