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