VHDL Issue Number: 0026 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Meaning of a constraint on a scalar alias is unclear. Related Issues: Relevant LRM Sections: 4.3.4 Key Words and Phrases: Alias, 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: 1990/09/27 Author of Analysis: Alex Zamfirescu Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/02 23:57:10 $ Description of Problem ---------------------- What does the constraint on a scalar alias mean? E.g., variable x : integer range 1 to 10; alias y : integer range 5 to 14 is x; What sense does this make? Should this be illegal? What does "it is viewed as if it were the subtype specified ..." from LRM 4.3.4 mean? Specifically, is variable x : integer range 1 to 10 := 6; alias y : integer range 1 to 5 is x; variable z : integer := y; illegal at the point of the declaration of z because when y is read it is outside the range of y? Proposed Resolution ------------------- The constraint implied by the subtype indication in a scalar alias declaration is ignored. VASG-ISAC Analysis & Rationale ------------------------------ There are apparently three possible interpretations of the constraint on a scalar alias: 1. Strict interpretation of "it is viewed as if it were the subtype specified ..." from LRM 4.3.4, i.e., if a scalar object is referenced via the alias, the subtype indication implied by the alias declaration, possibly different from the subtype indication of the scalar object declaration, is used to perform all required type checks. 2. It is an error if the subtype indication implied by the aliased scalar object and that implied by the alias declaration do not match. This means that for a scalar alias the subtype indication implied by the subtype of the aliased object should be the same as the subtype indication implied by the alias declaration. 3. Ignore the range constraint implied by subtype indication in a scalar alias. Option 1 and 2 will make illegal the second example in the above description of problem. The third interpretation will permit the declaration of z. The "modified view" (interpretation 1) approach when applied to aliases of arrays objects seems to be correct and quite useful. Indeed for arrays there is "another view" of the same data using another "grid" implied by the alias subtype. When applied to scalars, the same concept opens some problems. For scalars the alias constraint, if not ignored, applies directly to the value of the alias/object itself and will not constitute a one to one map of some indexes as in the array case. The problem is to determine if: a. The alias constraint applies also to the object or only to the alias ? In other words does the constraint of the alias propagate to the object ? a.1. If the alias constraint applies to the object, what is the semantic of multiple constraints, (from different aliases of the same object) ? a.2. If the alias constraint applies only to the alias, does this constraint apply a) only when the object is written via its alias (assigned to or initialized), b) just when the object is read, or c) in both cases (a) and (b)? During the discussion of this issue, some reasonable answers were found to the above questions a.1. and a.2 by the ISAC members. However, it was agreed that the answers were not an interpretation of the LRM rules but new semantic. Therefore, interpretation 1. was not considered as an immediate solution. Interpretation number 2. restricting the subtype of the alias to be the same as that of the object was also rejected as requiring a subtype check that is meaningless. Finally, the last interpretation (number 3 above) was considered as the only feasible short term solution. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Adopt the above proposed resolution: The constraint implied by the subtype indication in a scalar alias declaration is ignored. Treat the the sentences from LRM 4.3.4 "When the object denoted by the name is referenced via the alias defined by the alias declaration, it is viewed as if it were of the subtype specified by the subtype indication. The same applies to attribute references where the prefix of the attribute denotes the alias." as not referring to scalar types. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Following is a list of possibilities discussed by the ISAC members. One possiblity is to make optional the subtype indication in an alias declaration alias_declaration ::= alias identifier [:subtype_indication] is name; For example instead of writing alias y : integer range 1 to 10 is x; one could write just alias y is x; This leads to some interesting transition and upward compatibility issues. The possible future dialect, where subtype indication is optional in an alias declaration could have two different evolutions, i) one without upward compatibility, and a second ii) leading to a language compatible with IEEE Std 1076-1987. i) SCALAR_alias_declaration ::= alias identifier is name; Only declarations like alias y is x; are permitted for scalar objects - a simplification of the language that could balance the incompatibility issue. ii) Accept interpretation number 1. above, answering "yes, in both cases (a) and (b)" to question a.2. This means that the subtype indication will be optional in an alias declaration, and, when provided, the subtype constraint implied by the scalar alias declaration is used to check that the object value denoted by the name in the alias declaration is in the "resolved" range. Here "resolved" means one of the following: 1. The intersection of the ranges implied by the object declaration and the alias declaration; 2. Only the range implied by the alias constraint; 3. The intersection of all ranges defined by all alias declarations for that same scalar object. Choice number 1. for the resolved range above could be enforced further by allowing only sub-ranges of the object range for scalar alias definitions. Another possibility is to continue to accept the VHDL87 recommendation. Note: Here we used the notion of upward compatibility of a future (new) VHDL standard in the strict sense meaning that design entities described in VHDL87 (old standard) can be analyzed without modification, then elaborated and simulated using tools complying with the new standard. In this strict interpretation, only design file information may be used during analysis and elaboration, and at least the behavior is preserved for old models and for old design entities used in new designs.