[vhdl-200x-ft] Personal evaluation of proposals FT-14 and FT-15

These are the most important proposals in VHDL-200x for me and the designers
I've talked with at my company. I think the proposals are on the right
track, but need some honing.

I think these two proposals should be merged. Mostly I think this because I
was browsing the LRM trying to see what changes would need to be made for
these proposals, and they were highly interrelated. It also seems strange
to me to allow one composite type to have unconstrained elements and not the
other.

In general, the proposals are fairly simple and straightforward. My only
question is whether to allow partial constraints. Details on this are near
the end of this post.

In FT-14, the first example well illustrates the proposed enhancement.
Later examples confuse the issue for me. Specifically, the component
declaration

> COMPONENT Reduce is
> generic
> ( Width : integer;
> Depth : integer
> );
> port
> ( D_IN : IN array(Depth -1 downto 0) of
> std_logic_vector(Width-1 downto 0);
> Q : OUT array(Depth -2 downto 0) of
> std_logic_vector(Width-2 downto 0);
> );
> end COMPONENT;

is not particularly close to current VHDL syntax, and weakens VHDL's strong
typing philosophy. This is essentially declaring a type in an interface
list, which should be put in a separate proposal if it is desirable. I
don't have any current use for this feature.

The following example has some great ideas, but I don't think the syntax
works. Actually, I believe the syntax works right now, just not the way Jim
is suggesting. If I am wrong here, please let me know, because some of our
current tools seem to work the way Jim is describing instead of the way I
think they should based on the LRM.

>Form 1: unconstrained array of unconstrained array
> type two_dim_arrayofarray is array(natural <>) of std_logic_vector ;
>
> signal A : two_dim_arrayofarray (Depth-1 downto 0)(Width-1 downto 0) ;
> signal A2 : two_dim_arrayofarray (Depth-2 downto 0)(Width-2 downto 0) ;
>
> Currently arrays of arrays are really useful as one can manipulate
> a row as follows:
>
> signal D : std_logic_vector(Width-1 downto 0) ;
>
> D <= A(1) ;
>
> A further interesting extension would be to be able to grab a column
> as follows:
>
> signal G, H : std_logic_vector(Depth-1 downto 0) ;
>
> G <= A(Depth-1 downto 0)(1) ;
> H <= A(all)(1) ;
>
> Since one is really accessing a column of elements of std_logic,
> a type conversion may be required:
>
> G <= std_logic_vector(A(Depth-1 downto 0)(1)) ;
> H <= std_logic_vector(A(all)(1)) ;
>
> Perhaps further capability, but not justified by this example:
> A2 <= A(Width-2 downto 0)(Depth-2 downto 0) ;

The right-hand side of the first example,

> G <= A(Depth-1 downto 0)(1) ;

is already valid VHDL. The expression "A(Depth-1 downto 0)" is a slice name
which serves as a prefix for index "(1)". This produces a
std_logic_vector--element 1 of array A (an object of subtype
"std_logic_vector(Width-1 downto 0)") instead of a column of A. Still, I
could use this functionality. For example, I could extract all the sign
bits from a set of signed values. But this syntax may not be the best for
this operation.

The further capability

> A2 <= A(Width-2 downto 0)(Depth-2 downto 0) ;

would also be useful to me. Again, I believe this statement would currently
be interpreted differently than Jim intends. Specifically, "A(Width-2
downto 0)" is a slice name that serves as the prefix for the slice "(Depth-2
downto 0)". Assuming Width=Depth (or the expression is an error), this
expression would return a an array of subtype "two_dim_arrayofarray(Depth-2
downto 0)(Width-1 downto 0)".

The essence of these proposals is to add valid constructs, not change
current syntax. I propose dropping these sections from the proposal.

Instead, selecting columns and sub-arrays makes much more sense for
multi-dimensional arrays. Luckily, Jim addresses multi-dimensional arrays
next! However, the examples given illustrate the power of allowing slices
in multi-dimensional arrays, not arrays of unconstrained arrays. The type
definitions given are already valid VHDL. Consequently, I also propose
dropping this section from the proposal.

