Re: [sv-bc] Packed arrays of bytes -- are they legal?

>Is the following illegal?
>
>        typedef byte T1 ;
>        typedef T1 [3:0] T2 ;
>
>According to 5.2 of IEEE Std 1800-2005
> 
>    "Packed arrays can be made of only the single bit data types (bit,
>logic, reg) and recursively other packed arrays and packed structures." 
>
>and 
>
>    "Although an integer type with a predefined width n is not a packed
>array, it matches (see 6.9.2), and can be selected from as if it were, a
>packed array type with a single [n-1:0] dimension."

It was my understanding that the built-in integral types could not have
additional packed dimensions added.  The reason for this was apparently
that there was legacy Verilog code with ranges on integer declarations.
This code was illegal Verilog, but most tools would just ignore the
ranges.  There was concern that this legacy code would change meaning if
the range suddenly started meaning something.  I question the validity of
a "legacy" argument for code that has always been illegal, and that tools
should have been warning or erroring about, and users fixing.

>But a friend claims that this LRM restriction only prohibits the byte,
>integer, shortint keywords from being used directly in a packed array
>declaration.

While the reason for the restriction would not apply to a typedef, I
don't agree that the restriction does not apply there.  In general, a
typedef is just a renaming of the type and follows the same restrictions.
If there were a special rule for this case, it would need to be spelled
out in the LRM.

>An argument in favor of that viewpoint is 6.9
>
>    "SystemVerilog does not require a category for identical types to be
>defined here because there is no construct in the SystemVerilog language
>that requires it. For example, as defined below, int can be interchanged
>with bit signed [31:0] wherever it is syntactically legal to do so.
>Users can define their own level of type identity by using the $typename
>system function (see 22.2) or through use of the PLI."

This text is erroneous, or at least misleading, if it is interpreted as
meaning that these two types behave identically.  For one thing, these
two types behave differently when passed to DPI.  I think this statement
must be discounted.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.