>sunflowerhj wrote:
>> Hi:
>> Can anyone help me to understand why CIC filter can not be implemented
in
>> floating point?
>>
>> Mr. Dirk A Bell mentioned:
>>
>>>>A CIC filter cannot be implemented in floating point. To get it to
>>>>work it must be done in non-saturating integer math, such as is done
>>>>using non-saturating two's complement representation. The integer
>>>>math must wrap around.
>>>>
>>>>Dirk A. Bell
>>
>> in http://www.dsprelated.com/showmessage/4544/1.php
>>
>> Could anyone explain it in more details or refer some articles to
read?
>> Thanks for the help in advance.
>>
>> Jing
>>
>>
>>
>>
>
>
>It is because the CIC depends on exact integer math in order to exactly
>cancel samples in the comb part of the filter. Floating point has some
>nasty rounding that will prevent exact cancellation. A CIC also depends
>on the modularity of the number system: we allow the integrator to
>continuously overflow, but since the number system is modular and the
>comb section just takes the difference between the current and a delayed
>integrator output, the overflows are of no consequence. If it were to
>be done with floating point, a mod function would have to be used to
>preserve the modularity, otherwise the floating point will keep bumping
>up the exponent and shifting lsbs off the integrator as it sums without
>bound
>
>This becomes perhaps a bit more obvious if you consider a first order
>CIC. The CIC is a recursive implementation of a boxcar filter, which is
>to say it outputs the sum of the last N samples. Rather than summing
>all those samples on every sample interval, it accumulates the samples
>in an integrator (without regard to overflow). The comb section
>subtracts the integrator output of N samples ago from the current
>integrator output. Since the comb section is computing the difference
>between integrator outputs, we don't care about integrator overflows as
>long as the number system is modular (e.g. two's complement or RNS
>systems), meaning A+N=A where N is the modulus of the number system.
>For 2's complement, N=2^k where k is the number of bits.
>
>
Reply by Ray Andraka●November 17, 20062006-11-17
Jerry Avins wrote:
> Ray Andraka wrote:
>
> ...
>
>> Oops, I forgot the delay on the - branch into the comb
>
>
> Never mind. You finally screwed my head on straight anyway.
>
> Jerry
My pleasure? ;-) CIC's are one of the tricks I learned about early in
my DSP career, and at the time practically nobody was using them.
Nowadays I see them mentioned all over the place. That and CORDIC.
Reply by Jerry Avins●November 17, 20062006-11-17
Ray Andraka wrote:
...
> Oops, I forgot the delay on the - branch into the comb
Never mind. You finally screwed my head on straight anyway.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Ray Andraka●November 17, 20062006-11-17
Ray Andraka wrote:
> Jerry Avins wrote:
>
>> Ray Andraka wrote:
>>
>>> Jerry Avins wrote:
>>>
>>>> Ray Andraka wrote:
>>>>
>>>>> ... The comb section subtracts the integrator output of N
>>>>> samples ago from the current integrator output. ...
>>>>
>>>>
>>>>
>>>>
>>>> Not the integrator input from N samples ago from the current
>>>> integrator output?
>>>>
>>>> Jerry
>>>
>>>
>>> Nope, the boxcar is H(z)= 1 + z^-1 + z^-2 + .... +z^-n. This is a
>>> geometric progression of n terms, so
>>>
>>>
>>> H(z) = (1-z^-n)/(1-z^-1)
>>>
>>> the integrator is, u(z) = x(z) + u(z)*z^-1 = x(z)/(1-z^-1)
>>>
>>> so the CIC output is y(z) = (1-z^-n)*u(z) = u(z) - u(z)*z^-n
>>
>>
>>
>> Isn't that subtracting the *input* N samples ago from the current
>> output? I don't see a subtraction involving y(z^-n).
>>
>> Jerry
>
>
>
> Jerry,
>
> Subtracting the output of the integrator, not the output of the filter.
>
> The CIC is an integrator followed by a comb filter. The comb subtracts
> the output of the integrator (u) N samples ago from the current output
> of the integrator. The output of the filter (y) is that difference.
>
> integrator comb
> +---+ +---+
> --->| + |--+--+--->| + |------>
> +---+ | | +---+
> + ^ | | ^ -
> |____| |_z^-N_|
Oops, I forgot the delay on the - branch into the comb
Reply by Ray Andraka●November 17, 20062006-11-17
Jerry Avins wrote:
> Ray Andraka wrote:
>
>> Jerry Avins wrote:
>>
>>> Ray Andraka wrote:
>>>
>>>> ... The comb section subtracts the integrator output of N
>>>> samples ago from the current integrator output. ...
>>>
>>>
>>>
>>> Not the integrator input from N samples ago from the current
>>> integrator output?
>>>
>>> Jerry
>>
>> Nope, the boxcar is H(z)= 1 + z^-1 + z^-2 + .... +z^-n. This is a
>> geometric progression of n terms, so
>>
>>
>> H(z) = (1-z^-n)/(1-z^-1)
>>
>> the integrator is, u(z) = x(z) + u(z)*z^-1 = x(z)/(1-z^-1)
>>
>> so the CIC output is y(z) = (1-z^-n)*u(z) = u(z) - u(z)*z^-n
>
>
> Isn't that subtracting the *input* N samples ago from the current
> output? I don't see a subtraction involving y(z^-n).
>
> Jerry
Jerry,
Subtracting the output of the integrator, not the output of the filter.
The CIC is an integrator followed by a comb filter. The comb subtracts
the output of the integrator (u) N samples ago from the current output
of the integrator. The output of the filter (y) is that difference.
integrator comb
+---+ +---+
--->| + |--+--+--->| + |------>
+---+ | | +---+
+ ^ | | ^ -
|____| |______|
Reply by Jerry Avins●November 17, 20062006-11-17
Ray Andraka wrote:
> Jerry Avins wrote:
>
>> Ray Andraka wrote:
>>
>>> ... The comb section subtracts the integrator output of N samples
>>> ago from the current integrator output. ...
>>
>>
>> Not the integrator input from N samples ago from the current
>> integrator output?
>>
>> Jerry
> Nope, the boxcar is H(z)= 1 + z^-1 + z^-2 + .... +z^-n. This is a
> geometric progression of n terms, so
>
>
> H(z) = (1-z^-n)/(1-z^-1)
>
> the integrator is, u(z) = x(z) + u(z)*z^-1 = x(z)/(1-z^-1)
>
> so the CIC output is y(z) = (1-z^-n)*u(z) = u(z) - u(z)*z^-n
Isn't that subtracting the *input* N samples ago from the current
output? I don't see a subtraction involving y(z^-n).
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Ray Andraka●November 16, 20062006-11-16
Jerry Avins wrote:
> Ray Andraka wrote:
>
>> ... The comb section subtracts the integrator output of N samples
>> ago from the current integrator output. ...
>
>
> Not the integrator input from N samples ago from the current integrator
> output?
>
> Jerry
Nope, the boxcar is H(z)= 1 + z^-1 + z^-2 + .... +z^-n. This is a
geometric progression of n terms, so
H(z) = (1-z^-n)/(1-z^-1)
the integrator is, u(z) = x(z) + u(z)*z^-1 = x(z)/(1-z^-1)
so the CIC output is y(z) = (1-z^-n)*u(z) = u(z) - u(z)*z^-n
Reply by Jerry Avins●November 16, 20062006-11-16
Ray Andraka wrote:
> ... The comb section
> subtracts the integrator output of N samples ago from the current
> integrator output. ...
Not the integrator input from N samples ago from the current integrator
output?
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
>Hi:
>Can anyone help me to understand why CIC filter can not be implemented in
>floating point?
>
>Mr. Dirk A Bell mentioned:
>>>A CIC filter cannot be implemented in floating point. To get it to
>>>work it must be done in non-saturating integer math, such as is done
>>>using non-saturating two's complement representation. The integer
>>>math must wrap around.
>>>
>>>Dirk A. Bell
>in http://www.dsprelated.com/showmessage/4544/1.php
>
>Could anyone explain it in more details or refer some articles to read?
>Thanks for the help in advance.
>
>Jing
>
>
>
>
Reply by Ray Andraka●November 16, 20062006-11-16
sunflowerhj wrote:
> Hi:
> Can anyone help me to understand why CIC filter can not be implemented in
> floating point?
>
> Mr. Dirk A Bell mentioned:
>
>>>A CIC filter cannot be implemented in floating point. To get it to
>>>work it must be done in non-saturating integer math, such as is done
>>>using non-saturating two's complement representation. The integer
>>>math must wrap around.
>>>
>>>Dirk A. Bell
>
> in http://www.dsprelated.com/showmessage/4544/1.php
>
> Could anyone explain it in more details or refer some articles to read?
> Thanks for the help in advance.
>
> Jing
>
>
>
>
It is because the CIC depends on exact integer math in order to exactly
cancel samples in the comb part of the filter. Floating point has some
nasty rounding that will prevent exact cancellation. A CIC also depends
on the modularity of the number system: we allow the integrator to
continuously overflow, but since the number system is modular and the
comb section just takes the difference between the current and a delayed
integrator output, the overflows are of no consequence. If it were to
be done with floating point, a mod function would have to be used to
preserve the modularity, otherwise the floating point will keep bumping
up the exponent and shifting lsbs off the integrator as it sums without
bound
This becomes perhaps a bit more obvious if you consider a first order
CIC. The CIC is a recursive implementation of a boxcar filter, which is
to say it outputs the sum of the last N samples. Rather than summing
all those samples on every sample interval, it accumulates the samples
in an integrator (without regard to overflow). The comb section
subtracts the integrator output of N samples ago from the current
integrator output. Since the comb section is computing the difference
between integrator outputs, we don't care about integrator overflows as
long as the number system is modular (e.g. two's complement or RNS
systems), meaning A+N=A where N is the modulus of the number system.
For 2's complement, N=2^k where k is the number of bits.