RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089 (final in checker)

Well, I obviously posted a bad phrasing... but I think the question
remains:  do we need to explicitly clarify the role (or non-role) of the
procedural code surrounding the checker?

________________________________

From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Tuesday, December 04, 2007 1:45 PM
To: Seligman, Erik; Thomas.Thatcher@sun.com
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] Review of 2088 (covergroups in checker) and 2089
(final in checker)


Hi Erik,
 
covergroups: there should be no restriction saying that the cg must be
controlled by its explicit clocking event because in checkers they may
often be controlled by the sample() method.
 
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Seligman, Erik
	Sent: Tuesday, December 04, 2007 4:40 PM
	To: Thomas.Thatcher@sun.com
	Cc: sv-ac@eda.org
	Subject: [sv-ac] Review of 2088 (covergroups in checker) and
2089 (final in checker)
	
	
	 
	Hi Tom-- these proposals look good to me overall.  A couple of
comments:
	 
	2088 (covergroups in checker):
	    - 16.18.6: some instances of 'bins' are not boldfaced, and
the 'b' in one 1'b0 is; should fix.
	    - In general, as alluded to in earlier email conversations,
do we have to worry about the fact that by virtue of being in a checker,
the covergroup may be effectively within procedural code?  I'm wondering
if we might want some statement like "The covergroup's timing shall be
controlled only by its explicit clocking event, regardless of any
procedural context in which the checker in instantiated."  On the other
hand, maybe we don't need to bother, since it's consistent with how
concurrent assertions in checkers are treated anyway.  
	    
	2089 (final in checker):
	    - 16.18.4:  The last sentence reads "There is one limitation
on final procedures inside a checker:  Statements within final
procedures shall not write into free variables."     The phrase "one
limitation" sounds very absolute-- maybe it would be better to simply
state "Statements within final procedures shall not write into free
variables." without the preceding clause.  (Also remember that this is
technically true of *all* final procedures, since ones outside checkers
are never in a scope with legal free variables anyway.) 
	    - Also, referring to the same paragraph:  is it the case
that all code allowed in final procedures outside checkers is also
allowed in final procedures within checkers?  If so, this is a bit
different from the initial_check and always_check procedures described
in the two paragraphs above, which disallow general procedural code.  So
I think we should have an explicit statement clarifying this.  Something
like "All code which is allowed in a non-checker final block is also
allowed in final blocks within checkers."
	 
	 
	 
Erik Seligman

Formal Verification Architect

Corporate Design Solutions
Design Technology and Solutions

M.S. JF4-402                   
2111 NE 25th Ave
Hillsboro, OR 97124 

Phone:   (503) 712-3134

	 

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