2084 Analyzed Peter A record "element" is not called a "field" 2085 Submitted What happens when a parameter of mode out is not assigned in a procedure? 2086 Submitted Incorrect description of type mark in disconnection specification VHDL Issue Number: 2084 Language_Version VHDL-2002 Classification LRM Terminology, Grammar and Typographical Errors Summary A record "element" is not called a "field" Relevant_LRM_Sections 7.4.1 Locally static primaries 7.4.2 Globally static primaries Related_Issues Key_Words_and_Phrases record type field element Authors_Name James Authors_Phone_Number 503-685-0860 Authors_Fax_Number Authors_Email_Address jamesu@model.com Authors_Affiliation Mentor Graphics Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 7 February 2006 Date Analyzed: 8 February 2006 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: Description of Problem ---------------------- The term "field" of a record type is used instead of the term "element". 3 Types and 3.2.2 Record types mention only "element", not "field". Proposed Resolution ------------------- Change the use of "field" to "element" in 7.4.1 and 7.4.2. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct. According to 3.2.2, "A record type is a composite type, objects of which consist of named elements." Uses of the term "field" should be replaced with the term "element" throughout. Occurrences are: In 6.3, page 93, in the code comment in Note 1. In 7.4.1, page 114. In 7.4.2, page 115 VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the listed occurrences of the term "field" as meaning "element". VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Change the listed occurrences of the term "field" to "element". -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2085 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary What happens when a parameter of mode out is not assigned in a procedure? Relevant_LRM_Sections 2.1.1.1 Related_Issues Key_Words_and_Phrases procedures, out Authors_Name Larry Soule Authors_Phone_Number 650-584-1919 Authors_Fax_Number Authors_Email_Address larrys@synopsys.com Authors_Affiliation Synopsys Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 8 February 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- Here is an example of a procedure with an out-mode parameter that is conditionally assigned. architecture a of e is subtype t is bit_vector(1 to 4); constant c : t := (others => '1'); procedure p(i : in integer; o : out t) is begin if i > 0 then o := c; end if; end procedure; Section 2.1.1.1 says that only for in and inout parameters is the value copied in (when using pass by copy). When exiting the procedure, inout and out parameters are copied back in. If the out mode formal is not assigned in the procedure, this has the effect of writing t'left back into the actual which seem counter-intuitive. At least 2 VHDL implementations known to me handle this differently. Proposed Resolution ------------------- Specify that only parameters of mode out that have been assigned inside the procedure get copied out. 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: 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: Submitted Superseded By: ------------------------ Date Submitted: 8 February 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: 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 ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Thu Feb 9 16:14:15 2006
This archive was generated by hypermail 2.1.8 : Thu Feb 09 2006 - 16:14:49 PST