[sv-ec] RE: Mantis 2506

Hi Shalom:

The text is correct. Yesterday when I searched around I couldn't find the definition of [$:value], so I removed it. Upon a bit more thorough investigation today, I found the definitions and it does make sense for covergroup_range_list. I have changed the explanation of 23 to include covergroup_range_list. Version 11 is uploaded and contains that change.

The next SV-EC meeting is 2011.09.26.

Thanks,
Scott

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Tuesday, September 20, 2011 8:16 AM
To: Little Scott-B11206; SV_EC List
Cc: sv-champions@eda.org
Subject: RE: Mantis 2506

OK on most.

Questions:

In v10, 19.5 (bottom of page 5) says,

"It shall be legal to use the $ primary in a covergroup_value_range of the form [ expression : $ ] or [ $ : expression ]."

However, footnote fn1 says, "It shall be legal to use the $ primary in a covergroup_value_range of the form [ expression : $ ]."

Which is correct?

Regarding the following,

  1. Pages 8-9: "An implementation shall issue a warning under the following conditions if a coverpoint type is not present:
1) If e is unsigned and b is signed with a negative value.
2) If assigning b to a variable of type type(e) would yield a value that is not equal to b under normal comparison rules for ==.
3) If b yields a value with any x or z bits. This rule does not apply to wildcard bins because x and z shall be treated as 0 and 1 as described above.
An implementation shall issue a warning under the following conditions if a coverpoint type is present.
1) If the coverpoint type is unsigned and b is signed with a negative value.
2) If assigning b to a variable of coverpoint type would yield a value that is not equal to b under normal comparison rules for ==.
3) If b yields a value with any x or z bits. This rule does not apply to wildcard bins because x and z shall be treated as 0 and 1 as described above."

It looks like the two lists are identical except that the first refers to type(e) and the second to the coverpoint type. Can't you combine them instead of repeating all that text? (If you leave them, then you need a colon after "if a coverpoint type is present".)

[SL] I believe that the second set can be removed. a and b above define the type for e and b under both conditions. Given that information only a single set of rules should be needed. Do you agree?
[SB]
I also think that a single set of rules should be sufficient, but I think the wording may have to be tweaked to do it correctly. I'd like Gord and Steven to look at it, for example.

  1. Page 9: "If an element of a bins covergroupopen_range_list is a range [b1 : b2] and there exists at least one value in the range for which a warning would not be issued then the range shall be treated as containing the intersection of the values in the range and the values expressible by type(e)." Should the end refer to "values expressible by a variable of the coverpoint type" instead of "type(e)"?
 [SL] Given the fact that e shall be statically cast to the coverpoint type (from a above), is there a difference between "values expressible by a variable of the coverpoint type" and "type(e)"? I believe that type(e) covers both cases and is therefore the right thing to have there.
[SB] This goes back to the previous question. The problem is that "type(e)" refers to e in a self-determined context, not e cast to the coverpoint type.
I still have not reviewed the rest of the proposal. When is the next SV-EC meeting?

Regards,
Shalom

Shalom Bresticker
Intel LAD DA, Jerusalem, Israel
+972 2 589 6582 (office)
+972 54 721 1033 (cell)
http://www.linkedin.com/in/shalombresticker

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.