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

I like your point about using parallel bullet formats, so I tweaked it one more time.

http://www.verilog.org/mantis/view.php?id=3385

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben cohen
Sent: Tuesday, May 10, 2011 2:11 PM
To: Seligman, Erik
Cc: sv-ac@eda-stds.org
Subject: Re: [sv-ac] Uploaded proposal for 3385, ready for vote

Erik,
That's better. One more comment though. LRM states:
Actual argument expressions that are passed by value use the values of the underlying variables at the instant the deferred assertion expression was evaluated. Actual argument expressions that are passed by value, including function calls, shall be fully evaluated at the time the deferred assertion expression is evaluated.
[Ben] Maybe I am reading it wrong, or interpreting wrongly, however, I have an issue with
"However, there is no function call for a2, since the action block of a2 is itself a call to error_type, and its only argument is the expression opcode."
My issue is that the action block IS a function with arguments. Thus, to state that "
there is no function call for a2 is misleading. I think this reads better:
"However, upon the first failure of a2, the arguments of error_type are examined. Since the arguments contain an expression (opcode=64), no further evaluation is needed, and the function (error_type) is not evaluated; only if the arguments contains a function, then that function within the argument is evaluated.

I think that it would be a good idea to maintain the same format for both bullets:
* Thus upon the first failure of a1, the arguments of ..
* However, upon the first failure of a2, the arguments of
That maintains consistency.
Erik, feels free to modify this as you see fit; however, I am passing y opinions.
Ben
On Tue, May 10, 2011 at 1:22 PM, Seligman, Erik <erik.seligman@intel.com<mailto:erik.seligman@intel.com>> wrote:
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<mailto:hdlcohen@gmail.com>]
Sent: Tuesday, May 10, 2011 10:50 AM
To: Seligman, Erik; sv-ac@eda-stds.org<mailto: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<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.