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

I've submitted this as 1595. 

 

My personal suggestion is to allow enums as both members of packed
structs and as base types of packed arrays and to define type
compatibility rules for such types.

 

--Yulik. 

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Feldman, Yulik
Sent: Tuesday, September 12, 2006 10:34 AM
To: sv-bc@server.eda-stds.org
Cc: Samet, Moshe
Subject: [sv-bc] enums in packed arrays/structs

 

Hi,

 

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.

 

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.

 

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.

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.

 

Thanks,

            Yulik.