[sv-ac] RE: Mantis issue assignment

Hi Surrendra,

I agree, as long as we change "becomes" to "is" since the formal semantics says nothing about expression_or_dist changing, only about it holding. So the revised proposal is:

If the disable condition is true at anytime between the start of the observed region of the time step in which the evaluation attempt begins and the end of the observed region of the time step in which the attempt ends then the overall evaluation of the property results in disabled.

Dana

From: Surrendra Dudani [mailto:dudani@synopsys.COM]
Sent: Tuesday, July 13, 2010 6:09 PM
To: 'Dana Fisman'; 'Korchemny, Dmitry'; sv-ac@eda.org
Subject: RE: Mantis issue assignment

Hi Dana,
Regarding item 0002904, I think it should say something like,

 If the disable condition becomes true at anytime between the start of the observed region of the time step in which the evaluation attempt begins and the end of the observed region of the time step in which the attempt ends then the overall evaluation of the property results in disabled.

Surrendra
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Dana Fisman
Sent: Tuesday, July 13, 2010 2:56 AM
To: 'Korchemny, Dmitry'; sv-ac@eda.org
Subject: [sv-ac] RE: Mantis issue assignment

Proposals for the following mantis items have been uploaded.

0002452: No vacuity information about synchronous aborts
http://www.eda-twiki.org/mantis/view.php?id=2452

0002904: Clarify when disable iff condition must occur relative to starting and ending of an attempt http://www.eda-twiki.org/mantis/view.php?id=2904

0003134: sequence and property range parameters are erroneously defined
http://www.eda-twiki.org/mantis/view.php?id=3134

0003135: Verbal explanation of nexttime and always is misleading for multiple clocks.
http://www.eda-twiki.org/mantis/view.php?id=3135

Please review and comment.

Thanks,
Dana

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Monday, June 28, 2010 8:16 AM
To: sv-ac@eda.org
Subject: [sv-ac] Mantis issue assignment

Hi all,

Below is the list of Mantis items along to their assignment to the committee members. I also updated the ownership in Mantis except for those people who do not have a developer Mantis account.

Actions required:

* Address each Mantis item assigned. This may be done in one of the following ways:

o Write a solution proposal

o Argue that the Mantis item does not need to be implemented

o Argue that the Mantis item resolution may be postponed to the next PAR

* Present and discuss the resolution in SV-AC meetings or request an email ballot.

Effort allocation

* One Mantis item resolution in two weeks per person. Larger Mantis items may require more time to address.

2353

 'classes' missing from description

Anupam

2546

 'empty match' and 'vacuous success' are not clearly defined in LRM

Anupam

2934

 Precedence and associativity of case operator is not shown in the table

Anupam

2825

 16.16 Disable iff checkers not included in list of default extensions

Ben

2927

 Precedence between sequence/property operator and normal expression operator

Ben

2452

 No vacuity information about synchronous aborts

Dana

2904

 Clarify when disable iff condition must occur relative to starting and ending of an attempt

Dana

2476

 Need clarification about system functions $onehot, etc

Dmitry

2551

 trivial example error

Dmitry

2552

 Confusing comments regarding nexttime operator

Dmitry

3008

 In $past BNF, "expression" should be "expression1"

Dmitry

3015

 Examples of $fatal have bad arguments

Dmitry

1756

 The LRM does not indicate how the control tasks $asserton/off/kill affect verification statements in initial blocks

Ed

1763

 The LRM does not define whether assertion control tasks affect sequence methods and events

Ed

2839

 Contradictory statement of increment/decrement operators usage.

Ed

2491

 Conflicting rules in 16.17 (D7)

Erik

2557

 Rules for passing automatic variables to sequence subroutines are not clear

Erik

2938

 Surprising (to some users) interaction between deferred assertions & short-circuiting

Erik

2248

 Champions feedback - items related to Mantis item 1683

John

2479

 Annex F.5.2.1 conflicts with changes from 2434

John

2871

 Clause 16 does not forbid assertion local variables within clocking event expressions

John

2556

 Explicit package scope indication is not allowed for checkers

Laurence

2809

 Checker instantiation in checkers' always procedure

Laurence

1627

17.16 clarify that expect statement not allowed in functions

Manisha

2255

 clarifications on expect

Manisha

3117

make it clear that rewriting algorithm (F.4.1) applies to checker and let

Manisha

1678

 Clarify that rewriting algorithm doesn't replace name resolution

Scott

2386

 Rename 16.9 to "Local variables"?

Scott

2571

 confusing assertion clock inference rule

Scott

1853

 BNF for calls to $rose and other sample value system functions

Surrendra

2485

 terminology related to immediate and deferred assertions

Surrendra

2558

 Restriction inside checker construct

Surrendra

2271

 sequence events require a clocked sequence

Tapan

2340

 clarifications needed on vpi_control for non-temporal and immediate assertions

Tapan

2494

 37.44 Assertion diagram missing restrict

Tapan

2095

 Clarify meaning of distribution as condition for "disable iff"

Tom

2722

 Errors in Figures 16-14, 16-15, and 16-16

Tom

2754

 P1800-2009 Can clock change in conditional branch of 'if' operator

Tom

Thanks,
Dmitry

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

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