LabVIEW FPGA Idea Exchange

Community Browser
About LabVIEW FPGA Idea Exchange

Have a LabVIEW FPGA Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

LabVIEW NXG had the ability to create a resource file.  Though I cannot find the help reference for this I will describe the functionality below:


Right now the Target Scoped FIFO, P2P, DMA-FIFO, Memory, Handshake Items, Registers, Clocks, etc are all stored as part of LabVIEW Project (lvproj) file.


If want to port to a new project file or target I have to copy/paste.  This is not a big deal and works well.  However if I update one project's configuration I have to re-copy/paste.  From a configuration management perspective I cannot ensure the configurations are always the same.  With larger, multi-FPGA projects this becomes critical.


It would be great to have a file that holds all of these resources to allow for easier portability and configuration management.

The error "You must recompile the VI for the selected target" appears for reasons that, to me, are often obscure or even inexplicable. Recompiling is, as we know, painful. It would be good if the error message included the reason(s) for refusing the existing bitfile, since then I may be able to work out how to stop it happening.

I understand the message comes because LabVIEW decides there are "dirty dots" associated with the bitfile, what I would like the error message to tell me is which dots are dirty and why.

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.


When parsing message packets in my FPGA code I'm often using a custom packing method with multiple individual datasets being packed into a single U64 (for example) for transport.




With the introduction of Malleable VIs, I would love to be able to create my own packing and unpacking Malleable VIs but don't yet see how.  Problem is that the "Boolean array to Number" does not allow attaching a datatype like the "To FXP" does.  I would like to marry these two functions into a "Boolean array to FXP" node where I can wire in my input datatype and have the output datatype automatically maintained in a malleable VI.



Arising from similar requirements as I have posted many moons ago: HERE.... I naively thought putting a terminal in a disable structure would remove it from the FPGA compile. It doesn't.


Years later, I have developed a nice debug interface for my FPGA code which is becoming more and more modular as I refactor it.  I have many sub-modules with their own debug interfaces which can be turned on or off from the top-level VI via LVOOP method injection.


The problem is that I can't really compile my entire FPGA VI with ALL debug paths enabled as this just won't fit (It will sometimes compile, but most often not and our FPGA code base is still growing).  And this is before I even think about making my debug information more detailed.  I would like to be able to easily switch certain aspects of the debug interface on and off as testing requirements change.  On the debug interface level I can do this easily by simply not reading the data from the objects being used for the data transfer or simply passing in abstract methods which don't actually do anything and get optimised away.  But I'm left with a load of FP controls which are still eating up resources on the FPGA target. Smiley Mad I don't want to delete the controls because that leads me to X copies of ever-so-slightly out-of-sync versions of my test VI which quickly becomes a maintenance nightmare.  Instead, I want to be able to "easily" reconfigure my test front-panel to only compile the stuff I'm currently actually interested in.


Part of what I would like is the ability to actually define areas of the FP which are enabled, disabled or enabled (and preferably also based on whether simulation is active or not - hence conditional disables for FP).  This way, when compiling, the FP elements will actually disappear and full resource savings can be made (as Xilinx is clever enough to optimise away any pointless code LV may stillhave instantiated in VHDL).  In addition, the ability to define certain controls as being enabled only when in simulation mode can allow us to have SGL graphs and so on present when needed during debugging.


So, would having conditional disable options for the FP (where controls are shown as greyed out when not available) be of interest to anyone?  If this would be an FPGA only thing, I wouldn't shed and tears.


Am I the only one who would use this? hmm. Maybe.

The LabVIEW FPGA module has supported static dispatch of LabVIEW Class types since 2009. This essentially means all class wires must be analyzable and statically determinable at compile-time to a single type of class. However, this class can be a derived class of the original wire type which means, for instance, invoking a dynamic dispatch method can be supported since the compiler knows exactly which function will always be called.


This is not sufficient for many applications. Implementations that require message passing or other more event oriented programming models tend to use enums and flattened bit vectors to pass different pieces of data around on the same wire. All of this packing and unpacking can automatically be handled by the compiler if we can use run-time dynamic dispatch to describe the application.


We call for the LabVIEW FPGA module to add support for true run-time dynamic dispatch to take care of this tedious, annoying, and down-right boring job of figuring out how to pack and unpack bits everywhere. Whose with me?

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.


To allow the creation of reusable code we can wire references to IO nodes to make reusable subVIs. This principle does not appear to apply to module property nodes such as data rate. Enabling this will increase the scope of reusable FPGA components.

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).

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:



I have several projects that use the same code modules.  FIFOs are used to communicate with these modules.  It would be really nice if I didn't have to keep recreating the same FIFOs for each new project just to be able to reuse my modules.  I suggest being able to save FIFOs (DMAs also) in a lvlib file, similar to project variables in the Windows LabVIEW.

One of the benefits of the Instruction Framework is that one could develop several modules each using Instruction Framework.  The modules can then be integrated and the Instruction Framework modules can be assembled using Collections.


This information is not clear and the provided tutorial does not provide information on this use case.

The rvi folder has automation tools for FPGA compiles.  These are not very well documented.  There are no examples on using these.


Could additional info and examples be provided?


This is useful for projects where automated building helps continuous integration with tools such as Jenkins or Bamboo.

This would vastly simplify making re-usable modular sub-vis to handle complex interactions involving reading and writing front-panel controls to communicate over the FPGA interface. Presently, this requires a lot of complex code to be copied onto an large complex top-level vi. Being able to pass registers linked to front panel controls would allow controls to be bundled into clusters of registers and sent to sub-vis that could then be generically usable for repeat functionality or across multiple "channels".


As far as I can tell, method and property nodes don't support some of the inputs I need.  For example, I'd like to create a subVI to configure the terminal mode of my 9205 inputs.  The idea is to decouple the node from the specific resource.


Old Way in LabVIEW 2012




New Way





Steve K