Altera FIR compiler not using embedded multipliers

[Sparker]

Hello! It's my first message here.

I'm using Quartus 14.0 to make a project for Cyclone IV EP4CE6 FPGA. It has 15 18x18 embedded multipliers. But the FIR compiler II uses none of them no matter what value I assign for the 'LEs / DSP Block Multiplier Threshold' parameter. First I thought that it was so because I had a filter which required more multipliers than the FPGA had, so I created a simple filter having only 3 coefficients, but it still uses only logical cells. 

My project also uses multipliers created with a mega function, but they do use embedded multiplier elements.

Any ideas how to make it use those multipliers? This could save a lot of LEs for me.

[mngiggle]

An IP block mapping inefficiently might be due to the code that's interfacing to the FIR; it could be making Quartus think a DSP block wouldn't work (clocking, reset behavior, other items like that).  The sticking point can be finding -- if it exists -- the double-secret list of things to have to be "just so" to get it to instantiate correctly.   

This is for the wrong device and potentially more difficult, but there is an app note for inferring DSP blocks for HDL-defined FIRs: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an639.pdf.  May provide some clue. 

[Scrts]

An IP block mapping inefficiently might be due to the code that's interfacing to the FIR; it could be making Quartus think a DSP block wouldn't work (clocking, reset behavior, other items like that).  The sticking point can be finding -- if it exists -- the double-secret list of things to have to be "just so" to get it to instantiate correctly.   

This is for the wrong device and potentially more difficult, but there is an app note for inferring DSP blocks for HDL-defined FIRs: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an639.pdf.  May provide some clue.

True, the OP has to check if the part of the design was not optimized out.

[Sparker]

Thank you for your response. 

The filter is not optimized out because it is actually working and I can see that Quartus has assigned some logic to it.

It's quite unexpected but I've found that neither Analysis nor Fitter are to blame for not using embedded multipliers. The FIR Compiler II itself decides how many DSP blocks or LUTs to use. Changing parameters like Clock Frequency, Input Sample Rate or decimation factor options can cause the compiler to use different amount of DSP blocks.

Sadly, FIR Compiler II doesn't want to use DSP blocks for my single rate filter when its Clock Frequency is equal to Sample rate.

What I am doing is a CIC decimator with a FIR compensator filter. The input of the CIC is 20 MS/s, then I clock the FIR filter at 400 kHz, then I decimate it twice again by sampling at 200 kHz. It looks like clocking the FIR filter at 20 MHz and using its internal Altera-provided 'decimation' saves a lot of logic elements. How does it work? I thought that the structure of a filter should be the same no matter how I decimate my signal before it.

Sorry if my questions are stupid, I'm quite new to DSP. 

[parasole]

A good way to move forward is to study more general information about filters and their implementation in fpga.
CIC filters are the ones which do not require multipliers, then you need to know exactly what are you trying to design... 

[Scrts]

Did you try altera forums? If the solution is not there, raise a service request.

[Sparker]

Did you try altera forums? If the solution is not there, raise a service request.

No, I didn't try it yet. I don't have time to investigate this right now, but i will try to modify my design to use those embedded multipliers later. As I said, the compiler uses the embedded multipliers if I specify some decimation factor, so I'll try to use it soon.