This IR has been discussed several times. Please review it and vote before the next meeting. IR 2064 Analyzed Peter Type conversion of unconstrained output in a port map _____ Approve _____ Don't Approve -------------BEGINNING OF IR---------------- VHDL Issue Number: 2064 Language_Version VHDL-2002 Classification Language Definition Problem Summary type conversion of unconstrained output in a port map Relevant_LRM_Sections 3.2.1.1 Index constraints and discrete ranges "For an interface object or member of an interface object whose mode is OUT, BUFFER, INOUT or LINKAGE, if the formal part includes a conversion function or a type conversion, then the parameter subtype of that function or the type mark of the type conversion must be a constrained array subtype, and the index ranges are obtained from this constrained subtype; OTHERWISE, the index ranges are obtained from the object denoted by the actual designator(s)" Related_Issues Key_Words_and_Phrases type conversion, unconstrained Authors_Name Grugni Yannick Authors_Phone_Number +(32)16.390.742 Authors_Fax_Number Authors_Email_Address yannick.grugni@philips.com Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 7 March 2005 Date Analyzed: 8 March 2005 Author of Analysis: Peter Ashenden Revision Number: 2 Date Last Revised: 6 April 2005 Description of Problem ---------------------- We would like to know if the code below is vhdl 93 and 2002 compliant. The problem is the type conversion of an unconstrained output in the port map. According to cadence this code is vhdl 93/2002 compliant. According to modelsim this code is not vhdl 93/2002 compliant. Both companies refer to the same part of the LRM to conclude (3.2.1.1 Index constraints and discrete ranges) but they do different interpretation of it. So we would like to know definitively if it's or it isn't vhdl 93/2002 compliant. Acco ------------------------------------------------------ -- file add_unconstrained.vhd LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.ALL; ENTITY add_unconstrained IS PORT ( sample_in1 : IN unsigned; sample_in2 : IN unsigned; sample_out : OUT unsigned ); END add_unconstrained; ARCHITECTURE rtl OF add_unconstrained IS BEGIN sample_out <= sample_in1 + sample_in2; END rtl; ------------------------------------------------------ -- file type_conversion_of_unconstr_output.vhd LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.ALL; ENTITY type_conversion_of_unconstr_output IS PORT ( Asample_in1 : IN std_logic_vector(7 DOWNTO 0); Asample_in2 : IN std_logic_vector(7 DOWNTO 0); Asample_out : OUT std_logic_vector(7 DOWNTO 0) ); END type_conversion_of_unconstr_output; ARCHITECTURE rtl OF type_conversion_of_unconstr_output IS COMPONENT add_unconstrained PORT ( sample_in1 : IN unsigned; sample_in2 : IN unsigned; sample_out : OUT unsigned ); END COMPONENT; SIGNAL Asample_in1_tmp : unsigned(7 DOWNTO 0); SIGNAL Asample_in2_tmp : unsigned(7 DOWNTO 0); BEGIN Asample_in1_tmp <= unsigned(Asample_in1); Asample_in2_tmp <= unsigned(Asample_in2); u_add : add_unconstrained PORT MAP ( sample_in1 => Asample_in1_tmp, sample_in2 => Asample_in2_tmp, std_logic_vector(sample_out) => Asample_out --??? IS this line vhdl 93 compliant ??? ); END ARCHITECTURE; Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ The part of the LRM that addresses the code in question is the following text from 3.2.1.1: - For a local generic or a local port of a component that is of an unconstrained array type and that is associated in whole, the index ranges are obtained from the corresponding association element in the generic map aspect (in the case of a local generic) or port map aspect (in the case of a local port) of the applicable component instantiation statement. ... 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 an interface object or member of an interface object whose mode is out, buffer, inout, or linkage, if the formal part includes a conversion function or a type conversion, then the parameter subtype of that function or the type mark of the type conversion must be a constrained array subtype, and the index ranges are obtained from this constrained subtype; otherwise, the index ranges are obtained from the object denoted by the actual designator(s). In the component instantiation statement labeled u_add, sample_out is an out-mode local port of an unconstrained array type that is associated in whole. Hence its index range is obtained as specified in the last of the above paragraphs. Since the formal part includes a type conversion, then "the type mark of the type conversion must be a constrained array subtype". The key to the difference in interpretation between the two tools mentioned by the submitter is the interpretation of the word "must". Clause 0.2 states To the developer of tools that process VHDL, must denotes a requirement that the standard imposes. The resulting implementation is required to enforce the requirement and to issue an error if the requirement is not met by some VHDL source text. Thus, the code in question is in error, since the type mark of the type conversion is not a constrained array subtype. The rule following the word "otherwise" in the quoted paragraph only applies if the formal part does not include conversion function or a type conversion. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change. -------------END OF IR----------------Received on Fri Jul 29 10:37:47 2005
This archive was generated by hypermail 2.1.8 : Fri Jul 29 2005 - 10:37:53 PDT