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

 2nd iteration, sorry:

Thus upon the first failure of a1, the arguments of $error function are
examined. Since that argument itself includes a function call, that function
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.

On Tue, May 10, 2011 at 10:31 AM, ben cohen <hdlcohen@gmail.com> wrote:

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