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