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.