Mark, At this point, I think the self-determined context rules are actually close to the original intent. In other words, if the self-determined size is not the same as the enum base, it is an error. There are some issues in that rule regarding unsized, but I think the original intent was to have a stronger certainty about the value domain (particularly with auto incrementing enums) than is really possible with general context-determined evaluation. So, I am opposed to making the enum exactly like a parameter (with context determined semantics) but would not oppose some clarification to the sizing rules that are present and still normative. Gord. Mark Hartoog wrote: > I had forgotten that the LRM still contains this restriction: > > "Any enumeration encoding value that is outside the representable range of the enum shall be an error. If any > of the enum members are defined with a different sized constant, this shall be a syntax error." > > Unfortunately, this restriction is unworkable in the real world, where the size of the enum may be parameterized and the enum label expressions may involve parameters. > > It is also unclear what this text really means. It says "syntax error", implying that this can be detected at parsing time, but if the width is parameterized, that is not possible. You could argue that in my example: > > enum [2:0] { A = 2'b11 + 2'b01, B } e; > > the label was not defined with a sized constant. The label was defined with an expression that used sized constants. If you want to argue that all sized constants used in the expression must be the size of the enum, then what about this case: > > enum [3:0] { A = {2'b11, 2'b01 }, B } e; > > Are you going to argue that this is illegal because the sized constants used in the concat are not the same size as the enum. That is just silly. > > I originally implemented rigorous enforcement of this rule, but customers found that unacceptable. I was forced to relax enforcement of this rule. > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Thursday, April 30, 2009 9:10 PM > To: Mark Hartoog > Cc: Maidment, Matthew R; sv-bc@eda.org > Subject: Re: [sv-bc] RE: email ballot: Due 8am PDT Friday, May 1 > > > > Mark Hartoog wrote: >> SVDB 2477 ___Yes _X__No >> http://www.eda.org/svdb/view.php?id=2477 >> >> If enum constants are evaluated in a self determined context it will make them >> inconsistent with how expressions are evaluated elsewhere in system verilog. >> >> parameter [2:0] p = 2'b11 + 2'b01; >> enum [2:0] { A = 2'b11 + 2'b01, B } e; > > > This is not a legal enum -- you may not use an explicitly > sized value that doesn't match the enum width. > > Given that either sizes have to match the enum base or > be unsized, it isn't clear to me the circumstances under > which there is really going to be a difference. > > I guess if you have a >32 bit enum base width and then > added two unsized values that the implementation treated > as 32 bits integers (legal) and that caused a 32 bit overflow > you might get a difference. A bit obscure, but possible. > > Gord > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 1 06:45:21 2009
This archive was generated by hypermail 2.1.8 : Fri May 01 2009 - 06:46:02 PDT