VHDL Issue Number: 2127 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Possible LRM interpretation pitfall related to the predefined STANDARD package Relevant_LRM_Sections 14.2 Package STANDARD 10.3 Visibility 11.2 Design libraries 10.5 The context of overload resolution Related_Issues Key_Words_and_Phrases visibility, direct visibility, use clause, TIME, STANDARD, overloading Authors_Name Farrell Ostler Authors_Phone_Number 1-505-822-8972 Authors_Fax_Number Authors_Email_Address farrell.ostler@xilinx.com Authors_Affiliation Xilinx Corporation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 20 December 2007 Date Analyzed: 11 January 2008 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 23 May 2008 Description of Problem ---------------------- Here is a real-world case where two prominent vendors have differing interpretations of whether objects in the predefined STANDARD package compete for visibility with objects being made directly visible through use clauses. Hence, there is the possibility that the LRM is not sufficiently clear on this point. Consider a function min, returning the smaller of two integer arguments. The min function is declared in a package, pkg, and analyzed into library, lib. Now consider this function being made directly visible in architecture, arch, by a use clause: use lib.pkg.min; One VHDL tool, a simulator invoked by the ncvhdl command, apparently considers that the attempt to make the min function directly visible clashes with the min identifier from the predefined package STANDARD's TIME declaration. Thus it considers that no min identifier is visible at a point in arch where the min function is called. The other VHDL tool, a simulator invoked by the vcom command, does not consider that the min function clashes with the min from TIME in the predefined STANDARD package. Therefore at the point where the min identifier is used, it is associated with the min function. Proposed Resolution ------------------- Perhaps the ISAC could consider whether additional or modified language in the LRM would make the correct interpretation of this point more clear. Note that the ncvhdl tool apparently considers that the 'min' from STANDARD and a 'min' declared in some other package clash if the later is attempted to be made visible. However, the ncvhdl tool apparently does not consider that an 'and' in STANDARD clashes with an 'and' being made visible from package std_logic_1164. Again, the fact that one of these substantial companies, each with a large stake in VHDL, has apparently interpreted the LRM wrong suggests that a review of the LRM on this point is in order. VASG-ISAC Analysis & Rationale ------------------------------ This issue can be analyzed by considering the rules for visibility of a declaration identified by a use clause. 11.2 specifies that each design unit implicitly includes a use clause of the form use STD.STANDARD.all; in its context clause. 10.4 specifies that a use clause in which the suffix is the reserved word all identifies all declarations in the package. Thus, the implicit use clause above identifies all declarations in STANDARD, including the physical unit min of type TIME. 10.4 also specifies the scope of a use clause, starting immediately after the use clause and extending either to the end of the immediately enclosing declarative region (for a use clause occurring immediately with a declarative region) or to the end of the root declarative region (for a use clause occurring in a context clause). Thus, the scope of the implicit use clause for STANDARD is the entire design unit that it precedes (together with any secondary design unit, if the context clause precedes a primary design unit). The submitter's example includes a use clause that identified the declaration of a function subprogram named min in the package named pkg. It is not clear whether the use clause occurs in the context clause of the architecture body or immediately within the architecture body. However, for this analysis, the distinction is not significant, as we can just consider places within the scope of the use clause, where ever it appears (assuming there is no other declaration of the identifier min). Those places are also within the scope of the implicit use clause for STANDARD. Within such places, the declarations of min in STANDARD and of min in pkg are both potentially visible declarations, as specified in 10.4. That subclause then provides rules to determine whether a potentially visible declaration is made directly visible: A potentially visible declaration is actually made directly visible except in the following two cases: a) A potentially visible declaration is not made directly visible if the place considered is within the immediate scope of a homograph of the declaration. b) Potentially visible declarations that have the same designator are not made directly visible unless each of them is either an enumeration literal specification or the declaration of a subprogram (either by a subprogram declaration or by an implicit declaration). At each place considered in this analysis, there is no declaration of min other than those identified by the use clauses, so a) does not apply. So we consider b). The two declarations of min have the same designator, neither is an enumeration literal, but lib.pkg.min is a subprogram. So application of rule b) causes the two potentially visible declarations of min not to be made directly visible. Informally, we can say that there is a name clash, since one of the two declarations is not overloadable. The package STANDARD is not treated specially by the scope and visibility rules, so a name clash with a declaration from STANDARD has the same effect as a name clash in any other package. The submitter proposes that wording be added or changed in the LRM to make the rules clearer. The ISAC does not see the need for change or addition in this respect. The ISAC notes, however, that the rules relating to visibility of names identified by use clauses are being revised in the 2008 revision of the standard, and that those revisions may clarify aspects of the rules. The submitter also notes in the proposed resolution that a tool does not identify a clash of names between "and" declared in STANDARD and "and" declared in STD_LOGIC_1164 when the latter is the subject of a use clause. The ISAC points out that the tool is correct, since the declarations are all of subprograms, which are overloadable. Thus, according to rule b) in 10.4, all of the potentially visible declarations of "and" are made directly visible. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change other than those already included in the draft 1076-2008.