attached is IR 0034

In the last email I attached IR0134 instead of IR0034

VHDL Issue Number: 0034
Classification: Language Definition Problem
Language Version: VHDL-87
Summary: The meaning of the constraint on a scalar signal
                        parameter is unclear.
Related Issues: 0026
Relevant LRM Sections: 12.6.1
Key Words and Phrases: Signal parameter, constraint
Current Status: ISAC-Approved
1076-1993 Disposition: Closed (All Issues Completely Addressed)
Disposition Rationale: VHDL-93 LRM was revised.
Superseded By: N/A
-----------------------
Date Submitted: 1989/02/10
Author of Submission: Doug Dunlop
Author's Affiliation: Intermetrics, Inc.
Author's Post Address: 4733 Bethesda Ave #415
                        Bethesda, MD 20814
Author's Phone Number: (301) 657-3775
Author's Fax Number:
Author's Net Address: dunlop@inmet.inmet.com
-----------------------
Date Analyzed: 1991/01/11
Author of Analysis: Paul Menchini (mench@clsi.com)
Revision Number: $Revision: 1.9 $
Date Last Revised: $Date: 1995/08/03 00:14:34 $

Description of Problem
----------------------
As an example, consider the case of an INTEGER signal being associated with a
signal parameter of type NATURAL. Since there is no subtype check for the
posted values at the time a signal assignment statement is executed, what could
be the significance of the constraint on the signal parameter? Signal
parameters are essentially aliases for real signals. I.e., they do not have
driving and resolved values of their own and they do not directly participate
in the LRM 12.6.1 signal update activity.

Proposed Resolution
-------------------
The argument given above that signal parameters are aliases of real signals is
not completely accurate because of the subelement association that is possible
when passing a composite actual signal to a composite formal signal parameter.
This functionality cannot be explained in terms of aliases. Hence the
following revised approach is adopted. The constraint on a scalar signal
parameter continues to have no effect at the time a signal assignment is made
to the parameter (since there is no subtype check for the posted values at the
time the signal assignment is executed). However, when a subprogram is entered
and when it resumes after a WAIT, a check is made that the values of its scalar
signal parameters lie within their specified subtype.

VASG-ISAC Analysis & Rationale
------------------------------
This is a difficult issue, and the ISAC has not been able to develop a
satisfactory solution, especially for 1076-1987. The ISAC examined five
different possible solutions to this issue:

    1. Perform range checks on scalar signal parameters whenever

        a. the subprogram is entered,

        b. (for procedures) upon return from a wait statement, and

        c. at the return points of the subprogram.

        (This is the author's proposed solution with the addition of checking
        at the return points of the subprogram.)

    2. Never perform range checks on the signal parameters of a subprogram.

    3. Require that the subtype indication of a signal parameter denote (in
        Ada terms) the "first named subtype" of a type. (The VHDL LRM does not
        utilize this concept--the ISAC has informally been using the term
        "least constraining subtype" to denote the same concept.)

    4. Perform range checks whenever a signal parameter is read.

    5. Require that the subtypes of signals associated with signal parameters
        have bounds identical to the bounds of range of the subtype of the
        signal parameter with which they are associated.

(Contrast these possibilities with issue 26.)

Proposal 1 ensures that the value of the parameter is within its range
constraint over all simulated time. However, this proposal is potentially
quite expensive to implement, since many checks can potentially be made to an
unchanging subprogram parameter. Moreover, it is insufficient to guarantee
that no constraint errors occur on the associated signal. Consider a signal of
subtype Std.Standard.Natural associated with a signal parameter of subtype
Std.Standard.Integer and of mode out. If negative values are assigned to the
signal parameter, then a constraint error could potentially occur on the
associated signal when it is updated.

Proposal 2 is the only one felt to be compatible with existing implementations
and models. Nevertheless, it has the effect of introducing "noise" into the
language (and thereby reducing the self-documenting qualities of models), since
the subtypes of subprogram parameters are not meaningful.

Proposal 3 implies that no range checks need ever be performed by the
subprogram. Nevertheless, existing models can become illegal, since subtypes
that were formerly valid are now illegal to use as the subtypes of signal
parameters. Moreover, in the case of out and inout parameters, constraint
errors can still occur on signals associated with these parameters.

Proposal 4 again can be expensive to implement, since a signal is potentially
read many times between events on the signal.

Proposal 5 is like Proposal 3 in that no range checks are required by
subprograms. Moreover, existing models can be broken. Note that no constraint
errors will occur on signals associated with signal parameters if this proposal
were adopted, since the subtypes will have identical ranges. However, this
proposal will be expensive to implement.

VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
In spite of the dilution of the self-documenting qualities of models, the only
acceptable short-term solution appears to be to adopt Proposal 2, which
effectively ignores the subtype of subprogram parameters.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Each of the five cases enumerated above need to be carefully analyzed to
determine the best long-term solution. In particular, a solution similar to
that adopted for issue 26 should be adopted.
Received on Fri Dec 3 14:26:58 2004