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


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.

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




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.



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.


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.

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.


Smaller (and cheaper) sbRIO based on Xilinx Zynq

Status: New
by Active Participant vitoi on ‎05-01-2012 03:10 AM

A smaller (and cheaper) sbRIO based on the Xilinx Zynq chip. Target size is SO-DIMM form factor (68 x 30 mm (half the area of a credit card), 200 pins). Such a board  would be OEM friendly and can be plugged into a product (rather than the current sbRIO offerings that requires the product to be developed around the sbRIO rather than the sbRIO fitting into your product). Also, a Base Board that is (only) used during development. Below is what the proposed sbRIO and Base Board would roughly look like (courtesy of Enclustra FPGA Solutions)

mars_pm3_350.jpg       mars_pm3_350.jpg


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! :-)


Make Bitfile Paths Relative, Not Absolute

Status: New
by Active Participant James_McN on ‎08-05-2013 09:48 AM

Currently when you build a VI the bit file path is stored as relative (you can see it in the project XML). This means if you change the project location either:


  • Moving machines.
  • Checking in and out of source code control on different machines

You have to recompile the FPGA to use VI mode or run interactively. It seems the bitfile could be stored as a relative path like all VIs in the projects.





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



For Loop within Single Cyle Timed Loop

Status: New
by Active Participant Alex.T on ‎05-10-2013 02:56 PM

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.






Auto-Migrate to New RIO Target

Status: New
by Member Brian_R on ‎08-15-2012 03:16 PM

I just manually transferred a fairly large LabVIEW FPGA project from one target to another (7965R to 7966R).  It would be nice to be able to click on the RIO target in the project and have an option to "Migrate to New FPGA Target" in the context menu.  The menu would open a new dialog where you could select the new RIO target and then it is automatically added to the project and populated the VIs, FIFOs, derived clocks, memory blocks, etc. from the original target.  The user can choose whether or not to delete the original RIO target.


This would also make it very easy for users to transfer sample code from the LabVIEW Example Finder to the correct FPGA target (insead of having the folder labeled "Move These Files").


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


Shrink Method nodes

Status: New
by Member --thatguy on ‎02-11-2013 02:50 PM

This might have already been asked, but I couldn't find any posts.


X-Nodes are huge in comparison to the size of a subvi or most anything else on the block diagram of code, so lets shrink them down.


Can we remove the Read/Write box?  We already have the little triangle to tell us the function/direction.

Can we use the node name instead of the generic term Data/Element?  It's already there.


From there we can model it after a property node using references instead of error lines or we can model it after the IO node which is a little cramped but gets the job done.  Both options retain a purple/pink bar to help identify it's X-node-iness.



Per NI Applications Engineering, "If you intend to run multiple compiles in parallel on the [Linux] server then yes, you will need the Compile Farm Toolkit running on a Windows machine to handle the parallel workers."  I would like NI to support the FPGA Compile Farm Toolkit on Linux, so I don't need a dedicated Windows server to outsource compiles to workers.


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?


Add Device Pinouts Tab for R-Series Cards in MAX

Status: New
by Member Sev_K on ‎12-07-2012 04:12 PM

Currently Measurement & Automation Explorer (MAX) only shows the following information for a typical R-Series card:




It would be helpful to add a "Device Pinouts" tab that shows you all the pin assignments for your Analog and Digital IO:





Multi-core Compiling

Status: New
by Active Participant Manzolli on ‎03-08-2010 07:43 AM

Even though ibberger touched the concept in the idea , I do think that most o people uses LabVIEW under Windows environment. Compiling a FPGA VI happens all in the PC under Windows. I noticed that during this process the compiler uses only one core. Since I'm using a machine with a 4 core processor, the CPU use rarely goes above 25%.


My idea is to update the compiler allowing it to be multicore. The user should have the option to limit the maximum number of cores available to the compiler. This is necessary because the user may want to continue working, while the compiling process is being done in background.


FPGA module for 64-bit LabVIEW

Status: New
by Member D* on ‎08-05-2011 12:38 PM

With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace.  However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application.  Unfortunately, this isn't possible yet.


While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point.  I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA.  I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.


Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline.  This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.

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