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

Dave,

I don't see anything in the LRM that says there is an implicit cast of
the constant_expression to the base type unless the constant expression
happens to be a constant literal. 

If that were so, one could trivially bypass the restriction by assigning
the constant literal to a local parameter and using it instead.

I'd much prefer removing the restriction and doing it the way you
suggest, but I think the restriction really is there today and
applicable to all constant expressions, not just to constant literals.

-- Brad


-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Tuesday, August 26, 2008 8:21 AM
To: Brad Pierce; sv-bc@eda.org
Cc: Steven Sharp; dhiraj@cal.interrasystems.com;
shalom.bresticker@intel.com
Subject: RE: [sv-bc] Some query related with enum.

Hi Brad,

That text only applies to sized constant literals, not unsized constant
literals or constant expressions.

Dave


> -----Original Message-----
> From: Brad Pierce [mailto:Brad.Pierce@synopsys.com]
> Sent: Monday, August 25, 2008 6:23 PM
> To: sv-bc@eda.org
> Cc: Rich, Dave; Steven Sharp; dhiraj@cal.interrasystems.com;
> shalom.bresticker@intel.com
> Subject: 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.