[sv-ac] RE: Proposal uploaded for 2938

Ah, I see. You're right, it's a reasonable interpretation that the flush point (upon procedure re-entry) should cause the simulator to treat it as not ever evaluated. I should fix that description.

-----Original Message-----
From: Bresticker, Shalom
Sent: Monday, July 12, 2010 9:55 AM
To: Seligman, Erik; sv-ac@server.eda.org
Subject: RE: Proposal uploaded for 2938

"evaluate", yes.
But I was referring to "reported that p1 was evaluated and passed".

I don't believe that was the intent of the LRM with respect to deferred assertions.

Shalom

> -----Original Message-----
> From: Seligman, Erik
> Sent: Monday, July 12, 2010 6:39 PM
> To: Bresticker, Shalom; sv-ac@server.eda.org
> Subject: RE: Proposal uploaded for 2938
>
> You're right that this is a similar case. I do think that it's less of
> an issue here than with short-circuiting, because if the user had an
> explicit 'if', it's more clear that the function will only be executed
> when the condition is passing. Maybe I should add this example too.
>
> But I don't understand your comment that it might be a tool problem.
> Isn't any tool required to evaluate as I describe in the example, in
> order to comply with the language definition?
>
> -----Original Message-----
> From: Bresticker, Shalom
> Sent: Sunday, July 11, 2010 4:21 AM
> To: Seligman, Erik; sv-ac@server.eda.org
> Subject: RE: Proposal uploaded for 2938
>
> Erik,
>
> You wrote, "At the end of the time step, the simulator has reported
> that p1 was evaluated and passed, even though the final values for the
> time step would violate it."
>
> Maybe this is a tool problem.
>
> Suppose the code had been written this way:
>
> always_comb
> if (!b) f1(c);
>
> You would get the same behavior, wouldn't you?
>
> And this is without any short-circuiting operator.
>
> I would not expect the simulator to report the assertion as evaluated
> in this case.
>
> Regards,
> Shalom
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Seligman, Erik
> > Sent: Friday, July 09, 2010 8:15 PM
> > To: sv-ac@server.eda.org
> > Subject: [sv-ac] Proposal uploaded for 2938
> >
> > Hi guys-- I have uploaded a proposal at http://www.eda-
> > stds.org/mantis/view.php?id=2938 . Please take a look & send
> comments.
> >
> > >-----Original Message-----
> > >From: Accellera Mantis Bug Tracker [mailto:mantis@eda.org]
> > >Sent: Monday, June 28, 2010 4:47 AM
> > >To: Seligman, Erik
> > >Subject: [SystemVerilog P1800 0002938]: Surprising (to some users)
> > >interaction between deferred assertions & short-circuiting
> > >
> > >
> > >The following issue has been ASSIGNED.
> >
> >======================================================================
> > >http://www.eda-stds.org/mantis/view.php?id=2938
> >
> >======================================================================
> > >Reported By: Erik_Seligman
> > >Assigned To: Erik_Seligman
> >
> >======================================================================
> > >Project: SystemVerilog P1800
> > >Issue ID: 2938
> > >Category: SV-AC
> > >Reproducibility: always
> > >Severity: feature
> > >Priority: normal
> > >Status: assigned
> > >Type: Clarification
> >
> >======================================================================
> > >Date Submitted: 2009-12-30 13:03 PST
> > >Last Modified: 2010-06-28 04:46 PDT
> >
> >======================================================================
> > >Summary: Surprising (to some users) interaction
> > >between
> > >deferred assertions & short-circuiting
> > >Description:
> > >Consider this piece of code:
> > > function f1(v)
> > > p1: assert #0 (v)
> > > ...
> > > always_comb begin: myblk
> > > a = b || f1(c)
> > >
> > >Now suppose, during some time step, the following happens:
> > >- Initially b is set to 0 while c==1, and myblk is entered. When f1
> > is
> > >called, assertion p1 has a passing value.
> > >- Later in the time step b settles at a value of 1, while c becomes
> 0.
> > >This time, due to short-circuiting, f1 is never evaluated-- so the
> new
> > >failing value of assertion p1 is never seen.
> > >- At the end of the time step, the simulator has reported that p1
> was
> > >evaluated and passed, even though the final values for the time step
> > >would
> > >violate it.
> > >
> > >Strictly speaking, this is not a problem-- it's the behavior caused
> by
> > >the
> > >spec. But some of our designers have been caught off-guard, as it
> > >violates
> > >the intuition that a deferred assertion's result reflects the final
> > >settled
> > >values for each time step. It could actually be quite dangerous, in
> > >that
> > >the missed assertion failure could be seen as a false positive in
> > >testing.
> > >
> > >We had a proposal to hack our tools to turn off short-circuiting if
> > any
> > >later term contains assertions, but realized that that would be
> > >dangerous,
> > >as it wouldn't be backwards-compatible, and some clever users may be
> > >intentionally causing this type of behavior.
> > >
> > >So... Should we do something about this? Due to the way it
> violates
> > >intuitive notions of deferred assertions, I think we should consider
> > >adding an example of this specific case to the deferred assertions
> > >section, or at least including such an example in supplemental
> > >clarifications documents.
> > >
> >
> >======================================================================
> > >
> > >--------------------------------------------------------------------
> --
> > > (0009207) shalom (manager) - 2009-12-30 21:34
> > > http://www.eda-stds.org/mantis/view.php?id=2938#c9207
> > >--------------------------------------------------------------------
> --
> > >Another reason not to use logical operators where a bit-wise
> operator
> > >will
> > >do the job just as well.
> > >
> > >Issue History
> > >Date Modified Username Field Change
> >
> >======================================================================
> > >2009-12-30 13:03 Erik_Seligman New Issue
> > >2009-12-30 13:03 Erik_Seligman Type =>
> > >Clarification
> > >2009-12-30 13:04 Erik_Seligman Issue Monitored: Erik_Seligman
> > >
> > >2009-12-30 21:33 shalom Issue Monitored: shalom
> > >2009-12-30 21:34 shalom Note Added: 0009207
> > >2010-06-28 04:46 Dmitry KorchemnyStatus new =>
> > >assigned
> > >2010-06-28 04:46 Dmitry KorchemnyAssigned To =>
> > >Erik_Seligman
> >
> >======================================================================
> > >
> > >
> > >--
> > >This message has been scanned for viruses and
> > >dangerous content by MailScanner, and is
> > >believed to be clean.
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.