There are 2 messages in this thread.
You are currently looking at messages 0 to 2.
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