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.Received on Fri Jul 9 10:15:01 2010
This archive was generated by hypermail 2.1.8 : Fri Jul 09 2010 - 10:15:18 PDT