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