RE: [sv-bc] Some query related with enum.

>I believe the constant expression used to define a named value is
>evaluated in the context of an assignment to the base enum type.

The LRM has a counterexample

// Error in the bronze and gold member declarations
enum bit [3:0] {bronze=5'h13, silver, gold=3'h5} medal4;

because "If any of the enum members are defined with a different sized
constant, this shall be a syntax error."

Without this restriction the values of the members would be sensitive to
changes in the size of the base type and the following would no longer
be true

"Enumerated data types provide the capability to abstractly declare
strongly typed variables without ... a data type ... and later add the
required data type ... for designs that require more definition."

For example, consider the following illegal declarations

    enum            {tantalum = 1'b1 + 1'b1 + 1'b1 + 1'b1 + 1'b1}
metal73;
    enum logic[1:0] {tungsten = 1'b1 + 1'b1 + 1'b1 + 1'b1 + 1'b1}
metal74;

which would otherwise run afoul of Verilog context-sensitive arithmetic

               int'(1'b1 + 1'b1 + 1'b1 + 1'b1 + 1'b1) == 5
  type(logic[1:0])'(1'b1 + 1'b1 + 1'b1 + 1'b1 + 1'b1) == 2'b01

-- Brad



-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Rich, Dave
Sent: Monday, August 25, 2008 6:00 PM
To: Steven Sharp; dhiraj@cal.interrasystems.com; sv-bc@eda.org;
shalom.bresticker@intel.com
Subject: RE: [sv-bc] Some query related with enum.

> 
> The issue of the values being outside the representable range is less
> clear.  Does this include values that change meaning based on whether
> they are regarded as signed or unsigned?  Or does it only include
values
> that lose significant bits due to truncation?  The LRM does not say.
> 
> Case 4 is illegal regardless of your interpretation.  The value is
signed
> and the enum is signed, and for a signed number, truncation of 3 to 2
bits
> loses a significant bit: the sign bit in the truncated result does not
> match the original sign bit.
> 
> Cases 2 and 3 do not do any truncation, so they cannot be losing any
> significant bits.  Only the interpretation of the bit pattern changes
when
> it is regarded as signed rather than unsigned.  I don't think the LRM
text
> is clear on whether this is valid or not.
[DR] I believe the constant expression used to define a named value is
evaluated in the context of an assignment to the base enum type. If you
make that assumption (what other choices are there?), all of the other
issues should drop out.

Dave


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