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



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.


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.




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?


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.


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.


Don't compile if not needed !

Status: New
by Member manu.NET on ‎11-30-2010 02:51 AM



This morning, after a night of FPGA compilation, i moved my Labview project path into an other location.

(Without modification of relatives path inside the project directory)


And then ... when i tryed to launch my FPGA main VI ... :smileymad: the compilation started again !!!


I would be nice that the  "change detection mechanism" which detect if a compilation is required or not, doesn't take care of absolute paths !


I think that the "change detection mechanism" of FPGA code should be modified in order to only take in account the FPGA code dependencies.


The dependencies should not include ...



  • Absolute path references
  • disable conditional items ... if not used in the FPGA code 
  • ...
  • All things not directly needed and called by the FPGA code
  • ...




Build Selection option

Status: New
by Trusted Enthusiast on ‎11-29-2012 04:41 AM

Sometimes I just want to compile a lot of Bitfiles (Be it for a release or a debugging test case) and I have to right click each and every Build spec and choose "Build".  then wait about 10 seconds and do the same again for the next build spec.


How about being able to select multiple build specs and then select "Build Selection" and have time to go for lunch while the PC queues up all the compilations?


I don't use a compile farm and everything is done locally but at least the queuing could be automated.



I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.


The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.


I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.


Get the development system back online as quickly as possible.


Non-modal intermediate file generation

Status: Duplicate
by Member mattjsimps on ‎02-18-2011 03:08 AM

Wouldnt it be nice if, when you build an FPGA, rather than poping up a modal window, and preventing you from doing anything usefull for 10 mins or so (or more, dependant on the FPGA vi), LabVIEW went away and generated the intermediate files in the background?


After all, the actual compilation is now performed asyncronously (and you are using the cloud compile, arent you?:smileyhappy: ), so why should we sit and watch the intermediate files being generated?


Imagine the hours you would save a week, just by being able to get on and do something else.


Better check for Compile Server

Status: New
by Member Brinoceros on ‎01-06-2011 09:53 AM

If you try to compile while pointed to a Compile Server that is for any reason inaccessible (server is down, firewall, typo in the hostname, etc.) you must wait through the generation of intermediate files, then you receive the error message that LabVIEW FPGA was unable to contact the Compile Server at your configured hostname/IP.  Generating intermediate files can be a lengthy process and it shouldn't be necessary to wait through it just to find out if you have configured your Compile Server correctly.  Any of the following would be a much better experience:


  1. Attempt to connect to the Compile Server before generating intermediate files.
  2. If the connection to the Compile Server fails after generating intermediate files, give the option of specifying a new Compile Server hostname/IP and retrying without having to re-generate the intermediate files.
  3. At least put a connection check in Tools >> FPGA Module Options... so the user can test the connection to the Compile Server.  You wouldn't do this all of the time, but if you run into a problem at least this way you can keep trying new configurations without generating intermediate files.  Right now the best way to test new configurations is to create a blank FPGA VI (to decrease the length of generating intermediate files) and keep trying to compile it.

Auto Increment

Status: New
by Active Participant James_McN on ‎11-29-2010 10:30 AM


Simple one that I have heard a number of people request.  Why is there no auto-increment on the versions of an FPGA build specification versus any other versioned build specification in LabVIEW?  This should be a simple addition to bring the FPGA module inline with other LabVIEW modules.





Be able to programmatically compile FPGA code

Status: New
by Member J_Bangasser on ‎05-05-2010 04:14 PM
We can programmatically mass compile VI's and build executables but there is no easy method to compiling FPGA code.  We have a large application that consists of C++ and LabVIEW code.  We have automated our build process but we still have to compile the FPGA code using a procedure.  It would be nice to write a script or a VI that would compile all of our FGPA code.

Remove restristions on FPGA target names

Status: New
by Member dwisti on ‎03-31-2010 01:32 PM

With multiple hosts in one project remove the restriction of FPGA target names.  If I have 2 cRIOs in one project and the FPGA in those cRIO's is the same then so should the FPGA target name.





Of course, FPGA target names must be unique if they are within the same host.

I know its not necessarily a LVFPGA issue, but its us LVFPGA users that use fixed point numbers most often.  Why don't fixed point numbers always show coercion dots.  If every unnecessary numerical digit wastes chip resources, then isn't it more important that we know about these coercions so that we can avoid them?





For the moment, there is only one clock assigned with the FPGA main VI. "The top level clock"

This clock is used by the code created on the main block diagram. (Outside SCTL)


Today, if you need an other clock ... you have to use SCTL's ... but using SCTL generates many problems, because not all instructions are allowed in SCTL's ! 


I think that XILINX can handle a kind of partition ! 


My need would be, for example, to have one partition running at 40MHz ... and an other at 80MHz ... without having necessary to use SCTL's.


This is only an idea ... i think that behind my idea something heavy must be done !


The Top would be, to be able to share data between the different partitions (using FIFO for example) ... but i think this is one more difficulty !


The partition mechanism could be created in Labview FPGA as follow  ...



  • With multiple top VI's : On per partition
  • Or, with a special structure in the main vi block diagram : Partition structure, with a clock as input : Like a mega SCTL, without SCTL limitations.
  • Or, by adding a clock input to the while loops
  • ...



Thanks for reading.





Improper use of Global Variables in a SCTL causes compiling error 61056.


Currently, this error does not alert the user until a considerable amount of time has been used during compiling.

Please include a check in LabVIEW for inproper use and alert user before compiling. 


*Created for service request per customer recommendation.


Compiles Started over a VPN

Status: New
by Member --thatguy on ‎07-01-2010 09:16 PM

If I kick off a compile behind my VPN I can't re-connect to the compile when I get back to the office (different IPs?).   I know this isn't a typical use case, but when compiles times or queues are long I kind of have to work around the compiler's schedule (and occasionally work from home). 

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