# 80-tap Decimation Filter: divide into stages? / Cost of having a number of taps

I did a FIR filter hardware implementation with 80 taps (FPGA/VHDL). I will use it later as the decimation filter.

My questions:

1. Does the number of taps affect a cost of implementation of FIR?

FIR filters belong to the class of linear filters, the combination of N lower order filters can create the desired FIR filter of the higher order. So I was thinking If it makes sense to implement the combination of N lower order filters instead of a one 80 taps filter?

1. Is the decimation implemented in one stage usually?

EDIT 1

1. What is a difference between "filter ( convolution)", " polyphase filter" and "polyphase filter bank"?

Honestly, I dont know ny difference in an implementation.

• Regarding your question 3: please make it a new question, after reviewing other related questions (there are a few on that subject on this site).
– MBaz
May 25, 2021 at 13:28
• A polyphase implementation simply avoids either: calculating samples that are going to be thrown away (decimation), or multiplication by zeros (interpolation). Once you design your lowpass filter via the traditional means you use those filter coefficients in the polyphase implementation. May 25, 2021 at 14:34
• Breaking a decimation into multiple stages doesn't save that much on the computational power. It does save having to design a very long filter, where some design methods may break. Trying to decimate by 10,000 in one step, will break many filter design methods. Breaking it into stages allows the use of wider transition widths, which leads to smaller filter orders and reduced complexity at each stage. May 25, 2021 at 14:40
• asking a new question in an existing question is not a great idea; especially after accepting an answer already! May 25, 2021 at 15:44

Does the number of taps affect a cost of implementation of FIR?

FIR filters belong to the class of linear filters, the combination of N lower order filters can create the desired FIR filter of the higher order. So I was thinking If it makes sense to implement the combination of N lower order filters instead of a one 80 taps filter?

Is the decimation implemented in one stage usually?

Indeed, splitting decimation into multiple stages is something that is commonly done, because then only the first filter needs to run at the highest rate.

Now, 80 taps is not what we'd usually call a large filter, so yes, you can do that splitting, it's even advisable.

However, it might really be premature optimization: Your FPGA is probably fast enough to do all 80 MACs at full rate, and it doesn't even have to do that, seeing that you're building a decimating filter, so everything but the most naive implementation would be a polyphase filter implementation, which reduces your complexity to 80/(decimation) per input sample. Seeing that your filter is only 80 taps long, you're probably also not aiming for a very high decimation, anyway.

• Does polyphase decimation filter work better than a traditional filter?What is the main advantage? only complexity? May 25, 2021 at 12:00
• "Complexity", did you mean "computation complexity" or smth else? May 25, 2021 at 12:07

This is a bit late to the game and it depends on the decimation factor, but recently I've been working on a multichannel SDR receiver and in doing so stumbled on this article about half-band filters. The half-band filter works well if your decimation factor is divisible by 2, preferably multiple times. A small, efficient, filter is used to decimate (by a factor of 2) the high speed samples, a higher order filter used for the last stage where the sample rate is considerably lower. The one I'm using decimates by 2 for 5 stages (order 6, 6, 6, and 10) for a factor of 32, then a 126 coefficient FIR filter is used for the last stage to decimate by 5, for a total of 160, bring 2.4 MHz down to 16 kHz.

The filter design program I used couldn't handle 160x reduction in bandwidth I was looking for (2.4 Mhz to 16 kHz). The other advantage I have with the 6 step filter is that each filter can run in a separate thread, taking advantage of the multi-core CPU it is running on.

I hope my terminology is correct, I'm quite new at this stuff.