[sv-ac] SV-AC : status of email voting - updated 05/23/2006 - meeting at 12pmEDT today

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Tue May 23 2006 - 07:18:56 PDT
Status of email votes:
======================

Errata proposals 1347, 1346, 508 have been accepted unanimously.

Others may need further discussion.

Details:
--------

1381: vacuous success is not well defined in the LRM 
Bassam:		yes (some corrections required)
Surrendra: 	Discussion continues in the next meeting ...
Ed:			Discussion to be delayed till June 6 when Doron is back
Volkan:      yes


1361: need a way to control execution of action blocks
Bassam:		no - - must add VPI controls to proposal.
			- I think tasks should be consistent with asserton/off tasks, 
			i.e. not disable in-flight assertions
Surrendra: 	It is not clear whether the tasks execute disjointly. 
			Does turning on/off via one task affect the execution 
			result of other tasks?
			Is there any effects of turning on/off. 
			Does assertpasson/off mean non-vacuously?
Dmitry:		Needs more complete def. of existing tasks too, etc. 
			(see email)
Volkan:		yes


1347: forbid local variables in sampled value functions 
Manisha:		yes
Lisa:		yes
Joseph:		yes
Doron:		yes
Bassam:		yes
Surrendra:	yes
Ed:			yes
Dmitry:		yes
Volkan:		yes



1346: index error in semantics of $past 
		(already voted in March ;-( )
Manisha:		yes
Joseph:		yes
Doron:		yes
Bassam:		yes
Dmitry:		yes
John:		yes
Surrendra:	yes
Ed:			yes
Volkan:		yes


1326: No semantics for boolean abbreviation with sequence match item
Manisha:		better to define formal semantics for it (if possible) 
			instead of making it illegal.
Joseph:		yes
Doron:		yes
Bassam:		yes
Surrendra:	yes
Ed:			yes
Lisa:		yes
Dmitry:		yes
Volkan:		yes


508: $isunbounded definition 
Manisha:		yes
Lisa:		yes
Joseph:		yes
Doron:		yes
Bassam:		yes
Surrendra:	yes
Ed:			yes
Dmitry:		yes
Volkan:		yes


966: $isunbounded() 
Joseph:		yes
Doron:		yes
Bassam:		yes
Surrendra:	Need to consider all issues regarding the use of $, 
			including assignments to parameters.
Ed:			yes - limit to parameters not used in any expressions.
Lisa:		yes
Dmitry:		yes


805: disable iff condition should produce vacuous match 
Lisa:		I agree with this too - failure counters do not make 
			sense for coverage. 
			failure counters do not make sense for coverage.
Joseph:		yes
Doron:		I think that disabled should not count as a success  
			in coverage. we need to change is the report of the  
			number of failures in coverage
Bassam:		yes
Dmitry:		I don't think the failure should be reported for coverage at all.
Surrendra:	yes
Ed:			No success with disable to be reported.
Dmitry:		I agree with the definition of the vacuous success. 
			According to our discussion about the property 
			coverage definition, there is no meaning in disabled 
			coverage success, since it should not count as a 
			coverage event at all.  
			Therefore the suggestions concerning 
			Clause 17.13.3, page 288, 
			Clause 29.4.3, page 482, Clause 29.4.2, page 481, 
			and Annex I are not relevant. 
			I agree with the proposal concerning  Clause 28.4.2.
Volkan:		yes


928: list_of_formals superfluous (BNF)
Bassam:		No, not ready -- needs detailed LRM change proposal
Ed:			The statement is superfluous, but it is also necessary 
			to delete the definition of "formal_list_item" 
			in A.2.10 on pp 525
Lisa:		no - needs detailed LRM changes which I am working on
Volkan:		yes
Received on Tue May 23 07:18:45 2006

This archive was generated by hypermail 2.1.8 : Tue May 23 2006 - 07:18:58 PDT