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

Arturo Salz wrote:

> 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.

I agree -- the case width consistency makes sense due to
the synthesizable aspects, but it is pretty artificial in
the context of covergroups.


 > 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.


Ok (I think).  I would feel better if "may" was "is" in the last
sentence since otherwise I'm not sure if you have some odd
case in mind that I haven't thought about.




 > 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.

Hmm.  Actually I think that this is exactly the definition of
a cast -- a cast is the same as an assignment to a temporary
of the target type of the cast.  From 4.14:

     If the expression is assignment compatible with the casting type,
     then the cast shall return the value that a variable of the
     casting type would hold after being assigned the expression.

Since integral types are all assignment compatible, what
you are proposing is exactly a cast.

Unfortunately, that still has the bad artifacts for values
wider than the coverpoint expression.    See comments below.


 > 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 };
 >
 >             }
 >
 >             endcovergroup
 >
 > 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.


Agreed.



 > 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.



We don't (I think) want to define the cast as part of the bin
expression semantics prior to range "suppression" since that means
that one cannot determine whether the value (in the self-determined
sense) was outside the value of the coverpoint expression type.


So, what value is used in computation?  I think that an expression in
a bins construct needs to be widened to the wider of its size and the
coverpoint expression's size *without* changing its sign.  That
ensures that precision isn't lost during the bin expression
evaluation.  This must preserve the sign of the bin expression. This
corresponds to evaluating the expression *as though* it were the right
hand side of an assignment but NOT doing the assignment.

At that point, prior to value distribution you can actually determine
whether the value is in the representable range of the coverpoint's
self-determined type and "prune" the value set prior to the bin
distribution, and, as you suggest, warn if needed.

I think that this captures what you are suggesting -- bin values end
up being at least as wide as the coverpoint expression and yet retain
sign and "out of range" values until just before value distribution to
the bins.

Finally, all comparisons are then (easily) performed in the type of
the coverpoint expression since you have (by construction) ensured
that bin values are members of the coverpoint type.

The thing that I think I like in my refinement is that there is a
"Verilog-ish" way of talking about the value of the bin expression
which in other forms is either pretty ad hoc or has some value
artifacts.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com