Re: [sv-ac] Proposal uploaded for 2938

Look good. Suggestion, add at the end a reference to 11.3.5

Note that this situation could be avoided by using the bitwise | operator,
which does not allow short-circuiting, rather than the logical || in the
assignment to a (section 11.3.5).
Ben

On Fri, Jul 9, 2010 at 10:14 AM, Seligman, Erik <erik.seligman@intel.com>wrote:

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