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!
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I'm bringing back to life this long-lost idea:

as I think there are lots of situations where pre/post build actions could be useful for FPGA.


For example, as suggested here:

I have a large array of coefficients that I want to load from a file, then populate an array constant with it. I have a script to do it, now I would like to automatically run it before compiling the bitfile. For context, I want it to be a constant because controls take more resources and do not allow constant folding optimization.


I already had another situation where I made a tool to auto-generate code in case structures based on some specifications given by the developer. If however the developer forgets to run it before compiling, the FPGA VI won't work properly as necessary code has not been generated.


More generally, I think scripting for FPGA is way underrated. As FPGA code is quite often tedious and redundant to create (because optimization is priorized over readability, and because of the lack of type genericity), scripting has a great potential here. Allowing to run pre/post build actions for FPGA bitfiles would surely take FPGA scripting to the next level !

With even simple examples we experience errors when trying to run Instruction Framework based LabVIEW FPGA VIs.


This is a blocker for our using Instruction Framework.

MGT interfacing to the 7915 is provided:


It is not provided for other cards such as the 5785.  Is the interfacing the same?  Could examples for this be provided?

Working with the NI 5785 our team had a hard time understanding how to use TClk without all of the extra (e.g. streaming) code that comes with the example.


Through support we were eventually put in touch with R&D and they told us how to initiate TClk by setting some of the FPGA controls.  This was helpful but not intuitive.


TClk helps support beamforming applications shown in the NI Marketing but without this usability it is very difficult (impossible) to develop applications promised.


TClk also has other lower level features such as the delay correction.  No info is posted on this either but it is a property we can read.

When not using Instruction Framework to interface from the Host to LabVIEW FPGA the FPGA VI reference register items cannot be ordered by the user


They appear in a random order (order of creation) and it is not easy to find and select them.


I am referring to this function:

P2P is a very useful technology for sharing data between NI targets.


Could this be provided for GPUs?

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.

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.

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.

Can support for simulating CLIP nodes (as can be done with IP Integration Node) be provided in LabVIEW FPGA?


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


Can simulation ability be added for the CLIP?


This is available for IP Integration Node.

When we try to compile timing critical FPGA application, if might be failed because of timing violation.

But if it missed only a few nanoseconds, recompiling might resolve the error as below.


Resolving Timing Violations on the FPGA

If your failed compilation misses the required throughput time by only a few nanoseconds, try rebuilding your bitfile. Each build of a bitfile does not always produce identical results on the FPGA, so rebuilding sometimes resolves minor timing violations. 



In most case, compilation might require much time and it's difficult to take quick action after they found the aborted compilation result.

It would be great there is an option which allow automated recompile like below.

Of course the compilation completed, it wouldn't try recompile. Only failed, try to compile again.


** -------------------------------------------------------------------- **

Enable Auto Recompile [  *  ]   Number of Retry  [  4  ]

** -------------------------------------------------------------------- **

Allow usage of non NI hardware with LabVIEW FPGA.

There is plenty of cheap boards available that could be programmed in LabVIEW.

when you try to use serial NI 9870/71 with crio controllers it will lead you directly to access them from FPGA mode, however you will find it difficult or not allowed to use its connection with MODBUS device  so it will need be accessed by scan mode by installing the specified software on your crio to enable scan mode for these devices , may be we need clear declaration in serial NI 9870/71 datasheet to show that its possible to connect them in scan mode as it guide us only to FPGA and what are the best practices to it

Default interface for FIFOs is Timeout (


I would prefer the default be Handshaking.

The 7976 and 7915 have certain functions (e.g. Basic Elements) in different locations.  Some do not even show up (e.g. Channel is in 7976).


NI 7976 LabVIEW FPGA 2018:




NI 7915 LabVIEW FPGA 2018:



I have Labview 2020 installed, along with Vivado 2019.1.1_AR73110 (which is the version the vi package manager installed). My suspicion is there may be few bits missing from the Vivado installation that labview does, since said bits (like using a board definition as a starting point for a project) wouldn’t ever be necessary for the FPGA module’s normal operation.
The Short version is, Labview’s Vivado versions (2017.2 & 2019.1) behave the same way. I’d question why the C:\NIFPGA\programs\<VivadoVersion>\data\boards directory isn’t present (even if it provides no actual board definitions) in the labview installs if end users are allowed/expected to use the software for custom project uses (IE, FPGA IP export utility, expecting you to use the same vivado version), but ultimately the labview vivado versions do not appear to be missing anything major.
Maybe in future labview Vivado versions, include the data\boards directory, with a readme note about what to copy from a Xilinx Vivado version to get board presets to work, or leave the framework without any actual board definitions.

Dear mr, miss,

As the title already mentions. Please add support for the 903x series of cRIO in labVIEW NXG. The systems we have (9039) are just a few years old and we would like to show the benefits of NXG to our students.

kind regards,


Roel Jansen

sr. lecturer in Engineering. HAN University of Applied Sciences

High speed serial links are becoming more and more prevalent in FPGA designs. NI now offers FPGA cards with these MGTs exposed.


It would be a huge advantage to be able to design / implement devices with embedded SB-RIOs which are capable of interfacing vis MGT.


AFAIK, none of the currently available SB-RIO have any MGT functionality exposed. For us (Analytical device manufacturer) this would be a real game-changer.