FPGA Slice LUTs Usage with subVIs?

[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 code attached.  

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

[nathand]

Did you try compiling the FPGA more than once? There's randomness in the way the compiler places code on the FPGA, so it can succeed once and fail the next time on identical code. I don't think you should see any overhead from using a subVI, but it would help to see it in context. There might be something subtle that you've changed between the original and subVI version.

There's room to clean up your VI. The simplest change is to use the shift register output from the first loop instead of creating a separate tunnel containing the same value. The compiler might be smart enough to optimize that out, though. You could take the reciprocal of "Number of Elements to Read" once, and then replace the two divisions with more efficient multiplies. Change your memory item to store single-precision values, to avoid unnecessary extra conversions between single-precision and floating point - and for that matter, you could replace the memory item with another FIFO and then you wouldn't need to deal with addresses. If the memory item isn't used anywhere else in your code, then replace it with a VI-scoped memory item (or FIFO) instead of passing in a reference to the memory item, that will keep the code simpler. Instead of the case structure in the second for loop, you could send the output of the Greater Than to a Boolean to 0,1, then add that output to the shift register, which will have the same effect (no idea if it's any more efficient, but I think it looks cleaner).