FPGA Slice LUT usage with subVI

[nickc75]

I have a rather large FPGA VI, a part of which presently has logic that is replicated 4 times in parallel in the same loop to handle four separate data streams at the same time.  At present, the FPGA compiles without a problem with the highest resource utilization at around 97% for "Slice LUTs".  For the sake of readability, and to avoid making mistakes while trying to maintain the VI, I decided to wrap this logic into a reentrant subVI and replace each of the four replicated logic sections with an instance of the subVI.  I would think that this change would not amount to an increase in resource utilization, but now the VI fails to compile with Slice LUTs at around 114%.  I don't understand why this is happening.  The knowledge base [1] says that each instance of the reentrant subVI occupies separate hardware resources of the FPGA device, but shouldn't that include only the resources that one uses in the subVI?  Or is there some overhead resources (penalty?) incurred for using a subVI?

SubVI attached

[1] http://digital.ni.com/public.nsf/allkb/00B6F22B7EBBA59086256DD8007CA0BE

[MichaelBalzer]

Have you tried setting "Inline subVI into calling VIs" on the Execution tab of the VI properties? I don't know if this will have any effect on the FPGA compiler, but it's probably worth a shot.

What is the function your subVI is performing? It looks like some sort of RMS - have you considered using the RMS function from the FPGA Math & Analysis palette? It may be more space efficient.

In terms of general space optimisation, are your FIFOs and Memories set to use block memory or LUTs? If they're LUTs, you may be able to use block memory instead, assuming you have spare capacity.

Also be careful with data typecasts, and 'expensive' mathematical operations (e.g. divide, sqrt). Your subVI has a number of implicit typecasts from FXP to SGL, which all add up in terms of resource allocation.

[James_McN]

Hi,

What the knowledgebase describes was my understanding of how this should work. I wonder in your case if this is something to do with the FIFOs and memory.

A common problem with resources like this is that there may need to be additional code to handle arbitration between multiple writers for example.

Because this is generalised perhaps that has to be included since it doesn't assume what else might access it. This is just a theory though - It's the only thing I can think of.

As Michael has suggested there are some optimisations you could look to make in this VI anyway. Reducing the use of SGLs or at least dealing with some of the conversions will reduce usage.

You could also try creating a VI scoped memory if this isn't used elsewhere - this may affect the resources based on my theory above.

If you could limit the FIFO read to a fixed size which is a factor of 2 (e.g. 16, 32, 64) there is a short cut you can use power of 2 with a negative number on the divides which will probably greatly reduce your logic usage.

As mentioned you might as well change the memory item to be SGL since you are converting from that on both ends of the memory as well.

As a general LabVIEW advice I would label the inputs and outputs with more relevant labels which will help with reading the code. I also find this easier to read if you shift the bottom loop to the right of the top loop - this makes the data dependency (the average) more obvious and prevents backward running wires.

[nathand]

Duplicate post: http://forums.ni.com/t5/LabVIEW/FPGA-Slice-LUTs-Usage-with-subVIs/m-p/3600619 (sorry if that doesn't show up as a link, posting from a mobile device and don't have all the editor options)