dividing to 32bit signed integers with ieee_fixed_pkg -> error

[Altera_Forum]

Hello everyone, 

I am trying to divide two 32 bit signed integer signals (see code below). I am using the fixed point package from bishop, which invokes the lpm_divide megafunction.  When compiling the following error occurs:   Error (272006): In lpm_divide megafunction, LPM_WIDTHN must be less than or equals to 64  This tells me that the width of the numerator exceeded 64 bits, however the width of signal as is 32 bits.  Could someone please tell me what I am doing wrong? Would you recommend to divide signals like this or are there better ways of doing this? I am grateful for your advices.   library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; library ieee_proposed; use ieee_proposed.fixed_pkg.all; -- ---------------------------------------------------------------- entity fixed_pkg_example is port ( rstN : in std_logic; clk : in std_logic; a : in std_logic_vector(31 downto 0); b : in std_logic_vector(31 downto 0); div_out : out std_logic_vector(31 downto 0) ); end entity; -- ---------------------------------------------------------------- architecture behave of fixed_pkg_example is signal as : sfixed(31 downto 0); signal bs : sfixed(31 downto 0); signal divs : sfixed(sfixed_high(as,'/',bs) downto sfixed_low(as,'/',bs)); begin -- Type conversions as <= to_sfixed(a,as'high,as'low); bs <= to_sfixed(b,bs'high,bs'low); -- calculation divs <= as / bs; -- resize to meet output signal width div_out <= to_slv(resize(divs,31,0)); end architecture;

[Altera_Forum]

This will be the inference of the lpm_divide. The code itself has nothing to do with lpm_divide (thats the synthesisor placing them for you) 

As the error says, the LPM divide megafunction has a limit of 64 bits, so it cannot place a divider that large for you. You will have to find one that allows larger input or build your own.

[Altera_Forum]

I neither realize at first sight why the numerator should exceed 64 bit length nor what's the purposed of using the fixed point package for an all integer divider. I guess it's because you are using the fixed point divider beyond the intended number range.

[Altera_Forum]

Probably the same basic reason why dividing -32768 by -1 gives a value that is outside 16 bits.

[Altera_Forum]

--- Quote Start ---  I neither realize at first sight why the numerator should exceed 64 bit length nor what's the purposed of using the fixed point package for an all integer divider. I guess it's because you are using the fixed point divider beyond the intended number range.  --- Quote End ---   The above example should just show the problem with the port width. I am using true fixed-point integer later on.

[Altera_Forum]

Remember that Quartus does not have full VHDL 2008 support yet, so using the '93 version will not carry any support from Altera. 

Also, using divides like this is very poor practice - you get no pipelining so the FMax will be very low.

[Altera_Forum]

--- Quote Start ---  Remember that Quartus does not have full VHDL 2008 support yet, so using the '93 version will not carry any support from Altera. Also, using divides like this is very poor practice - you get no pipelining so the FMax will be very low.  --- Quote End ---   I am an beginner and thankful for every hint.  I hope I understand the concept of pipelining: Instead of calculating the mathematical expression or logic result at once, the output is produced over a range of FPGA cycles where. Why does latching the intermediate results and step-wise calculation increase the achievable clocking speed, fmax?  Back to the division: It would then be better practice if I invoke lpm_divide myself and connect the clock for pipelining? According to the manual lpm_divide megafunction supports pipelining. About the '93 version: I am experiencing a very steep learning curve right now. Once I am more comfortable with the fixed-point integer arithmetic's etc., I might be able to handle my tasks without the fixed_pkg.  Thanks!

[Altera_Forum]

--- Quote Start ---  Probably the same basic reason why dividing -32768 by -1 gives a value that is outside 16 bits.  --- Quote End ---   Ok. This would explain why I might exceed the output width of the calculated result, but not why a 32 bit input signal appears to be larger then the limiting 64 bits?

[Altera_Forum]

--- Quote Start ---  I am an beginner and thankful for every hint.  I hope I understand the concept of pipelining: Instead of calculating the mathematical expression or logic result at once, the output is produced over a range of FPGA cycles where. Why does latching the intermediate results and step-wise calculation increase the achievable clocking speed, fmax?   --- Quote End ---    The clock speed is determined by the worst case delay from one register to another. With less pipelining, there is more logic between the registers, and hence a larger delay/slower fmax.    --- Quote Start ---   Back to the division: It would then be better practice if I invoke lpm_divide myself and connect the clock for pipelining? According to the manual lpm_divide megafunction supports pipelining. About the '93 version: I am experiencing a very steep learning curve right now. Once I am more comfortable with the fixed-point integer arithmetic's etc., I might be able to handle my tasks without the fixed_pkg.  Thanks!  --- Quote End ---    Yes, invoking the divide yourself (either directly or from the megawizard - I suggest the latter at first) will give you a pipelined result. But even better to avoid divides as much as possible. Are you just trying to do A/B where B is constant? thats the same as A * 1/B, and 1/B is still a constant. Multiplies are much less resource hungry than divides, and need fewer pipe stages (usually just 1).   The fixed package is still a great thing to use and works really well. I used it for an entire image processing algorithm (it contained 2D filters, upsamplers, downsamplers and histograms).

[Altera_Forum]

The task is to calculate a feedforward solution for a control problem and I need the division between terms depending on input signals. It seems now that it might be a better solution to calculate the feedforward offline and use a LUT.  

Thanks for your support.