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.