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

Hi Dmitry:

I am not sure that any definition of vacuity for the abort operators
will be ideal in all cases. I have not been too worried because our
vacuity definition is fairly crude; more refined notions of formula and
subformula coverage can be defined and are useful.

For fails, I think that all of them require analysis, whether vacuous or
not.

J.H.

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Korchemny, Dmitry
Sent: Monday, September 13, 2010 10:43 AM
To: Seligman, Erik; sv-ac@eda.org
Subject: [sv-ac] RE: Call to vote. Due September 13

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 <http://www.mailscanner.info/> , and is
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.