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

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
>