Re: [sv-ac] feedback on 2088 and 2089

Hi Lisa and Dmitry,

Here are the fixes I have put into the proposals for 2088 and 2089:

1.  References to default disable iff.  I have put green notes next to
     the the BNF where default disable iff appears to show that this is
     being added by Mantis 1674.

2.  I removed the change which would have added "With the exception of a
     covergroup declaration"

3.  In 2088, I added covergroups into the list of elements that may be
     included in a checker body.

4.  By font problems, you mean that "initial_check" is in 10-point bold
     courier, rather than 9-point bold courier, correct?  I have changed
     it.

5.  Both cover group declarations and instantiations will allowed. The
     example showed both a declaration and an instantiation, but I have
     added text to say that an instantiation is also allowed.

6.  If formal arguments are defined for a covergroup, then any input
     ports, checker variables, or free variables may be passed as actual
     arguments to the covergroup.

7.  I'm not sure what this question means:  "May checker variables
     represent cover points?"  Do you mean "May a covergroup reference a
     checker variable directly?"
     The example in my proposal does this:  The coverpoint cp_active_d1
     refers directly to checker variable active_d1.


I have uploaded new versions of both proposals.  Let me know if I have 
answered all your questions.

Thanks,

Tom


Lisa Piper wrote:
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> *Sent:* Monday, December 17, 2007 7:52 AM
> *To:* Lisa Piper; Thomas.Thatcher@sun.com
> *Cc:* sv-ac@eda.org
> *Subject:* RE: [sv-ac] feedback on 2088 and 2089
> 
>  
> 
> Hi Tom,
> 
>  
> 
> Here are some more comments about 2088:
> 
>  
> 
>     * Do you allow only cover group declaration in the checker or its
>       instantiation as well?
> 
> [Lisa Piper >>>] I noticed this too, but I could not find in the LRM any 
> specification of covergroup_instance, so I decided that it must be 
> stated somewhere in the text that it can only be instantiated where it 
> is declared.
> 
>     * If you allow cover group instantiation as well, what kind of
>       formal arguments are allowed? May they be checker variables? May
>       they be free variables?
>     * May checker variables represent cover points?
> 
>  
> 
> Thanks,
> 
> Dmitry
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] 
> *On Behalf Of *Lisa Piper
> *Sent:* Sunday, December 16, 2007 9:56 PM
> *To:* Thomas.Thatcher@sun.com
> *Cc:* sv-ac@server.eda.org
> *Subject:* [sv-ac] feedback on 2088 and 2089
> 
>  
> 
> Hi Tom,
> 
> My feedback on 2089, and one more on 2088,
> 
> 1. Why wasn’t this text also updated for 2088?   Also, there are font 
> issues with the PDF for initial_check (these font issues are also in the 
> checker proposal itself).
> 
> A checker body may contain the following elements:
> 
> ¾ Declaration of* **let*, sequences, properties and functions.
> 
> ¾ Concurrent assertions.
> 
> ¾ Free variables and their assignments (see 16.18.5).
> 
> ¾ Default clocking and disable declarations.
> 
> ¾* **initial_check*, and* **always_check*, and* **final* procedures (see 
> 16.18.4).
> 
> ¾ Generate blocks, containing any of the above elements.
> 
> 2. Minimally there should be a note that changes are needed to the VPI 
> diagrams when the checker VPI is added.  Same applies to 2088.
> 
> Lisa
> 
> ---------------------------------------------------------------------
> 
> Intel Israel (74) Limited
> 
>  
> 
> This e-mail and any attachments may contain confidential material for
> 
> the sole use of the intended recipient(s). Any review or distribution
> 
> by others is strictly prohibited. If you are not the intended
> 
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> 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* <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.