Insufficient FPGA resources for custom control FIFO

[kholub]

I am attempting to write an FPGA vi which uses a custom control (fixed-size 78 element U8 array) as the data type for a target-scoped FIFO. I only need to hold ~5 elements in my FIFO, and have tried both block memory and flip flops. In either case, my compilation fails due to lack of FPGA resources. However, If I scope out a U8 fifo large enough to hold 78*5 U8 elements, the compilation succeeds. Why does this happen, and are there any solutions that still allow me to use a custom control data-type FIFO?

[RikkiTikkiTucker]

Hi!

What target are you trying to deploy this target on?  Also, can you try creating the described FIFO in a new project with a blank FPGA VI and see if that compiles?

Thanks!

[natasftw]

When you build the array, you're not just mapping out a place to store those values, you're mapping out a communication path to get things from the front panel of the FPGA elsewhere.  Those are another type of resource.  Try removing your FIFO entirely.  Do you still fail?  If so, I'd suspect that's the issue you're running into.

What is it you're doing that makes you assume the FIFO, itself, is the issue?

[Sam_Sharp]

Probably not of that size. By using a 78xU8 FIFO you're creating a minimum 'block size' (is the best I can think to describe it?) of that size which puts constraints on the FPGA compilation - it might be that having to allocate memory/space for the array constants on the block diagram and/or front panel controls is causing difficulties for the compiler to route on the FPGA. 

It's worth having a read of the High Performance FPGA Guide (http://download.ni.com/pub/gdc/tut/labview_high-perf_fpga_v1.1.pdf) - it mentions things like having a large array as a front-panel indicator or control is resource intensive.

I would try to pipeline the data by using a U8 FIFO and adding some code so you know how to separate the data on the recieving end.

[kholub]

I'm using a PXIe-8115 with a 7951 R target. Elimating/replacing the 78xU8 FIFO with an equivalent U8 array and keeping track of the sizing internally did work, but it's not the most ideal option.