Subject: Re: Proposal for array types
From: Peter Flake (flake@co-design.com)
Date: Fri Apr 05 2002 - 08:34:30 PST
Paul,
Thanks for your proposal. I have the following comments.
At 01:08 PM 4/3/02 -0800, Paul Graham wrote:
>Section 4.2 Packed and unpacked arrays
>
>Change this paragraph:
>
> Dense arrays of small data types such as bits can be stored packed (8
> bits to a byte) or unpacked (1 bit to a word). This choice affects the
> efficiency of operations such as addition of bit vectors or selection of
> individual bits, and is similar to the Verilog-2001 notions of vectored
> and scalared. Assignments and arithmetic operations are allowed for
> packed arrays but not for unpacked. The vectored and scalared modifiers
> shall behave as defined in the IEEE Verilog standard. They may be used
> by software implementations to optimize performance.
>
>to:
>
> A packed array is a mechanism for subdividing an integer into subfields
> which can be conveniently accessed as array elements. Consequently, a
> packed array is guaranteed to be represented as a contiguous set of
> bits. (An unpacked array may or may not be so represented). A packed
> array differs from an unpacked array in that when a packed array appears
> as a primary, it is treated as an integer.
>
> [ Need to clarify: if a packed array is declared 'signed', does this
> mean that the array, viewed as a single integer, is a signed integer,
> or does it mean that each element in the array is signed, or both? ]
The array viewed as a single integer is signed, like Verilog 2001.
Note that Verilog 2001 defines part selects as unsigned.
> [ Also, I see no need to mention 'scalared' and 'vectored' in this
> section. These keywords have nothing to do with SystemVerilog, and
> perhaps should be deprecated. In any case, they don't belong in the
> section on arrays. ]
Where should they be mentioned?
>11.2 Tasks
>
>Change
>
> Each formal argument also has a data type which can be explicitly
> declared or can inherit a default type. The default type in
> SystemVerilog is logic, which is compatible with Verilog. SystemVerilog
> allows packed arrays to be specified as formal arguments to a task, for
> example:
>
> task mytask4(input [3:0][7:0] a, b, output [3:0][7:0] y);
> ...
> endtask
>
>to:
>
> Each formal argument also has a data type which can be explicitly
> declared or can inherit a default type. The default type in
> SystemVerilog is logic, which is compatible with Verilog. SystemVerilog
> allows an array to be specified as a formal argument to a task, for
> example:
>
> task mytask4(input [3:0][7:0] a, b[3:0], output [3:0][7:0] y[1:0]);
> ...
> endtask
>
> [ I assume that the full declaration of b in this example is:
>
> input [3:0][7:0] b[3:0];
>
> Am I right? ]
Yes
>Likewise, change the corresponding sentence for functions in 11.3:
>
> SystemVerilog allows packed arrays to be specified as formal arguments
> to a function, for example:
>
> function [3:0][7:0] myfunc4(input [3:0][7:0] a, b);
>
>to:
>
> SystemVerilog allows an array to be specified as a formal argument to a
> function, for example:
>
> function [3:0][7:0] myfunc4(input [3:0][7:0] a, b[3:0]);
>
>Also, to allow a function to return an unpacked array, we need to change the
>syntax a little. I propose changing:
>
> function_declaration ::=
> function [automatic] data_type tf_name ; or ( fn_formals )
>
>to:
>
> function_declaration ::=
> function [automatic] data_type tf_name [unpacked_dimension] ; or
> ( fn_formals )
>
>That is, allow an optional unpacked_dimension to follow the function name in
>its declaration. For instance:
>
> function [3:0] f [7:0] (input [3:0] x [3:0] );
> return {x, x}; // is this a legal use of array concatenation?
No.
>Section 16 System tasks and system functions
>
>16.1 Introduction
>
>Change:
>
> SystemVerilog adds a system function to determine the bit size of a
> value.
>
>to:
>
> SystemVerilog adds several system function to determine the bit size of
> a value and the bounds of an array.
>
>Add:
>
> 16.3 Array querying functions
>
> Five new system functions are provided to return the bounds of an
> array. Each function has the syntax:
>
> <function>(<array>, <dimension>)
>
> where <function> is one of {$left, $right, $low, $high, $size}. <array>
> is any declared array. <dimension> specifies which dimension of the
> array is to be queried.
>
> The dimensions of an array are numbered as follows. The slowest varying
> dimension (packed or unpacked) is dimension 1. Successively faster
> varying dimensions have sequentially higher dimension numbers. For
> instance:
>
> // Dimension numbers
> // 3 4 1 2
> reg [3:0][2:1] x [1:5][2:8];
>
> The $left function returns the left bound (msb) of the dimension.
> The $right function returns the right bound (lsb) of the dimension.
> The $low function returns the minimum of $left and $right of the
> dimension.
> The $high function returns the maximum of $left and $right of the
> dimension.
> The $size function returns the number of elements in the dimension, or
> $high - $low + 1.
I would add $dimensions(<array>) to return the count of the number of
dimensions, 0 for scalar.
> For an integer or bit type, only dimension 1 is defined. For an integer
> X declared without a range specifier, its bounds are assumed to be
> [$bits(X)-1:0].
For any scalar (non-array) type, such as int a; the number of dimensions
should be 0. The type can be found using $type(a).
Regards,
Peter.
This archive was generated by hypermail 2b28 : Fri Apr 05 2002 - 09:35:36 PST