--- Quote Start ---
In my earlier post I alluded to this; and in a derived calculation each data type must be explicitly declared, i.e. :
derived_constant : std_logic_vector(15 downto 0) := to_unsigned(2047,16) - constant_1 - constant_2
where ieee.numeric_std.all is declared versus signed or unsigned libraries.
--- Quote End ---
The bit string for RAG_min that's calculated in the first expression doesn't change if the individual terms are either interpreted as signed or unsigned quantities. A problem arises, if the signedness of the constant is assumed wrong in a sign sensitive expression, e.g. a compare. Or if we imagine, that Quartus doesn't calculate the bit string but inserts the right hand side similar to a# define macro in the further calculations.
CONSTANT RAG_min : STD_LOGIC_VECTOR (11 DOWNTO 0) := (x"802"+PWM_DC_min+PWM_Crossover);
CONSTANT RAG_min : STD_LOGIC_VECTOR (11 DOWNTO 0) := x"880";
--- Quote Start ---
well this is part of a VHDL File "using" a Cyclone IV EPC4CE15 by 95%. The code is neither handy nor am I allowed to post it here as whole. I agree just posting snipets makes things not easier to investigate or explain.
--- Quote End ---
I didn't ask for the full code. The way you described the problem suggested a clearly detectable wrong evaluation of the said derived constants in a specific expression. If so, it should be possible to post a few lines that reproduce the issue. At least, the involved arithmetic operation should be known, e.g. compare, sign extension or different? Otherwise you can ask if the assumption about the nature of the problem actually holds.
Personally, I'm first of all interested to know if there's a hidden Quartus problem with derived constants.
For the time being, I conclude that there may be a limited problem with derived std_logic_vector constants under ieee.std_logic_signed.
Thanks,
Frank
Honored Contributor
