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

>From: Gordon Vreugdenhil <gordonv@model.com>

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

I disagree.  The LRM text refers to a "different sized constant".  It
is apparently referring to a sized literal.  It is not using "constant"
to mean constant expression, since it allows a constant expression that
is an unsized literal, even though that expression may be a different
size.  Mark's example is not a sized literal; it is an expression.

Whoever wrote this rule was assuming that the value would be set by
a sized or unsized constant, and did not write it generally enough to
apply to constant expressions in general.  We can either throw out the
rule because it is too narrow to apply to all situations, or try to
generalize it.

You seem to be trying to generalize it by disallowing an expression
containing an explicitly sized literal that doesn't match the enum
width.  I don't think that is a valid way to generalize it.  There
could be explicitly sized literals whose size is not equal to the
expression size.  For example:

  enum [2:0] { A = {1'b0, 1'b1, 1'b0}} e;
  
Here is an expression that uses explicitly sized literals whose size
does not match the base type, but it should not be an error.  The
expression size matches.

The rule cannot be that the self-determined expression size must match
the enum width, because unsized literals are allowed, and those are
expressions that may not match the enum width.  Also, users would be
unhappy if they could not use simple decimal literals for the values.

I am not sure how else you might be trying to generalize it.  Trying
to say that it is an error if the size does not match and that size
was determined by a sized literal would be to complex to be practical.
It is messy enough to calculate the size of an expression, without
having to keep track of whether that size was determined by a sized
literal.

The only rational way I can see to interpret the text is that it is
only applied in the special case where the expression is just a
sized literal.

I think it would be better if we just threw out this overly narrow
rule, and came up with a reasonable and general one.  For example,
evaluate the expression in the context of a cast to the base type.
If that cast would truncate any significant bits, then it is an
error.  Use the standard definitions of overflow.  For unsigned,
you have an overflow if the discarded bits are not all zero.  For
signed, you have an overflow if the discarded bits are not all
the same.

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

For one thing, there are expressions whose size is not the same as
their operands.  And I am sure I can come up with other cases where
it makes 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.

Yes, that would be one example.

To come up with any others, I would want a more precise specification
of what you think the general rule is.

Steven Sharp
sharp@cadence.com


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