Hello,
I am a new bee trying to understand the CIC operation. I am using the
following model to understand the behaviour. When I increase the CIC order
(Q) when the decimation ration R is >1, I don't see the attenuation
increase as per expectation. I am using 0.2fs as the reference point to
measure the attenuation. Following is what I measured from the plot:
Q=1, -0.92 dB
Q=2, -2.49 dB
Q=3, -3.54 dB
Q=4, -4.79 dB
For the above, I have kept R=4 and N=2.
I was expecting the magnitudes to be: -0.92000 -1.84000 -2.76000
-3.68000 (for Q=1..4).
Not sure what I am missing. Appreciate any help on the above.
Thanks,
----------------------
%CIC Decimatior with integrator followed downsample followed by Comb
close all;
clear all;
Q=4 % CIC Stages
R=4; % Decimation rate
N=2; % Delay needed for Comb
Fs=1; % Normalized sampling freq
% Input (impulse)
Ni=2000; % # of input samples to CIC
x=zeros(1,Ni);
x(1)=1;
int_in=x;
% Integrator
for q=1:Q
dly=0;
for i=1:Ni
int_out(i)=int_in(i)+dly;
dly=int_out(i);
end
int_in=int_out;
end
% Downsample by R
y_down = int_out(1:R:end).*R;
comb_in=y_down;
% Comb
for q=1:Q
dlybuf=zeros(1,N);
for i=1:length(comb_in)
comb_out(i)=comb_in(i)-dlybuf(N);
dlybuf(2:N)=dlybuf(1:N-1);
dlybuf(1)=comb_in(i);
end
comb_in=comb_out;
end
y_comb=comb_out;
% Comb output
cic_out=y_comb./(R*N)^Q;
Nc=length(cic_out); % # of samples at CIC output
% Freq response plot for CIC output
figure;
grid on;
hold on;
Y=fft(cic_out);
Y=10*log10(abs(Y));
f_axis_range=0:1/Nc:(1-1/Nc);
plot(f_axis_range,Y);
xlabel('Normalized Sampling Freq (Post Decimation)');
ylabel('dB');
---------------------------------------
Posted through http://www.DSPRelated.com
CIC attenuation not as expected with increase in CIC order
Started by ●February 22, 2016
Reply by ●February 22, 20162016-02-22
Try moving your delay buffer lines before the comb out instruction instead of after. Your delay is off by 1 I think. Also I assume you know that your integrators will quickly head towards infinity since they are open-loop. Even mighty Matlab will eventually give you an error. It's probably OK for short simulations. The real implementation uses fixed-point math with modulo operation to avoid this problem. Bob
Reply by ●February 23, 20162016-02-23
>Try moving your delay buffer lines before the comb out instructioninstead>of after. Your delay is off by 1 I think. >Hi Bob, Thanks for the response. I tried your suggestion, but it did not help. However, with my original code, with N=2, I am indeed seeing one null at fs/2 as we expect. Doesn't that point to the delay line being OK.>Also I assume you know that your integrators will quickly head towards >infinity since they are open-loop. Even mighty Matlab will eventuallygive you>an error. It's probably OK for short simulations. The realimplementation>uses fixed-point math with modulo operation to avoid this problem. > >BobYes, Thanks. For the real implementation I guess I need to use 2's complement logic in the integrators. -TT --------------------------------------- Posted through http://www.DSPRelated.com
Reply by ●February 23, 20162016-02-23
On Tuesday, February 23, 2016 at 3:57:22 AM UTC-5, TrimTram wrote:> >Try moving your delay buffer lines before the comb out instruction > instead > >of after. Your delay is off by 1 I think. > > > > Hi Bob, > Thanks for the response. I tried your suggestion, but it did not help. > However, with my original code, with N=2, I am indeed seeing one null at > fs/2 as we expect. Doesn't that point to the delay line being OK. > > >Also I assume you know that your integrators will quickly head towards > >infinity since they are open-loop. Even mighty Matlab will eventually > give you > >an error. It's probably OK for short simulations. The real > implementation > >uses fixed-point math with modulo operation to avoid this problem. > > > >Bob > > Yes, Thanks. For the real implementation I guess I need to use 2's > complement logic in the integrators. > > -TT > > --------------------------------------- > Posted through http://www.DSPRelated.comI'd like to ask a question here. I understand the problem of the integrators in CIC filters. Any small error or a one time error will accumulate and eventually overflow. If this was hardware, we would change the integrators such that instead of infinite gain at DC, we would roll the gain off at very low frequency. Thus a one time error would gradually be eliminated and small errors would not accumulate. Can this same approach (limiting the gain at low frequencies) be used in a DSP implementation to make these CIC filter more tolerant of errors and if not, why not? Mark
Reply by ●February 23, 20162016-02-23
makolber@yahoo.com wrote:> On Tuesday, February 23, 2016 at 3:57:22 AM UTC-5, TrimTram wrote: >> >Try moving your delay buffer lines before the comb out instruction >> instead >> >of after. Your delay is off by 1 I think. >> > >> >> Hi Bob, >> Thanks for the response. I tried your suggestion, but it did not help. >> However, with my original code, with N=2, I am indeed seeing one null at >> fs/2 as we expect. Doesn't that point to the delay line being OK. >> >> >Also I assume you know that your integrators will quickly head towards >> >infinity since they are open-loop. Even mighty Matlab will eventually >> give you >> >an error. It's probably OK for short simulations. The real >> implementation >> >uses fixed-point math with modulo operation to avoid this problem. >> > >> >Bob >> >> Yes, Thanks. For the real implementation I guess I need to use 2's >> complement logic in the integrators. >> >> -TT >> >> --------------------------------------- >> Posted through http://www.DSPRelated.com > > I'd like to ask a question here. > > I understand the problem of the integrators in CIC filters. > Any small error or a one time error will accumulate and eventually overflow. > > If this was hardware, we would change the integrators such that instead of infinite gain at DC, we would roll the gain off at very low frequency. > Thus a one time error would gradually be eliminated and small errors would not > accumulate. > > Can this same approach (limiting the gain at low frequencies) be used in a DSP implementation to make these CIC filter more tolerant of errors and if not, why not? > > > Mark >I suppose maybe? Kind of misses the point, though. Implemented in fixed point as intended, a CIC integrator has no error, just bit growth. This is easy to accomodate on inexpensive hardware that lacks floating-point capabilities, and provides an adequate interpolation or decimation filter with few resources. Once you've got a big monster doing floating-point, you COULD work around the non-ideality of floating-point numbers so that you can still use a CIC filter, and thus get an adequate filter with lots of resources. Or you could make a better filter on fewer resources, because you've already got the big hardware to handle it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●February 26, 20162016-02-26
On 2/23/2016 8:28 AM, makolber@yahoo.com wrote:> On Tuesday, February 23, 2016 at 3:57:22 AM UTC-5, TrimTram wrote: >>> Try moving your delay buffer lines before the comb out instruction >> instead >>> of after. Your delay is off by 1 I think. >>> >> >> Hi Bob, >> Thanks for the response. I tried your suggestion, but it did not help. >> However, with my original code, with N=2, I am indeed seeing one null at >> fs/2 as we expect. Doesn't that point to the delay line being OK. >> >>> Also I assume you know that your integrators will quickly head towards >>> infinity since they are open-loop. Even mighty Matlab will eventually >> give you >>> an error. It's probably OK for short simulations. The real >> implementation >>> uses fixed-point math with modulo operation to avoid this problem. >>> >>> Bob >> >> Yes, Thanks. For the real implementation I guess I need to use 2's >> complement logic in the integrators. >> >> -TT >> >> --------------------------------------- > > Posted through http://www.DSPRelated.com > > I'd like to ask a question here. > > I understand the problem of the integrators in CIC filters. Any small > error or a one time error will accumulate and eventually overflow. > > If this was hardware, we would change the integrators such that > instead of infinite gain at DC, we would roll the gain off at very > low frequency. Thus a one time error would gradually be eliminated > and small errors would not accumulate. > > Can this same approach (limiting the gain at low frequencies) be used > in a DSP implementation to make these CIC filter more tolerant of > errors and if not, why not? > > MarkWhy would you do that? A CIC filter is just a funky implementation of an boxcar FIR filter. If you're worried about floating-point numerical stability - just use your favorite FIR filter kernel. It's stable. I've always considered a CIC filter to be the wrong tool for the job if the data is floating point. Bob.
Reply by ●February 26, 20162016-02-26
On Thursday, February 25, 2016 at 11:55:04 PM UTC-5, Rob Doyle wrote:> On 2/23/2016 8:28 AM, makolber@yahoo.com wrote: > > On Tuesday, February 23, 2016 at 3:57:22 AM UTC-5, TrimTram wrote: > >>> Try moving your delay buffer lines before the comb out instruction > >> instead > >>> of after. Your delay is off by 1 I think. > >>> > >> > >> Hi Bob, > >> Thanks for the response. I tried your suggestion, but it did not help. > >> However, with my original code, with N=2, I am indeed seeing one null at > >> fs/2 as we expect. Doesn't that point to the delay line being OK. > >> > >>> Also I assume you know that your integrators will quickly head towards > >>> infinity since they are open-loop. Even mighty Matlab will eventually > >> give you > >>> an error. It's probably OK for short simulations. The real > >> implementation > >>> uses fixed-point math with modulo operation to avoid this problem. > >>> > >>> Bob > >> > >> Yes, Thanks. For the real implementation I guess I need to use 2's > >> complement logic in the integrators. > >> > >> -TT > >> > >> --------------------------------------- > > > Posted through http://www.DSPRelated.com > > > > I'd like to ask a question here. > > > > I understand the problem of the integrators in CIC filters. Any small > > error or a one time error will accumulate and eventually overflow. > > > > If this was hardware, we would change the integrators such that > > instead of infinite gain at DC, we would roll the gain off at very > > low frequency. Thus a one time error would gradually be eliminated > > and small errors would not accumulate. > > > > Can this same approach (limiting the gain at low frequencies) be used > > in a DSP implementation to make these CIC filter more tolerant of > > errors and if not, why not? > > > > Mark > > Why would you do that? > > A CIC filter is just a funky implementation of an boxcar FIR filter. If > you're worried about floating-point numerical stability - just use your > favorite FIR filter kernel. It's stable. > > I've always considered a CIC filter to be the wrong tool for the job if > the data is floating point. > > Bob.HI BOB!!!!!!!!!! We should keep in touch via email or something... We are using a CIC filter in an FPGA DSP application and it is implemented in fixed point. But sometimes for some corner case input conditions, it must overflow (or some other problem) becasue it will sometimes go unstable and once unstable it will stay unstable until reset. I was wondering if the leaky integrator would at least get it to come back on it's own after a time. Or will a leaky integrator ruin the filtering characterisitics? Or would a leaky integrator be difficult to implement efficently? We are using a CIC intsead of FIR for the same reasons anybody would, better use of resources. Bob, write me via email,(not the yahoo email addr that I post from, it's a dead letter box) I'd like to stay more in touch. Mark
Reply by ●February 26, 20162016-02-26
On Fri, 26 Feb 2016 17:28:52 -0000 (UTC), Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:>makolber@yahoo.com wrote: > >> We should keep in touch via email or something... >> >> We are using a CIC filter in an FPGA DSP application and it is implemented in fixed point. But sometimes for some corner case input conditions, it must overflow (or some other problem) becasue it will sometimes go unstable and once unstable it will stay unstable until reset. I was wondering if the leaky integrator would at least get it to come back on it's own after a time. Or will a leaky integrator ruin the filtering characterisitics? Or would a leaky integrator be difficult to implement efficently? >> > >You've got something up with your implementation then.</obvious> > >The whole idea in a CIC (decimation direction) is that it's fine if >integrator overflows once between one comb iteration and the next, >because the subtract in the comb de-overflows it and it all works out. >Similar idea in the interpolation direction. The fixed point >makes it so that you can drop one of the comb's zeros exactly onto the >z=1 pole of the integrator, they cancel out and you get pleasingly >finite gain. > >In order to keep that, you get the classic CIC problem of bit gain; the >data path needs to get wider and wider as you go through the stages >because the moment you start throwing LSBs away by any means, you no >longer have that perfect cancellation and things get unstable and wonky. > >Donadio's paper at http://home.mit.bme.hu/~kollar/papers/cic.pdf is a >good read if you haven't yet, and a svelte six pages. Hogenauer's >original one is probably the most informative, but reading it's like >swimming through molasses. > >-- >Rob Gaddi, Highland Technology -- www.highlandtechnology.com>Email address domain is currently out of order. See above to fix.I'll +1 on Rob's inputs. One of the beauties of CIC implementations is that they are tolerant of overflow/rollover. Something is slightly awry with Mark's filter if it has overflow issues and stability problems. Both of those problems are rare with CIC filters and generally indicate a problem of some kind. And *that* being said, CIC implementations are usually simple enough that I'd think it would be fairly easy to spot a problem by inspection. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●February 26, 20162016-02-26
On Tue, 23 Feb 2016 07:28:03 -0800, makolber wrote:> On Tuesday, February 23, 2016 at 3:57:22 AM UTC-5, TrimTram wrote: >> >Try moving your delay buffer lines before the comb out instruction >> instead >> >of after. Your delay is off by 1 I think. >> > >> > >> Hi Bob, >> Thanks for the response. I tried your suggestion, but it did not help. >> However, with my original code, with N=2, I am indeed seeing one null >> at fs/2 as we expect. Doesn't that point to the delay line being OK. >> >> >Also I assume you know that your integrators will quickly head towards >> >infinity since they are open-loop. Even mighty Matlab will eventually >> give you >> >an error. It's probably OK for short simulations. The real >> implementation >> >uses fixed-point math with modulo operation to avoid this problem. >> > >> >Bob >> >> Yes, Thanks. For the real implementation I guess I need to use 2's >> complement logic in the integrators. >> >> -TT >> >> --------------------------------------- >> Posted through http://www.DSPRelated.com > > I'd like to ask a question here. > > I understand the problem of the integrators in CIC filters. > Any small error or a one time error will accumulate and eventually > overflow. > > If this was hardware, we would change the integrators such that instead > of infinite gain at DC, we would roll the gain off at very low > frequency. > Thus a one time error would gradually be eliminated and small errors > would not accumulate. > > Can this same approach (limiting the gain at low frequencies) be used in > a DSP implementation to make these CIC filter more tolerant of errors > and if not, why not?Erm -- no. If the integrator is working correctly, and there's a DC component to the input, it WILL keep building, and that is _perfectly normal_. The trick in the CIC filter is to do the work in integer math and let the integrator roll over -- basically you're doing modulo 2^n arithmetic at your bit width, taking advantage that a finite-width adder will just automatically roll over without any special hardware to make it happen. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●February 26, 20162016-02-26
Eric Jacobsen <eric.jacobsen@ieee.org> wrote:>I'll +1 on Rob's inputs. One of the beauties of CIC implementations >is that they are tolerant of overflow/rollover. Something is >slightly awry with Mark's filter if it has overflow issues and >stability problems. Both of those problems are rare with CIC filters >and generally indicate a problem of some kind. > >And *that* being said, CIC implementations are usually simple enough >that I'd think it would be fairly easy to spot a problem by >inspection.Which is a really good thing, because it's unlikely you'd discover an instability via RTL simulation. Steve
