RE: [sv-ac] Statistics counters proposal

From: Lisa Piper <piper_at_.....>
Date: Mon May 07 2007 - 19:44:48 PDT
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.
Received on Mon May 7 19:45:55 2007

This archive was generated by hypermail 2.1.8 : Mon May 07 2007 - 19:46:17 PDT