Mismatch between Xilinx FIR interpolation filter

B

Benjamin Couillard

Guest
Hi everyone,

I'm currently using a design with a 5 /4 interpolation Filter used to
convert a signal sampled @ 80 MHz to 100 MHz. The Interpolation filter
is designed using FIR compiler 3.2 (ISE 10) and implemented on a
Virtex 5 FPGA. The problem is present in simulation too.

For this purpose we have used a 33-tap filter. The filter works well
however there is an implementation difference between Matlab and the
Xilinx core. I used a step response to characterize both systems and I
obtain slightly different results. There is a slight phase delay
between the Matlab implementation (with upfirdn function) and the
interpolation FIR filter compiled with FIR Compiler 3.2.

I have run some tests to understand better the problem and it seems to
be related with the decimation process. Let me explain :

Assuming

X : original signal sampled @ 80 MHz

X_up : signal stuffed with 4 zeros for every sample @ 400 MHz (only
used for explanation purposes)

Y : X_up filtered by our 33-tap FIR filter @ 400 MHz

Z : Decimated version of Y Signal @ 100 MHz

X = X0, X1, X2, X3,... Xn, ... Xm,...

The complete resampling process would look like this

X_up = X0,0,0,0,X1,0,0,0,0,X2,0,0,0,0,X3,0,0,0,0,X4,0,0,0,0,....,Xn,
0,0,0,0,....

Then X_up is filtered by the FIR filter to obtain the "Y signal".

Y = Y0, Y1, Y2, Y3, Y4,, Y5, Y6, Y7, Y8 .... @ 400 MHz

By decimating by 4, we take only 1 sample out of 4. However it seems
that Matlab and Xilinx do not take the same sample

In Matlab, with the upfirdn function, I obtain the following results

Z_matlab = Y0, Y4, Y8, Y12, ... @ 100 MHz

Z_xilinx = Y1, Y5, Y9, Y13,... @ 100 MHz.

Basically, the Xilinx output signal is shifted by one sample @ 400
MHz, or one quarter of a sample @ 100 MHz. Am I the only one that got
this problem? Is there a way to control the decimation process by
selecting which sample out of N is selected? This is an important
issue since the decimation process influences the phase of the signal.


I am also aware that with the polyphase implementation, the
implementation does not compute all samples in the Y sequence @ 400
MHz, I only added these intermediate signals to be clearer.

Thanks

Benjamin Couillard
 
On 24 Aug, 16:20, Benjamin Couillard <benjamin.couill...@gmail.com>
wrote:
Hi everyone,

I'm currently using a design with a 5 /4 interpolation Filter used to
convert a signal sampled @ 80 MHz to 100 MHz. The Interpolation filter
is designed using FIR compiler 3.2 (ISE 10) and implemented on a
Virtex 5 FPGA. The problem is present in simulation too.

For this purpose we have used a 33-tap filter. The filter works well
however there is an implementation difference between Matlab and the
Xilinx core. I used a step response to characterize both systems and I
obtain slightly different results. There is a slight phase delay
between the Matlab implementation (with upfirdn function) and the
interpolation FIR filter compiled with FIR Compiler 3.2.

I have run some tests to understand better the problem and it seems to
be related with the decimation process. Let me explain :

Assuming

X : original signal sampled @ 80 MHz

X_up : signal stuffed with 4 zeros for every sample @ 400 MHz (only
used for explanation purposes)

Y : X_up filtered by our 33-tap FIR filter @ 400 MHz

Z : Decimated version of Y Signal @ 100 MHz

X = X0, X1, X2, X3,... Xn, ... Xm,...

The complete resampling process would look like this

X_up = X0,0,0,0,X1,0,0,0,0,X2,0,0,0,0,X3,0,0,0,0,X4,0,0,0,0,....,Xn,
0,0,0,0,....

Then X_up is filtered by the FIR filter to obtain the "Y signal".

Y = Y0, Y1, Y2, Y3, Y4,, Y5, Y6, Y7, Y8 .... @ 400 MHz

By decimating by 4, we take only 1 sample out of 4. However it seems
that Matlab and Xilinx do not take the same sample

In Matlab, with the upfirdn function, I obtain the following results

Z_matlab = Y0, Y4, Y8, Y12, ... @ 100 MHz

Z_xilinx = Y1, Y5, Y9, Y13,... @ 100 MHz.

Basically, the Xilinx output signal is shifted by one sample @ 400
MHz, or one quarter of a sample @ 100 MHz. Am I the only one that got
this problem? Is there a way to control the decimation process by
selecting which sample out of N is selected? This is an important
issue since the decimation process influences the phase of the signal.

I am also aware that with the polyphase implementation, the
implementation does not compute all samples in the Y sequence @ 400
MHz, I only added these intermediate signals to be clearer.

Thanks

Benjamin Couillard
You have my sympathy, it's not easy dealing with undocumented or
"optimized" features. Getting the correct output phase from
polyphase filters are usually not covered in text books.
Let's assume the filter consists of five banks of coefficients,
controlled by an modulo-5 commutator, which is incremented
in steps of 4. Each time the commutator rolls over we clock
in a new input sample. To explain what you see we must
assume the commutator starts with the value 1 (and not 0 as
it should).

So we have
Five polyphases: H0, H1, H2, H3, H4
H0 = h[0], h[5] ...
H1 = h[1], h[6] ...
H2 = h[2], h[7] ...
etc

Normally h[0]*x[0] is the first output from a filter.
If I understand correctly your first output is
h[1]*x[0] = y[1]

You need:
x[n], n: 0012344567889
H_ix: 0432104321043 ; starting in H0: y[0], y[4], y[8] etc

You have:
x[n], n: 0112345567899
H_ix: 1043210432104 ; starting in H1: y[1], y[5], y[9] etc

Fix/suggestion: insert 1 zero sample, "*", and skip its output
y[*].
x[n], n: *001234456788
H_ix: 1043210432104 ; starting in H1: y[*], y[0], y[4], etc

The dummy sample will align/sync the commutator to the y[0]-sequence.

Best rgds
 

Welcome to EDABoard.com

Sponsor

Back
Top