Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributorfixed-point tips
Hi
I have some experience with Quartus, but in the past have only worked on projects that implement very basic boolean expressions (like generating pulses with user defined widths and delays). I have been asked to try and build a block that does some stuff rather more complicated than I am used to with real numbers... but of course the final block has to be synthesizable. Here is an example of a "phase diff block" that is needed. Inputs: I1, I2, Q1, Q2, A1, A2 (all 16-bit with values lying between -1 and +1) cMode (Boolean) kc (all 16-bit with values lying between 0 and +1) Outputs: Pd (16-bit with values lying between -1 and +1) LD (Boolean) The function to implement is something like: Pd = (I1 * Q2 - I2 * Q1) / (A1 * A2) ld = (1-kc) * ld + kc * (I1 * I2 + Q1 * Q2) / (A1 * A2) If cMode = '0' THEN LD = 0 ELSIF ld > 0 THEN LD = 1 ELSE LD = 0 To be honest I don't really know where to start with how to define the data types and the equation for Pd. Any tips most welcome. Many thanks, Kurt18 Replies
Altera_ForumHave a look through this document for the recommended coding styles to infer DSP or memory or anything else:
http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=code%20templates you should be able to replace signed/unsigned with ufixed and sfixed.- Altera_Forum
Thank you guys for your answers. I was just unclear on whether or not I could use these types (sfixed, ufixed) with the LPM functions, or MegaCore functions so I don't have to reinvent the wheel. Also I am required to use the special DSP blocks (Stratix chips) for the application I am trying to develop and I was not sure whether this library would work with it.
- Altera_Forum
The Altera MegaFunctions are also inferred, when using arithmetic operators in HDL code, in addition, there are synthesis attributes to specify e.g. priority for hardware or software multiplier. They can be used for the design as a whole, for design units or part of them.
So in most cases, you don't have to care for the usage of MegaFunctions respectively the optimal implementation of your code. - Altera_Forum
Using these libraries has nothing to do with the LPM library. the LPM libraries are a separate thing altogether. Using the fixed_point libraries should give you much more reaadable and portable code, as well as making simulations much faster. The synthesisor should take the code and place multiplers/adders for you. The LPM library does not use the sfixed or ufixed types, so no you cannot input them into an LPMMULT and make it work, you have to type convert the values to std_logic_vector (which really is meant to have no meaning other than a collection of bits)
So, where before you will have had:
you can replace it with:mult : altmult_add generic map ( width_a => 16, width_b => 16, ...... ) port map ( clk => clk, dataa => a, datab => b, ... result => p, );
To be honest, this method has been around for years using the numeric_std package, just with the fixed package now it makes reading fixed point code that much easier.mult_proc : process(clk) begin if rising_edge(clk) then p <= a*b; end if; end process; - Altera_Forum--- Quote Start --- A std_logic_vector can be assigned to an sfixed signal by a conversion function, if it represents a fixed point number. But what do you mean with work correctly? If e.g. an overflow has occured in a LPM module, that don't provide saturation, it can't be recognized from the bit_vector. So the question is mainly, if the LPM module works correctly. --- Quote End --- What I meant to ask is will the operations (multiply, add, etc) that a LPM/MegaFunction uses will give the correct results given an ufixed, or sfixed? Or just including the libraries will automatically use those functions for the fixed point types?
- Altera_Forum
A std_logic_vector can be assigned to an sfixed signal by a conversion function, if it represents a fixed point number. But what do you mean with work correctly? If e.g. an overflow has occured in a LPM module, that don't provide saturation, it can't be recognized from the bit_vector. So the question is mainly, if the LPM module works correctly.
- Altera_Forum--- Quote Start --- fixed point is easy to deal with. Like integer arithmatic a 16bitx16 bit gives a 32 bit result, but now you havd 1.15 number. a 1.15 x 1.15 gives a 2.30 (2 bits magnitude, 30 bits fraction) result. remembering these rules makes using the ieee.numberic_std package possible because you can monitor which bits are magnitude, and which are fractional. so the following numbers, with range -1 to +1 signal A, B : signed(15 downto 0); (1.15 number) signal C : signed(31 downto 0); (2.30 result) signal OP : signed(15 downto 0); (1.15 output (16 bits)) c := A * B; --2 magnitude bits, 30 fractional bits OP := C(30 downto 15); --in range -1 to nearly 1 (this is only possible if -1x-1 is not a possible input. If it is, you need to use the range (31 downto 16), and your result will be a 2.14 result, but you will lose 1 bit of accuracy. a 1.15 number only represents -1 to nealy 1, and cannot represent +1 itself, so an extra bit of magnitude is required) When multiplying any signed numbers, you will always have 2 sign bits as the MSBs unless you multiply the most negative number by itself, so assuming max neg x max neg is not possible, you can ignore the MSB and gain an extra bit of accuracy But now, life is alot easier All you need to do is use the new floatfixpkg from the IEEE: http://www.vhdl.org/fphdl/vhdl.html from here you can do stuff like this:
Division is always going to be a bummer. But if you remember that A/B is actually just A * 1/B, and you can generate 1/B in software, all division problems are removed. --- Quote End --- I have a question regarding these libraries, do they work correctly if you were to use Altera's LPM modules like ALTMULT_ADD, ALTMULT_MAC, etc as their inputs?signal A,B : sfixed(1 downto -14) signal C : sfixed(3 downto -28) signal D : sfixed(3 downto -12) process(clk) begin if rising_edge(clk) C <= A*B; end if end process; D <= c(d'range); - Altera_Forum
Hi All
Many thanks for all your suggestions... being lazy I ended utilizing the recent IEEE fixed_pkg. For those interested, below is the code I ended-up with which seems to do the job OK (the functionality is a little different from my initial posting as the designer changed it):
There is some extra stuff in there just to help me with decoding, which I will remark out for the final version, but it seems to be passing testing at the moment. Many thanks, KurtLIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.NUMERIC_STD.ALL; LIBRARY WORK; USE WORK.math_utility_pkg.ALL; USE WORK.fixed_pkg.ALL; ENTITY phase_diff IS PORT ( clk : IN STD_LOGIC; i_I1 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_Q1 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_I2 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_Q2 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_A1 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_A2 : IN STD_LOGIC_VECTOR (15 DOWNTO 0); i_cMode : IN STD_LOGIC; i_kc : IN STD_LOGIC_VECTOR (31 DOWNTO 0); o_phase_corr : OUT STD_LOGIC_VECTOR (31 DOWNTO 0); o_lock_detect : OUT STD_LOGIC; recipr : OUT STD_LOGIC_VECTOR (34 DOWNTO 0); a1a2 : OUT STD_LOGIC_VECTOR (33 DOWNTO 0) ); END ENTITY phase_diff ; ARCHITECTURE arch OF phase_diff IS SIGNAL s_phase_corr : SFIXED (0 DOWNTO -31); SIGNAL s_phase_corr_prev : SFIXED (0 DOWNTO -31); SIGNAL s_ld : STD_LOGIC; SIGNAL s_lock_fixed_prev : SFIXED (0 DOWNTO -15); BEGIN PROCESS(clk) VARIABLE v_I1 : SFIXED (0 DOWNTO -15); VARIABLE v_Q1 : SFIXED (0 DOWNTO -15); VARIABLE v_I2 : SFIXED (0 DOWNTO -15); VARIABLE v_Q2 : SFIXED (0 DOWNTO -15); VARIABLE v_A1_u : UFIXED (0 DOWNTO -15); VARIABLE v_A2_u : UFIXED (0 DOWNTO -15); VARIABLE v_A1 : SFIXED (0 DOWNTO -16); VARIABLE v_A2 : SFIXED (0 DOWNTO -16); VARIABLE v_kc : SFIXED (0 DOWNTO -31); VARIABLE v_recip : SFIXED (33 DOWNTO -1); VARIABLE v_pd_s1 : SFIXED (2 DOWNTO -32); VARIABLE v_pd_fixed : SFIXED (36 DOWNTO -33); VARIABLE v_pld_s1 : SFIXED (2 DOWNTO -32); VARIABLE v_pld_fixed : SFIXED (0 DOWNTO -15); VARIABLE v_lock_s1 : SFIXED (2 DOWNTO -46); VARIABLE v_lock_s2 : SFIXED (1 DOWNTO -46); VARIABLE v_lock_fixed : SFIXED (0 DOWNTO -15); BEGIN IF RISING_EDGE(clk) THEN v_I1 := TO_SFIXED( i_I1, 0, -15 ); v_Q1 := TO_SFIXED( i_Q1, 0, -15 ); v_I2 := TO_SFIXED( i_I2, 0, -15 ); v_Q2 := TO_SFIXED( i_Q2, 0, -15 ); v_A1_u := TO_UFIXED( i_A1, 0, -15 ); v_A2_u := TO_UFIXED( i_A2, 0, -15 ); v_A1 := TO_SFIXED( v_A1_u ); v_A2 := TO_SFIXED( v_A2_u ); v_kc := TO_SFIXED( i_kc, 0, -31 ); a1a2 <= TO_SLV( RESIZE( v_A1 * v_A2, (2 * v_A1'HIGH) + 1, 2 * v_A1'LOW) ); -- 1 DOWNTO -32 v_recip := RESIZE( RECIPROCAL ( v_A1 * v_A2 ), (-2 * v_A1'LOW) + 1, -1 * ((2 * v_A1'HIGH) + 1) ); -- 33 DOWNTO -1 recipr <= TO_SLV( v_recip ); v_pd_s1 := RESIZE(( v_I1 * v_Q2 ) - ( v_I2 * v_Q1 ), (2 * v_A1'HIGH) + 2, 2 * v_A1'LOW ); v_pd_fixed := v_pd_s1 * v_recip; -- (I1Q2-I2Q1)/(A1A2) v_pld_s1 := RESIZE(( v_I1 * v_I2 ) + ( v_Q1 * v_Q2 ), (2 * v_A1'HIGH) + 2, 2 * v_A1'LOW ); v_pld_fixed := RESIZE( v_pld_s1 * v_recip, 0, -15 ); -- (I1I2+Q1Q2)/(A1A2) v_lock_s1 := ( 1 - v_kc ) * s_lock_fixed_prev; v_lock_s2 := v_kc * v_pld_fixed; v_lock_fixed := RESIZE( v_lock_s1 + v_lock_s2, 0, -15); -- (1-kc)*lock+kc*pld s_lock_fixed_prev <= v_lock_fixed; IF ((i_cMode = '1') AND (v_lock_fixed > TO_SFIXED(0.5, 0, -15))) THEN s_ld <= '1'; ELSE s_ld <= '0'; END IF; IF (i_cMode = '0') THEN s_phase_corr <= TO_SFIXED( 0, 0, -31 ); ELSE s_phase_corr <= RESIZE( s_phase_corr_prev + (v_kc * v_pd_fixed), 0, - 31 ); END IF; s_phase_corr_prev <= s_phase_corr; END IF; END PROCESS; o_phase_corr <= TO_SLV( s_phase_corr ); o_lock_detect <= s_ld; END arch; - Altera_Forum
Another thing I forgot to mention - it can get more complicated when you do something like using a range -0.5 to + 0.5
With this, you can actually gain accuracy because you can use "imaginary" bits. This comes in handy when you have 18 bit hardware multipliers but your values need to be in the range something like -(2^-18) to 2^-18 (ie. very small) where the most sig. 18 bits are all sign bits. So you represent what would be a 36 bit number in 18 bits, with an "imagniary" 18 bits on the front. For full accuracy on the result, you'd need a 72 bit number - 36 imaginary sign bits and 36 bits of result. - Altera_Forum
fixed point is easy to deal with. Like integer arithmatic a 16bitx16 bit gives a 32 bit result, but now you havd 1.15 number. a 1.15 x 1.15 gives a 2.30 (2 bits magnitude, 30 bits fraction) result. remembering these rules makes using the ieee.numberic_std package possible because you can monitor which bits are magnitude, and which are fractional.
so the following numbers, with range -1 to +1 signal A, B : signed(15 downto 0); (1.15 number) signal C : signed(31 downto 0); (2.30 result) signal OP : signed(15 downto 0); (1.15 output (16 bits)) c := A * B; --2 magnitude bits, 30 fractional bits OP := C(30 downto 15); --in range -1 to nearly 1 (this is only possible if -1x-1 is not a possible input. If it is, you need to use the range (31 downto 16), and your result will be a 2.14 result, but you will lose 1 bit of accuracy. a 1.15 number only represents -1 to nealy 1, and cannot represent +1 itself, so an extra bit of magnitude is required) When multiplying any signed numbers, you will always have 2 sign bits as the MSBs unless you multiply the most negative number by itself, so assuming max neg x max neg is not possible, you can ignore the MSB and gain an extra bit of accuracy But now, life is alot easier All you need to do is use the new floatfixpkg from the IEEE: http://www.vhdl.org/fphdl/vhdl.html from here you can do stuff like this:
Division is always going to be a bummer. But if you remember that A/B is actually just A * 1/B, and you can generate 1/B in software, all division problems are removed.signal A,B : sfixed(1 downto -14) signal C : sfixed(3 downto -28) signal D : sfixed(3 downto -12) process(clk) begin if rising_edge(clk) C <= A*B; end if end process; D <= c(d'range);
