NI Home > Community > NI Discussion Forums

LabVIEW FPGA Idea Exchange

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

On the cRIO-9068, the third serial port and the second Ethernet adapter is actually mounted on the FPGA, resources are consumed to redirect to realtime. Currently there are no access to this resource on the FPGA for developers, only from the Realtime.


I would like some I/O Nodes for interacting with these devices on the FPGA. NI could put up some examples how they could be used.


Today the resources are invisible to the developer, except for the additional long compile time and resources used (about 7%).


I attached pictures of the FPGA design and the resources consumed for a blank vi.




Jens Eriksen



0 Kudos

As part of my quest to solve problems arising from over-cautious Register transfers HERE I found a solution which WOULD have worked if I was able to force multiple clocks derived from the same source to be have synchronised start points (so that the iteration counters of the loops are known relative to each other). It seems that clocks derived from the same base clock do not neccessarily all start with Iteration zero at the same time.


My suggestion would be to either

  • Give some option to force such loops to have synchronous starts (also when using external clocks) -or-
  • Allow loops with external clocks to terminate so that we can put together out own synchronisation method



Optimised registers for related clock domains

Status: New
by Trusted Enthusiast on ‎04-02-2014 12:54 PM

HERE I detailed a problem I currently have with Registers between two clock domains which are closely related (phase-locked).


It turns out that there is handshaking going on which, essentially, is not really neccessary.  It would be nice to have the option to have something similar to a Register for such clock domains where we know explicitly the relationships between the clocks and thus does not require handshaking.




XControls on the FP for interactive debugging

Status: New
by Trusted Enthusiast on ‎03-24-2014 11:01 AM

I find myself again and again having to memorise bit field index and other things in order to be able to debug FPGA code efficiently.  What I would really like to be able to do is to create an XControl with a compatible datatype (Say U64) and have this display and accept input in the form of human-readable information.


The data being transported is simply a U64 and the FPGA code doesn't need to know anything about the XControl itself.  Just allow a host visualisation based on an XControl to ease things a bit.


I've already started using LVOOP on FPGA and I think this could be another big improvement in the debugging experience.  Having an input XControl (or a set of XControls) for certain LVOOP modules on the FPGA just gets me all excited.

0 Kudos

Pipelining gain compensation in CORDIC algorithms

Status: New
by Trusted Enthusiast on ‎03-24-2014 09:15 AM

The CORDIC High throughput functions available in LabVIEW are capable of running at high frequencies, thus allowing FPGA code to (for example) multiplex multiple demodulators without exploding device utilisation.


Unfortunately, the option to apply a Gain correction to the results does not pipeline the actual multiplication, thus artificially limiting the available speed of the CORDIC algorithms.


In my code I always deactivate the Gain compensation and do this "manually" allowing the code to compile at much higher frequencies and more efficiently utilising the FPGA device.


It would be great if it were possible to also pipeline this multiplication as part of the CORDIC High-throughput node instead of being forced to implement the multiplication separately.


User Lorn has found a brilliant tip for *DRASTICALLY* speeding up FPGA compile times under Windows for PCs with the turbo boost feature. What's more, it's extremely simple to implement.


Please let's see this in future versions of LabVIEW as standard.

Many data streams contain information for multiple channels or multiple samples. Today one must pack this data into larger integer types or interleave the data manually into multiple writes to the DMA FIFO API. It would be much simpler if the DMA natively support cluster and array data types. The local FIFO, Memory, and Register APIs already support this; extend it to DMA.

For debugging, using FPGA VIs in interactive mode can be very valuable.  I have, to this day, not been able to find out how LV determines if a bitfile and a VI match.


Therefore whenever I click on the run button for a VI, I'm never quite sure if the bitfile will match or not and often have to wait 1-5 minutes before I can resume working with LabVIEW.  This is a very high price to pay for something which I end up cancelling.  I would like very much if the IDE would TELL ME that the bitfile and VI don't match before starting a new compilation and thus wasting my time.


This is opposed to a CTRL_Click of the run arrow which explicitly tells the IDE to compile.


store build version number within FPGA

Status: New
by Member tvogel on ‎12-02-2013 02:53 AM

I'm currently looking for a way to read out the FPGA version number from the FPGA.

All I found was a way to parse the *.lvbitx, but that's not what I want.

Are there any plans to store the version number in a FPGA register to be read out at runtime?


Best regards


The FPGA compilation results should be copied to a file in the folder with the bitfile.  This is needed to track the history of compilation results, especially useful when using source code control.  Right now they get overwritten with each recompile.


Adding a Post-build action VI to the FPGA build spec, would also enable something like this.


support acquire write region on sbRIO

Status: New
by Trusted Enthusiast on ‎11-14-2013 01:27 PM

