FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6486 Discussions

FFT Megafunction problem - strange spikes

Altera_Forum
Honored Contributor II
1,674 Views

Hi, I use FFT IP Core (Quartus 9.1 SP2 / Quartus 11.1 SP2). I send sine-signal to sink pins and get fft-signal from source pins of core. 

Then I plot ABS, real and imag of my fft-signal in Matlab. 

 

Figure 1 shows that there is strange spikes at fft-signal. 

 

When I move phase of sine-signal, figure changes. This show at figure 2. 

 

What is it? How to find out the solution of the problem? 

Help me please! 

 

PS: sorry for my english-)
0 Kudos
10 Replies
Altera_Forum
Honored Contributor II
571 Views

It is likely to be harmonics of your tone. A harmonic occurs if your tone correlates with sampling frequency(integer relation). It is basically quantisation noise concentrated in certain frequencies. As such it is normal but you need to see how far in dBs are they down from signal level

0 Kudos
Altera_Forum
Honored Contributor II
571 Views

I do not use a real signal (from ADC). I use "ideal" sine generated at Matlab: 

signal 1: 

for i=1:128;  

ss(i) = Amp*sin(pi/100+pi*i/4); 

end 

 

signal 2: 

for i=1:128; 

ss(i) = Amp*sin(pi/10+pi*i/4); 

end. 

 

I put this signal (ram_in.hex) to In-System Memory Content Editor and then send to FFT core. Then I get signal from FFT core and save to ram. Then I get ram_out.hex from In-System Memory Content Editor and put to Matlab.
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

In any case your fpga fft result must match fft matlab 

But if you compare to Matlab fft you must also quantise the input and output in matlab in order to model FPGA. 

 

your vector is too short to judge. Moreover your cycles are not complete. The vector is better to have full sine cycles. 

 

So the spikes may be due to truncation. 

 

You don't need to think of real ADC signal. The same rule applies to any vector that is equivalent to what ADC will give you
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

> 20% THD and a similar DC component can't be explainced by a small deviation from full cycle. The FFT input signal must be seriously distorted somehow. Did you monitor the actual FFT input stream?

0 Kudos
Altera_Forum
Honored Contributor II
571 Views

Oh, I forgot to write settings of my FFT Core: 

Variable-Streaming, 

Floating-Point, 

2048 points (and I try any others variants - 128 points, 1024 points), 

Input Order - Natural Order, 

Output Order - Digit Reverse Order 

 

 

--- Quote Start ---  

In any case your fpga fft result must match fft matlab 

But if you compare to Matlab fft you must also quantise the input and output in matlab in order to model FPGA. 

 

your vector is too short to judge. Moreover your cycles are not complete. The vector is better to have full sine cycles. 

 

So the spikes may be due to truncation. 

 

You don't need to think of real ADC signal. The same rule applies to any vector that is equivalent to what ADC will give you 

--- Quote End ---  

 

 

 

--- Quote Start ---  

In any case your fpga fft result must match fft matlab 

--- Quote End ---  

Yes, I want that. 

 

--- Quote Start ---  

Moreover your cycles are not complete 

--- Quote End ---  

It is not true. My cycles are full complete! 

 

--- Quote Start ---  

The vector is better to have full sine cycles. 

--- Quote End ---  

It is not true. The vector have full sine cycles! 128 points = 16 sine cycles. 

 

 

--- Quote Start ---  

> 20% THD and a similar DC component can't be explainced by a small deviation from full cycle. The FFT input signal must be seriously distorted somehow. Did you monitor the actual FFT input stream? 

--- Quote End ---  

 

 

 

--- Quote Start ---  

Did you monitor the actual FFT input stream? 

--- Quote End ---  

Yes, I check FFT input stream (fft:fft_inst|sink_real at signal tap) - it is equivalent to data at matlab. 

 

This is my new experiment: 

1 sine cycle = 2048 points. 

Figure 1 - sine of phase 0 degrees, ABS(FFT), real(fft), imag(fft) - there is spikes 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6137  

Figure 2 - sine of phase 0 degrees, real( matlab_ifft ( fpga_fft )), imag( matlab_ifft ( fpga_fft )) - there is spikes 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6138  

 

Figure 3 - sine of phase 10 degrees, ABS(FFT), real(fft), imag(fft) - there is not spikes 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6139  

Figure 4 - sine of phase 10 degrees, real( matlab_ifft ( fpga_fft )), imag( matlab_ifft ( fpga_fft )) - there is not spikes 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6140  

 

This is my matlab file:https://www.alteraforum.com/forum/attachment.php?attachmentid=6142
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

And my vhdl source code of myfft: 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6143  

 

have any ideas? I think Altera FFT Core is wrong:(
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

I am still trying to understand your problem. Is it both matlab and fpga showing same problems or just fpga. I can see your spikes are very low pointing to some quantisation issues.  

 

Yes you are right your cycles are complete, sorry. Also try better bitwidth resolution, you are only using max value of 256. 

 

can you also focus on differences of real and imag between fpga and matlab and not the abs of fft since you are adding further processing. 

In your matlab program you are rounding x but you are not rounding fft result.
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

When you compare Matlab fft with fpga fft you should quantise Matlab model in a way similar to fpga.  

 

fft inputs: you need to input into Matlab and fpga the same quantised input and that is what you are doing I believe.  

 

fft outputs: Similarly you need to compare like by like i.e. quantised Matlab fft output with fpga fft output. Moreover, you better check real and imaginary outputs rather than abs() since this adds further processing.  

Then you and we can come to some better idea what the error is. If yoy then have fpga spikes then they should be +/- few integer values for a quantised range. Let us know...
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

 

--- Quote Start ---  

When you compare Matlab fft with fpga fft you should quantise Matlab model in a way similar to fpga.  

 

fft inputs: you need to input into Matlab and fpga the same quantised input and that is what you are doing I believe.  

 

fft outputs: Similarly you need to compare like by like i.e. quantised Matlab fft output with fpga fft output. Moreover, you better check real and imaginary outputs rather than abs() since this adds further processing.  

Then you and we can come to some better idea what the error is. If yoy then have fpga spikes then they should be +/- few integer values for a quantised range. Let us know... 

--- Quote End ---  

 

 

1. Kaz, what do you interpret as "quantised fft output"? I do not understand this. Can you show this as matlab code, please? 

 

2. Do you see attached files? I understand, that results of matlab and fpga can differ in few range. But I see difference in large range. Example this: 

 

--- Quote Start ---  

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6155  

--- Quote End ---  

 

 

 

Thank you for help and sorry for my english.
0 Kudos
Altera_Forum
Honored Contributor II
571 Views

I haven't looked at all your results but this last one indicate your fft is badly different from Matlab. 

 

Anyway at this point I can only advise on how to compare to Matlab fft: 

 

x = round(2048*sin(2*pi*(0:2047)/2048)); %full sine, zero phase 

y = round(fft(x)); 

plot(real(y)); 

plot(imag(y)); 

 

Your fpga output should be comparable to y assuming fpga uses rounding as opposed to direct truncation. 

 

Moreover there might be issue of scaling differences between fpga fft core and matlab(you should have noticed that if any). 

 

Notice that the term(0:2047) determine phase and have big effect on result, try (1:2048) and all changes. 

 

So I come to believe you might have something wrong with your fft control logic apart from the minor rounding issue.
0 Kudos
Reply