Altera FFT Vs Matlab FFT. Strange Results

I suggest you to use a simpler source signal in order to debug better. Many sources of problems may be hidden here.

Use a single- or multi-tone test signal to compare the results.

That should be easier to analyze.

Already done.

My design has 3 IP cores: two FFT and one IFFT. One FFT has as input the pseudorandom code; the second fft some bpsk signals. After some products in frequency domain i come back in time domain to check data messages. Using a Lut instead of the FFT (with the matlab ffts with 12 bit fixed points) for the pseudorandom codes every things is ok. If i replace the LUT with the FFT from Altera for the pseudoradom codes the results are not correct. The second FFT and the IFFT are Altera IP FFT cores and work perfectly. The problem is the FFT for this particular input (only {-1,1}).

An independent design check comes from the matlab test bench after generating the core (page 2-16 FFT MegaCore function V8.0 User Guide).

Thanks

After plotting

>> plot(real(ifft(out_Altera)))

>> plot(imag(ifft(out_Altera)))

it is evident that the imaginary part of the IFFT (which should be zero everywhere) is considerably different from zero.

Also I tried to understand what kind of disturbance is imposed over the ideal result by:

>> plot(abs(out_Altera./out_Matlab))

or

>> plot(log10(abs(out_Altera))-log10(abs(out_Matlab)))

if you prefer the log diagram.

It is difficult to check the problem with this kind of pseudo-random signal, try to build a periodic signal (square wave, etc.) by using only +1 and -1 at the input and check the output. It should be easier to analyze.

I have several suggestions and also want to point out that it is not quite fair to compare Altera's FFT to Matlab's FFT.

First of all, Matlab's FFT implementation (the fft function) is actually a floating point DFT implementation- and we don't really have control over twiddle precision within the fft function. So that wouldn't exactly be a fair comparison...

Also one thing I found about Altera's FFT core (especially with the older architectures that utilize block floating point representation: i.e. streaming, burst and buffered burst), it is best if you scale up your data (so you are using all of the dynamic range). I presume it is due to the block floating point structure (the data is scaled after each stage of butterfly... therefore if you are not using enough precision, it is very possible that your data would completely disappear somewhere within the FFT core).

Please see my attached .zip file for detail. In the zip file, you will find three files:

- in.mat (this is your original input)

- FFT_Altera_model.m -> this is the bit-accurate matlab simulation model generated by Altera's FFT megacore, version 8.0 (here I am using a streaming FFT core)

- FFT_Altera_tb.m -> this is my testbench comparing Altera's result with matlab fft's result (using your input)...

Two things to note:

1. By scaling up the input prior to Altera's fft function and then scaling the output back, we see that Altera's fft generates similar output to matlab's fft function. The bigger the data and twiddle resolution, the smaller the difference between Altera's and Matlab's fft spectrum. The difference can be attribute to the fact that Matlab uses floating point representation.

2. Also your Altera's fft output is really = data_out*2^(-exp_out) -> see appendix in FFT UG. Did you remember to do this?

3. Without properly scaling the input data prior to Altera's fft function.... the difference is pretty big.... I imagine this is what you're seeing...

Also if you are using the FFT core, you do need to pay attention to the sink_ready signal... make sure you don't input data while sink_ready is low... That gave me some trouble before...

Anyhow, hope this helps...

Thanks for the support. After some studies of the block floating point engine I have found the right way to use it. Now I obtain only quantization error with zero mean value ad a deviation <1. Perfect.

Gabriele

Two possible errors:

1. You are inputting data to the FFT core when it isn't ready. You should really wait for sink_ready signal to be asserted.

2. You are using a streaming FFT (I can't tell) and that you are not using the full dynamic range for the input. As I explained in the earlier note (from the same threat), you should really use full dynamic range. Otherwise, it is possible that your input would disappear within the core (due to the block floating point -> data is rounded and truncated after each butterfly stage).

Also... attach a bigger picture, so people can see what you're doing...

Hi to all,

I'm testing FFT core v8.1 with Quartus Simulator and the output is always 0. I attach a image of my input signals.

http://www.alteraforum.com/forum/C:%5CUsers%5CDuarte%20Carona%5CDesktop%5CSimulator.jpg

Thank you.

Duarte Carona