It would be nice if the sbRIO targets supported the DMA Acquire Write Region (and Acquire Read Region, although maybe that's already supported - I only tried Write Region since that's what I need for my application). Failing that, perhaps the documentation could mention that those methods are not supported on all targets?

We have a "group" of occurrences.  We can't identity individual occurrencs easily because you can't store them in an array (where we would use indexes to identify).  When using a cluster they all get the same name (labels aren't used!) which is bug-prone.  The only workaround is to create a control cluster, and that's not a clean solution.

0 Kudos

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


Lets enqueue creating intermediate files

Status: New
by Active Participant Piotr_Kruczkowski on ‎10-18-2013 02:40 AM

Hi, since there an be a queue for compiling FPGA code, it seems natural to me to also be able to make a queue for generating intermediate files.


I'm working with 10 build specs. for compilation per project and generating intermediate files for my design takes aprox. 3-4 minutes. This means that I need to sit by my computer for half an hour just waiting and clicking build on every build specification. Sometimes I work with FPGA VI which need to build intermediate files for something like 7-10 minutes, so this is a pain.


It would be great if there was a way of just highlighting all build specifications for compilation with shift and just creating the intermediate files for them automatically one by one.


Can this be done?


Smaller NI FPGA device that sbRIO and without CPU

Status: New
by Member JCC_(SK) on ‎10-08-2013 04:05 AM

Idea: New NI FPGA module with:


  • small FPGA (something which LabVIEW FPGA could already program Spartan 6 ...)
  • programmable by LabVIEW FPGA Module
  • IOs only
  • no CPU
  • DIP connector
  • One LED
  • Reset Button
  • Price under $100

Something like Papilio Pro.


Reason: As ATE manufacture sometimes we need small FPGA to do something inside ATE or ITA (interface test adaptor). To use sbRIO/myRIO is to big (complexity,price). Because we use TestStand and LabVIEW out knowledge of VHDL is small.


We could learn VHDL but after that we could stop to use LabVIEW FPGA! :-)


Allow Select Node to Invert Select Terminal

Status: New
by Member Pie566942.0 on ‎09-30-2013 05:42 PM

I'd like the Select node to provide an Invert bubble on the Select Terminal, similar to how the Compound Arithmetic node allows the developer to invert any input.  I don't like crossing wires.


Select Node with crossed wires in 2012: 2013-09-30_153921.jpg Select Node without crossed wires in future release (optional invert shown): 2013-09-30_154017.jpg


Keep your Invert node comments to yourself :smileywink:




-Steve K


Currently, LabVIEW does not have the functionality to save the settings of the modules (e.g. cRIO module channel names) so it can be imported into another target. The only option is to copy and paste. This functionality would speed things up significantly when moving from one target (e.g. cRIO-9074) to another (e.g. cRIO-9076) with the same modules or most of the same modules.


Support Property Nodes on FPGA Targets

Status: New
by Member Pie566942.0 on ‎09-06-2013 12:46 AM

I would like to access class attributes of my FPGA class hierarchy with property nodes.  I prefer the property node API over VIs for data member access because it allows you to grab properties from across the hierarchy in a single node.  This leads to a (much) cleaner block diagram and expedites development.  For example in the screenshot below, the FXP attributes belong to the NI_9205 class, while the "_OP" attributes belong to the parent.  I don't care about the Invoke node API over a subVI, because the wiring work and diagram appearance are about the same IMHO.






Steve K


Make generated VHDL files accessible

Status: New
by Member komorbela on ‎09-05-2013 08:39 AM

As the compilation goes on of the LabVIEW FPGA code to bitfile, there is an intermediary step when a VHDL file (or maybe Verilog?) is generated. This file would be very beneficial if you want to use another FPGA target, that NI supports. I know that this VHDL file cannot be directly used for non supported FPGA, but it would be a very good starting point for the ones that know VHDL language.

0 Kudos



I find Conditional Disable Symbols in FPGA code very useful especially in a R&D environment where needs and code change back and forth rapidly. However, I also find it hard to keep track of all these changes. I propose to add support for reading FPGA Conditional Disable Symbols from Host to enable VIs like "" that would allow for the Host program to know the state (hardware revision of sorts) of the FPGA bitfile and adapt.


I'll give an example to illustrate this proposal.


Function A is implemented in FPGA bitfile v1. Function B is implemented in Host and is based on multiple calls to Function A. Your boss now wants Function B implemented in FPGA for performance reasons with means to disable the code if required. For this you define a Conditional Disable Symbol in the FPGA project "FPGA_WITH_FUNC_B" and write FPGA code for FPGA bitfile v2. Switching between v1 and v2 is easy enough from the project manager, but for the Host side there's no way of knowing whether Function B is implemented directly in the FPGA or should be "emulated" via Function A as before. If you could do a check like "if FPGA_WITH_FUNC_B == TRUE" you could easily make the Host aware of this.




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!
Idea Statuses
Top Kudoed Authors
User Kudos Count