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

From: Brad Pierce <Brad.Pierce@synopsys.com>
Date: Wed Aug 10 2011 - 17:58:23 PDT

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.
Received on Wed Aug 10 17:58:48 2011

This archive was generated by hypermail 2.1.8 : Wed Aug 10 2011 - 17:58:52 PDT