LabVIEW FPGA Idea Exchange

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!
Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 

Turbo Boost the speed of FPGA compiles under Windows (Method included!)


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.

Trusted Enthusiast

I've just tried it and I was quite taken aback by the results.  I halved my compile time (OK, it's only a small benchmark tool but still).




Active Participant

Thanks Intaris - replication of these results is invaluable for encouraging people to back this.

Active Participant

Well some interesting results my end. I had high hopes when estimated device usage was available in 5 minutes (as opposed to 27 without turbo!). In the end the difference was between 43 mins (with turbo) and 56 mins without.


That single core was burning 100% on the nose a lot of the time. I suspect the turbo clocking may have had to scale back to avoid thermal limits. This would explain the initial sprint followed by a jog. I am however running my PC with the case open at the moment, so airflow may be suboptimal.

Active Participant

Just recompiled again with Turbo on to look at the throttling, and it built the thing in only 32 minutes this time.

Proven Zealot

I voted for this but I don't think it will be easy for NI to implent.  Maybe just have a knowledge base document somewhere describing this, instead of having this as an official feature of the FPGA toolkit.  The problem comes when you ask a user to turn on TurboBoost in their BIOS settings.  There are many different BIOS manufacturers, for many computer manufacturers and asking them to change any setting in there takes some time to find the right one.  


It isn't as simple as saying "Press F2 on startup, then go to Settings, and turn on TurboBoost"  Some BIOSes use the delete key, or F12, or F8, or F10, or the thinkpads have a blue button.  Then describing where the setting is won't work either.  I'm all for more exposure to this features, but I don't know what (if anything) NI can make simpler other then detecting if TurboBoost is already on, and using it if it is.

Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communicatin? Checkout my 9 part CAN Blog series.

Active Participant

Hoovahh wrote:


I'm all for more exposure to this features, but I don't know what (if anything) NI can make simpler other then detecting if TurboBoost is already on, and using it if it is.

That's all I'm asking for, Hoovahh. Motherboards that support TurboBoost generally have it enabled by default anyway, so a majority will see the benefit without having to do a thing if this is implemented.

As for instructions, it could be as simple as a footnote "Compilation speed can be supported by enabling the TurboBoost feature on selected motherboards. Consult your motherboard manufacturer's documentation to find out how to enable this feature".

Really I'm just asking for a little research to be done to see if there are any gotchas- e.g. cases where performance suffers rather than improves, and assuming there aren't, or those cases can be identified and avoided by not enabling the feature that the standard LabVIEW callchain includes the relevant switches (as Lorn outlined) to enable this enhancement.

I realise it's easy to create your own shortcut and use this 'hack', but currently it's something you have to remember to do every time you run LabVIEW, and the unofficial nature of it will put some people off.


I agree that this should be mentioned somewhere in NI documentation for LabVIEW FPGA.

Active Participant

I've taken the liberty of copying a quote from bwv1043 below to add some more corroborating 'evidence' and keep it all in one place-


"Just to give an update, I'm consistantly getting my 45-50% compile time savings using Turbo Boost.  I also tried Cloud Compile Server using 30-day eval code and the result is disappointing, 110 minutes."

Active Participant

By the way- anyone tried this tip who doesn't have Turboboost? Any advantage?


ToeCutter, it benefits even on a machine without Turbo Boost.  I have an older machine with Intel i3 and I always force Compile Worker to run on one core.  I can't tell you the numbers but the compile time is definitely reduced, although not as drastically as on i5 /w Turbo Boost.


I came back to post another question -


Has anyone experienced the compile process hang in Place and Route step?


My compile jobs often get stuck in Place and Route step but I cannot determine if it's caused by using this trick.  I can still cancel the compile so it's not like the compiler is frozen.  I can see that the CPU core is still running something.  It eventually errors out (fail to compile. Timing error) after sometimes 3 hours or up to 7 hours.


Rebooting machine before compile seems to reduce the chance of the compiler hang problem.  Again, I have no evidence that this actually helps.