Farrow decimator

Hi,
I'm trying to build a decimating Farrow filter and facing a problem with 
transition from an ideal Simulink model to the model which would be 
closer to actual hardware implementation.  The examples that are 
supplied with MATLAB/Simulink use the Sample Rate Conversion block so 
that the input delay line in the Farrow filter operates at the input 
data rate and the rest of the filter operates at the output data rate. 
I've tried to modify the examples and come up with a solution where the 
whole filter operates in the input clock domain, but the taps of the 
delay line are latched with a set of registers using an irregular clock 
(the frequency of the irregular clock is roughly equal to the desired 
output clock rate). This irregular clock is generated by an accumulator, 
which is loaded with the value equal to Fs_out/Fs_in. The same irregular 
clock drives  a fractional delay generator, which is implemented as a 
binary counter with some additional logic, and is also used to store 
data into a FIFO buffer that provides synchronization between input and 
output clock domains (both input and output clock signals in the system 
will be generated by the same fractional-N PLL). In order to make my 
description clearer i posted a simplified block-diagram of the model here:
http://imageshack.us/photo/my-images/143/forcompdsp.png/

The model works fine when floating point representation of the modulo 
values in counter and mu generator are used. But when i change the data 
format to fixed-point the model starts crashing down after some time 
(the length of time that the model operates as intended the data 
wordlength) even though i make some attempts to mitigate effects of 
finite word length representation inside of the counters. I guess that 
it happens due to the fact that the two counters are used. I have 
already used Farrow resamplers in previous designs, but they were all 
interpolators and utilized a single counter for both enable signal and 
fractional delay values generation, so i didn't have problems like this 
one.
I'd really appreciate if someone could tell me what is wrong with my 
model or pointed me to an example of correct implementation of such a 
system.


-- 
Alexander

A little update

> (the length of time that the model operates as intended the data wordlength)

should read as
(the length of time that the model operates as intended depends on the 
data wordlength)
i.e when i use 20 bits for representation of Fs_out/Fs_in and 
mod((Fs_in/Fs_out),1) the model works without errors for a longer time 
than when i use 16-bit values.

-- 

Alexander

>A little update
>
>> (the length of time that the model operates as intended the data
wordlength)
>
>should read as
>(the length of time that the model operates as intended depends on the 
>data wordlength)
>i.e when i use 20 bits for representation of Fs_out/Fs_in and 
>mod((Fs_in/Fs_out),1) the model works without errors for a longer time 
>than when i use 16-bit values.

A Farrow structure is FIR based. It doesn't really have a way to degrade
over time, like many IIR structures do. Sounds like you have a bug, rather
than an algorthmic problem.

Steve

Hi Steve,
When i was writing about wordlength i meant not the Farrow filter
coefficients, but the words written to the counters that are used to
generate the clock enable and the current value of mu (fractional delay).
The problem with quantization of the value loaded to the counter also
exists in the case of an interpolating Farrow filter, since, in general,
due to finite wordlength representation in hardware the output sampling
frequency clock that must be generated in the input sampling rate clock
domain is either a bit higher or a bit lower than desired. However when the
wordlength is big enough the effects of counter modulus quantization show
up long after the resampler starts operating.
When doing Farrow inperpolator designs i used a FIFO buffer at the Farrow
filter input and a single counter working in the input sampling rate clock
domain, which generated both current value of mu and a FIFO write enable
signal. In order to mitigate the effect of counter modulus finite
wordlength i constantly monitored the number of words in the FIFO and
either added one LSB to or subtracted one LSB from the counter modulus
depending or whether the FIFO is more than half full or not. I admit that
this solution might be not the most elegant one, but it works.
Now i have two counters in the decimating Farrow resampler - the one is
used to generate an enable signal, whose  frequency is on the average equal
to the output sampling rate, in the input sampling rate clock domain and
the other is used to generate the current value of mu. The first counter is
loaded with Fs_out/Fs_in. The second one is loaded with
mod(Fs_in/Fs_out,1). And i can't make them work synchronously when the
fixed-point data formats are used (however, the whole system works fine
with double floating precision of the counter modulus values). So i guess
that something is wrong in the way i'm trying to build the synchronization
system and i hoped that somebody in the newsgroup would advise me or point
to an example. So far i've seen a lot of information on interpolating
resamplers design. The only example of the decimating resampler that i've
met was the AppNote from Altera but it is limited to the input and output
sampling rates that are both integer divisors of the FPGA master clock.

Alexander

Alexander

Use one  NCO  to  control  the interpolator.  Use FIFO pointer to control
this NCO.

On 31.05.2011 10:51, Alexander Petrov wrote:
> Alexander
>
> Use one  NCO  to  control  the interpolator.  Use FIFO pointer to control
> this NCO.
>
>
>

Hi Alexander,
Do you mean that i have to use a single NCO that counts in increments of 
(Fs_in/Fs_out)/ceil(Fs_in/Fs_out) and wraps every time it gets equal or 
greater than Fs_in/Fs_out? This is the only choice i can think of  now 
where the same counter can be used for getting both mu values and FIFO 
write enable. I tried to avoid this because a comparator is used inside 
of the accumulator loop and the data width required to represent current 
value of the counter is increasing. Or maybe there is some other way?

-- 

Alexander

The following link may help, look at page 3 describing how to compute M for
decimating farrow:

http://www.altera.com.cn/literature/an/an347.pdf

Kadhiem

>I tried to avoid this because a comparator is used inside 
>of the accumulator loop and the data width required to represent current 
>value of the counter is increasing. Or maybe there is some other way?
>
>-- 
>
Think better  hardware  architecture. accumulator - mod 2^N adder, enable -
MSB or carry out, mu - adder out most significant  few  bits, etc.

Hi Alexander,
> Think better  hardware  architecture. accumulator - mod 2^N adder, enable -
> MSB or carry out, mu - adder out most significant  few  bits, etc.

What you describe works well for an interpolator. But as i do a 
decimator things get a bit more complicated or, at least, it seems to me 
that they do. Assume that the input sampling rate, Fs_in, is 24e6 and 
the output sampling rate, Fs_out, is 10e6.
I build an NCO in the Fs_in clock domain, which is incremented by 
10/24th in each cycle, and  use its MSB as an irregular clock. Then i 
derive a FIFO write enable (WE) signal by detecting rising edges of this 
irregular clock (i also use this signal to enable operation of the most 
part of the Farrow filter except the input data delay line, which runs 
at Fs_in).
As i do decimation by 2.4 i have to supply (synchronously with the FIFO 
WE signal) the following fraction delay values :
0
1 - mod(2.4,1) = 0.6
1 - mod(4.8,1) = 0.2
1 - mod(7.2,1) = 0.8
and so on...
And i can't derive these values from the NCO that is used to generate 
FIFO WE  ... or maybe have taken the wrong path and have to build the 
system in some other way.


-- 

Alexander

On 31.05.2011 15:15, kaz wrote:
> The following link may help, look at page 3 describing how to compute M for
> decimating farrow:
>
> http://www.altera.com.cn/literature/an/an347.pdf
>
> Kadhiem
Thanks
I have already seen this paper, but decided to use the algorithm of mu 
generation described here:
http://www.altera.com/literature/an/an623.pdf
If i fail to make my model work i'll try the approach suggested in 
AN347, but the first impression is that i'm going to face the similar 
problem.

-- 

Alexander