The resulting proposal ends after the "element e" declaration. Again, this
first example is an excellent illustration of the proposed enhancement. The
proposal does need to be extended to show another level of unconstraint (see
the example below) and establish one of partial constraints rules below (or
a better one I haven't thought of).

But first a quick discussion of FT-15. Although I also am not jazzed about
the subtype indication syntax, I cannot think of another that is more
natural or consistent with the existing language. And I really want the
capability, so I'm willing to live with the syntax.

Now back to partial constraints. To make this a little more concrete, I
will combine Jim's examples.

type std_logic_matrix is array (natural range<>) of std_logic_vector;
type std_logic_3dim is array (natural range<>) of std_logic_matrix;
type complex is record
  a : std_logic ;
  re : signed ;
  im : signed ;
end record ;
type complex_vector is array (natural range<>) of complex;

-- constraining in declaration
signal A : std_logic_matrix(7 downto 0)(5 downto 0) ;
signal B : complex (re(7 downto 0), im(7 downto 0)) ;

entity in_question is
  generic (
    width_re : integer := 8;
    len_data : integer := 4
  );
  port (
    phasor : complex(re(width_re-1 downto 0));
    more_phasors : complex_vector;
    data_3d_1con : std_logic_3dim(len_data-1 downto 0);
    data_3d_2con : std_logic_3dim(1 to len_data, 1 to len_data);
    data : std_logic_matrix(0 to len_data-1)
  );

Signal declarations must be fully constrained. That's fine. The fun
discussion I know of centers around port maps (or interface lists in
general). I see a few possible rules.

1) Require all subtype indications to be constrained. I think this is a bad
idea since it removes functionality already in the language.

2) Require all subtype indications to have fully constrained elements. This
would allow only the top level of a composite type port to be unconstrained.
For example, the "more_phasors" port would be illegal because the "complex"
type element is not constrained. On the other hand, the "data" could be
legal if the "(0 to len_data-1)" applied to the element type instead of the
"std_logic_matrix" type. This does not remove any functionality already in
the language, but the syntax could be messy.

3) Require all constrained subtype indications to have fully constrained
elements. This corresponds to the "data_3d_1con" port if the constraint
applies to the type of the element of the element ("std_logic_vector").
Again I think this is the reverse of what I expect.

4) Require all subtype indications to be constrained except at the lowest
level. This is also equivalent to the functionality currently in the
language although from a different direction relative to (2). However, I
cannot think of a good way to express this in English or in a formal
grammar. I think this is not the best option.

5) Require all subtype indications with constrained elements to be
constrained. This is the mirror image of (2). This requirement would match
naturally with the syntax and require minimal LRM changes.

6) Require nothing. This free-for-all approach would require some
additional language extensions in order to skip specifying constraints.
Also, this is the only rule that would allow partially constrained records.

Both (2) and (3) infer a "bottom-up" approach similar to what the C language
requires for its arrays. Still, I think the syntax is backward. I would
intuitively associate the constraint on "data_3d_1con" with its type,
"std_logic_3dim", and not with the lowest-level type, "std_logic_vector".
Rules (4) and (5) infer a "top-down" approach which is more natural
syntactically, but may have elaboration issues.

One possible syntax addition is to allow an "open" constraint. For example,
to constrain the lowest element type of "data_3d_1con", use a port
specification like

    data_3d_1con : std_logic_3dim(open)(open)(len_data-1 downto 0);

This addition would enable (6) and make (2) and (3) more natural to my way
of thinking.

Personally, I am not too particular about which rule is adopted. All of the
designs I have seen at my company fully constrain all subtype indications on
ports (even though the language does not require it). Basically, everything
is going to have to be constrained eventually anyway. It might be
inconvenient to specify a few more generics, but it doesn't change the scope
of what I can describe with the language (although I have not thought much
about subprogram interface lists). On the other hand, it is a good idea to
avoid requiring what isn't really required so you don't have to remove the
requirement in the next version of the language. I am very interested to
hear what others think about how the possible rules would affect
elaboration.

In summary, I really want these changes. I think the proposals are
basically sound once FT-14 is whittled down. When they address partial
constraints, I think they will be complete and ready for analysis.

On related topics, I would use slices of multi-dimensional arrays if they
were legal. I can try to put something together if I know to which group to
post it. Also, if FT-14 is accepted, the first thing I will do is create a
package with types like "std_logic_matrix" and "signed_vector". These types
could easily and profitably be included in the std_logic_1164 and
numeric_std packages.

I hope to see comments and corrections posted soon!

---
Ryan Hinton
L-3 Communications / Communication Systems - West
ryan.w.hinton@L-3com.com