From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW FPGA Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
AndyBrown

Improve Compile Retrieval Process

Status: New

Long compile times are a necessary evil of FPGA code.  Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency.  As compile times approach 3-4 hours, their successful completion becomes paramount.  All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost.  It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file.  The only solution is to restart the compile costing another 3-4 hours of productivity.

 

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight.  Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning.  By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight.  If one of the compiles fails because of timing or resource problems, there's nothing that can be done.  But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

 

I propose that the current methods for compiling bitfiles be modified.  The goal is to improve user productivity.  Some of my suggestions include:

  • For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
  • If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
  • Make sure that all of this still works when changing connections to the worker.  For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
  • Don't remove any chance to get a compile if there was a communication error.  Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.
Systems Engineering - National Instruments
1 Comment
kdnelson
Member

I'm shocked that this idea doesn't have 10000 kudos.  How has it languished here for > 2 years?!  Every FPGA developer has lost bitfiles due to a disconnected compilation; the lost time must total millions of hours.  We need to get out the word about this idea so we can get NI's attention.