Enclosed are two new IRs, which are also in the repository. Also, don't forget about next weeks ISAC meeting! I'll try to send the agenda on Monday. Chuck Swart -------------BEGINNING OF IR---------------- VHDL Issue Number: 2081 Language_Version VHDL-2002 Classification LRM Terminology, Grammar and Typographical Errors Summary The term ancestor is used where parent is meant Relevant_LRM_Sections 2.2, Note 6 on page 25. 8.1, on page 118. Related_Issues Key_Words_and_Phrases explicit ancestor, parent 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: Submitted Superseded By: ------------------------ Date Submitted: 24 January 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- The term "ancestor" is used where the term "parent" should be used. The term "explicit ancestor" is defined in 2.2 on page 24, and refers to the signal or member of a signal that is a prefix of an attribute name. The term "parent" is defined in 2.2 on page 23, and refers to a process or subprogram that directly or indirectly calls a given subprogram. In 2.2, Note 6 on page 25, the term "ancestor" is used to refer to a subprogram declared in a protected type declaration or body; the term "parent" is meant. In 8.1, on page 118, the term "ancestor" is used to refer to a subprogram whose body is declared within a protected type body; the term "parent" is meant. In both cases, the incorrect terminology was introduced in P1076a, probably as a result of misunderstanding of terminology by the language change authors. (I'm probably culpable, at least in part!) Proposed Resolution ------------------- Replace both occurrences of the term "ancestor" with "parent". VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2082 Language_Version VHDL-2002 Classification Language Definition Problem Summary Elaboration of unconstrained interface objects Relevant_LRM_Sections 4.3.2.2 Association lists 12.2 Elaboration of a block header 12.5 Dynamic elaboration Related_Issues Accellera VHDL-TC VTC-7, LCS-2006-118 Key_Words_and_Phrases elaboration, formal interface objects, association elements 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: Submitted Superseded By: ------------------------ Date Submitted: 27 January 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- The order of elaboration of interface objects and the corresponding associations is problematic when the type of an interface object is unconstrained. For such interface objects, the index ranges are taken from the association elements. 12.2 and 12.5 specify that elaboration proceeds by first elaborating the formal objects (generics, ports or parameters), followed by elaboration of the association lists. Elaborating the formal objects involves elaborating the subtype indications and creating the objects. However, for objects of unconstrained types, the objects cannot be created until the index ranges are known, and that isn't until the corresponding association elements are elaborated. Proposed Resolution ------------------- Elaboration needs to be defined in such a way that association elements are elaborated before formal objects are created. A possible sequence may be (1) elaborate the subtype indications of the formals (2) elaborate the association elements (including any implicit association elements) (3) determine index ranges for formals from association elements, if required (4) create formals VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Fri Jan 27 16:28:11 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 27 2006 - 16:28:18 PST