RE: [sv-bc] unpacked multi-D array type compatibility

I would argue that the way the LRM is written today, the intuitive
interpretation of multi-D arrays is that they are true multi-D arrays
and that other ways of looking at them are special cases, rather than
the other way around.

Understand that there are several issues here: only one is whether the
two forms really are the same (are they really? does $dimensions give
the same result in both cases?). Another is a clear and unambiguous
specification in every relevant place in the LRM of the behavior of an
operation on a multi-D array.

I would also argue that it is more intuitive to say that a multi-D array
can be looked at in more than one way and to specify in each place which
way is used than to say that it is really a 1-D array, but in a few
dozen places we relate to it in the "wrong" way.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Jonathan Bromley
> Sent: Sunday, March 05, 2006 11:37 AM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] unpacked multi-D array type compatibility
> 
> > Fair enough.  But array_2 is really a one-dimensional array,
> too,
> > because all arrays in Verilog are one-dimensional.  An array
> > in Verilog
> > is said to be "multidimensional" if its elements are arrays.
> >
> > The syntax for declaring nested array types without defining
> them in
> > typedef stages is just sugar.
> 
> By contrast with VHDL, in which you can create a true n-
> dimensional
> array:
> 
>   type twoD_array is array(1 to 3, 5 downto 0) of integer;
> 
> distinct from the more common and useful array of 1-d arrays:
> 
>   type oneD_array is array(5 downto 0) of integer;
>   type array_of_arrays is array(1 to 3) of oneD_array;
> 
> array_of_arrays is not compatible with twoD_array.
> 
> If Shalom is right that the LRM doesn't yet say so, it would
> probably be a good idea for it to contain an explicit statement
> of SV's behaviour as described by Brad.
> 
> Multi-dmensional arrays have limited practical usefulness in
> VHDL because it is so spectacularly tiresome to slice them,
> but the underlying idea provides some interesting possibilities
> (like being able to extract arbitrary rectangular "slices").
> I assume that, at this late stage, sv-bc would prefer not to
> grapple with such delights.  SV has plundered enough existing
> languages already; perhaps we should draw the line at
> cross-border raids on Matlab and APL :-)
> --
> Jonathan Bromley