ISAC: Some questions concerning IR2121

Attached is a first version of a document which identifies some of the 
issues with partially open ports.
We should go over this at our next ISAC meeting.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Partially OPEN port maps.

Since VHDL-93 it has been illegal to use subelement association in
port maps or generic maps with some elements associated to signals and
other elements left OPEN.  This rule has caused problems for
designers, and there is a formal request to relax this
restriction. The ISAC is seeking input from interested persons to
identify potential problems in removing or relaxing this requirement.
For brevity, we will call such associations "mixed".

History of the Problem

The restriction was put into VHDL-93 in two places. Clause 1.1.1.2
states: "It is an error if some of the subelements of a composite
formal port are connected and others are either unconnected or
unassociated." This change was made in response to IR 0066. However,
no wording in this IR mentions subelement association. In addition
Clause 4.3.2.2 states: "It is an error if an actual of OPEN is
associated with a formal that is associated individually." This was
added in response to a ballot comment written by Jim Vellenga. The
ballots are no longer available, so the intended purpose of these
changes is somewhat obscure. The ISAC is interested in any additional
feedback on the origins of these changes.

Potential problems with relaxing the restriction.

1. The ISAC has not yet found any issues with allowing
mixed associations for ports of mode OUT.

2.Here is one example involving ports of a constrained subtype:
Suppose port P is of mode IN and of type bit_vector( 1 to 3 ) and you
supply a port map association of

    P(1) => S1, P(2) => S2.

Currently, you will get an error message, because you haven't associated
P(3). However, under the proposed change, this might be legal, but
unintended. One solution would be to allow partially unconnected ports, but
to disallow partially unassociated ports. For this example, you would have
to say specifically
    P(3)=> OPEN.

For ports of mode IN, there are potential problems in determining the
value of the port.

3. For mixed associations it makes sense to determine the initial
values for the OPEN subelements from the (required) default expression
in the port declaration. However, the default expression supplies
values for all subelements, and in general, the entire default
expression must be evaluated. This evaluation can be quite complicated
and expensive, involving impure functions and other complications. The
most reasonable interpretation is to determine values for all
subelements, then discard values which are covered by explicit
associations in the port map.

4a. In some cases involving unconstrained array types, the default expression
might not provide the correct values. 

Consider the following example:

    port p1: IN bit_vector := ( 1 => '1', 2 => '0');

The following association is legal:

     ...port map( p1(3) => '1', p1(4) => '0')... --default value not used

Port p1 gets its range from the subelement association and its
direction from the declaration of bit_vector.

The following association is also legal:

    ... port map ( p1 => OPEN )

Port p1 gets its range, direction and value from the default expression;

But what values are assigned in the following mixed case?

   ... port map ( p1(3) => '1', p1(4) => OPEN )

Port p1 gets its range (3 to 4) from the subelement association, but
there is no corresponding default value for p1(4) or is there a
matching element rule?

This issue becomes more serious for VHDL-200X, which allows
unconstrained subelements such as arrays of strings.

4b. port p1: IN bit_vector := ( 1 => '1', 2 => '0');
association
p1(1) => s1, p1(2) => s2, p1(3) => OPEN, p1(4) => s4
Is this legal? If so, what value is assigned to p1(3)?

5. The current LRM states that "It is an error if a port of any mode
other that IN is unconnected or unassociated and its type is an
unconstrained array type."  The main reason for this restriction is
the difficulty in determining the bounds and direction of an
unassociated, unconstrained port. However, we might want to relax this
restriction if subelement association is used to assign each
subelement to OPEN, because, in that case, the subelement associations
determine the bounds of the port.

6. Effect on incremental binding. OPEN elements in mixed port associations
can later be remapped using incremental binding. This might be difficult to
implement.

7. Non-compliant tools. The submitter of IR 2121 claims that the mixed
association is generated by a particular CAD program. There is a question
whether some non-compliant tools should modify their algorithms to generate
legal VHDL code, vs. many compliant tools changing their implementation. On
the other hand, partially OPEN ports seem to be natural in some realistic 
situations.

The ISAC is trying to gather opinions from a broad spectrum of VHDL
designers and implementors. We are particularly interested in finding
out: 1) Are there other technical issues which must be addressed? 2)
Is the gain to designers great enough to justify the effort needed to
solve all technical issues? 3) Do you have suggestions on solving any
of these technical issues?

Chuck Swart
Chair
VHDL Issues Screening and Analysis Committee (VASG)