[sv-ac] RE: Call to vote. Due September 13

From: Korchemny, Dmitry <dmitry.korchemny@intel.com>
Date: Mon Sep 13 2010 - 08:43:23 PDT

I think that this is first of all a specific question about aborts: if the abort condition is true, should we consider the property evaluation as vacuous? Of course, there are many different definitions of vacuity, we should select the most basic one.

According to our definition (scan || read_cond) is never vacuous as a Boolean expression. 16.15.8 Nonvacuous evaluations reads:

An evaluation attempt of a property that is a sequence is always nonvacuous.

If we rewrite you property as (scan or read_cond) it will still have only nonvacuous evaluations:

An evaluation attempt of a property of the form property_expr1 or property_expr2 is nonvacuous if, and only if, either the underlying evaluation attempt of property_expr1 is nonvacuous or the
underlying evaluation attempt of property_expr2 is nonvacuous.

since property_expr1, 2 are Boolean in our case.

Thanks,
Dmitry

From: Seligman, Erik
Sent: Monday, September 13, 2010 5:17 PM
To: Korchemny, Dmitry; Korchemny, Dmitry; sv-ac@eda.org
Subject: RE: Call to vote. Due September 13

Isn't this a common problem for vacuity though, if the user decides to 'cheat' and use parts of the definition in different ways than intended?

We also see bogus vacuity reports when we have combo assertions that account for enable bits, such as (scan || real_cond), always having a vacuous term when scan is tied low for FPV.

I think there is a bigger question here, about whether we should consider some language mechanism for better vacuity checking control.

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Sunday, September 12, 2010 1:38 PM
To: Korchemny, Dmitry; sv-ac@eda.org
Subject: [sv-ac] RE: Call to vote. Due September 13

Hi all,

Some thoughts about vacuity definition for aborts.

Sometimes the only possible success or failure of a property with aborts is a vacuous one. This is not specific to synchronous aborts. Consider the following example:

sig should remain high at least n clock ticks after rise.

!sig ##1 sig |-> reject_on(!sig) 1'b1[*n + 1]

According to our definition this property may have only vacuous failures, though I would not define them as such.

Thanks,
Dmitry

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Wednesday, September 08, 2010 12:13 PM
To: sv-ac@eda.org
Subject: [sv-ac] Call to vote. Due September 13

-You have until 11.59 pm PDT, Monday, September 13, 2010 to respond

-An issue passes if there are zero NO votes and half of the eligible

 voters respond with a YES vote.

-If you vote NO on any issue, your vote must be accompanied by a reason.

 The issue will then be up for discussion during a future conference

call.

-Note: For some issues, the proposed action is captured in the bug note

       (resolve as duplicate, already addressed, etc.).

As of the September 7, 2010 meeting, the eligible voters are:

Laurence Bisht

Eduard Cerny

Ben Cohen

Surrendra Dudani

John Havlicek

Tapan Kapoor

Manisha Kulshrestha

Scott Little

Anupam Prabhakar

Erik Seligman

Samik Sengupta

Tom Thatcher

SVDB 2452 ___Yes ___No
http://www.eda-stds.org/mantis/view.php?id=2452
http://www.eda-stds.org/mantis/file_download.php?file_id=4379&type=bug

---------------------------------------------------------------------

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<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, 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.
Received on Mon Sep 13 08:44:22 2010

This archive was generated by hypermail 2.1.8 : Mon Sep 13 2010 - 08:44:26 PDT