FFT core

[astromike]

I am attempting to use a Xilinx FFT core in to create an FFT in the NI-5640R FPGA.  I am using LabVIEW FPGA 8.2 to do this and the FFT core I am using is a 14-bit Pipelined 4096-point FFT.  I am injecting into the FFT a sine wave that is created with a 1024-point LUT.  There is only one period of the sine wave in the LUT, so I feed the 4k FFT a total of 4 cycles.  Using the output index that is associated with the output elements of the FFT, I store the Re/Im values to a 4k block of memory.  A counter then cycles through the memory moving the Re/Im values, along with the appropriate index, to two FIFOs (one for the Re/Im values, one for the index).  On the Host, the Re/Im values and their corresponding index are removed together from their corresponding FIFOs.  The Re/Im values are then split apart, converted to 16-bit integers, casted to a double, and then converted to polar to get the magnitude.  The index is used to then store the magnitude in the correct spot of a 4k array.

When I run the VIs, I expect to get a constant impulse at 1024 on a plot of the 4k array (if my math is correct).  Instead, I get a dancing impulse around 512 (maybe my math is incorrect).  I can understand my math being wrong, but I do not understand why the impulse is dancing around and why it occasionally disappears, it should be constant.  Does anybody have any ideas or know what I'm doing wrong?  I have included the FPGA and HOST VIs along with the FFT core for reference.

[JLewis]

I don't know what rate you're running at, but it seems likely that you're losing a lot of data on the way back to the host. At 40 MHz, you would fill up the host buffer in less than a millisecond (I tried this on a PCI-7833R, and the FPGA buffers overflowed almost immediately). If you have any buffer overflows, there is no guarantee that your data is coherent since the index and results are on separate DMA channels.

I would recommend adding logic to monitor your buffer states and errors, both on the FPGA and host. Increasing the size of the buffers on both ends should help, and optimizing your host FIFO read loop might be necessary. Instead of reading a point at a time, try reading a whole frame as an array. Minimize unnecessary operations in the host loop, such as writing the array to the front panel indicator. Try a very slow clock rate until you have verified the FFT core, then work on the transfer issues.

You will probably also need to delay starting the FPGA VI until the host acquisition loop is ready to go. Uncheck the "Open and Run" option in the pop-up menu for Open FPGA VI Reference, and add a Run method as the last operation before entering the loop. This will reduce the chance of overflowing the FPGA buffer before the host gets going.

One way to ensure coherence between your index and data is to pack a 16-bit index with both the real and imaginary parts, sending real+index on one channel and imag+index on the other. This will ensure that the data belongs to the correct index, but then you will have to figure out what to do if they get out of sync.

[astromike]

I was running at the Configuration Rate of the PCI-5640R, which was 20MHz.  Changing to the adjustable RTSI clock and setting it to 1MHz, I was still running over the buffers.  I never thought of that, so that helped A LOT!!!  I have redesigned the FPGA a little bit to remove the memory, and the design is much simpler, why I was making it harder I don't know.  Then again, I'm new to FPGA work.  I have taken most of your ideas, and am working on the others.  For now, to test the FFT, I am now decimating the FFTs by 2 in the FPGA and I'm only looking at the first FFT frame on the host.  I am also waiting for valid data before filling the FIFOs.  I'll further decimate the FFTs when I start looping the host again.  Matching the index to the Re/Im values is definitely a great idea.

I have confirmed the FFT to work with a peak at k=+/- 4, which I believe to be the correct values.  I am posting my current VI to help others that may be running into the same issues.  The Host isn't as well documented as I would like, but shouldn't be too hard to follow.  The FPGA should be real easy to follow, except maybe the decimating part.

JLewis, thank you again for your help.  I've been banging my head on this for a few days.