Implementation of CIC filter using floating point

Question

I am trying to implement a CIC filter and was reading through the literature and found that CIC filter cannot be implemented using floating point. I am unable to understand why that would happen. The reasoning that is given everywhere seems to be that the integrators are not stable when using floating point but I am not able to understand why that would be. Can someone explain how that would happen?

I also found that using polyphase decomposition would allow for floating point implementation but I am not sure how that would happen since the transfer function is still the same. I am not able to find a satisfactory explanation for this. Is this the only way to do floating point implementation?

Also I read that CIC filter is good if the decimation factor is high, but I am looking for a decimation factor of about 5 to 20. Why wont using a CIC filter be a good approach in this case.

Answer 1

Heh. I've just worked this out, and I think you can implement a CIC using floating point -- but it wouldn't be perfect, and in most processing environments it would be a waste of resources.

The basic CIC stage is an integrator implemented modulo a maximum number -- in an integer implementation, this would be $x_{max} = 2^n$ where $n$ is the word length, in a non-integer fixed-point implementation it would be the maximum span of values that the data type could hold.

$$x_k = \left(x_{k-1} + u_k \right) \mod x_{max} \\ y_k = \left(x_k - x_{k - N} \right) \mod x_{max}$$

where "$y = x \mod x_{max}$" maps $x$ onto the interval $y \in \left[ -\frac{x_{max}}{2}, \frac{x_{max}}{2} \right )$.

You choose $x_{max}$ so that over $N$ samples, there's no chance that the value of $x_k$ can roll over more than once.

The thing that makes the CIC less than practical in a floating point environment is that you have to do the modulo operation explicitly, either by actually doing a floating point modulo, or by detecting that $x_k$ or $y_k$ is outside of $\left[ -\frac{x_{max}}{2}, \frac{x_{max}}{2} \right )$ and adjusting them by adding or subtracting $x_{max}$.

The thing that makes the CIC less than exact in a floating point operation is that floating point arithmetic truncates more or less depending on the exponent.

The reason that the CIC is so attractive for fast, computationally efficient DSP is because with fixed point (integer or not) math, is because with typical adder hardware and 2's part arithmetic, the modulo operation comes for free -- it's just the fixed-word-width overflow that's usually the bane of fixed-point arithmetic. So you pay nothing -- in a sense, less than nothing* -- for the modulo.

The reason that CIC is exact is because if all the arguments are fixed point with the same radix (i.e., integers), then all of the operations are bit-exact. This can't be said for floating point.

So -- in a floating point environment you can implement a CIC filter. But, you'll be larding on so much extra computational resources to do the two modulo operations, that you may as well do something else, like half-band filters. The only place where it would make sense to use a CIC in floating point, in my opinion, would be if you're working on a test bench and you want to simulate a system that you're going to implement later.

* because you don't have to worry about detecting it, or preventing it.

Answer 2

See this post from Robert Bristow-Johnson, I think he posts on this stack exchange group by the way.

https://www.dsprelated.com/showthread/comp.dsp/364544-1.php

This post is about moving-average filters, but a CIC filter is basically a RMA filter with decimation or interpolation.

For more info on the problems with floating-point arithmetics

https://stackoverflow.com/questions/10371857/is-floating-point-addition-and-multiplication-associative

You can probably mitigate the issue by putting the comb filter stage on the first stage and the integrator at the second the stage so your integrator will never saturate when you apply a DC value. However, you might still end up with some residual value in your integrator that you can't get rid of.

For your second question, CIC filters don't have a flat pass-band so they are generally used in conjunction with another low-pass FIR filter to get a flatter passband.

Instead of using CIC filters, have you considered using halfband filters for decimation ? They're efficient and have a flatter passband than CIC filters. https://en.wikipedia.org/wiki/Half-band_filter

Answer 3

I believe the reasons floating point cannot be used directly in the exact same form is in how a CIC handles roll-overs in addition to creating a quantization error that will vary with the internal level of the CIC accumulator: the CIC essentially subtracts an integrated result (accumulator output) from the same result N samples ago (where N is typically the decimation rate but needn’t be). With fixed point arithmetic the result of the subtraction is the same even after the inevitable overflow of the accumulator - this is not the case with floating point so the accumulator would require additional reset features to prevent overflow or underflow.

The Cascade Comb-Integrator in simplest form is an accumulator (Integrator) followed by a difference of the accumulated output over N-samples (Comb) and for fixed point is equivalent to an N sample moving average, and (for fixed point only) the order of operations can be interchanged (between accumulator and comb):

The bottom implementation where the differencing occurs first followed by an accumulator cannot be implemented in floating point since a random walk error would be introduced in the accumulator, however the implementation with the accumulator first (as used in CIC decimators) would have no such issue other than requiring a reset of the accumulator in proximity of overflow/underflow condition.

What will occur in floating point is a quantization error that is proportional to the level in the accumulator, such that the accumulator can float up to such a large number that a given difference that would be measured with very high precision for a lower accumulator output value would be of much lower precision when the exponent is higher and even ultimately completely truncated. For example consider a single-precision floating point implementation if the difference was 12.7 but the accumulator has grown to $2 \times 10^{16}$; in this case the difference would be truncated to 12, and once it has grown to $2 \times 10^{17}$ the same difference would be zero.