RE: [sv-ec] New Mantis item on Coverage: bins rhs non-constant expressions

Arturo, Jonathan, Mark,

Thanks for the comments.  I agree with you guys.
We'll create a proposal which effectively documents
the motivation for this restriction in 18.4.

Regards,
Doug

> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Tuesday, May 08, 2007 11:44 AM
> To: Warmke, Doug; sv-ec@eda.org
> Subject: RE: [sv-ec] New Mantis item on Coverage: bins rhs
non-constant expressions
> 
> Doug,
> 
> The decision to restrict the bins specification to be constant (or
> constant per class with an embedded covergroup) was a deliberate
choice.
> The motivation was to keep the per-type coverage space the same for
all
> instances of a particular covergroup. Otherwise, merging the coverage
> results of multiple covergroup instances onto the covergroup type
> becomes more complicated and more confusing.
> 
> If we do choose to relax this restriction, I agree that the proper
> semantics would be to take snapshot of the expression values at
> covergroup construction time. But, I believe that we will also have to
> specify the mechanism for merging the coverage results of multiple
bins
> with different ranges. Unless we are addressing a specific user need,
my
> bias would be to leave this restriction in place and document the
> motivation in the LRM.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Warmke, Doug
> Sent: Sunday, May 06, 2007 1:48 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] New Mantis item on Coverage: bins rhs non-constant
> expressions
> 
> Hi All,
> 
> I've uploaded a new Mantis item
>    http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001802
> 
> Following is the Mantis Description, reproduced for convenience.
> Comments, anyone?  Based on feedback, I can either create a proposal
> for this issue, or close the Mantis as "Not to be fixed".
> 
> Consider this testcase:
> 
> class myclass;
>      int id;
>      int ign_id;
>      covergroup cg;
>          coverpoint id {
>              ignore_bins ign = {ign_id};
>          }
>      endgroup
> endclass
> 
> The P1800-2005 LRM currently states, in 18.4:
> 
>     The open_range_list used to specify the set of values
>     associated with a bin shall be constant expressions,
>     instance constants (for classes only), or non-ref
>     arguments to the coverage group.
> 
> Thus, the above testcase is illegal.
> Is this overly restrictive?
> 
> The need for requiring constant expressions isn't clear. It would be
> possible to accept non-constant expressions, and take a "snapshot" of
> the expression value at covergroup construction time. There may be
some
> subtelties involved, such as function calls with side effects as part
of
> the expression. This should be considered, but we think it won't be a
> showstopper. Non-constant variables could easily be handled, in any
> case.
> 
> One clear fact is that the expressions used on the rhs of coverage
bins
> must not be allowed to vary with time after the covergroup is
> constructed.
> 
> Regards,
> Doug
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


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