[sv-ec] RE: Updates to 2506

Hi again...

I went to put away my notes and realized that I did not address the comments on the set expression syntax (<>). My recollection is that the group felt we can just remove the <>. I will make that change to the grammar and examples in the next version.

Thanks,
Scott

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