Re: [vhdl-200x-ft] Question on FT14: why a period in array element constraint

Peter,
I am not real comfortable with the approach of
lets make FT14 syntax now and worry about slicing
later. I would prefer that we have in mind a
syntax for slicing that is consistent with what we
do for FT14, however, I also want to go forward with
FT14 during FT.

If we are going to forgo the ".", is there a way to
augment the slicing rules so that in the presence of
arrays of arrays, the second slice applies to the second
array rather than reslicing the first array. So
revising the example from FT15 section B without the "."

TYPE BYTE_VECTOR IS ARRAY(NATURAL RANGE <>) OF UNSIGNED(7 DOWNTO 0);
TYPE NIBBLE_VECTOR IS ARRAY(NATURAL RANGE <>) OF UNSIGNED(3 DOWNTO 0);

SIGNAL Bytes : BYTE_VECTOR(1 TO 10);
SIGNAL Low_Nibbles : NIBBLE_VECTOR(1 TO 10);
SIGNAL High_Nibbles : NIBBLE_VECTOR(1 TO 8);

Low_Nibbles <= NIBBLE_VECTOR(Bytes(1 TO 10)(3 DOWNTO 0));
High_Nibbles <= NIBBLE_VECTOR(Bytes(2 TO 8)(7 DOWNTO 4));

Regards,
Jim

> Ryan,
>
> Thanks for the rationale. I'm inclined to re-examine the tentative syntax
> in FT15 rather than obfuscate the syntax in FT14.
>
> For FT15, I'm not particularly enamoured of the proposed changes to selected
> names. The way names work now is that they take a (syntactically) arbitrary
> prefix, and append a suffix whose form indicates the kind of operation to be
> performed:
>
> prefix.identifier - selection within a name space (eg, a record)
> prefix(expression, ...) - array indexing
> prefix(discrete_range) - 1D array slicing
> prefix'identifier - attribute referencing
>
> This is to a first-order approximation, but it gives you the flavour of
> things. You can see that in each case, it's syntactically clear where the
> suffix ends.
>
> It seems that the problem exposed in FT15 is that we want to distinguish
> between doing multiple levels of slicing at different levels in the
> hierarchy of a composite object, versus repetitive slicing at the top-level
> of the hierarchy. One way to achive this would be to consider the
> multi-level slicing as a single operation, and to provide a notation for it
> as a name suffix that is delimited in some way.
>
> Part A of FT15 goes part of the way, by extending the slice notation to work
> for other than 1D arrays. It proposes decimated names:
>
> prefix(index_decimation, ...)
>
> where index_decimation is either an expression or a discrete_range. This
> subsumes both indexed names (index_decimations are all expressions) and
> slice names (one index_decimation that is a discrete_range).
>
> What we also want is a way of specifying that, after doing a decimation or
> selection, we apply a suffix operation across all elements of the result.
> This yields something that has the same top-level structure (ie, rank) as
> the result of decimation or selection, but with different element structure.
>
> Come to think of it, maybe you want to do this not just for the result of
> decimation or selection, but for any prefix. Your example in FT15.B,
> getting the real sign bits, illustrates this. In the example, you use a 2D
> slice to refer to the whole of the array so that you can then dive down to
> the element structure:
>
> SIGNAL Cplx_5x7 : COMPLEX_7BIT_MATRIX(1 TO 5, 1 TO 7);
>
> Cplx_5x7(1 TO 5, 1 TO 7).re.(6 DOWNTO 6)
>
> You don't really want to slice the top-level structure of the array here,
> but you're forced to in order to navigate deeper into the structure.
>
> Maybe a way to meet the requirements is to invent a subelement operation
> (for want of a better name) that does record element selection and/or
> decimation below the top-level structure. Playing with syntax for now, the
> above example might look like
>
> cplx_5x7{.re(6 downto6)}
>
> The other examples in FT15.B might be recast as
>
> Bytes{(3 DOWNTO 0)}
> Bytes(2 TO 8){(7 DOWNTO 4)}
>
> I'm not proposing we resurrect FT15 at this stage. Rather, I'm suggesting
> that we don't mess up the syntax in FT14 in order to conform with an
> incompletely considered proposal in FT15. I'd prefer to design a clean
> syntax for FT14, then make sure FT15 integrates with it cleanly when we come
> back to it next rev.
>
> Comments?
>
> 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: Hinton, Ryan W @ CSW-SLC [mailto:ryan.w.hinton@L-3com.com]
>>Sent: Tuesday, 21 December 2004 02:23
>>To: 'Peter Ashenden'; vhdl-200x-ft@eda.org
>>Subject: RE: [vhdl-200x-ft] Question on FT14: why a period in
>>array element constraint
>>
>>
>>Peter,
>>
>>The period was included to make it more consistent with
>>FT-15, which has been deferred. The syntax for the
>>constraint is a little odd, but in FT-15 the period was used
>>to slice multiple levels of hierarchy (as opposed to slicing
>>the top-level array multiple times).
>>
>>---
>>Ryan Hinton
>>L-3 Communications / Communication Systems - West
>>ryan.w.hinton@L-3com.com
>>
>>
>>-----Original Message-----
>>From: Peter Ashenden [mailto:peter@ashenden.com.au]
>>Sent: Wednesday, December 15, 2004 10:00 PM
>>To: vhdl-200x-ft@eda.org
>>Subject: [vhdl-200x-ft] Question on FT14: why a period in
>>array element constraint
>>
>>
>>Folks,
>>
>>I'm looking through FT14, and wonder why the proposed syntax
>>includes a period before an array element constraint. The
>>specific rule is
>>
>> augmented_index_constraint ::=
>> optional_index_constraint . constraint
>>
>>This means a subtype indication constraining an element
>>subtype would be written
>>
>> A(0 to 7).(10 downto 1)
>>
>>Is there any reason for not omitting the period and just writing it as
>>
>> A(0 to 7)(10 downto 1)
>>
>>Thanks.
>>
>>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
>>
>
>
>
>
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~