RE: [sv-ec] Typing of coverpoint and bins expressions

Gord,

 

I believe the best approach is a hybrid between your 2nd and 3rd
alternatives, closer to the 2nd.

 

While there are some similarities between coverpoint/bins specification
and case statements, they 

are not exactly the same. In particular, the need to match the bit
length of all expressions involved

in the case (bins) is unwarranted.

 

let me try to summarize the rules that I believe best capture user
intent.

 

1) Coverpoint expressions are self-determined.

            This seems straightforward as coverage measures the values
present in the coverpoint

            expression at the time of sampling. In particular, I think
it makes no sense to attempt to

measure a coverpoint value that may not be representable by the
coverpoint itself.

 

2) Expressions that specify the bounds of bins (or bin indices) are
computed by considering

each expression as the right hand side of a procedural assignment
statement to a variable of 

the same type as the coverpoint expression.

            This is very similar to your 2nd alternative, except that
instead of casting the result to

the type of the coverpoint expression, the type of the coverpoint
expression becomes

part of the expression evaluation.

For example, bins b of cp2 is then computed as:

            bins b: logic signed [3:0] temp_y1 = -1;              =>
yielding 4'shf

                       logic signed [3:0] temp_y1 = 0;               =>
yielding 4'h0

 

3) Once the bins values have been normalized to the type of the
coverpoint expression, the

comparison to determine whether a sampled coverpoint value lies within a
bin proceeds by

comparing the values of the two the identical types.

 

4) Regular Verilog expression semantic are used for both computing the
bins (item 2 above)

and comparing the bins to the value (item 3 above).

 

I believe the above rules best capture the user intent. In particular,
when the precision (or bit

length) of the coverpoint expression is greater than that of the bins
expression. For example,

consider the following:

 

logic [2:0] a;

covergroup cg @(...);

            coverpoint a {

                bins a2 = { 0 : 2'b11 + 2'b11 };

            }

            endroup

The bins expression is computed using the precision of the coverpoint (3
bits) yielding the

expected 2'b110 (3+3 => 6).

 

The only remaining issue is how to deal with out-of-range bins (bin
values that are not

representable by the type of the coverpoint expression. As you point
out, if we leave things

at this point, the truncation/cobversion to the target type is likely to
lead to unintended and

possibly overlapping bins. For example:

 

            coverpoint a {

                bins a3[] = { 0, 1, [8:9] };

            }

 

Since the coverpoint's precision is 3-bits, the above yields:

            bins a3[] = { 3'b000, 3'b001, 3'b000, 3'b001 };

Which is very likely not the intent.

 

I believe that a warning should be issued when the bins value is not
representable in the type

of the coverpoint. Note that, in general, this is a run-time warning
since the bins values are

often computed when the covergroup is created.

 

            Arturo

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, January 24, 2006 3:01 PM
To: SV_EC List
Subject: [sv-ec] Typing of coverpoint and bins expressions

 

(Sorry for the length of this; I wanted to cover most of the bases to
try to get to consensus more quickly.)

 

P1800-2500 does not explicitly discuss the types of coverpoint
expressions and how those types relate

to the types of bin expressions.  Although all are required to be
integral, issues related to sign and width are not addressed.

 

For the purposes of typing, one can consider the coverpoint expression
to be involved in a comparison

relationship with each value in the bins.  The simplest way to formalize
the typing is to require that a

coverpoint expression and each value in the bin expressions be typed as
though the values participated

in a case statement where the case expression is the coverpoint
expression and each case_item is a

bin value expression.  All bin expressions for a coverpoint are
considered simultaneously.

 

Example:

 

    logic [3:0] x;

    logic signed [3:0] y;

    covergroup @(posedge clk);

       cp1: coverpoint x {

          bins a = { 1'b1, 1'b0 };

          bins b = { -1, 0 };

       }

       cp2: coverpoint y {

          bins a = { 1'b1, 1'b0 };

          bins b = { -1, 0 };

          bins c = { 15, 0 };

       }

       cp3: coverpoint y {

          bins a = { 2'sb1, 2'sb0 };

          bins b = { 4'shf, 4'sh0 };

       }

       cp4: coverpoint y {

          bins a = { 1, 0 };

          bins b = { -1, 0 };

       }

    endcovergroup

 

For cp1 and cp2, the effective type of the bins expressions and
coverpoint expression would be "unsigned logic [31:0]".

For cp3, the effective type is "logic signed [3:0]". For cp4, the
effective type would be "integer".

 

This does cause some (Verilog consistent) odd behavior.

For cp2 in particular, if we have a source assignment "y = -1" and
sample,  we will not match the bin value -1 in b due to unsigned
comparisons but would match the value 15 in "c".  This is consistent
with the equivalent Verilog case behavior.

 

 

A second alternative is to say that all expressions are self-determined
and than bin expressions are cast to the type of the coverpoint
expression before being compared.  The bad effect of this option is that
it would not be possible to express "out of range" values since casting
truncates/converts to fit the target type.  For example, if we had:

       cp5: coverpoint x {

          bins a = { [0:20] };

       }

one would have very surprising behavior since the range would become
[0:4].  Requiring "modulo" awareness (effectively casting each value in
a range) would still be surprising for ranges such as [10:20].

 

 

 

The final alternative is to treat all expressions as self-determined but
then do value analysis in the domain of mathematical integers.  Any
self-determined bin value that was not representable in the domain of
values expressed by the coverpoint expression's self-determined type
would be unreachable.  Such values could be ignored in terms of the bin
construction prior to the distribution of values.  This means that all
values that are considered to be part of actual bin construction are in
fact part of the representable range of the coverpoint expression; such
an approach could result in empty bins but we are already working on
language for the rules in such cases.

 

 

 

I've entered a Mantis item 1313 on this issue as a placeholder; once we
build consensus on the rules for the types, I can formalize the
proposal.

 

 

My personal preference is to adopt the final alternative.

This approach, although not in keeping with normal Verilog typing, does
not produce comparison artifacts that are not obvious in the structure
of the code.

 

Gord.

 

-- 

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

Gordon Vreugdenhil                                503-685-0808

Model Technology (Mentor Graphics)                gordonv@model.com