Peter,
I think we need to slice arrays of arrays also (it was in
the original proposal). I also think we need arrays of
arrays to make it easy to either ignore the last dimension
or use some other property of the type (unsigned, signed, ...)
entity GenericShift is
generic (
Width : integer := 4 ;
Depth : integer := 4 ;
) ;
port (
Clk : in std_logic ;
ShiftIn : in std_logic_vector(WIDTH-1 downto 0) ;
ShiftOut : out std_logic_vector(WIDTH-1 downto 0)
) ;
end entity GenericShift ;
architecture RTL of GenericShift is
-- hopefully added to 1164 some day
type std_logic_matrix is array (natural range<>) of std_logic_vector ;
signal ShiftReg : std_logic_matrix(DEPTH-1 downto 0)(WIDTH-1 downto 0) ;
begin
ShiftReg <= ShiftReg(Depth-2 downto 0) & ShiftIn when rising_edge(Clk) ;
end RTL ;
Also if the array is to store math values such as signed or
unsigned. Note I used the "." notation temporarily so no one
will object to the interpretation of the slice.
type unsigned_matrix is array (natrual range <>, natural range <>) of signed ;
signal A : unsigned(0 to 3, 0 to 3).(7 downto 0) ;
signal SignBit1_1 : std_logic ;
signal Row, Col : std_logic_vector(0 to 3) ;
Now lets suppose I need to collect the sign bits in one of
the dimensions of the matrix:
-- first sign bit:
SignBit1_1 <= A(1,1).(7) ;
-- row 1 sign bit
Row <= std_logic_vector(A(1, 0 to 3).(7)) ;
-- Column 1 sign bit
Col <= std_logic_vector(A(0 to 3, 1).(7)) ;
The original proposal for arrays of arrays included
slicing for both multidimensional arrays and
arrays of arrays. Ryan decided not to include it since
he realized that the following did not do what I wanted
it to do.
A2 <= A(Width-2 downto 0)(Depth-2 downto 0) ;
I think we need a notation to accomplish this. I am happy
with ".", however I would be happier without it. I agree
with Steve that we should not break backward compatibility,
however, here I think we should look at what is being
considered and determine whether this is something that was
a side-effect of the bnf notation or something that was
really intended. Likewise was it something that was
really used or not.
Cheers,
Jim
P.S.
In some ways I like "." better as it acknowledges that
the inner array dimensions are a field of the outer
dimension. Hence it would have a nice consistency
with record elements.
> Jim,
>
> Why are you using arrays of arrays, as opposed to multidimensional arrays?
> If you used the latter, Steve's notions of extending slices to denote
> rectangular chunks of multidimensional arrays would be rather elegant.
> Using a single index for one of the dimensions instead of a range would
> "collapse" that dimension of the chunk. So, for example, matrix(3 downto 1,
> 3) would not be a 3x1 matrix, but a 3-element vector.
>
> Cheers,
>
> PA
>
> --
> Dr. Peter J. Ashenden peter@ashenden.com.au
> Ashenden Designs Pty. Ltd. www.ashenden.com.au
> PO Box 640 Ph: +61 8 8339 7532
> Stirling, SA 5152 Fax: +61 8 8339 2616
> Australia Mobile: +61 414 70 9106
>
>
>
>>-----Original Message-----
>>From: owner-vhdl-200x-ft@eda.org
>>[mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Jim Lewis
>>Sent: Monday, 31 May 2004 07:26
>>To: vhdl-200x-ft@eda.org
>>Subject: Re: [vhdl-200x-ft] FT14 arrays of arrays and slices
>>
>>
>>Steve,
>>I don't like what you are doing with generate at all.
>>I think what we need is a consistent syntax for both
>>constraining arrays of arrays and slicing arrays of arrays.
>>Your generate only applies to slicing and the readability is terrible.
>>
>>
>>Is it possible to fix the following so it can slice
>>an array of an array?
>> Matrix_5x4(0 to 4)(3)
>>
>>It is odd to note that slicing the array of array
>>as follows does seem to do what I would expect:
>> Matrix_5x4(3)(2 downto 1)
>>
>>So is this an ambiguous place in the standard?
>>
>>
>>I think if this does not work, we need to reconsider
>>FT14 and figure out an alternate syntax for
>>constraining arrays of arrays. One that can give
>>us a consistent syntax for slicing an array of an
>>array.
>>
>>I suggested a separator of "." because it is also
>>used with records to separate items, but anything
>>that is consistent would be ok with me.
>>
>>With the "." syntax constraining an array of an array:
>> signal A : std_logic_matrix(7 downto 0).(5 downto 0) ;
>>
>>and slicing the array of array:
>> col <= Matrix_5x4(0 to 4).(3) ;
>>
>>Cheers,
>>Jim
>>
>>
>>>If slice names were extended to multi-dimensional arrays,
>>
>>then slices
>>
>>>for one or more dimensions could work:
>>>
>>> signal matrix : array(4 downto 0, 7 downto 0) of std_logic;
>>>
>>> my_vector <= matrix(3 downto 1, 3);
>>> -- This would slice off the 3rd bit of the 2nd dimension
>>
>>for each "row"
>>
>>> -- in the sliced matrix of (3 downto 1, 7 downto 0).
>>>
>>>But, this syntax would not automatically have extended
>>
>>meaning for the
>>
>>>array of arrays declaration that Jim provided below. I'd
>>
>>be concerned
>>
>>>that such extension would cause syntactic ambiguities or other
>>>problems.
>>>
>>>Perhaps what is needed is some form of repetition syntax
>>
>>that can be
>>
>>>combined with the slice/index names we already have:
>>>
>>> my_vector <= i in (3 downto 1) generate matrix(i, 3);
>>>
>>>And for Jim's example:
>>>
>>> col <= i in (0 to 4) generate Matrix_5x4(i)(3) ;
>>>
>>>This could be defined such that nesting is possible. Consider an
>>>arbitrary 3D array:
>>>
>>> z_axis_slice <= x in (2 to 5) generate (y in (0 to 2) generate
>>>threeD(x, y, 1));
>>>
>>>If this is a bit cumbersome, consider the use of a "function call
>>>syntax":
>>>
>>> my_vector <= matrix(generate(3 downto 1), 3);
>>> col <= Matrix_5x4(generate(0 to 4), 3);
>>> z_axis_slice <= threeD(generate(2 to 5), generate(0 to 2), 1);
>>>
>>>This form could cause parsing problems due to the function call
>>>syntax. I'm hopeful that the (re)use of the keyword generate would
>>>disambiguate any parsing problems. (Actually, in
>>
>>re-reading it, the
>>
>>>parsing ambiguity would probably be in trying to interpret
>>
>>"generate(x
>>
>>>to/downto y)" as a slice name.) But, compiler gurus would know
>>>better. (BTW, I like this form because it is more concise
>>
>>and easy to
>>
>>>read while leaving the existing slice and index name
>>
>>definitions alone
>>
>>>-- thus ensuring backward compatibility.)
>>>
>>>-Steve Bailey
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: owner-vhdl-200x-ft@eda.org
>>>>[mailto:owner-vhdl-200x-ft@eda.org
>>
>><mailto:owner-vhdl-200x-ft@eda.org> ] On Behalf Of Jim Lewis
>>
>>>>Sent: Saturday, May 29, 2004 11:58 PM
>>>>To: vhdl-200x-ft@eda.org
>>>>Subject: [vhdl-200x-ft] FT14 arrays of arrays and slices
>>>>
>>>>With FT14/FT15, we can constrain array ports and signals
>>>>using the following syntax:
>>>> type std_logic_matrix is array (natural range<>) of
>>>>std_logic_vector ;
>>>> subtype Matrix_5x5 is std_logic_matrix(4 downto 0)(4 downto 0) ;
>>>> signal A : std_logic_matrix(7 downto 0)(5 downto 0) ;
>>>>
>>>>
>>>>Is there anything that can be done to make indexing of arrays
>>>>of arrays more consistent with the above syntax?
>>>>
>>>> constant Matrix_5x4 : std_logic_matrix (0 to 4) := (
>>>> 0 => "0000",
>>>> 1 => "0001",
>>>> 2 => "0010",
>>>> 3 => "0011",
>>>> 4 => "0100"
>>>> ) ;
>>>>
>>>> signal row : std_logic_vector(3 downto 0) := (others => '0') ;
>>>> signal partial_row1 : std_logic_vector(1 downto 0) :=
>>>>(others => '0') ;
>>>> signal partial_row2 : std_logic_vector(1 downto 0) :=
>>>>(others => '0') ;
>>>> signal col : std_logic_vector(0 to 4) := (others => '0') ; . . .
>>>>
>>>> row <= Matrix_5x4(4) ; -- "0100"
>>>> partial_row1 <= Matrix_5x4(3)(1 downto 0) ; -- "11"
>>>> partial_row2 <= Matrix_5x4(3)(2 downto 1) ; -- "01"
>>>> -- col <= Matrix_5x4(0 to 4)(3) ; -- "0011"
>>>>-- not what I want
>>>>
>>>> I would like Matrix_5x4(0 to 4)(3) = "00000" an array of
>>
>>std_logic.
>>
>>>>Is there a practical application of where the current syntax
>>>>does something that is useful and in use?
>>>>
>>>>Do we need to consider additional syntax when constraining
>>>>arrays of arrays so we can indicate what we are doing?
>>>>
>>>>For example:
>>>> signal A : std_logic_matrix(7 downto 0).(5 downto 0) ;
>>>>
>>>>and:
>>>> col <= Matrix_5x4(0 to 4).(3) ;
>>>>
>>>>
>>>>For the full example, see the attached code.
>>>>
>>>>Cheers,
>>>>Jim
>>>>-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>Jim Lewis
>>>>Director of Training mailto:Jim@SynthWorks.com
>>
>><mailto:Jim@SynthWorks.com>
>>
>>>>SynthWorks Design Inc.
>>
>> http://www.SynthWorks.com <http://www.SynthWorks.com>
>>
>>>>1-503-590-4787
>>>>
>>>>Expert VHDL Training for Hardware Design and Verification
>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>
>>>
>>>
>>>
>>>------------
>>>Stephen Bailey
>>>ModelSim Verification TME
>>>Mentor Graphics
>>>sbailey@model.com
>>>303-775-1655 (mobile, preferred)
>>>720-494-1202 (office)
>>>www.model.com <www.model.com>
>>>
>>--
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Jim Lewis
>>Director of Training mailto:Jim@SynthWorks.com
>>SynthWorks Design Inc. http://www.SynthWorks.com
>>1-503-590-4787
>>
>>Expert VHDL Training for Hardware Design and Verification
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>
>
>
>
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Received on Mon May 31 10:26:05 2004
This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 10:26:09 PDT