Re: [sv-ac] Uploaded proposal for 3385, ready for vote

Erik,
I had to struggle in understanding the explanation:
Thus upon the first failure of a1, the function error_type is called with
opcode=64, and func_assert fails and displays the message “Opcode error.”
However, there is no function call for a2, since its only argument is the
expression opcode.

May I suggest the following rephrasing:

   - The first time each assertion fails, the arguments of the action block
   are evaluated, even though the action block itself is not executed.
   - Thus upon the first failure of a1, the function $error is called and its
   argument error_type(opcode), with opcode=64, is evaluated; thus,
   func_assert fails and displays the message “Opcode error.”
   However, for a2, the arguments of function error_type is the expression
   opcode, and therefore does not need an evaluation. Thus, the function
   error_type is not evaluated in this case, and no message is displayed.

   - The pending reports with opcode=64 are placed on the deferred assertion
   report queue.

   - When block b1 is executed again, the pending reports are flushed.
   - On the second failure of assertion a1, function error_type is called
   with opcode==0, so assertion func_assert passes. The second failure of a2
   again does not result in a function call.
   - When the assertions later mature, the $error task will be called for
   a1, and the function error_type will be called for a2.

So the deferral and flushing prevented a report from the first failure of a1
as expected. But the evaluation of action block arguments, which happens
every time a pending assertion report is queued, caused a function to be
called upon each failure. In general, users must be cautious about the
contents of action blocks for deferred assertions, since the evaluation of
their arguments on every failure may seem inconsistent with the deferral in
some usages.
On Tue, May 10, 2011 at 8:38 AM, Seligman, Erik <erik.seligman@intel.com>wrote:

> Hi guys—I’ve uploaded a new proposal version at
> http://www.verilog.org/mantis/view.php?id=3385 , after making a few
> updates based on email feedback to the last one. I added a clarifying
> sentence in the first part of the deferred assertions section, to state
> explicitly that the args are immediately evaluated when the assertion is,
> and also expanded the example to include a case where the top level of the
> action block is a function call.
>
>
>
> I think it’s now ready for a vote.
>
> --
> 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.