[sv-ec] RE: Feedback on grammar change for 2506

Hi Brad:

Thanks for your input.

Shortening to covergroup_expression and specialization are good ideas. I will implement those.

I should have been more clear. None of the text reflects the grammar change. When I looked at it initially I believed that there would be a good number of changes required to the text. I didn't want to make those changes until I felt the changes to the grammar were stabilizing.

Also, a good point on the integer_expression. I will fix that as well.

Thanks again for the feedback,
Scott

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Brad Pierce
> Sent: Wednesday, August 10, 2011 7:58 PM
> To: Little Scott-B11206
> Cc: sv-ec@eda.org
> Subject: [sv-ec] RE: Feedback on grammar change for 2506
>
> Thanks, Scott and Gord, for asking for my feedback. Yes, in general it
> seems like a good approach to me.
>
> The particular name "covergroup_constant_expression" seems a little off
> to me, because rather than being a restriction of
> "constant_expression", it's a restriction of "expression". Could it be
> shortened to "covergroup_expression" instead?
>
> I'd recommend the use of specialized names like
> "with_covergroup_expression", "set_covergroup_expression",
> "integer_covergroup_expression" vs. generic names like
> "integer_expression".
>
> The proposed text still mentions "open_value_range" in 19.5, and the
> change of name is not reflected in footnote 38.
>
> Why does "integer_expression" generate $ again? It's already generated
> by "covergroup_constant_expression" via "expression" via "primary".
> Couldn't that $ just be an addition to footnote 38?
>
> -- Brad
>
> BTW in 19.5.6, how can it be that e is self-determined according to
> bullet a, yet is not self-determined in the presence of a coverpoint
> type according to bullet b?
>
> And isn't the following an unnecessarily long way to say "statically
> cast"?
>
> "If there is no coverpoint type, then b shall be evaluated as
> though it were the right-hand side of an assignment to a variable whose
> type is type(e). In the presence of a coverpoint type, e and b shall be
> evaluated as though it were the right-hand side of an assignment to a
> variable whose type is the coverpoint type."
>
> Why not simply, "If there is no coverpoint type, then b shall be
> statically cast to the type of e. In the presence of a coverpoint type,
> e and b shall be statically cast to the coverpoint type."?
>
>
>
> -----Original Message-----
> From: Little Scott-B11206 [mailto:B11206@freescale.com]
> Sent: Wednesday, August 10, 2011 6:19 AM
> To: Brad Pierce
> Cc: sv-ec@eda.org
> Subject: Feedback on grammar change for 2506
>
> Hi Brad:
>
> In the most recent SV-EC meeting the group determined that a grammar
> change to create a single grammar item where a set of semantic
> restrictions exist would be preferable to creating/maintaining a list
> of grammar items where these restrictions exist. Gord suggested we run
> this type of grammar change by you before proceeding. I have included
> a version of the proposal which includes the grammar update
> (covergroup_constant_expression is added which induces several other
> changes). I also left the previous solution of the list of grammar
> items (you can find this at the top of page 4). In the process of
> making the grammar change I determined that the previous list is
> incomplete and some items would be difficult to describe without some
> sort of grammar change. Would you object to the grammar change shown
> here?
>
> Also, we have an outstanding question for you from your previous
> Champion's feedback on 2506. We would appreciate a response.
>
> Regarding your feedback below:
>
> 3) Is there more than one way in the standard to understand "evaluates
> to true"?
> Why do we need to say "The truth value of the with clause expression
> is
> interpreted in the same way an expression is interpreted in the
> condition of
> a procedural if statement(Sec. 12.4).?
>
> In my initial revision, I stated:
>
> [SL] That statement was intended to be a clarification. Questions have
> been raised about it before. I have removed that sentence.
>
> In the SV-EC meeting yesterday the group felt that the clarification is
> useful and the sentence should stay. Steven pointed to mantis 1251 as
> an example of the potential confusion regarding the use of "evaluates
> to true". Based on this information are you okay if we leave in the
> sentence in question?
>
> Thanks,
> Scott
>
> --
> 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.