Re: [sv-ec] Errata: 3.1a Draft2, Section 20

Subject: Re: [sv-ec] Errata: 3.1a Draft2, Section 20
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Feb 19 2004 - 10:57:18 PST

Sandeep,

I've collected all your messages into one.
Please see my comments below.

    Arturo

--------------------------------------------------------------------------------

Section 20.2
This section mentions that a covergroup can be defined in a module, program, interface, or a class. It does not clarify whether a covergroup can be defined in the definitions name space and inside packages. Also the behavior of covergroups with relation to compilation units ($unit) needs to be included in the LRM.

The same paragraph of Section 20.2 states:
    The covergroup construct is a user-defined type.

Therefore, like any user-defined type, a covergroup can be defined in the following name-spaces:
    - compilation unit scope name space
    - module name space
    - block name space
As in so many other sections, that particular sentence in the LRM is not intended to be comprehensive.
The BNF correctly shows covergroup declaration as being a package_or_generate_item.

I believe this is appropriately covered by the LRM and does not require a change.

--------------------------------------------------------------------------------

Section 20.4
The bins specification for a coverpoint values does not talk about open value ranges. Though this might be included deep somewhere in the formal syntax definition of value_range, it is not clear whether open value ranges are allowed in bins specification. This should be explicitly explained with the help of examples.

Suggestion: Include examples containing following bins specifications.

bins a = { [0:100], [1000:$] }; // bin capturing values from 0 to 100 and 1000 onwards

Good point. I propose we change the declaration of the example in the middle of page 313, and the following paragraph as shown:

    intbit [9:0] v_a;

    covergroup cg @(posedge clk);
    coverpoint v_a
    {
        bins a = { [0:63],65 };
        bins b[] = { [127:150],[148:191] }; // note overlapping values
        bins c[] = { 200,201,202 };
        bins d = { [1000:$] }; // 1000 and onwards
        bins others[] = default;
    }
    endgroup

In the example above, the first bins construct associates bin a1 with the values of variable v_a between 0 and 63, and the value 65. The second bins construct creates a set of 65 bins b[127], b[128],. b[191]. Likewise, the lastthird bins construct creates 3 bins: c[200], c[201], and c[202]. The fourth bins construct associates bin d with the values between 1000 and 1023 ($ represents the maximum value of v_a). Every value that does not match bins a, b[], or c[], or d is added into its own distinct bin.

--------------------------------------------------------------------------------

Section 20.4.1
The document must also contain an example of the usage of default sequence. The example on Page 293 can be modified as follows

bit [4:1] v_a;
covergroup cg @(posedge clk);
coverpoint v_a
{
  bins sa = (4 => 5 => 6, {[7:9],10}=>{11,12});
  bins sb[] = (4=> 5 => 6, {[7:9],10}=>{11,12});
  bins allother = default sequence;
}
Endgroup

The bin "allother" is used to keep track of all the other transitions which are not defined for bins "sa" and "sb". Specifying "allother[]" will generate an error.

OK. Change the example in Section 20.4.1 at the bottom of page 315 (and 316) as suggested:

    bit [4:1] v_a;

    covergroup cg @(posedge clk);
        coverpoint v_a
        {
            bins sa = (4 => 5 => 6, {[7:9],10}=>{11,12});
            bins sb[] = (4=> 5 => 6, {[7:9],10}=>{11,12});
            bins allother = default sequence ;
        }
    endgroup

And, add the following sentence to the first paragraph of page 316:

The bin allother tracks all other transitions that are not covered by the other bins: sa and sb.

--------------------------------------------------------------------------------

Section 20.4.1
It should be clarified in the document that if a covergroup specification does not contain the sampling event, a transition specification viz. "value1 => value2" means the values taken by the coverpoint variable/expression at two consecutive calls to the sample() method of the covergroup instance, in procedural code.

I do not believe such a clarification is needed. The LRM does state (in Section 20.2):
    If the clocking event is omitted, users must procedurally trigger the coverage sampling.

If a clocking event is not specified, then the trigger for all samples (whether values or transitions) is controlled exclusively by the sample() method. There is no confusion here.

--------------------------------------------------------------------------------

Section 20.6
The "goal" option is mentioned in the table. The document does not clarify what is to be done when goal is met. Even though it is likely to be implementation specific, some minimal details about the default behavior can be included in the LRM.

Suggestion: An implementation specific information message is displayed whenever a goal is met for the first time. The message must contain details of the covergroup/covergroup instance for which the goal has been met.

You misunderstood the "goal" option. The "goal" option does not result in any particular action during simulation, it merely allows users to specify a target for particular coverage items. The coverage report will indicate if a particular test (or set of tests) have reached the desired goal. The coverage report is implementation specific.

--------------------------------------------------------------------------------

Section 20.6
There is no way to specify global options applicable to all the covergroups.

Suggestion: Add syntax to define global options applicable to all covergroups. For example,

global_covergroup_options.auto_bin_max = 100;

Section 20
In order to separate the design and verification efforts, it should be possible for a user to write the coverage model independent of the design and then bind it to the design. The features binding properties to a module/instance are explained in the section on assertions, using the bind construct. The bind construct should be extended to allow binding of coverage model to modules/instances.

Section 20
Extensions to VPI would be required to access the covergroup definitions, instances and details. It should be possible to iterate over covergroup definitions/instances in a scope, coverpoints/bins/crosses/transitions in a covergroup and their details.

Since a hierarchical scope is created all the way upto a bin, the following piece of code (or something similar),

hdl = vpi_handle_by_name("top.i1.c11.A.auto[0]", 0);
vpi_get_value(hdl, value_p);

should work and return the coverage count or coverage value of the specified object.

These ideas are well motivated. However, I believe it is too late to add new functionality to this version.
I propose we add this request to the list of future enhancements.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

This archive was generated by hypermail 2b28 : Thu Feb 19 2004 - 11:01:11 PST