cic interpolator filter in floating point vs fixed-point

would like to share one thing i learned in a hardway about CIC
interpolator. many of us do matlab model before trying any fixed-point
coding. incidentally, i had no fixed-point tool set  with my matlab. this
forced me to write a plain (floating point) code for my CIC integrator an
comb. implementing  this was straight forward. i also implemented
fixed-point code in C. 

interesting observation was noted when i tried to compare the output of c
code with that of matlab code. for some duration the output was +/-1
error,  as expected. however, as the time duration of the input waveform
is increased, i noticed the error between ref out and that of c was
increasing ! in fact, the increasing profile had a clear step pattern. for
every 'K' samples, the error amplitude increases and continued as and when
i feed more samples. 

invested time to check to find that the error was with matlab reference
not with my fixed-point code. the error became +/-1 when i changed my
matlab code with integer add/sub with wrapping! 

You have to use fixed-point add/sub with wrapping as 2's complement to
implement CIC.  time to realize that  message in matlab doc about CIC that
'this module requires fixed-point tool set' was not a marketing technique
from mathworks. CIC will not work in floating point! 
hope this will be helpful to someone.

 










---------------------------------------
Posted through http://www.DSPRelated.com

xchalil <111653@DSPRelated> wrote:

>would like to share one thing i learned in a hardway about CIC
>interpolator. many of us do matlab model before trying any fixed-point
>coding. incidentally, i had no fixed-point tool set  with my matlab. this
>forced me to write a plain (floating point) code for my CIC integrator an
>comb. implementing  this was straight forward. i also implemented
>fixed-point code in C. 

>interesting observation was noted when i tried to compare the output of c
>code with that of matlab code. for some duration the output was +/-1
>error,  as expected. however, as the time duration of the input waveform
>is increased, i noticed the error between ref out and that of c was
>increasing ! in fact, the increasing profile had a clear step pattern. for
>every 'K' samples, the error amplitude increases and continued as and when
>i feed more samples. 

>invested time to check to find that the error was with matlab reference
>not with my fixed-point code. the error became +/-1 when i changed my
>matlab code with integer add/sub with wrapping! 

An excellent experience -- CIC filters require exact integer
arithmetic with truncation and overflow.  This is one case where
a floating point implementation might be not only inexact,
but possibly completely wrong.

Steve

On Thursday, February 4, 2016 at 2:02:55 PM UTC-5, Steve Pope wrote:
> xchalil <111653@DSPRelated> wrote:
> 
> >would like to share one thing i learned in a hardway about CIC
> >interpolator. many of us do matlab model before trying any fixed-point
> >coding. incidentally, i had no fixed-point tool set  with my matlab. this
> >forced me to write a plain (floating point) code for my CIC integrator an
> >comb. implementing  this was straight forward. i also implemented
> >fixed-point code in C. 
> 
> >interesting observation was noted when i tried to compare the output of c
> >code with that of matlab code. for some duration the output was +/-1
> >error,  as expected. however, as the time duration of the input waveform
> >is increased, i noticed the error between ref out and that of c was
> >increasing ! in fact, the increasing profile had a clear step pattern. for
> >every 'K' samples, the error amplitude increases and continued as and when
> >i feed more samples. 
> 
> >invested time to check to find that the error was with matlab reference
> >not with my fixed-point code. the error became +/-1 when i changed my
> >matlab code with integer add/sub with wrapping! 
> 
> An excellent experience -- CIC filters require exact integer
> arithmetic with truncation and overflow.  This is one case where
> a floating point implementation might be not only inexact,
> but possibly completely wrong.

well, i have seen a moving-sum or moving-average filter implemented with the integrator and delay line done in floating-point.  maybe it was double-precision.  i sorta objected to it on principle, but the accumulated error didn't seem to explode in the time we were running it (for hours).

in principle either you must make sure that whatever you add is exactly what you subtract from the integrator, **or** you need to put the pole of the integrator slightly inside the unit circle.

r b-j