RE: [sv-bc] default initial value issues

I thought that Mark gave a very well written description of the enum
situation. I have a few comments to add.

>Note that even with enums defined to be very strongly typed in the
>language, it is possible to achieve the second view also. For example,
>
>typedef enum logic [1:0] {A, B, C, D} ET;
>
>logic [1:0] myvar;
>
>always @(....)
> myvar = A;
>
>Here the variable is not declared of the enum type, and will initialize
>to 'x', but the user is still free to assign the enum labels to it.

In practice, one of the biggest advantages for users in using enums
(compared to `define or parameter approaches) is the ability to print
out the enum values by name with $display or in the debugger or waveform
viewer. While this suggested approach does allow the use of enum literals
without worrying about type checking, it does not give this important
capability. The use of casts in printing might allow working around it,
but this is ugly.

>The second view above was how enums were specified in System Verilog 3.0.
>In 3.1 an effort was made to shift the standard to the first view,
>but it didn't really make it. Enums became more strongly typed and
>the initialization to the first label rule was added, but there were
>several ways (casts and unions) left to introduce values that were
>not one of the labels.

They are also apparently allowed in packed structs and arrays, which
provides another way to introduce arbitrary values, much like unions.
And if enums are considered bit-stream types, and bit-stream types are
bit-addressable (both implied by the glossary entry for bit-stream),
then they might be writeable via bit and part selects, which would allow
yet another way.

It is my understanding that enums were intended for use at the hardware
design level, such as for state machine states. The kinds of things that
are done at that level are not very compatible with strong typing. There
are reasons why Verilog is not strongly typed.

The description of type checking also seems to indicate that a static
type check is not sufficient, but that dynamic checks may be needed in
some cases at runtime. For a large set of non-consecutive enum values,
this could carry a significant simulation cost.

>If we want to change the initialization of 4 state enums, then I would
>be strongly opposed to making the initialization of 4 state enums different
>then 2 state enums. All enums should initialize in the same way. This means
>either first label or the default initial value for the base type ('x' for
>4 state and '0' for 2 state).

I limited my initial proposal to 4 state enums because I was trying to
minimize changes, and the simulation initialization issue applies only to
4 state values. However, I agree that it would be more consistent if all
enums initialized to the default initial value for their base type. This
would also resolve issue 286.

I have to say that Mark makes excellent arguments that initializing to
the first label value, and strong typing in general, offers limited
advantages. At the same time, it leads to significant problems. Perhaps
it should be reconsidered.

Steven Sharp
sharp@cadence.com
Received on Thu Nov 4 19:45:26 2004