Turn on suggestions

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

Showing results for

- Intel Community
- FPGAs and Programmable Solutions
- FPGA Intellectual Property
- FFT Megacore V11.1 problem

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

Altera_Forum

Honored Contributor I

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

12-14-2011
04:07 PM

1,023 Views

FFT Megacore V11.1 problem

Hi all,

I am using Terasic's DE2-70 dev board and I am building a windowed FFT processor (8192 points each, 16 non-overlapping windows) using Quartus II and Modelsim-Altera. The megacore uses buffered burst architecture with block floating points. 18-bit data and 18-bit twiddle. Now I have read previous threads about the sink_sop and sink_eop threads, and i developed a state machine to provide these signals properly. Additionally, the source_valid signal fluctuates when the FFT processor is providing the outputs (once every 4 outputs in simulation). I assume that is normal and I just ignore the clock cycles where the source_valid is de-asserted. I tested the hardware implementation with a simple hard-wired 64 point (that cycles 128 times to fill each 8192 window). the modelsim simulations, matlab fft, quartus-generated matlab testbench, and the hardware output perform very well, with little or no differences (the data did not span the whole dynamic range but just 8 out of 18 bits. Only real data was fed into the processor with the imaginary input tied permanently to ground). With this testing sequence, everything was fine. Now I put in real data from a 14-bit ADC (tested with a single tone sine wave). i took the raw data output of the ADC (which was stored in memory) (the exact same sequence of data that passes through the FFT processor). Matlab's FFT and the quartus generated test bench give perfect answers, but the hardware results are incorrect now ! I am attaching the FFT results as an image (just for one window, the others are almost identical). Any help as to what this problem is would be quite appreciated. Side note: I know that precision is sacrificed in the block floating point by the fft processor in favor of high-amplitude signals. And since a zero average sine wave will have a DC offset of (0x2000) in a 14-bit ADC output, I subtracted this value out of each data point so that the input data to the FFT is centered about 0. Still, the output is not close to satisfactory. only when my input amplitude is really small (1mVpp), such that only a very small dynamic range of the input (32 LSB (5 bits) or less), does the FFT work. Additional info: signal was 300kHz sine, which at a 25MHz sampling rate, and 8192-point FFT, would correspond to FFT output sample number 99 as in the figure (delta_f = 25Mhz/8192 = 3.05kHz approx). Figure only shows output FFT in the range of interest, but the actual data is 8192 points wide as expected. the blue spectrum is what both quartus's matlab test bench and what matlab FFT predict (identical), but the red is what I get from the hardware (same hardware that worked perfectly for very small dynamic range input).Link Copied

15 Replies

Altera_Forum

Honored Contributor I

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

12-14-2011
06:46 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-14-2011
06:49 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-14-2011
06:53 PM

44 Views

I am talking about waves that actually enter your FFT, not what you send to ADC

Altera_Forum

Honored Contributor I

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

12-14-2011
07:06 PM

44 Views

One other question: you say zero average sine has offset, why?

Altera_Forum

Honored Contributor I

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

12-14-2011
09:33 PM

44 Views

Hi Kaz, thanks again for bearing with me.

1) Yes. the data going into the fft core pins comes from an SSRAM memory, which I populated in the past with data coming from an ADC. I extract this data in memory into MATLAB to check against matlab's FFT and Altera's matlab test bench. both results are almost perfectly close to each other. However, when the data from my memory enters directly into the FFT core, I get the erroneous harmonics-like spectrum. This same design worked with very small dynamic range input as I mentioned earlier 2) Most ADC converters do not encode the analog data to signed numbers. In my case, let's assume my input analog sine wave is spanning -Vm/2 to Vm/2 (no offset). The 14-bit ADC will translate the -Vm/2 value to 0x0000, and the Vm/2 to 0x3FFF. So a zero-valued analog input data will translate to 0x2000 after being digitized in the ADC. This is an "artificial DC" because of the shifting that the ADC does. I just subtracted this value from the data that came out of the ADC (before storing in memory), so that I get ready 2's complement, zero average numbers to feed into the FFT core later. It is this "adjusted" data that I use in all hardware tests, as well as matlab fft and Altera's matlab testbench simulations.
Altera_Forum

Honored Contributor I

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

12-14-2011
10:50 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-15-2011
07:27 AM

44 Views

You should clock your data into fft with its own sampling rate i.e. 25MHz.

But I still have doubts. Clocking sinewaveform of Fs 25MHz from sdram using 100MHz will not produce harmonics but will just shift your 3KHz to 12 KHz. There might be something else wrong in your clocking. Also make sure that your ADC data is not offset binary which needs inverting the sign bit.
Altera_Forum

Honored Contributor I

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

12-15-2011
02:41 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-15-2011
02:48 PM

44 Views

That is true. If you just want to pass it as test signal into fft then you can run fft at any speed then interpret your frequency value e.g. 3KHz moves to 12 KHz if you run fft at 100MHz.

Now are you saying that matlab fft is ok for your vector and testbench is ok but not the actual hardware fft? Or is correct at low signal dynamic range only then I suspect clipping inside.
Altera_Forum

Honored Contributor I

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

12-15-2011
03:08 PM

44 Views

Yes, kaz. That is exactly what I am saying. Matlab fft and testbench (both my own and the altera generated matlab testbench) work perfectly ok. The hardware does not, though. but I am now finding out that when I clock the FFT core at frequencies less than or equal to 10MHz, the output is correct ! I am still doing some tests to see if this works over the entire dynamic range. I will keep the thread posted but I suspect that the FFT core (in my cyclone II device) cannot be clocked too fast.

This actually will cause a problem for me because I will need to change the clocking of my ssram (one frequency during acquisition, and another frequency during FFT), which means I might have to use a gated clock :(
Altera_Forum

Honored Contributor I

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

12-15-2011
03:22 PM

44 Views

So is't timing issue, I assume you passed timing but are your sure about ssram interface timing?

Regarding clocks, you use clock control block or may be just one clock with different enable rates.
Altera_Forum

Honored Contributor I

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

12-15-2011
03:24 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-15-2011
06:26 PM

44 Views

Altera_Forum

Honored Contributor I

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

12-15-2011
06:54 PM

44 Views

If captured data from ram is captured at the point it goes into fft inside fpga then I will say so far so good.

Then if it timing problem I expect the tool to report violations but I doubt it because I can assume that timing violations may be random and not leading to regular harmonics. At first I thought may be some MSBs are violated but then I expect chaotic output unless it involved some corner coefficient only. You may run at 1 MHz with full dynamic range and see. Also apply reset just in case.
Altera_Forum

Honored Contributor I

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

12-16-2011
03:02 PM

44 Views

Topic Options

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

For more complete information about compiler optimizations, see our Optimization Notice.