Reply to thread

Message: [QUOTE="James Unterburger, post: 3522416"] The compiler can't figure out which "&" operator to use. The rules in 7.3.5 Type conversion prohibit the target type from being used to figure out the expression type. Every array type comes with 4 implicit "&" operators: "&"[array,array RETURN array] "&"[array,elem RETURN array] "&"[elem,array RETURN array] "&"[elem,elem RETURN array] VHDL uses only the base type when doing operator overloading (figuring out which operator to use). This includes using only the base type of the "elem" in the above. --======================================================================== LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.numeric_std.ALL; HWID : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0); RAM_addr : OUT UNSIGNED(9 DOWNTO 0); TYPE reg_type IS ARRAY (0 TO NUM_REGS-1) OF STD_LOGIC_VECTOR(HWID'RANGE); SIGNAL regs : reg_type; SIGNAL data_in : STD_LOGIC_VECTOR(HWID'RANGE); Line 156: RAM_addr <= UNSIGNED("00" & data_in); --======================================================================== Take the expression ("00" & data_in). Remember, we can't use the enclosing type conversion target type UNSIGNED because of the 7.3.5 rules. The type of data_in is clearly std_logic_vector. Now we must figure out the type of "00" and which of these 8 to call: In this testcase, 8 relevant "&" operators are visible. 1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector] 1b) "&"[std_logic_vector,std_ulogic RETURN std_logic_vector] 1c) "&"[std_ulogic,std_logic_vector RETURN std_logic_vector] 1d) "&"[std_ulogic,std_ulogic RETURN std_logic_vector] 2a) "&"[reg_type,reg_type RETURN reg_type] 2b) "&"[reg_type,std_logic_vector RETURN reg_type] 2c) "&"[std_logic_vector,reg_type RETURN reg_type] 2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type] In the items labeled with "2", the type "reg_type" really means the anonymous base type of the constrained array subtype "reg_type". From these 8 concatenation operators, we need to pick the 1 that will work, else we have an ambiguity (error). The right operand "data_in" type being std_logic_vector, there remain 4 possible choices: 1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector] 1c) "&"[std_ulogic,std_logic_vector RETURN std_logic_vector] 2b) "&"[reg_type,std_logic_vector RETURN reg_type] 2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type] Looking at the left operand string literal "00" (which is necessarily some 1-dim array type), we can further prune this down to 2 choices (and know that "00" is std_logic_vector): 1a) "&"[std_logic_vector,std_logic_vector RETURN std_logic_vector] 2d) "&"[std_logic_vector,std_logic_vector RETURN reg_type] We can't decide which one of these 2 "&" operators to call. Overloading occurs on the base type, and we can't use the RETURN type at all when we're in a type conversion expression. The number of elements of the constrained array subtype "reg_type" is irrelevant, any length error would occur separate and after the overload resolution has occurred. Basically, we don't know if ("00" & data_in) means, "make an even longer std_logic_vector value", or "make a 2-element array value of type "reg_type" (which would be an error because every element of such a value has to be the same length as the other, and has to be the same length as the actual element subtype of the array); the 2-element interpretation must be considered even if the "reg_type" doesn't define exactly two elements, and regardless of the length of the element subtype. There are at least 2 ways to make this work: This effectively tells the expression of the type conversion to UNSIGNED that "you are of type std_logic_vector", eliminating choice 2d from the list: RAM_addr <= UNSIGNED(std_logic_vector'("00" & data_in)); This converts data_in to UNSIGNED, bringing into play the 4 "&" operators for type UNSIGNED, changing the interpretation of "00" so that it's of type UNSIGNED, and chosing the "&"[unsigned,unsigned RETURN unsigned] concatenation operator: RAM_addr <= "00" & UNSIGNED(data_in); [/QUOTE]

Verification