VHDL Issue Number: 1057 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Expanded names are not allowed in extended regions. Related Issues: 0113, 0223 Relevant LRM Sections: 6.3, 10.3 Key Words and Phrases: expanded names, extended regions, selected visibility Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/12/21 Author of Submission: Daniel S. Barclay Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd. Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-992-3536 Author's Net Address: daniel@compass-da.com ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.8 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- Problem Summary: Expanded names are not treated the same way in extensions of a region as they are in the extended region. Specifically, for a construct that has an associated region that is extended by a later construct, expanded names that are legal in the first construct are not legal in the later construct. This violates the intent of extended regions in VHDL, and is inconsistent with the rest of the language. An Example: For example, consider the following VHDL: entity E is signal P : INTEGER; begin ... P ... ... E.P ... end; architecture A of E is begin ... P ... ... E.P ... end; Assume that there are not other declarations with the identifiers "E", "A", or "P". First consider the simple name "P" and normal region extension. If the simple name "P" appears in the entity declaration after the end of the signal declaration, it is legal and denotes the signal declaration. If that simple name appears in the architecture body, it is also legal and also denotes the signal declaration. This happens because the architecture body is defined to extend the region of the entity declaration, and because the scope and visibility of the signal declaration are defined to extend into the architecture body. Now consider the expanded name "E.P". If the expanded name "E.P" appears in the entity declaration after the end of the signal declaration, it is legal and denotes the signal declaration (just as the simple name "P" would). However, if the expanded name appears in the architecture body, it is illegal. This behavior violates the intent of region extension in VHDL and is inconsistent with most of the rest of the language. Cause of Problem: This inconsistency results from the eighth text paragraph in section 6.3: An expanded name denotes a named entity declared immediately within a named construct if the prefix denotes a construct that is an entity interface ... and the suffix is the simple name ... of a named entity whose declaration occurs immediately within that construct. This form of expanded name is only allowed within the construct itself. Specifically, the last sentence makes the expanded name illegal in the architecture body. (The prefix of the expanded name denotes an entity declaration. The suffix is the simple name of a declaration immediately within that entity declaration. Therefore, the expanded name denotes the signal declaration in the entity declaration. If the expanded name in the architecture body, it does not appear with in the entity declaration itself. Therefore such an occurrence is illegal.) This also restricts expanded names in package bodies (for declarations in package declarations), block configurations (for declarations in block statements, generate statements, architecture bodies, and entity declara- tions), and subprogram bodies (for interface declarations in subprogram declarations). The inconsistency also regions from the 19th paragraph in section 10.3, which says: Finally, within the declarative region associated with a construct other than a record type declaration, any declaration that occurs immediately within the region and that also occurs textually within the construct is visible by selection at the place of the suffix of an expanded name whose prefix denotes the construct. The text "and that also occurs textually within the construct" is new. It was added per Issue Report 0113, which attempted to address the problem with the paragraph from section 6.3. However, the IR completely missed the problem. It addressed only entity declarations and architectures, never noticing the problem with all other disjoint regions and scope extensions, which don't have names that denote them. The added text restricts selected visibility to match the excessive restric- tion above on use of expanded names. Normally, an expanded name "R.X" denotes the declaration(s) of X occurring immediately within the region associated within the construct denoted by "R". However, with the wording added to section 10.3 for VHDL 1993, the expanded name "R.X" denotes only some of the declarations of X in the region. For example, consider a package declaration P declaring some functions F, and its package body, declaring some additional functions F. In the package body, the simple name F denotes all functions declared in the region (the package declaration and the package body), but the expanded name P.F would denote only those functions declaration in the package body. (Actually, it's probably illegal or ambiguous. P doesn't denote the package body; it denotes the package declaration, right?) The restriction also means that an expanded name with a prefix that denotes an entity declaration cannot always be used to denote a declaration declared immediately within the declarative region associated with that entity declaration. This restriction of visibility is inconsistent with treatment of region extension throughout the language. Region Extension and Declarative Regions vs. Constructs and Declarative Parts: In VHDL, some declarative regions consist of disjoint pieces of text. For example, an entity declaration and an architecture body, two separate constructs, form one declarative region. Most rules in VHDL treat those separate constructs, with separate declarative parts, as one declarative region: - A subprogram declaration and its corresponding subprogram body must occur immediately within the same declarative region, but not necessarily within the same declarative part. - Restrictions on access from pure functions to non-local signal and variables in defined in terms of declarative regions, not declarative parts. - Entity/architecture pairs, package declaration/body pairs, and subprogram declaration/body pairs are defined as declarative regions. - Declarations are defined to occur immediately within a declarative region. - The scope of declarations, use clauses, and library clauses is defined in terms of declarative regions, not declarative parts. - Hiding of declarations is defined in terms of declarative regions, not declarative parts. - Homographs are defined in terms of declarative regions, not declarative parts. - Most visibility rules are defined in terms of regions, not declarative parts. - Equivalent block statements include declarations from both the entity and the architecture, without distinguishing them. - Illegality of duplicate declarations of homographs is defined in terms of declarative regions, not declarative parts. Only certain rules related to declarations are defined in terms of declarative parts instead of declarative regions: - Attribute, configuration, and disconnection specifications must appear in the declarative part of the construct in which the affected named entity, component instantiation statement, or signal declaration occurs. - "All" are "others" in specifications are defined in terms of declarative parts or constructs. - An incomplete type declarations and its corresponding full type declaration must appear in the same declarative part. These cases exist for specific reasons. Consider specifications: A specification annotates another construct, and the annotated information must be accessible where the other construct is accessible. If an attribute specification in a package body were allowed to annotate a declaration in the package declaration, units that used the package declaration and saw no annotation would have to be reananlyzed whenever the package body was analyzed. Thus, the language treats extended regions transparently except where there is a specific reason not to. Therefore, selected visibility for expanded names should follow the region extension of the rest of the language and should be defined in terms of declarative regions, not declarative parts or constructs. Proposed Resolution ------------------- Treat expanded names consistently. Allow an expanded name to appear in constructs that extend the region associated with the construct in which the denoted declaration appears. Implement this by changing the above-quoted LRM paragraphs. For the last sentence of the LRM paragraph from section 6.3: Determine the intended effect and the actual effect of the last sentence. Determine whether existing rules, especially scope and visibility rules, are sufficient by themselves. If other rules are sufficient, remove the last sentence. Otherwise, refer to declarative regions (including region extensions) associated with constructs instead of referring to constructs. For the paragraph from section 10.3, remove the text "and that also occurs textually within the construct" from the sentence. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD