RE: [sv-ac] RE: Call to vote. Due June 28

Hi Manisha,

It should always be sufficient to keep the time of the latest global clock tick only. The overhead in $assertof/kill or disable iff should only be applicable to assertions using future global clocking sampled value functions.

Thanks,
Dmitry

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Friday, June 25, 2010 2:18 PM
To: Eduard Cerny; Korchemny, Dmitry; sv-ac@eda.org
Subject: RE: [sv-ac] RE: Call to vote. Due June 28

Hi,

I also think there is overhead of keeping extra details in this case. But this overhead is not just limited to execution of $error. I think all the assertions that have future value functions in them, will have to keep track of the time when they actually ended as the behaviour of $assertoff/kill or disable iff also depends on it.
As is clear from the following paragraph:

"The behavior of disable iff and other asynchronous assertion related controls such as $assertkill (see 20.11 and 20.12) is with respect to the interval of the evaluation attempt defined above. If, for example, $assertkill is executed in a time step strictly after the last tick of the assertion clock for the evaluation attempt, then it shall not affect that attempt, even if $assertkill is executed no later than the next global clocking tick."
So, if we really want to fix the overhead issue, we need to look at the behavior of disable iff and $assertkill etc also.

Thanks.
Manisha

________________________________
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard Cerny
Sent: Friday, June 25, 2010 2:01 AM
To: Korchemny, Dmitry; sv-ac@eda.org
Subject: [sv-ac] RE: Call to vote. Due June 28
Hello Dmitry,

I vote NO not because the proposal is incorrect in itself, but because I think that reporting the time of the preceding global clock tick

- creates overhead because you must maintain that time somewhere and in assertions distinguish whether to report current or global clock time,

- vpi - if the testbench read current time of a call back that will be different from failure time reported by the engine,

- with property operator we never report the time of the property evaluation (i.e., the start time), but rather the time when the property concluded. Reporting previous time for future value functions creates inconsistency.

best regards,
ed

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Tuesday, June 22, 2010 1:56 PM
To: sv-ac@eda.org
Subject: [sv-ac] Call to vote. Due June 28

-You have until 11.59 pm PDT, Monday, June 28, 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 June 22, 2010 meeting, the eligible voters are:

Laurence Bisht

Eduard Cerny

Ben Cohen

Surrendra Dudani

Dana Fisman

John Havlicek

Tapan Kapoor

Scott Little

Manisha Kulshrestha

Anupam Prabhakar

Tom Thatcher

SVDB 2732 ___Yes ___No
http://www.eda-stds.org/mantis/view.php?id=2732
http://www.eda-stds.org/mantis/file_download.php?file_id=4288&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.
--
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.