LabVIEW FPGA Idea Exchange

In current versions of LabVIEW FPGA, placing a For Loop inside an SCTL will result in code that cannot be compiled; this is because conventially For Loops work iteratively and therefore require multiple clock signals to drive each new iteration.

However, I think a logical implementation of a For Loop within an SCTL would be the generation of multiple parallelised instances of whatever code is inside the For Loop. This would greatly improve readability and flexibility by avoiding the user having to manually create multiple separate instances of the same critical code on the Block Diagram.

This would require the For Loop to execute a known maximum number of times.

Parallel loops are supported by LabVIEW but not LabVIEW FPGA, this requires us to copy/paste the same blocks multiple times to make them run in parallel.  I would like to see the ability to use parallel loops on FPGA targets as FPGAs are very well suited to this style of programming and the current copy/paste parallelism hinders this.

I have to remember to place a comment next to every memory element so that I can quickly know its size.  This is especially important because I can't get to the property window if I'm viewing the vi outside of the FPGA Target Scope. I can view the data type of a memory/FIFO element by hovering over the wire that goes into a read/write property with the context help window open, so I don't really care about that.  However I cannot view its size.  This could be fixed in one of two ways, add it to the context help when you hover over the element or display it directly on the memory element.

I posted this suggestion in the forums, but it is something I would like to see improved and included in the FPGA library. The idea is to multiplex multiple inputs/outputs to a single high-throughput math function. If someone has to do a lot of fixed point math on the FPGA, the resources are used up quickly. The multiply block is primarily what I would like to see this implemented for, but I think it would be useful with all of the high-throughput math functions.

In one project I quickly ran out of DSP48E's on my FPGA, and since I had many fixed-point multiplies with the same data type configuration, I created a state machine to step through the inputs, allowing me to replace 4 high-throughput multiplies with one multiply block for multiple operations. Sequential operations are possible by feeding the output of one operation into the input of another (I didn't implement that in the forum post below, but it can be done). I think Labview could improve pipelining of the multiplexed function, ease of setting the number of inputs/outputs and data-type, hand-shaking logic for operation in SCTL, etc. LabVIEW could also show separate schematic figures for each of the multiplexed functions (example: a PCB layout software such as Eagle shows separate blocks on the schematic for each opamp on a chip containing multiple opamps).

http://forums.ni.com/t5/LabVIEW/Multiplexed-multiply-to-conserve-resources-on-FPGA/m-p/1668138/highl...

When working with LabVIEW FPGA if so much as the value of a block diagram constant is changed, the entire application must be recompiled.

It seems that there could be a smarter method to deal with recompiling that might allow selected portions of the block diagram to be recompiled without the need to recompile the entire app.

Some of the tradeoffs might be lower FPGA utilization efficency and timing constraints, but allowing minor changes to the FPGA code without the overhead of a complete recompile would certainly make debugging applications much faster.

I am not necessarily proposing an implementation just posting an idea that seems like it would add value to the LV-FPGA development experience.

Memory initialization is one of the more tedious aspects of LVFPGA coding.  A lot of my LVFPGA vis have multiple memory elements that I need to access simultaneously for a given operation.  I've tried to streamline the initialization process by making all memory initialization vis read from an init values file and populate the array indicator.  However now I have to have multiple initialization vis reading from different points in the same init values file.  If I could somehow get a parameter into the memory initialization vi, I could programmatically select from where in the init values file to read.  Here is how this could work: