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

Erik,
Great! You got a winner! I like it. It is clear.
Thanks,
Ben

On Tue, May 10, 2011 at 2:48 PM, Seligman, Erik <erik.seligman@intel.com>wrote:

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