I have been given the task of measuring the performance of Biquad IIR filters on a new CPU that we are evaluating.

What I know is that the Biquad filters can be cascaded to form higher order filters.

I drew the following based on some light reading to form a fifth order IIR filter. For every new sample that arrives, do I have to simply execute the 3 equations for each of the stages sequentially

y1 = b0*x + ..;
d11 = ..;
d12 = ...;
y2  = ...;
d21 = ..;
...
...
d31 = b1*y2...;


The 5 coefficients for each of the stages are available and so are the initial differences (Dx1 and Dx2). So should I just sequentially execute the stages for each sample? Is that all to Biquad IIR software implementation? I would be grateful if you can tell me what else is in the recipe.

• I'm a bit surprised to see cascaded Biquad filters run on a CPU to form a fifth order IIR, especially with the D32==0 constraint you're mentioning, this really, really looks like something that you'd do in hardware, ie. when designing an FPGA or ASIC, but practically never in software. You're basically doing something that dedicated hardware is good at, but that breaks performance on modern CPUs very much – small-scale recursive functionality basically has the effect of stalling the CPU pipeline, and that means that this very probably performs much, much worse than an equivalent,but longer,FIR – Marcus Müller Mar 18 '17 at 15:54
• ... which means this benchmark might be a bit bogus – you figure out how good your new CPU is at something that you wouldn't do on a CPU if you're doing performance-optimization. But then again, I don't know what the bigger picture, or the CPU you're looking at is, so take this with a grain of salt. – Marcus Müller Mar 18 '17 at 15:56
• The common motivation to break down higher-order IIRs into Biquads is to avoid instability and all kinds of numeric trouble; if you're implementing this in floating point, however, your filter / signal would have to be very bad-behaved to cause such trouble if you directly went for the fifth order IIR; if you're doing this in fixed point of low bitwidth (say, 16 bit or so), things like ARM and x86 and generally every processor core sold as DSP have things that can take a lot of operands and do a Multiply-Accumulate, and that's what you need to build very fast FIR filters; hence my confusion. – Marcus Müller Mar 18 '17 at 16:09
• @Marcus. The data is 16 bits. Actually its not a CPU, but a streaming processor we want to run this on. That said, there is a version of the benchmark that was written for a CPU. Based on your comments, I am now really curious to know how this was originally done. In any case, is my code snippet correct? – Raj Mar 18 '17 at 17:43
• I should also tell you that the samples arrive from another filter chain. So this Biquad that I am writing is a later stage filter. – Raj Mar 18 '17 at 17:46