RE: [sv-ac] Statistics counters proposal

I'd say coverage on sequences that are properties, i.e., implicit first
match.
ed


________________________________

	From: Lisa Piper [mailto:piper@cadence.com] 
	Sent: Monday, May 07, 2007 10:45 PM
	To: Eduard Cerny; sv-ac@eda.org
	Subject: RE: [sv-ac] Statistics counters proposal
	
	
	Interesting - I thought sequence coverage was the one of most
interest.
	 
	Lisa


________________________________

		From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
		Sent: Monday, May 07, 2007 7:37 PM
		To: Lisa Piper; Eduard Cerny; sv-ac@eda.org
		Subject: RE: [sv-ac] Statistics counters proposal
		
		
		Hi Lisa,
		 
		yes, it would be a 2-step process but sequence coverage
is the one less practical and used. Therefore, this would force the
person to think why sequence coverage (with all matches) is needed.
		 
		Best regards,
		ed
		 


________________________________

			From: Lisa Piper [mailto:piper@cadence.com] 
			Sent: Monday, May 07, 2007 7:08 PM
			To: Eduard Cerny; sv-ac@eda.org
			Subject: RE: [sv-ac] Statistics counters
proposal
			
			
			Thanks Ed!   
			 
			I agree with your point on the disable iff.  It
should be looking at the "property_spec" only.   I think the existing
text misled me on this.
			 
			I'm not sure I like restricting it to a sequence
instance because then it will always be a two step process to define it
(e.g. I would have to define the sequence and then use the cover
property).  
			In case it was not clear, this is important
since the coverage results are stated to be different depending on
whether the property_spec is a sequence (all match) or a property (1
match per attempt)..
			 
			Lisa


________________________________

				From: Eduard Cerny
[mailto:Eduard.Cerny@synopsys.com] 
				Sent: Monday, May 07, 2007 2:09 PM
				To: Lisa Piper; sv-ac@eda.org
				Subject: RE: [sv-ac] Statistics counters
proposal
				
				
				hi Lisa,
				 
				I think that diable iff should not
change the status from sequence to property.  
				 
				 Also, sequence expression could be
restricted to sequence instance, to make it clear from the definition
that it is a sequence. 
				 
				Best regards,
				ed
				 


________________________________

				From: owner-sv-ac@eda.org
[mailto:owner-sv-ac@eda.org] On Behalf Of Lisa Piper
				Sent: Monday, May 07, 2007 2:02 PM
				To: sv-ac@eda.org
				Subject: [sv-ac] Statistics counters
proposal
				
				
				Hi all,

				 

				I would like to get early feedback on a
proposal  that I am writing to clarify the statistic counters that are
associated with assertions. The current chapter 17 LRM specifies that
these counters must exist for cover statements only, yet 29.1.2 text is
written as though all counters are available for all assertions.  I
think there is value in having the statistic counters for all
assertions. For assert and assume statements, it may be useful to know
the number of failures and passes. A failure indicates a bug of some
kind while a pass is confirmation that the stimulus tested the behavior.
For cover properties, only the number of non-vacuous passes may be of
significance. 

				 

				I would like to propose that a minimal
set of pass/fail counts be required for all assertions (immediate and
concurrent), and that others can be optionally provided if desired.  And
only the pass counter is required for cover properties (others are
optional).  Are there any objections to this principal?

				 

				 The other part of the proposal is to
clarify how to distinguish a property_spec from a sequence_expr. (this
is Mantis 1768)  A property_spec that is just a single sequence_expr
shall be interpreted as a sequence, whereas a property_spec that is not
just a sequence_expr shall be interpreted as a property.  For example,
an expression that contains an implication operator or a disable iff
term, is considered a property. A property instance that is just a
single sequence_expr is interpreted as a sequence (assuming there is not
any default disable iff clause).  Does this sound ok?

				 

				Lisa


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