Gord, My comments inlined below. Aerturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Wednesday, January 25, 2006 9:47 PM To: Arturo Salz Cc: SV_EC List Subject: 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. [Arturo] No odd case in my mind. I meant "is". > 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. [Arturo] You are right. I wanted to make a distinction between the implicit cast we are considering, and an explicit cast. Unfortunately, that still has the bad artifacts for values wider than the coverpoint expression. See comments below. [Arturo] Yes, and I cover those later. > 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. [Arturo] I believe we are in agreement. We both see the need to catch the out-of-bounds error. 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. [Arturo] Yes, I agree. I was using the assignment only as a conceptual model for determining the sign and precision. 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. [Arturo] Yes, I agree. I used the assignment only as a conceptual model for determining the sign and precision. 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. [Arturo] I never intended my write-up to be the LRM. I'm in complete agreement with your refinement. Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu Jan 26 11:37:57 2006
This archive was generated by hypermail 2.1.8 : Thu Jan 26 2006 - 11:38:21 PST