> 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

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

>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.

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

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.

>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.

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 5/26/2011 6:24 AM, david447 wrote:
>> I forgot to specify that, my impulse response is equal to
>> 0111111111111111, during on clock period.
>>
>> The output of the CIC, when I use 48 bits, is equal to (clock divided
by
>> 40):
>>
>> 000000000000000010010000001010100101111110101001
>> 000000000000100000010001000100101101110110111010
>> 000000000000100111000011101001100111100010001100
>> 000000000000000100100010111100101011101000010110
>> 000000000000000000000000000000100111111111111011
>>
>> Before it is equal to zero, and after too.
>>
>> It seems there is a problem because the input 011...111 is the highest
>> value in 2's complement form, and there are many MSB bits equal to zero
at
>> the output.
>
>If the gain of the filter is 40^6.  If you take 32767*40^6 = 
>134213632000000L in binary, 
>'0b_01111010_00010001_00001011_11011100_00000000_00000000'.
>
>I don't think the density of 0s is a good metric.
>
>Your third output is, 41937172620L, which is ~3200 times smaller than it 
>should be?
>
><Python snip for the above numbers>
>In [3]: x = int("0111111111111111",2)
>In [4]: y = x * 40**6
>In [5]: y
>Out[5]: 134213632000000L
>In [6]: bin(y)
>Out[6]: '0b11110100001000100001011110111000000000000000000'
>In [7]: out = int("000000000000100111000011101001100111100010001100", 2)
>In [8]: out
>Out[8]: 41937172620L
>In [9]: float(y)/out
>Out[9]: 3200.3500382854377
>
>Chris
>
>
>

Hello,

Thanks again for your help.

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...

On 5/26/2011 6:24 AM, david447 wrote:
> I forgot to specify that, my impulse response is equal to
> 0111111111111111, during on clock period.
>
> The output of the CIC, when I use 48 bits, is equal to (clock divided by
> 40):
>
> 000000000000000010010000001010100101111110101001
> 000000000000100000010001000100101101110110111010
> 000000000000100111000011101001100111100010001100
> 000000000000000100100010111100101011101000010110
> 000000000000000000000000000000100111111111111011
>
> Before it is equal to zero, and after too.
>
> It seems there is a problem because the input 011...111 is the highest
> value in 2's complement form, and there are many MSB bits equal to zero at
> the output.

If the gain of the filter is 40^6.  If you take 32767*40^6 = 
134213632000000L in binary, 
'0b_01111010_00010001_00001011_11011100_00000000_00000000'.

I don't think the density of 0s is a good metric.

Your third output is, 41937172620L, which is ~3200 times smaller than it 
should be?

<Python snip for the above numbers>
In [3]: x = int("0111111111111111",2)
In [4]: y = x * 40**6
In [5]: y
Out[5]: 134213632000000L
In [6]: bin(y)
Out[6]: '0b11110100001000100001011110111000000000000000000'
In [7]: out = int("000000000000100111000011101001100111100010001100", 2)
In [8]: out
Out[8]: 41937172620L
In [9]: float(y)/out
Out[9]: 3200.3500382854377

Chris

<snip>
>> Another test you can do to help shed some light, is simply remove the
>> gain of the CIC before sending to the FIR.  The gain of your CIC is
>> (R*D)^S = 40^6 = 4.096e9 (unfortunate it is not a power of 2 :)).  For
>> test purpose, you should be able to remove the gain and get back to a
>> 16bit number, if you right shift by 32 you will have a little less than
>> unity gain but you will be in the 16bit range.
>
> So, if I understand well, I have to shift the output by 32 bits, without
> any truncation during the CIC process ?
>
Yes that is a valid approach.  Note, because your gain is not a power of 
two you will be over compensating.  You will have something less than 
0dB at 0Hz.

>> Why is your first comb section only 22bits?  I believe it needs to match
>> the size of the last integrator (to undo the wrapping).
>
> I tried to put 22bits to the last integrator and the first comb, but the
> problem is the same.
>
I didn't crunch the numbers but I would think the comb should be 24. 
Promote the comb to the size of the integrator not the other way around.

Chris