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 BromleyReceived on Sun Mar 5 02:06:37 2006
This archive was generated by hypermail 2.1.8 : Sun Mar 05 2006 - 02:07:43 PST