Re: [sv-bc] enum bit-/part-select

From Shalom:
>Is it legal to do an assignment to a bit- or part-select of an enum?

It is not clear whether you can even read a bit- or part-select of an enum.
Section 4.10.4 says that an enum variable used as part of an expression is
automatically cast to the base type of the enum.  I don't think you can
bit- or part-select the result of an explicit cast.  So if this is really
regarded as a cast, that might prevent doing a select of it.  But since
it is an implicit cast, maybe that is OK.  If it were worded more like
the variable is "treated as if it were of the base type", rather than
"cast to the base type", then it would definitely be legal.

It seems desirable to allow this, and I don't see any reason not to.
There are situations where you might want to use some bits out of an
enum state register to control some logic.

On the other hand, assigning to a select of an enum will bypass the
type-checking on the enum, and allow it to be set to invalid values.
I don't see this as a big problem, since the user isn't likely to do
this by accident, and there are already plenty of ways the user can do
this if they want to.  But the people in favor of stronger typing on
enums may not like this.

The wording in the LRM does not seem to allow this.  The use of the word
"cast" that was mentioned above would presumably prevent it, since I don't
think that a cast is legal as an lvalue.  Even if it said "treated as a
if it were of the base type", I don't think that would allow it.  The text
also says "used as part of an expression", and the left-hand-side of an
assignment is not really an expression.

So I don't think it is allowed, and there are reasons why some people
might not want it allowed.  It is not as obviously useful as reading the
selects.  I wouldn't object to allowing it, but others might.

I am adding SV-EC to the CC list for this, since they are generally more
in favor of strongly typed enums for testbenches, while the SV-BC is
generally more in favor of weakly typed enums for design use.

Steven Sharp
sharp@cadence.com