RE: [sv-bc] packed integer arrays

Paul,

There is an important aspect of the predefined integer
types that you might not be aware of.

Due to DPI, the types
    bit signed [31:0] x;
and
    int

are quite different. 
Same for the others (shortint, byte, longint).

On the C side of the interface, the predefined integer
types are treated as their C equivalents:
  int      -> int
  shortint -> short
  longint  -> long long
  byte     -> char

Any packed bit vector type is treated as a svBitVecVal*,
and the C programmer extracts bits from words in the
svBitVecVal array using offsets, shifts, and masks.

For 4-state types, all packed arrays are treated as
svLogicVecVal*, and the PLI aval/bval scheme is used
to extract bits.

On the pure SV language side, I can see that bounding the
range of predefined integer types might be useful for
synthesis and expression of design intent.  I'm not
opposed to this idea, though I haven't thought about
its ramifications deeply.  You should probably enter a
Mantis item, since it's most likely too late in the
balloting process to introduce such a major new
concept in the language.

I've been thinking that the predefined integer types would
be most useful on the "System" side of SystemVerilog, however,
where such range bounding would presumably be less useful.

Regards,
Doug


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Paul Graham
> Sent: Monday, April 25, 2005 6:24 AM
> To: sv-bc@eda.org
> Subject: [sv-bc] packed integer arrays
> 
> I wonder if the issue of packed integer arrays could be
> revisited.  It is currently illegal to declare a packed
> array of predefined integer types:
> 
>     integer [3:0] x;
> 
> This is because it was legal in verilog-1995 (or maybe just
> in some simulators) to attach a range to an integer
> declaration, in much the same way that a range could be
> attached to a parameter declaration.  This range would not
> create an array of integers, but instead specify a different
> width for the single integer.
> 
> To avoid ambiguity with this odd declaration, SV disallows a
> packed array of any predefined integer type.  I can see why
> this restriction should exist for the integer declaration
> given above, but why should it apply to all the other
> predefined integer types?  It makes all the predefined
> integer types into second-class types.  
> 
> This restriction is unnecessary.  There is no legacy code
> which looks like this:
> 
>     byte [3:0] x;
> 
> or like this:
> 
>     typedef integer [3:0] int_vec;
> 
> or like this:
> 
>     struct packed {
>         integer [3:0] x;
> 	...
> 
> or like this:
> 
>     integer [3:0][1:0] x;
> 
> So I end up defining types "mybyte", "myint", etc. just to
> have useful first-class integer types.  It makes me wonder
> why the predefined integer types exist in the first place.
> 
> The only case we are guarding against is an "integer"
> declaration with a single range in the packed array syntax.
> There is no other case that can cause ambiguity or backwards
> incompatibility.  I see no reason to generalize from this
> special case to include all predefined integer types in all
> declarative contexts.
> 
> So I propose changing the rule (section 5.2) from:
> 
>     Integer types with predefined widths cannot have packed
>     array dimensions declared. These types are: byte,
>     shortint, int, longint, and integer.
> 
> to:
> 
>     There is one exception to the rules for packed array
>     syntax.  A variable declaration whose data type is the
>     predefined type "integer" followed by a single
>     dimensional range is interpreted as a signed array of
>     bits whose bounds are given by the range. That is, a
>     variable declaration of the form:
> 
>         integer [msb:lsb] x;
> 
>     is equivalent to:
> 
>         logic signed [msb:lsb] x;
> 
> Or if you don't like that, how about this:
> 
>     There is one exception to the rules for packed array
>     syntax.  A variable declaration whose data type is the
>     predefined type "integer" followed by a single
>     dimensional range is an error.
> 
> Paul
>