RE: [sv-ac] FW: #805

Isn't it that the disbale iff, although asynchronous is interpreted in
the synchronous context of the assertions as
- not starting a new attempt, and
- killing attempts in flight.
 
The first one could be tied to the clock of the disabled assertion. The
2nd one seems more problematic. In that case, the value change of the
condition could trigger the call back as Lisa suggests. So, either a
clock tick and disable condition being true or a change of disable if
condition to true (for all attempts in flight). Does that make sense?
 
ed


________________________________

	From: Lisa Piper [mailto:piper@cadence.com] 
	Sent: Monday, June 12, 2006 9:26 AM
	To: Bassam Tabbara; Kulshrestha, Manisha; Eduard Cerny;
sv-ac@verilog.org
	Subject: RE: [sv-ac] FW: #805
	
	

	I have a question - "disable iff" is asynchronous.  Below it is
stated that there is always a callback per attempt.  If it is per
attempt, you could miss it.  So will "disable iff" callbacks happen
every simulation cycle, or every attempt?  I don't like the idea of
having one every simulation cycle.  Perhaps it could be defined as a
callback when it changes value.

	 

	lisa

	 

	
________________________________


	From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org]
On Behalf Of Bassam Tabbara
	Sent: Friday, June 09, 2006 2:57 PM
	To: Kulshrestha, Manisha; Eduard Cerny; sv-ac@verilog.org
	Subject: RE: [sv-ac] FW: #805

	 

	Hi Manisha,

	 

	I think this is ok as is. About your concern, we are always
issuing a callback per attempt result so this is no different. There is
another set of callbacks (cbAssertionSys...) for a wide scale (all
assertions) on/off/disable (aka kill), obviously that's only one CB
until the next start/enable, under user control here not a matter of
sampling a signal as in former.

	 

	** Ed, like the other ticket (I forget #), we should add SV-CC
for reviewing VPI part as well once we are done with ticket in AC.

	 

	Thx.

	-Bassam.

	 

	 

	
________________________________


	From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org]
On Behalf Of Kulshrestha, Manisha
	Sent: Friday, June 09, 2006 11:35 AM
	To: Eduard Cerny; sv-ac@verilog.org
	Subject: RE: [sv-ac] FW: #805

	Hi All,

	 

	I have uploaded a new version of the proposal on mantis. This
includes suggestions by Lisa (done differently than suggested) and
corrections from Ed ( I have made succeeded to succeeded nonvacuously). 

	Ed, I have made the corrections but I am not sure about
usefulness of those callbacks. I feel callback on each disable
evaluation when disable is already true, is going to be unnecessary and
expensive. Probably Bassam can suggest something. Anyone else ?

	 

	Thanks.

	Manisha

	 

	
________________________________


	From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
	Sent: Thursday, June 08, 2006 7:39 AM
	To: Kulshrestha, Manisha; sv-ac@verilog.org
	Subject: RE: [sv-ac] FW: #805

	Manisha, 

	 

	the last statement in the document you sent says:

	 

	- cbAssertionSuccess, cbAssertionVacuousSuccess,
cbAssertionDisabledEvaluation and cbAssertionFailure: cb_time is the
time when the assertion succeeded or failed.

	 

	Should it say that in the case of disabled evaluation it is the
time when it was disabled? Rather than just succeeded or failed? Is it
useful to report disabled time likely to be the start time in many
cases?) Also, under succeeded, does it cover vacuous success? 

	 

	Best regards,

	ed

		 

		
________________________________


		From: owner-sv-ac@verilog.org
[mailto:owner-sv-ac@verilog.org] On Behalf Of Kulshrestha, Manisha
		Sent: Tuesday, June 06, 2006 11:50 AM
		To: sv-ac@verilog.org
		Subject: [sv-ac] FW: #805

		
		
		

		-----Original Message-----
		From: Kulshrestha, Manisha
		Sent: Thu 6/1/2006 12:17 PM
		To: 'sv-ac@eda.org'
		Subject: #805
		
		
		Hi All,
		
		I have incorporated most of the feedback in my updated
proposal (attached here). Please send your feedback. The original
proposals are still on mantis in case you want to compare. The main
change in this document is that disabled is not a success and thus very
few changes are needed in the LRM.
		
		Thanks.
		Manisha
		
		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