RE: [sv-bc] RE: email ballot: Due 8am PDT Friday, May 1

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


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