VHDL Issue Number: 0019 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Meanings of names in association lists are unclear. Related Issues: 0060 Relevant LRM Sections: 10, 4.3.3.2 Key Words and Phrases: Select visibility, association lists Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Section 10.3 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: 1989/06/14 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/08/02 23:48:51 $ Description of Problem ---------------------- X(Y) is ambiguous as a formal if X is a visible (type-conversion) function and there is a formal array X. X is ambiguous as an actual if there is a local X and a normally visible X. It is unclear if X+4 as an actual in a generic map is valid if X denotes a local generic. If this is valid, it is unclear if the association counts as the required association for X. Note that select visibility is rather botched in VHDL. This notion was taken from Ada but adapted poorly. First, in VHDL, there is select visibility over wide regions of text (e.g., expressions) as opposed to in Ada where it is defined on an identifier basis. Second, in regions to which select visibility applies, normal direct visibility is also possible. Proposed Resolution ------------------- If X(Y) appears as a formal, X is a visible (type-conversion) function, and there is a formal X, it is assumed this a reference to a subelement of the formal X. If X appears as an actual in a binding indication and there is a local X and a normally visible X, it is assumed this is a reference to the local X. Hence in both cases, "priority" is given to the select-visibility interpretation. If X+4 appears as an actual in a binding indication, X cannot refer to a local. References to locals in such contexts are only considered valid if the actual is in the form of a name. VASG-ISAC Analysis & Rationale ------------------------------ The visibility problems in this area of the LRM are broader than is suggested here. In particular, they are not confined to association lists since the LRM does not say, in general, who "wins" when one declaration is visible by selection and another declaration is directly visible. It seems to make most sense that if a declaration is visible by selection at a particular point, no declaration should be directly visible at that point. This seems to be the approach taken by Ada, although the wording in the Ada LRM (i.e., paragraph beginning "Where it is not visibly by selection, ..." in Ada LRM 8.3) appears somewhat confused. What remains to be solved are the problems of select visibility in VHDL association lists. These problems are not present in Ada because Ada does not support subelement association. Furthermore, Ada does not have a need for select visibility on the right-hand side of a named association element. Two approaches seem possible for the problems of select visibility in VHDL association lists. Consider for example a parameter association list association element A => B where A and B represent sequences of symbols and consider the need to make the formal parameters of the subprogram visible (at least somewhere) within A. One approach would make select visibility "applicable" for each identifier in A. This is a simple way to work the problem but it makes select visibility applicable for some identifiers unnecessarily which can result in conflicts (e.g., Y in X.Y(...) => B) and which would have to be resolved with additional LRM rules (e.g., "." visibility has higher priority). The alternative approach is to say that select visibility is only applicable for the leftmost identifier in A. An additional statement would be required with the second approach that the parameter to a type conversion function appearing in an association element is visible by selection. The second of these approaches seems simpler and cleaner and is therefore the preferred solution that is detailed below. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- ********************* Clarification 1: The second paragraph following the list of 11 items in LRM 10.3 leads with the sentence: A declaration is said to be *directly visible* within a certain part of its immediate scope; this part extends to the end of the immediate scope of the declaration, but excludes places where the declaration is hidden as explained below. This sentence should be read as though it were written: A declaration is said to be *directly visible* within a certain part of its immediate scope; this part extends to the end of the immediate scope of the declaration, but excludes places where the declaration is hidden (as explained below) or where any declaration with the same identifier, operator symbol, or character literal is visible by selection. ********************* Clarification 2: Items 7, 8, 9, 10, and 11 in the list of 11 items in LRM 10.3 each contain the phrase ... at the place of the formal designator (before the compound delimiter =>) in a ... These phrases should be read as though they were written ... at the place of the leftmost identifier, operator symbol, or character literal in the formal part of a ... ********************* Clarification 3: Items 8 and 9 in the list of 11 items in LRM 10.3 each contain the phrase ... at the place of the actual designator (after the compound delimiter =>) in a ... These phrases should be read as though they were written ... at the place of the leftmost identifier, operator symbol, or character literal in the actual part of a ... ********************* Clarification 4: The list of 11 items in LRM 10.3 should be read as though it contained the following two additional items: 12. For a formal parameter declaration of a given subprogram declaration, a local generic or local port declaration of a given component declaration, or a formal generic or formal port declaration of a given entity declaration: at the place of the leftmost identifier, operator symbol, or character literal in the formal designator of a formal part that is in the form of a function call in a named association element of a corresponding subprogram call, component instantiation statement, or binding indication, respectively. 13. For a local generic or local port declaration of a given component declaration: at the place of the leftmost identifier, operator symbol, or character literal in the actual designator of an actual part that is in the form of a function call in an association element of a corresponding binding indication. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- It is not clear that this is the "best" long-term solution to these problems. We recommend that these issues be re-studied when the next revision of the standard is being prepared.