These two IRs have been analyzed in anticipation of today's meeting. -------------BEGINNING OF IR---------------- VHDL Issue Number: 2054 Language_Version VHDL-2002 Classification Language Definition Problem Summary Individ. assoc. rules for array formal are not valid Relevant_LRM_Sections 3.2.1.1 Index constraints and discrete ranges Related_Issues Key_Words_and_Phrases individual association, unconstrained array formal Authors_Name James Unterburger Authors_Phone_Number 503.685.0860 Authors_Fax_Number 503.685.0921 Authors_Email_Address jamesu@model.com Authors_Affiliation Model Technology Authors_Address1 8005 SW Boeckman Road Authors_Address2 Wilsonville, OR 97070 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 6 January 2005 Date Analyzed: 03 March 2005 Author of Analysis: Larry Soule Revision Number: 2 Date Last Revised: 10 November 2005 Description of Problem ---------------------- The rules for determining the index ranges of an interface object (or member of an interface object) of an unconstrained array type and whose subelements are associated individually are given in 3.2.1.1: The directions of the index ranges of the formal [interface object] are those of the base type of the formal; the high and low bounds of the index ranges are respectively determined from the maximum and minimum values of the indices given in the association elements corresponding to the formal. It is then further ("followup") stated that: If the index ranges for an interface object or member of an interface object are obtained from the corresponding association element (when associating in whole) or elements (when associating individually), then they are determined either by the actual part(s) or by the formal part(s) of the association element(s), depending upon the mode of the interface object, as follows: [For a formal of mode IN, INOUT, or LINKAGE, if the actual part includes no conversion function or type conversion; likewise for a formal of mode OUT, BUFFER, INOUT, or LINKAGE, if the formal part includes no conversion function or type conversion, then] the index ranges are obtained from the object {or value} denoted by the actual designator(s). This "followup" does not make sense for individual associations because the actual designators do not have a corresponding index range, they are instead elements of the formal's array type; the index range(s) are already known as coming "from the maximum and minimum values of the indices given in the association elements corresponding to the formal". Also, the requirement that the result type of a conversion function or type mark of a type conversion (if present on the formal and/or actual parts) be a constrained array subtype is not applicable for individual association elements because they represent elements of the formal's array type, which is not necessarily of an array type itself. Proposed Resolution ------------------- 1) Clarify that the direction of the base type of an array type is in fact the direction of the index subtype of the array type at a given index position. 2) Remove the references to individual associations in the "followup" rules. 3) Clarify what the requirements are for individual associations that have formal and/or actual parts that include conversion functions and/or type conversions. VASG-ISAC Analysis & Rationale ------------------------------ The directions of the index ranges of the formal generic or formal port are that of the type of the formal; the high and low bounds of the index ranges are respectively determined from the maximum and minimum values of the indices given in the association elements corresponding to the formal. 1) The LRM says "The directions of the index ranges of the formal generic or formal port are that of the type of the formal". However, the direction of the base type of an unconstrained array is undefined (from 3.2.1). To define this, the sentence above should be removed and the sentence following it changed to: The directions of the index ranges of the formal generic or formal port are that of the type of the formal; The high bounds, low bounds, and directions of the index ranges are respectively determined from the maximum values, minimum values, and directions of the indices given in the association elements corresponding to the formal. 2) As the submitter says, in the case of individual associations, "the actual designators do not have a corresponding index range, they are instead elements of the formal's array type". Thus, the references to individual associations in the "followup" rules should be removed. The new language should be: If the index ranges for an interface object or member of an interface object are obtained from the corresponding association element (when associating in whole), then they are determined either by the actual part or by the formal part of the association element, depending upon the mode of the interface object, as follows: 3) The rewording of #2 above will also remove the restriction that the result type of a conversion function or type mark of a type conversion be a constrained array subtype when associating individually since the new paragraph only applies when associating in whole. With this, the rules for obtaining the index ranges when associating individually should be clear (obtained from the maximum and minimum values of the indices given in the association elements corresponding to the formal). VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revise section 3.2.1.1 as described in the analysis -------------END OF IR---------------- VHDL Issue Number: 2074 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Problem with direct/select visibility in formal part Relevant_LRM_Sections: 4.3.2.2, 10.3 Related_Issues: 0006 Key_Words_and_Phrases: Authors_Name: Chuck Swart Authors_Phone_Number: 503.685.0846 Authors_Fax_Number: 503.685.0921 Authors_Email_Address: cswart@model.com Authors_Affiliation: Model Technology Authors_Address1: 8005 SW Boeckman Road Authors_Address2: Wilsonville, OR 97070 Authors_Address3: Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 12 September 2005 Date Analyzed: Author of Analysis: Chuck Swart and Ajayharsh Varikat Revision Number: 2 Date Last Revised: 10 November 2005 Description of Problem ---------------------- Consider the following two VHDL code fragments: A) LIBRARY ieee; USE ieee.std_logic_1164.ALL; -- X01 becomes visible as a subtype ENTITY e1... ... ARCHITECTURE a1 OF e1 IS COMPONENT c1 IS PORT(X01: IN std_logic); BEGIN instance1: c1 PORT MAP ( X01(X01)=> s1); END a1; B) PACKAGE p2 IS constant X01: integer := 1; subtype bv1 is bit_vector(1 TO 1); END p2; LIBRARY ieee; USE work.p2.ALL; --X01 and bv1 become visible ENTITY e2... ... ARCHITECTURE a2 OF e2 IS COMPONENT c1 IS PORT(X01: IN bv1); BEGIN instance1: c1 PORT MAP ( X01(X01)=> s2); END a2; Are either of these legal VHDL? In example A) there are two possible interpretations: 1. The leftmost X01 is a type mark (with direct visibility) and the X01 inside the parentheses is a formal designator. This expression is legal. 2. The leftmost X01 is a port name (with visibility by selection) indexed by a subtype, which in this case is illegal. In example B) there are also two possible interpretations, with the legal/illegal cases reversed from example A) with respect to direct visibility and visibility by selection: 1. The leftmost X01 is a constant name (with direct visibility) and the expression inside the parentheses is a port name. This construct is clearly illegal. 2. The entire term is a formal designator, which reduces to an indexed name. The leftmost X01 is a port name (with visibility by selection) and the X01 inside the parentheses is an index expression. The grammar allows formal_part ::= formal_designator |<function>_name ( formal_designator) | type_mark ( formal_designator ) The name of the formal designator is visible by selection while the name of the type_mark (and the index expression in example B) are directly visible. So the question reduces to what visibility rules are used to analyze: X01(X01) which can be interpreted syntactically as either type_mark ( formal_designator) or simple formal_designator? Given the visibility rules of 10.3, it is hard to tell if directly visible names take priority over names visible by selection, or vice-versa. If direct visibility has priority then interpretation 1 applies to both examples, making example A) legal and example B) illegal. If selected visibility has priority, then interpretation 2 applies, making example B) legal and example A) illegal. If one were to argue that interpretation 1 applies to example A) and interpretation 2 applies to example B) then the visibility rules would be context dependent (or even more context dependent than current rules). The syntactic ambiguity in the formal_part rule is the major area (if not the only area) in which the rules for direct visibility conflict with those for visibility by selection. The closest analogy is the potential conflict between selected names and expanded names described in IR0006. This conflict is resolved by adopting the expanded name interpretation. I believe that different simulators interpret the two test cases in different ways, so this issue should be resolved to improve portability of the language. Proposed Resolution ------------------- Adopt a rule stating that in formal parts selected names hide directly visible names ( or vice-versa). This would make both examples illegal. Other solutions are possible, but the important thing is to not make the visibility rules context sensitive. In particular, interpretations A 1 and B 2 should not both be legal. VASG-ISAC Analysis & Rationale ------------------------------ The specific places at which such a conflict could occur are (from clause 10.3 of the LRM) "h) For a formal parameter declaration of a given subprogram declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named parameter association element of a corresponding subprogram call. i) For a local generic declaration of a given component declaration: at the place of the formal designator in a formal part ( before the compound delimiter =>) of a named generic association element of a corresponding component instantiation statement: similarly, at the place of the actual designator in an actual part (after the compound delimiter =>, if any) of a generic association element of a corresponding binding indication. j) For a local port declaration of a given component declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named port association element of a corresponding component instantiation statement; similarly, at the place of the actual designator in an actual part (after the compound delimiter =>, if any) of a port association element of a corresponding binding indication. k) For a formal generic declaration of a given entity declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named generic association element of a corresponding binding indication; similarly at the place of the formal designator in a formal part (before the compound delimiter => of a generic association element of a corresponding component instantiation statement when the instantiated unit is a design entity or a configuration declaration. l) For a formal port declaration of a given entity declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named port association element of a corresponding binding specification; similarly, at the place of the formal designator in a formal part (before the compound delimiter =>) of a port association element of a corresponding component instantiation statement when the instantiated unit is a design entity or a configuration declaration. m) For a formal generic declaration or a formal port declaration of a given block statement: at the place of the formal designator in a formal part( before the compound delimiter =>) of a named association element of a corresponding generic or port map aspect." The ISAC agrees that there should be a clear rule to determine visibility when there is a potential conflict between direct visibility and visibility by selection. It is preferable to choose visibility by selection over direct visibility because a declaration which is no longer directly visible can often be accessed by other mechanisms. In conclusion, the ISAC recommends that the syntactic ambiguity indicated in the problem description be resolved in favor of formal_designator, with a similar interpretation for actual_part. With this interpretation the leftmost X01 in example A) is interpreted as a port name, so the example is illegal. Example B) is legal: the leftmost X01 is a port name and the second X01 refers to the constant in the package. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the Recommendation for Future Revisions were in effect. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Add wording similar to the following to clause 10.3 immediately after the existing paragraph that begins with "A declaration is said to be hidden...": "At a place in which a declaration is visible by selection every declaration with the same designator which would otherwise be directly visible is hidden."Received on Thu Nov 10 16:01:38 2005
This archive was generated by hypermail 2.1.8 : Thu Nov 10 2005 - 16:01:45 PST