[sv-ec] RE: Updates to 2506

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Little Scott-B11206
Sent: Friday, February 18, 2011 12:38 PM
To: sv-ec@eda.org
Cc: Fais Yaniv-RM96496
Subject: [sv-ec] Updates to 2506

Hi all:

I have uploaded a new version of the 2506 proposal (_v2). Below are a summary of the changes in this version, questions I have, and comments from John. I am not sure that my understanding of comments made in the meeting is 100% correct. Please clarify if I have misunderstood or omitted a point made in the meeting.

Thanks,
Scott

Changes
--------------------
-Removed restriction in the first new paragraph of 19.5 that a cover_point_identifier must be specified if a data type is specified and updated the grammar.
-Added an example showing a data type declaration without a covergroup name.
-Addition to 19.5.1.1 clarified how the true value for the with clause is interpreted.
-Addition to 19.5.1.1 changed from keyword item to name item
-In 19.5.5.1 removed the ability to use the coverpoint name in the with expression for bins definition and required the use of item. Adjusted the examples accordingly.
-Adjusted the punctuation and wording of the second bullet in the itemized function restrictions in 19.5.1.1.
-Added a restriction limiting the with clause functions to a procedural calling context.
-Fixed an improper use of should

Questions
--------------------
. The original statement "Functions shall be automatic (or preserve no state information) and have no side effects" is used several places in the LRM. I agree with the idea that was mentioned in the meeting to change it to "Functions shall be automatic, preserve no state information, and have no side effects." However, this does on the face of things seem to not be backward compatible. I believe I could create a void static function that meets the original criteria. I don't believe it would be useful. My preference is to agree on this statement and make it consistent throughout the LRM. Thoughts?
. The term 'procedural calling context' is not in use elsewhere in the LRM. Do we need to adjust the language or is it well understood what we mean?
. I believe there was some question in meeting regarding the example:
  coverpoint b
  {
    bins func[] = b with (myfunc(item));
  }
The question was about the use of b in place of the open_range_list. The proposal specifies that only the name can be used in place of the open_range_list. In this case b is the name of the coverpoint and the variable. The LRM states, "If the label is omitted and the coverage point is associated with a single variable, then the variable name becomes the name of the coverage point."
. Jonathan(?) raised the question about allowing functions inside a cross. This avoids the need to cast to CrossQueueType or use the scope resolution operator to define the return type for the function as is done in the final example of the proposal. Gord and Arturo had some concerns. After thinking about it, can either of you say more or suggest a set of restrictions that such functions would have to meet?

Comments from John
--------------------
-19.5.1.1. "If the open_range_list includes the same value multiple times, the with clause may select that value to appear in the bin multiple times." I don't think that this language is precise enough. Ray Ryan (?) asked about this, I think. If there is a list of lists being used to specify a bounded (explicitly) bin array, then I think that the with clause should first filter the lists of lists, and then whatever is left over should be distributed to the components of the bin array. Check with Ray and others to get agreement on this and then make the LRM language clearer.
-19.6.1.2. How does the statement about range bound inference apply if the coverpoint has an explicitly specified type? Make sure the current statement is correct in that case.
-19.7. How does effort_limit interact with a bin array? Make sure that the language is inclusive or exclusive of this case as appropriate. Right now, I think the reader is left to guess.

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