VHDL Issue Number: 0005 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Visibility of architecture name in the entity aspect of a binding indication is not well-defined. Related Issues: None. Relevant LRM Sections: 5.2.1.1, 10.3, 11.2 Key Words and Phrases: Visibility, binding indication, configuration, libraries Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: Unavailable Superseded By: N/A ----------------------- Date Submitted: 1989/02/03 Author of Submission: Paul Menchini Author's Affiliation: CAD Language Systems, Inc. Author's Post Address: P.O. Box 13036 Research Triangle Park, NC 27709-3036 Author's Phone Number: (919) 361-1913 Author's Fax Number: Author's Net Address: mench@clsi.com ----------------------- Date Analyzed: 1990/06/14 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/07/26 17:33:24 $ Description of Problem ---------------------- The visibility of the architecture name in an entity aspect of a binding indication is not well-defined. Section 5.2.1.1 (Page 5-4 and 5-5) seems to imply that the architecture exists and is visible at the time the binding is analyzed, but this aspect of visibility is not covered in Section 10.3. In particular, this section does not define the name of an architecture to be visible outside of itself, either directly or by selection, except in the case of a block specification in a block configuration for an architecture (Item 2 on Page 10-3). It seems that the entity must exist, else the generic map aspect and the port map aspect of the binding indication could not be checked for errors during analysis; is this error analysis in fact required? It also seems that the architecture must exist if the architecture is configured by the current design unit, else the existence of these blocks could not be verified; is this verification in fact required? Proposed Resolution ------------------- In Section 5.2.1.1, explicitly state that the architecture must exist during the analysis of the design unit containing the entity aspect. In Section 10.3, add an item between Items 2 and 3 at the bottom of Page 10-3: "2a. For an architecture body associated with a given entity name: at the place of an architecture name (between the parentheses) in the first form of an entity aspect in a binding indication." VASG-ISAC Analysis & Rationale ------------------------------ This IR is deceptive in the sense that it appears simple but exposes several rather fundamental differences in the way VHDL is supported and in the way it is used. Three different views of VHDL configuration information have been implemented and are currently provided by vendors. For descriptive purposes herein, these are referred to as SEMI-SOFT, HARD, and HARD-EVEN-IN-ARCHITECTURES. A fourth view of configuration information, SOFT, has not been implemented (to the knowledge of the ISAC), but is conceptually very appealing. For the purpose of explaining these differing views, we consider the following VHDL: entity one is end one; architecture a of one is component comp end component; begin l:comp; end a; entity two is end two; architecture a of two is component three end component; begin l:three; end a; entity three is end three; architecture a of three is begin ... end a; use work.all; configuration c of one is for a for l:comp use entity two(a); end for; end for; end c; Also for the purpose of this discussion, we say a design unit DEPENDS ON another design unit if re-analyzing the latter unit requires re-analyzing the former unit before re-simulating. For any of the above-mentioned views, the configuration above analyzes and elaborates correctly. With the SEMI-SOFT view, the configuration does not DEPEND ON architecture a of two (or on architecture a of three) but it does DEPEND ON architecture a of one. In both the HARD and HARD-EVEN-IN-ARCHITECTURES views, the configuration DEPENDS ON all three architectures. In the SOFT view, the configuration does not DEPEND ON any of these architectures. These differences with respect to dependencies give rise to differences concerning when semantic analysis is performed and when errors are detected. For SOFT, very little (if any) semantic analysis is performed during analysis of the configuration. Error messages for undeclared identifiers, etc., are not seen by the user until elaboration time. FOR SEMI-SOFT, semantic errors in the "explicitly-written" part of the configuration are reported at analysis time of the configuration; semantic errors with respect to the implicit aspects of the configuration are not reported until elaboration time. For HARD and HARD-EVEN-IN-ARCHITECTURES, all semantic errors (for both explicit and implicit VHDL) are reported at analysis time of the configuration. The difference between HARD and HARD-EVEN-IN-ARCHITECTURES can be seen by considering the following VHDL: entity five is end five; architecture a of five is begin ... end a; entity four is end four; architecture a of four is component c end component; for l:c use entity work.five(a); begin l:c; end a; In each of the SOFT, SEMI-SOFT, and HARD views of VHDL, architecture a of four above does not DEPEND ON architecture a of five. In the fourth view, HARD-EVEN-IN-ARCHITECTURES, this dependency does exist. How could we end up with these different interpretations of VHDL configuration information? The proponents for the various views appear to feel the LRM supports (or at least allows) their particular views. The ISAC can reach no agreement on which of these views (if any) the LRM does require. The most relevant LRM references here appear to be the last paragraph of 11.4, the last paragraph of 1.3.2, most of 5.2.1.1 and 5.2.2. A main source of the ambiguity seems to be lack of a clear distinction in the LRM between analysis- time and elaboration-time errors. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- After much discussion the ISAC has concluded there is no good way to solve this problem in the short term. It does not appear to be practical or desirable to require any of these views to be supported by all VHDL implementations in the near future. The ISAC recommendation is for the VASG to simply point out to VHDL users that these differences exist in VHDL implementations. Market pressures will encourage implementors to provide the support that offers the best functionality for users. It may make sense for future versions of VHDL to clarify the semantics of configuration information to the point of narrowing (perhaps to one) the allowed views. It is not clear there is a single "best" interpretation; perhaps some user-selectable control over the interpretation of the configuration information is the best answer. Until then, users should be warned about the different implementation strategies that exist. A suggestion to lessen interoperability problems when sending VHDL source would be to assemble the design units in the canonical order that is acceptable to any of the known views. This is the ordering defined by the DEPENDS ON requirements of the HARD-EVEN-IN-ARCHITECTURES view. It is true that not all VHDL descriptions have such a canonical ordering (recursively instantiated architectures). Thus, in terms of the submitter's proposed resolution, the first aspect of the proposal is rejected. An implementation may or may not require the architecture to exist during the analysis. The intent behind the second aspect of the recommendation is accepted. The Chapter 10 visibility rules should be complete and cover the case of the architecture body identifier in an entity aspect of a binding indication. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD