RE: [sv-bc] enums in packed arrays

> Steven Sharp
> 
> At yesterday's SV-BC meeting, we modified the description of 
> packed unions in a way that allows enums as members of packed 
> unions.  We also noted that the LRM allows enums as members 
> of packed structs.
> 
> Given this, it seems inconsistent that the LRM does not allow 
> enums as elements of packed arrays.  Shouldn't we change this also?

I believe we discussed this in the past. We talked about allowing packed

arrays of enums provided that a packed array would be allowed for the 
base type of the enum (bit, logic, or reg). This would exclude enums 
with default base type int or other build in integer types. I thought
we made this change, but I cannot find it in any LRM, so I guess we
never approved it.

The reason packed arrays are not allowed for the build in integer types
is that VerilogXL allowed range specifications on integers and ignored 
them. Although this is not part of the LRM, most Verilog tools also
ignore
ranges on integers, so allowing packed dimensions on integers would
create
a backwards compatibility problem with legacy Verilog 95 designs (but
not the
actual LRM). For consistency we did not allow packed arrays of the
2-state
integer types, int, long int, and byte. 

We already allow back door packed arrays of these types:

typedef struct packed { integer x; } ST;
ST [3:0] s;

I don't see a problem with allowing packed arrays of all enums
regardless of
the base type. It does not create any backward capability issue. 

If you are going to argue that that there is something really different
about
integer, int, and byte from bit, logic, and reg, then why do we allow
integer, 
int and byte in packed structs and unions?