CIC pruning theory

On 30.05.2011 16:12, david447 wrote:

> So I tried to shift my output with 32 bits (with 48 bits in all stages).
> Obiouvsly, the results are :
> 0000000000001000
> 0000000000001001
> 0000000000000001
>
> And zero before and after.
>
> According to what I said previously, with the highest value at the output,
> I have many zeros in the MSBs, so when I truncate like here, I have
> nothing...
>
There might be a bug in your VHDL code, since, as was mentioned before, 
the output should be much greater when a full-scale impulse is applied 
to the CIC input. Can you post the code on some file sharing engine?


-- 

Alexander

>On 30.05.2011 16:12, david447 wrote:
>
>> So I tried to shift my output with 32 bits (with 48 bits in all
stages).
>> Obiouvsly, the results are :
>> 0000000000001000
>> 0000000000001001
>> 0000000000000001
>>
>> And zero before and after.
>>
>> According to what I said previously, with the highest value at the
output,
>> I have many zeros in the MSBs, so when I truncate like here, I have
>> nothing...
>>
>There might be a bug in your VHDL code, since, as was mentioned before, 
>the output should be much greater when a full-scale impulse is applied 
>to the CIC input. Can you post the code on some file sharing engine?
>
>
>-- 
>
>Alexander
>

Hello,

CIC parameters :
Stages : 6;
Decimation : 40;
Delay : 1;
Bin = 16;
Bout = 48 (= Bmax)


Some part of my VHDL code :
http://www.4shared.com/document/14tgWFXY/cic.html


Thank you for your help!

David.

I am sorry, I forgot to add this information :

I5 signal uses all of the 48 bits.
C0, C1 and C2 too.
But, from C3, all of the 48 bits are not used.
Indeed :
C3 : bits 44 to 47 never used (equal to zero);
C4 : bits 37 to 47;
C5 : bits 36 to 47.

So I was thinking that I have to prunne the MSB of my comb signals, instead
of the LSB.
What do you think about that ?

Thank you,

David.

Hello David,
Sorry for misleading you. Your pulse response might be OK because with 
the decimation ratio of 40 the filter suppresses much of the pulse 
spectrum contents. That's why so many MSBs are constant in the pulse 
response. If you sum the pulse response samples you'll get a number that 
is roughly 40 times lower than the maximum value in 48-bit signed format.

> I am sorry, I forgot to add this information :
>
> I5 signal uses all of the 48 bits.
> C0, C1 and C2 too.
> But, from C3, all of the 48 bits are not used.
> Indeed :
> C3 : bits 44 to 47 never used (equal to zero);
> C4 : bits 37 to 47;
> C5 : bits 36 to 47.


> So I was thinking that I have to prunne the MSB of my comb signals, instead
> of the LSB.
> What do you think about that ?

You can't do that. Apply a step function or a full-scale low frequency 
sinewave instead of a unity length pulse and you'll see all the bits 
changing at the filter output.


PS: Your code looks a bit strange. Firstly, it contains description of 5 
stages instead of 6. The value that you latch in the decimation process 
is also strange. And, finally, why do you convert the output of the last 
comb to the unsigned?

-- 

Alexander

>Hello David,
>Sorry for misleading you. Your pulse response might be OK because with 
>the decimation ratio of 40 the filter suppresses much of the pulse 
>spectrum contents. That's why so many MSBs are constant in the pulse 
>response. If you sum the pulse response samples you'll get a number that 
>is roughly 40 times lower than the maximum value in 48-bit signed format.
>
>> I am sorry, I forgot to add this information :
>>
>> I5 signal uses all of the 48 bits.
>> C0, C1 and C2 too.
>> But, from C3, all of the 48 bits are not used.
>> Indeed :
>> C3 : bits 44 to 47 never used (equal to zero);
>> C4 : bits 37 to 47;
>> C5 : bits 36 to 47.
>
>
>> So I was thinking that I have to prunne the MSB of my comb signals,
instead
>> of the LSB.
>> What do you think about that ?
>
>You can't do that. Apply a step function or a full-scale low frequency 
>sinewave instead of a unity length pulse and you'll see all the bits 
>changing at the filter output.
>
>
>PS: Your code looks a bit strange. Firstly, it contains description of 5 
>stages instead of 6. The value that you latch in the decimation process 
>is also strange. And, finally, why do you convert the output of the last 
>comb to the unsigned?
>
>-- 
>

Hello,

Thank you for your response.

I have modified my VHDL code like this :

http://www.4shared.com/document/qA5bIIAF/cic.html?

I changed the first integrator part as follows :
I0 = I0 + data_in
(instead of I0 = data_in)

Than, I suppressed the C0 signal, and I grab the last integrator signal
directly (in the Comb process) :
CD0 = I5 et C1 = I5 - CD0

Then, you were right, I made a mistake so I add a comb part :
C6 = C5 - CD5

Now, I have this result (always in 48 bits) :
000000000000001111010100010100110101011101001010
000000001000101000010101011000101101001100010010
000000011010100111100111111000100010100110010100
000000001100101011110011001100000001011001110100
000000000000101001110101000110100001010110100010
000000000000000000000000000000101111111111111010 

So now, I can try to prune the output to 16 bits, but I'm afraid that I'll
loss a lot of information.

So, I improved my code, and I add the pruning theory :
The problem is the same :

0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000110
0000000100000100
0000001101001100
0000000110100110
0000000000010110
0000000000000000
1111111111111111
0000000000000000
1111111111111111
0000000000000000
0000000000000000
1111111111111111
0000000000000000
1111111111111111
0000000000000000
etc.

So I think that I just have to discard 32 bits at the output...and fortget
the pruning theory.

Here is my complete code :
http://www.4shared.com/document/N0OJI3sV/cic2.html

> So, I improved my code, and I add the pruning theory :
> The problem is the same :
>
> 0000000000000000
> 0000000000000000
> 0000000000000000
> 0000000000000000
> 0000000000000000
> 0000000000000000
> 0000000000000110
> 0000000100000100
> 0000001101001100
> 0000000110100110
> 0000000000010110
> 0000000000000000
> 1111111111111111
> 0000000000000000
> 1111111111111111
> 0000000000000000
> 0000000000000000
> 1111111111111111
> 0000000000000000
> 1111111111111111
> 0000000000000000
> etc.
>


As i wrote in one of the previous posts, it is most likely happens due 
to additional noise introduced by pruning LSBs in integrator stages (i'm 
not absolutely sure, since i have never gone so deep into pruning 
theory). This noise causes least significant bits to change even when 
actual pulse response duration ends because of accumulation of errors in 
integrators. Assuming properly chosen lengths of individual stages the 
peak-to-peak noise shall not exceed minimum value representable in the 
desired output data format - that's the ultimate goal of pruning. But as 
the noise is bipolar and truncation is used in both integrator and comb 
stages the negative values of noise are converted to a minimum negative 
value (all ones in signed fixed-point format). If you use true rounding 
to nearest instead of truncation at the output of the last comb stage 
then you are likely to get what you want to see. Sorry if i was unclear 
in my description - english is not my mother tongue and my language 
skills are not so good for writing such long passages :(

As for the loss of information... yes you are going to lose something 
(though not much, because your input data are 16-bit wide) due to 
reduction of the output wordlenth, no matter if you simply truncate the 
output or use pruning in the intermediate stages of the filter. But if 
further processing stages in your system can work with 16-bit data only 
the loss of precision in the CIC filter output shouldn't bother you that 
much.

-- 

Alexander