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

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  ]

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

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 !

Number to Boolean Array and Boolean Array to Number along with array manipulation functions (index, replace, reverse) are commonly used methods in FPGA for doing bit manipulation on arrays of integers inside SCTLs. Not having access to these functions is prohibitive and results in having to write code like this:


This becomes very unwieldy when dealing with arrays of 20+ elements. If Number to Boolean Array and Boolean Array to Number are truly no-op elements, then they (along with basic array manipulation nodes) should be added to the list of supported nodes inside for loops inside SCTLs.

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.

While for loops inside SCTLs offer limited functionality, placing an unsupported element inside the for loop does not result in broken code. Instead, one has to wait until the second stage of generating intermediate files to discover that the element is not supported. Code like the example below should show a broken run arrow if it is not supported.


Annotation 2019-08-14 111042.png

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.

Xilinx log window should use a fixed-width font.


Which of these two string indicators with identical content is easier to read?


FPGA Xilinx Log font.png


The one on the left is Courier, the one on the right is the default Application font

LabVIEW FPGA has chosen to disconnect typedefs in Register Items, Memory Items, FIFOs, and Handshake Items ( Please reconsider this decision.

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.





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.



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 ... Smiley Mad 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
  • ...



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.

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?Smiley Happy ), 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.

This is the current situation when dealing with register creation on FPGA targets:


Regsiter Create.png


This is what I would like:


Regsiter Create wishful thinking.png


I am currently creating a group of classes to abstract out inter-loop communication and the ONLY thing changing between classes (aside from variations between Ragister vs FIFO vs Global and so on) is the datatype.  Being able to link the Register creation to a data input (the data value of the class itself for example) would save a lot of work in such operations.  If it were also possible to do the same for the Register stored within the class private data then implementing different classes int his way would be really easy.


Even without classes, the ability to autoadapt the type of registers / FIFOs in this way would be a real step towards re-usable code on FPGA.



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.

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.

Along the same line of thinking as this idea:

It would be cool if we got rid of the coercion dot here for smaller integers and integer fixed point numbers as the index for an array.

Smaller integer representation for indexes2.png

As it is, it's hard to tell if the compiler will use the bigger I32 for this.

This behavior would also useful for other integer inputs like the memory address input.

Hi there,


I got following feedback from a LV FPGA user:


When developing a FPGA application in LabVIEW, after submiting a FPGA code compilation - usually quite a lengthy process - if you modify the code either on the Front Panel or Block Diagram while compiling is in progress, this results in a Compilation Error at the end.

And this occurs regardless the modification be only a mere cosmetic change, without any implication in the code that is being compiled.
This is quite frustrating when you realize that the compilation has failed (maybe after half an hour waiting) just because you unconsciously clicked and resized some control or node.


In such a situation, when LabVIEW detects a code change while the FPGA compilation is running, it should warn the user with a message box; if the user confirms the code change, the current compilation can be inmediately aborted or let it continue (at user option); on the other hand, if the user cancels the modification, nothing happens and the compilation continues to a successful (hopefully) end.





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.

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.