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

OK, I uploaded a new version at http://www.verilog.org/mantis/view.php?id=3385 . I took your points into account, though I then modified the phrasing further. Please take a look & see if it sounds better now.

Thanks!

From: ben cohen [mailto:hdlcohen@gmail.com]
Sent: Tuesday, May 10, 2011 10:50 AM
To: Seligman, Erik; sv-ac@eda-stds.org
Subject: 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<mailto: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<mailto: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.