Re: [sv-bc] enums in packed arrays/structs

>From: "Feldman, Yulik" <yulik.feldman@intel.com>

>The subject was already discussed once
>(http://www.eda-stds.org/sv-bc/hm/4326.html), but the discussion seems
>to be incomplete. I still have the following concerns:
>
> 
>
>1.       The original thread says: "We also noted that the LRM allows
>enums as members of packed structs". This is not fully accurate. Looking
>on section 4.11 "Structures and unions", I see: "Noninteger data types,
>such as real and shortreal, are not allowed in packed structures or
>unions". However, enum is arguably a "noninteger" type. Enum is an
>integral type, but not an integer type (according to 4.3 "Integer data
>types"). So, if the intention is that enums are allowed as members of
>packed structs, this should be clarified.

From the way I started the referenced thread, I clearly believed that
we had deliberately modified packed unions to allow enums.  So if there
is a distinction between "noninteger" and "nonintegral" that would
prevent it from saying this, then it does not match the intent.

We do need to be careful in interpreting terminology.  If there is
a definition of "integer type" as a technical term, the English
phrase "noninteger data types" does not necessarily mean the same
thing as "data types other than integer types".  Of course, it would
be better if the LRM were clear without this level of nitpicking.

I definitely agree that this should be made clearer.


>2.       The original thread also raised the question of whether the LRM
>should allow enums as elements of packed arrays. At present, they seem
>to be disallowed as per section 5.2 "Packed and unpacked arrays":
>"Packed arrays can be made of only the single bit data types (bit,
>logic, reg) and recursively other packed arrays and packed structures".
>Looking at the thread, no substantial arguments were raised as to why
>the enums should be disallowed as elements of packed arrays. However,
>the discussion didn't result in an action item.

The discussion got derailed into whether the predefined integer types
should be allowed in enums.  That was contentious enough to distract
everyone from the original question :-)


>3.        Related to both enums in packed structs and enums in packed
>arrays, if both or only of one them is allowed or should be allowed,
>there is a seemingly not previously discussed ambiguity related to the
>definition of type equivalence and assignment compatibility of such
>types. According to 6.9.2 "Equivalent types", "Packed arrays, packed
>structures, packed unions, and built-in integral types are equivalent if
>they contain the same number of total bits, are either all 2-state or
>all 4-state, and are either all signed or all unsigned" and according to
>6.9.3 "Assignment compatible", "All equivalent types, and all
>nonequivalent types that have implicit casting rules defined between
>them, are assignment-compatible types". So a packed struct/array
>containing an enum would be equivalent and assignment compatible to
>other "appropriate" packed types. However, this raises at least two
>concerns:
>
> 
>
>a.        Simple enums (not parts of arrays/structs) are not equivalent
>to other types. Having enums in packed arrays/structs being considered
>equivalent to other types will be inconsistent and will create a
>precedent.

The enums are still not equivalent.  Only the packed arrays/structs are
equivalent.  When a packed array/struct is referred to as a whole, it
is just a vector, and the normal vector rules apply.  That is pretty
much the meaning of packed.  You could view it as a union between
the array/struct and a vector, with a well-defined overlaying of the
representation.  When you refer to the vector member of that union,
it doesn't matter what the other member was defined as.


>b.       Assignment compatibility of enums is in one direction only (due
>to implicit casting rules defined only in one direction). Whether the
>enums in arrays/structs are equivalent to other types or not, there is
>some missing language as to how the assignment compatibility of such
>types is defined. Intuitively, one may want to define it in terms of
>going recursively over all array elements/struct members and applying
>corresponding implicit casting rules to the corresponding parts of the
>other type, but this is complicated enough to be left to the imagination
>of the reader.

Again, when you refer to the entire packed array/struct, it is just a
vector.  It doesn't matter what is in it.  The implicit casting rules
that apply are those that apply to the vector type.

If this kind of complete bypassing of any type checking on the
elements/members of the array/struct is not desirable for some types
(such as enums) then those types should not be allowed in packed
arrays/structs.  Note that the same arguments can be applied to
unions.  

But once you allow something, the type rules for the packed array/struct
referenced as a whole are well-defined.  They are those of a vector of
that width, 2/4-stateness and signedness.

Steven Sharp
sharp@cadence.com