[sv-ac] RE: Proposal uploaded for 2938

Actually, I think this may be a clarification worth another Mantis. Looking at the exact language in our description of flush points, I see "If a violation report flush point is reached in a process, its violation report queue is cleared. Any pending violation reports are discarded." We don't clearly state that the assertion should be treated as not attempted.

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

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