IRs 2074 and 2086 have been updated. LCS 113 supersedes IR 2054. This LCS has deep consequences, so I would like you to read it carefully. But if you don't have time the area aroung page 6 deals most closely with IR 2054. If you can't get access to LCS 2006-113, let me know and I'll send you a copy (The isac mailing list won't accept it because it places a Draconian limit on file sizes) Also, in my notes for IR 2074 I have a statement: "There was also confusion about wording regarding actuals. The visibility rules favoring select names are intended to apply to local parameters used as actuals, not to all actuals." Can anyone speak to the reason for this? I thought that clauses h) through m) were pretty clear about this. 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: 10 November 2005 Author of Analysis: Chuck Swart and Ajayharsh Varikat Revision Number: 3 Date Last Revised: 18 April 2006 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_designator. Note that the above LRM sections apply visibility by selection to formal and actual designators, not to formal or actual parts. If visibility is to be used to distinguish the cases under discussion it is beneficial to extend select visibility to the entire formal or actual parts. With this interpretation the leftmost X01 in example A) is interpreted as a port name, so the example is illegal. Example B) is also illegal: Both references to X01 refer to the port name, so the example is semantically illegal. 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 --------------------------------------------- In items h) through m) in clause 10.3 replace each occurrence of "at the place of the formal designator in a formal part" with "at the place of the formal part" and replace each occurrence of "at the place of the actual designator in an actual part" with "at the place of the actual part". 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." -------------BEGINNING OF IR---------------- VHDL Issue Number: 2086 Language_Version VHDL-2002 Classification Language Definition Problem Summary Incorrect description of type mark in disconnection specification Relevant_LRM_Sections 5.3 Disconnection specification, page 85 Related_Issues Key_Words_and_Phrases disconnection specification, type mark Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 8 February 2006 Date Analyzed: 13 March 2006 Author of Analysis: Chuck Swart Revision Number: 2 Date Last Revised: 18 April 2006 Description of Problem ---------------------- In the last paragraph of page 85, the first sentence reads: If the guarded signal is a declared signal or a slice thereof, the type mark must be the same as the type mark indicated in the guarded signal specification (see 4.3.1.2). Since the paragraph describes a guarded signal specification, it appears that the first type mark referred to in the sentence is the type mark in the guarded signal specification. Thus, the sentence appears to state, tautologically, that the type mark must be the same as itself. Subsequent sentences in the paragraph state that, for other forms of signal name, the type mark must be the same as the type mark in a declaration of the signal. Thus, it would appear that the first sentence should say that the type mark be the same as the type mark in the declaration of the signal, not the same as itself. A further problem is that the paragraph only deals with a declared signal, a slice of a declared signal, an element of a declared array signal, and an element of a declared record signal. It does not deal with other members of a composite signal. Proposed Resolution ------------------- Amend the tautological description to refer to the type mark of the subtype indication in the signal declaration. Revise the case analysis to cover the cases: - A declared signal or a slice of a declared signal: the type mark must be the same as that in the signal's declaration; - A slice of an array subelement of a composite signal: the type mark must denote the same subtype as the array element's subtype; - An element of an array subelement of a composite signal: the type mark must denote the same subtype as the element subtype indication in the declaration of the array type; - An element of a record subelement of a composite signal: the type mark must denote the same subtype as the element subtype indication in the declaration of the record type. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is essentially correct. However, the LRM seems to impose a more stringent requirement involving type mark matching instead of subtype matching. So the wording in the proposed solution should be changed as indicated below. In addition, for consistency, on page 86, the first sentence should also be changed in a similar manner (indicated below). 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 --------------------------------------------- Clause 5.3 Disconnection specification The paragraph beginning: "If the guarded signal is a declared signal or a slice thereof..." Should read: "If the guarded signal specification denotes a declared signal or a slice thereof then the type mark in the specification must be the same as the type mark in the subtype indication of the guarded signal declaration (see 4.3.1.2). If the guarded signal specification denotes an index value of a declared signal then the type mark in the specification must be the same as the type mark of the element subtype indication in the declaration of the array type of the guarded signal declaration. If the guarded signal specification denotes a slice of an array subelement of a composite signal then the type mark must be the same as the type mark in the subtype indication of the array subelement declaration. If the guarded signal specification denotes an element of an array subelement of a composite signal then the type mark must be the same as the type mark of the element subtype indication in the declaration of the array type. If the guarded signal specification denotes a record element of a composite signal then the type mark must be the same as the type mark of the element subtype indication in the declaration of the record type. Each signal must be declared in the declarative part enclosing the disconnection specification." The paragraph beginning: "Subject to the aforementioned rules, a disconnection specification applies to the drivers of a guarded signal S of whose type mark denotes the type T..." Should read: "Subject to the aforementioned rules, a disconnection specification applies to the drivers of a guarded signal S specified with type mark T..." -------------END OF IR----------------Received on Tue Apr 18 16:49:04 2006
This archive was generated by hypermail 2.1.8 : Tue Apr 18 2006 - 16:49:06 PDT