RE: [sv-ec] Mantis proposal for coverage computation

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Thu Jul 19 2007 - 10:26:10 PDT
Dave,

 

I find this proposal problematic.

 

First, the proposal  is incomplete since it only deals with cover-points
and doesn't specify how to handle cross-points of the merged
cover-points. Consider for example:

 

CG_1 {              // One instance of covergroup CG

Cp1: b1_1, b1_2;           // cover point with two bins

Cp2: b2_1; b2_2;           // cover point with two bins

Cr: Cp1xCp2;                // Cross with 4 bins

}

 

CG_2 {              // Another instance of covergroup CG

Cp1: b1_3, b1_4;           // cover point with two bins

Cp2: b2_3; b2_4;           // cover point with two bins

Cr: Cp1xCp2;                // Cross with 4 bins

}

 

How many cross-bins are to be considered for the cumulative coverage
instance? 8 (add => 4+4) or 16 (multiply => 4x4)? Changing the bin space
of a cover point impacts all such transitive dependencies. And, both add
and multiply schemes suffer from similar problems.

 

At a more fundamental level, this proposal requires tools to lose
information that users felt was important to specify, collect, and hence
report. In general, merging coverage data of a particular cover-group
across multiple instances or even tests requires a consistent coverage
grid. Parameterization of cover-groups can lead to the following
inconsistencies in the coverage grid:

1.       Differences in the number of bins (for a given coverage item),
due to:

a.       Differences in auto_bin_max

b.      Bin elimination due to illegal/ignore bins 

c.       Unconstrained/constraint array bins generation   

d.      Different cross spaces 

2.       Differences in bin names (for a given coverage item)

a.       Generated array bins names differ 

3.       Differences in bin coverage space

a.       Arguments are used to modify the extent of the coverage space 

 

A better scheme to address this problem is to dynamically create
separate sub-types for differently parameterized cover-groups. The
cumulative coverage of the cover-group is then be computed as the
average coverage of all its sub-types. It is better to dynamically
create new cover-group subtypes than dynamically modify an existing
type. This way users have access to all the specific information as well
as the cumulative (or merged) information.

 

Note that in general, parameterization that changes the bin-space though
arguments is not a good methodology because it complicates the merging
and the user interpretation of coverage data resulting from multiple
tests.

 

I've added this email as a note to your proposal.

 

            Arturo              

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
David Scott
Sent: Friday, June 22, 2007 11:00 AM
To: sv-ec@eda-stds.org
Subject: [sv-ec] Mantis proposal for coverage computation

 

I've submitted a new Mantis against coverpoint coverage computation:

 

http://eda.org/svdb/view.php?id=1897

 

This is to clarify the language "union of all significant bins" and

"overlapping bins" -- which is relevant to computing cumulative coverage

for covergroups with parameterized instances.

 

-- Dave Scott

 

 

-- 

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.
Received on Thu Jul 19 10:26:38 2007

This archive was generated by hypermail 2.1.8 : Thu Jul 19 2007 - 10:26:54 PDT