Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Community Forums
- :
- Forums
- :
- Hardware Development
- :
- AI Engine, DSP IP and Tools
- :
- Strange xfft Core Output

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted
##

edoutthere

Observer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-12-2017 11:05 AM - edited 12-12-2017 11:07 AM

1,671 Views

Registered:
07-24-2017

Strange xfft Core Output

Folks,

I am seeing an unexplainable result from the FFT core.

Settings:

FFT V9.0

65k points

pipelined streaming

16-bit input and output

output is natural order

XK index is output

Vivado 2015.2 Win7 64

VHDL host language

I created a test project to hold the generated testbench file

I instrumented the tb with code to save off the generated data and the output of the fft

hooked into the op_data that is saved from the m_axis_data_tdata

The tb runs and I can reliably graph the input signal and output results in matlab

The first thing I noticed is that the results come out at the end of the output vector, that is, DC is at index 65535, and the spikes for the increasing frequencies have indices less than 65k. The "second half" of the output vector, reverse order. I generate a 1000Hz signal and the index of its spike is 64535 - sounds plausible.

When I run the fft() in matlab on the TB generated input data, I get DC at index 0 and the test frequencies at positive indices from zero. There is a mirror image of this starting at 32768, continuing to DC at 65536.

What I read on the xilinx forums is that the core should work like matlab, FFTW, etc. (with natural order output)

Any explanations?

Issue #2:

If I generate a signal of 40000Hz in the TB:

theta2 := real(i) / real(MAX_SAMPLES) * 40000 * 2.0 * MATH_PI;

This shows up at the index that would be 40000, instead of wrapping around like it does in matlab. If I take the generated signal data from the TB and do a FFT on it in matlab, I get what I expect.

I have attached a screen shot from the simulator. Note the xk index where the cursor is, this is the "40000Hz" spike. The input data has 1000Hz, 30000Hz, 31000Hz, 32000Hz signals in it. (xfft_output_with_40k_sim.png)

There is a screen shot of the output from matlab plot() Fn of the same output data, "fft core output". (xfft_output_with_40k.png)

There is a screen shot of the input data processed with the matlab FFT, "input data spectrum". (input_data_matlab_fft.png)

Is there a reasonable explanation for issue 2?

Thanks,

Ed

4 Replies

Highlighted
##

austin

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-12-2017 11:22 AM

1,659 Views

Registered:
02-27-2008

Recall,

That in MatLab everything is perfect, and aligned.

In the real world, signals are continuous, so depending on where you start and end, the resulting spectrum will have artifacts as a result of that.

Austin Lesea

Principal Engineer

Xilinx San Jose

Principal Engineer

Xilinx San Jose

Highlighted
##

balkris

Xilinx Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-12-2017 08:10 PM

1,628 Views

Registered:
08-01-2008

FFT IP results are correct as well. The ** fft** function returns a vector that

Hope it make sense for you

Thanks and Regards

Balkrishan

--------------------------------------------------------------------------------------------

Please mark the post as an answer "Accept as solution" in case it helped resolve your query.

Give kudos in case a post in case it guided to the solution.

Balkrishan

--------------------------------------------------------------------------------------------

Please mark the post as an answer "Accept as solution" in case it helped resolve your query.

Give kudos in case a post in case it guided to the solution.

Highlighted
##

edoutthere

Observer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-13-2017 06:31 AM

1,616 Views

Registered:
07-24-2017

Thanks for the responses! To clarify, in the TB, there is no "sampling frequency" so the first "bin" should correspond to 1/32768Hz. I assigned Hz to these to establish a baseline of understanding. In the matlab scripts I use, there is a sampling_freq variable because in its real-world use, the samples it FFTs come from ADCs, etc. Using Hz also lets us use nyquist of 1/2 MAX_SAMPLES, in this case 32767Hz.

Given that, when the TB generates a sample buffer, the math establishes the max freq that can be resolved. To test this, I ran the TB with both 30000Hz and 40000Hz signals. Look at the results I attached. The first one is 30000Hz. Notice that the signal goes from + value to -value from sample to sample (the .im is not expanded). I expect this when the nyquist is 32767Hz. Then take a look at the second image. This is 40000Hz, notice it is an undersampled mess. Totally expected. This should show up in the spectrum somewhere less than the nyquist. The matlab FFT resolves this. In the images from my earlier post, in the "input data spectrum" note the spike at about 25000Hz (sorry for the sparse x axis). The XFFT is somehow showing the signal at 40000, hence the question. It is really strange that it can do this given the mess that the input signal is. Even stranger still, it can resolve 50000Hz and 60000Hz! The input signals look like crap and the XFFT is able to correctly resolve them.

I have a theory on this, but only the authors of the XFFT code can prove this out: I think the XFFT is better than the "typical" fft. When we use a FFT in real life, we take care that XFFT does not get presented with garbage, the data is windowed, etc. My bet is that by virtue of its design, the XFFT really can resolve MAX_SAMPLES frequencies. (I think I proved just that) I noticed in the documentation for the core the output data arrangement is not specifically documented, which "bins" correspond to DC, nyquist, etc. There is an undocumented characteristic going on here....

Ed

Highlighted
##

Thank you for this answer. I couldn't manage to understand it right off the bat and for this reason I dare to write an example in case if another slow thinker like me finds the topic.

Consider (-3,3) spectrum with numbers of frequency bins looking like this: -3,-2,-1, 0, 1, 2, 3 - where 0 is for DC. What is received at the output of the core is this: 0, 1, 2, 3,-3,-2,-1. The (-3,-2,-1) part is moved to the end of the pack. The "-1" bin comes with tlast=1. Simulation proven.

Many thanks

Ilya

ilya.denisov

Visitor

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

03-15-2019 10:02 AM

852 Views

Registered:
07-21-2018

Consider (-3,3) spectrum with numbers of frequency bins looking like this: -3,-2,-1, 0, 1, 2, 3 - where 0 is for DC. What is received at the output of the core is this: 0, 1, 2, 3,-3,-2,-1. The (-3,-2,-1) part is moved to the end of the pack. The "-1" bin comes with tlast=1. Simulation proven.

Many thanks

Ilya