[sv-ac] 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.
> >

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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