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

Hi Erik,

Thanks for the feedback.  I think I have fixed the things you pointed out. I 
have uploaded a new copy of both 2088 and 2089 to Mantis.

	2088_covergroups_20071205.pdf
	2089_finalInChecker_20071205.pdf

Tom

Seligman, Erik wrote:
>  
> 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.

fixed.

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

Didn't add anything at this time.

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

Took out the "one limitation" clause.

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

Added a similar statement.

>  
>  
>  
> 
> *Erik Seligman*
> 
> ***Formal Verification Architect*
> 
> *Corporate Design Solutions*
> *Design Technology and Solutions*
> 
> M.S. JF4-402                  
> 2111 NE 25^th 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.

-- 
------------------
Thomas J. Thatcher
Sun Microsystems
------------------

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.