VHDL Issue Number: 0092 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Visibility of an architecture body identifier is unclear. Related Issues: Relevant LRM Sections: 10.2, 10.3 Key Words and Phrases: Architecture body, visibility Current Status: Analyzed 1076-1993 Disposition: Superseded (ISAC Issues Outstanding) Disposition Rationale: N/A Superseded By: 1050 ----------------------- 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/18 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/07/26 18:53:31 $ Description of Problem ---------------------- It is unclear how the identifier of an architecture body relates to identifiers for various other declarations such as the corresponding entity declaration, a declaration immediately inside the corresponding entity declaration, and a declaration immediately inside the architecture body. Proposed Resolution ------------------- The root of this problem seems to be that an architecture body is not a declaration, hence the rules on visibility and hiding in LRM 10.2 and 10.3 cannot be applied to its identifier. Accordingly, it is assumed an architecture body is a declaration. This implies, among other things: 1. An architecture body identifier may be the same as the identifier for the corresponding entity declaration. These homograph declarations are not illegal by LRM 10.3 because they are not contained immediately within a declarative region. Furthermore, the architecture body does not hide (LRM 10.3) the entity declaration because these declarations are at the same level (there is no inner or outer declaration). 2. An architecture body identifier may be the same as the identifier of a declaration occurring immediately within the corresponding entity declaration. However, the architecture body identifier is an outer declaration and the declaration in the entity is an inner declaration. Hence, the architecture body identifier is hidden throughout the architecture body. 3. An architecture body identifier may be the same as the identifier of a declaration occuring immediately inside the architecture body. The architecture body identifier is hidden within the scope of the inner declaration. 4. If an architecture body identifier is the same as the identifier of its corresponding entity declaration, both are directly visible in the architecture body (following the reserved word IS). As with overloadable declarations, a direct reference within the architecture body to either of these declarations may be ambiguous if the appropriate context does not determine a unique meaning. Of course, the entity declaration in such a case may be referenced with an expanded name whose prefix is WORK. VASG-ISAC Analysis & Rationale ------------------------------ Regarding point 1 in the author's proposed resolution: There is some sympathy in the ISAC for considering a global, outermost declarative region wherein library logical names and the name of the design unit are considered to be declared. This addition greatly regularizes both the process of interpreting the LRM and makes the abstract model of scope and visibility close to that of most implementations. In particular, it disambiguates the rules of select visibility. It is mostly but not universally felt that the (ultimate) prefix of a selected name (whose suffix is visible by selection in the context of the prefix) must be directly visible. For example, using the majority interpretation, the interpretation of the name "Lib.Pkg.Decl" proceeds as follows: The name "Lib" is first interpreted with direct visibility in the innermost complete context of the entire selected name. The name "Pkg" is then interpreted with select visibility in the context of "Lib". Finally, the name "Decl" is interpreted with select visibility in the context of "Lib.Pkg". (The minority interpretation is that library names have a special form of visibility such that they cannot be "hidden" by inner declarations. The difference in these interpretations can be exemplified by the following example: library L; package P is -- "L" here clearly means the library name. constant L: Integer := 0; -- "L" standing alone (i.e., not as the prefix of a selected name) -- here clearly means the constant. However, if it is a prefix of a -- selected name (e.g., "L.P1.all"), according to the majority -- interpretation, this name is illegal. According to the minority -- interpretation, this name is legal; "L" still refers to the -- library logical name. end P; (The minority interpretation is justified by noting that library logical names are not declarations and they are not "declared" in a declarative region.) The ISAC also achieved concensus on the following examples: 1. entity E is end E; architecture E of E is begin -- legal up to this point, but within the architecture a reference to -- "E" is ambiguous. end E; 2. entity E is signal A: Integer; end E; architecture A of E is -- legal; within the architecture a refrence to "A" denotes the -- signal end A; 3. entity E is end E; architecture A of E is signal A: Integer; begin -- legal; within the architecture a reference to "A" denotes the -- signal end A; VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD