FPGA not enough BRAM?

[ngb222]

I have tried to decrease the amount of block RAM this VI requires, but if I decrease the number of elements requested in the FIFO's (by a factor of 16 from 8192 to 512), there is barely any alleviating effect on the BRAM required during compilation (~5%).

Is there another way I can edit this FPGA VI to decrease my block memory use, because at the moment I am at 150% capacity... I cannot decrease the FFT size, I have to compute the Fourier transform of 2^16 elements.

[wiebe@CARYA]

We know...

[wiebe@CARYA]

Why split up in three loops? Have you tried to merge two or three loops? That would eliminate one or two FIFOs.

How big are those FIFOs? The FIFO between the 1st and 2nd loop should not need to be bigger then a few elements, as the both run at the same speed. That's the same reason to merge them...

[James_McN · Accepted solution]

The way the FFT algorithm works is hugely memory intensive. I believe at a minimum it requires blockRAM for every sample in the FFT (so 65k samples in your case, possibly x4 as it looks like you have a 4 channel FFT) whereas most targets measure their blockRAM in KB or low MB values.

In short - FPGA's suck for FFTs FFTs use so much resource on the FPGA targets available to us it is rarely worth it. I would only look to perform the FFT on the FPGA if I needed the results on the FPGA - otherwise I would do it on the host processor instead.

To more directly answer your question:

1. Reduce the size of the FFT - this will have a big impact on BlockRAM usage.
2. Get a bigger target if you need the FFT on the FPGA and at that length.
3. Move the FFT to the host.

Sorry to be the bearer of bad news...

[ngb222]

Hi wiebe@CARYA, thanks for the response. I was basing most of the code off of examples provided by LabVIEW and their FFT example had it split into three loops in this way (FFT 1 Channel, 1 sample). You're right though, it's unnecessary in this case, so I changed the two top loops into one. Still having the BRAM issue though, which I now understand is most likely coming from the FFT, thanks James_McN for the insight. Unfortunately, I do need that data on the FPGA for further processing. I know I could easily do this on the host, but the purpose of using the FPGA was to speed everything up and do as much of it in parallel as possible (the plan was to compute the FFT of 2 large data sets and then compare the two).

[wiebe@CARYA]

---

@ngb222 wrote:

Hi wiebe@CARYA, thanks for the response. I was basing most of the code off of examples provided by LabVIEW and their FFT example had it split into three loops in this way (FFT 1 Channel, 1 sample). You're right though, it's unnecessary in this case, so I changed the two top loops into one. Still having the BRAM issue though, which I now understand is most likely coming from the FFT, thanks James_McN for the insight. Unfortunately, I do need that data on the FPGA for further processing. I know I could easily do this on the host, but the purpose of using the FPGA was to speed everything up and do as much of it in parallel as possible (the plan was to compute the FFT of 2 large data sets and then compare the two).

---

Guess you have to either reduce the length, reduce the (input and\or output) resolution, or find some other algorithm all together.

I'm not sure how this FFT compare would exactly work. Why would this be easier in Fourier domain? How would this compare work exactly? What are the pass\fail criteria?

[ngb222]

So essentially the point of this is to find the relative amplitude of two signals at specific frequencies.

[Terry_ALE]

Have you looked at the Xilinx IP FFT? https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgahelp/fpga_xilinxip_descriptions/ and then https://www.xilinx.com/products/intellectual-property/fft.html.  It can go up to 65536 and is more efficient than the NI LabVIEW FPGA Express VIs.

[James_McN]

Hi,

Terry's suggestion is worth investigating - I'm not sure if there will be a gain or not but got to be worth a try.

I realised later as well - I said reduce the size as in the length, but perhaps there is also room for you to reduce the data type width as well. This may also have a beneficial effect.

If you look at Terry's link there is a link to another page with example resource utilisations which may help the judgement of if it can work on your target (though none quite match what you need): https://www.xilinx.com/support/documentation/ip_documentation/ru/xfft.html

Cheers,

James

[wiebe@CARYA]

---

@ngb222 wrote:

So essentially the point of this is to find the relative amplitude of two signals at specific frequencies.

---

Getting the amplitude of specific frequencies is a lot cheaper than a full blown FFT.

The filter can be a lot 'cheaper', and you don't actually care about the entire filtered result, you can just take the max (|min|, max) of the result. So you don't need any data buffer...

In other words, you can have a PtByPt filter filtering the specific frequency, and it would have a very small internal state.