[sv-ac] RE: Proposal uploaded for 2938

Not only a "reasonable interpretation", I think it is the expected and required interpretation.

Shalom

> -----Original Message-----
> From: Seligman, Erik
> Sent: Monday, July 12, 2010 7:59 PM
> To: Bresticker, Shalom; sv-ac@server.eda.org
> Subject: 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.
> > >

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