Subject: Re: Thoughts about arrays in SystemVerilog
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Mar 26 2002 - 14:48:09 PST
Paul Graham wrote:
>
> Here are a few thoughts about arrays in SystemVerilog. This is not a
> proposal, just an exploration of the issues raised at yesterday's phone
> meeting.
>
> 1. Peter pointed out that one source of Verilog's simulation efficiency is
> its lack of variable length arrays.....
I suspect the performance difference on large arrays due to variable size
would be marginal, and probably has more to do with the restricted set of
data types in Verilog.
> 2. A feature of VHDL and C, but not Pascal or Verilog, is the ability to
> declare a function which operates on a variable-length array. In VHDL this
> is done using an unconstrained array argument. In C it is done with a
> pointer to the start of the array and a specification of the element type,
> but no indication of the array length. It would be nice, at some point in
> the future, to allow Verilog functions (and modules) to accept
> variable-length array arguments.
Definitely a good idea...
> One objection to variable-length arguments is that they require
> simulation-time size data, which goes against the efficiency concerns in
> part 1. above. But a way to get around this problem is by function or
> module cloning....
.. Might want to add 'inline' (as per C++) to avoid inefficiency in functions
and tasks, if you do a modular compile it's hard to do cloning.
>
> 3. The first item in my array proposal is to remove the packed array syntax
> and use only the unpacked array syntax....
> If we remove the packed array syntax, then we can adopt the convention that
> all array bounds appearing in a declaration or typedef beyond the first
> (bit-vector) dimension are applied to the unpacked array dimensions. With
> this convention,
>
> typedef reg [3:0] foo; // bit-vector range [3:0];
> foo [4:0] bar; // same as reg [3:0] bar [4:0]
> foo bar2 [4:0]; // same as reg [3:0] bar2 [4:0]
>
Since we probably want to drive synthesis with this, I would suggest
keeping the disctinction of packed vs. unpacked, particularly when
talking about objects that are addressable - the implication being
packed = contiguous.
Similarly unions should only contain "packed" objects....
> 5. With all this said, I have to admit that the packed array syntax is
> convenient for representing something like an array of registers which are
> in turn subdivided into bit-fields. For instance, the PowerPC Altivec
> register set can be declared as:
>
> reg [3:0][31:0] regs [31:0];
>
> If you're familiar with the Altivec register set, you'll know that it can
> also be declared as:
>
> reg [127:0] regs [31:0];
> reg [8:0][15:0] regs [31:0];
> reg [15:0][8:0] regs [31:0];
>
> Basically, a 128-bit register can be seen as a single integer, 4 words, 8
> half words, or 16 bytes.
==?
union {reg [3:0][31:0] A;
reg [127:0] B;
reg [8:0][15:0] C;
reg [15:0][8:0] D;} regs [31:0];
> However, Verilog-2001 does provide variable part selects, which I suppose
> are intended to make it easy to index into an integer as though it were a
> small array. So even without packed arrays it is not too hard to index
> into 'regs' like:
>
> regs[x][y*8-1-:8] -- get y'th byte of x'th reg
> regs[x][y*16-1-:16] -- get y'th half-word of x'th reg
> regs[x][y*32-1-:32] -- get y'th word of x'th reg
>
> Comments anyone?
>
> Paul
We had some discussion about overlays and endianness, since Verilog is not
compiled to a specific architecture, and pointers are not implemented (yet),
I think we should take "little-endian" as the norm for packing. I.e. running
your Verilog simulation on Sparc vs. X86 should get the same results without
ugly `ifdefs in the source. E.g.:
union { int i;
char c[3:0];
bit [31:0] b;} reg32;
c[3] always contains the sign bit of 'i' which is also b[31].
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Tue Mar 26 2002 - 14:49:46 PST