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

Steven Sharp wrote:
>> 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."
> 
> [T]he 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.

Right.  Haven't seen any in the wild, but we have regression tests for it.

>> 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.

The question then is whether this is a syntactic restriction on the use
of some convenience keywords, or a semantic restriction on additional
types.  It's clear that "typedef signed [31:0] my_integer" is not
impaired in this way.  Saying that "integer" is a different type which
/is/ so impaired and continues to be impaired even if renamed seems
to give too much emphasis to the cover-up of the legacy syntax anomaly.

> 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.

Appendix F.6.4 describes DPI type matching as making the distinction you expect.
> The input mode arguments of type byte unsigned and shortint unsigned are not equivalent to
> bit[7:0] or bit[15:0], respectively, because the former are passed as C types unsigned char and
> unsigned short and the latter are both passed by reference as svBitVecVal types. A similar lack of
> equivalence applies to passing such parameters by reference for output and inout modes, e.g., byte
> unsigned is passed as C type unsigned char* while bit[7:0] is passed by reference as svBitVecVal.

Since integer and my_integer types "match", will there be any DPI difficulty
when an integer variable passes via a function or interface port to a my_integer
variable?  Perhaps these types should /not/ match?  They can continue to be
"equivalent": a matter which always admits some small coercion of bounds values
or bit width.

If a semantic property of keyword integral types is being specified, I'd prefer
to see a type-query capable of distinguishing the new types, so that strict
binding rules can enforce identical DPI compatibility of the data.

Greg


> 
> Steven Sharp
> sharp@cadence.com
> 
> 


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