LabVIEW fpga compilation : translate error then translate again

[pnouvel]

Hello everybody,

I have a question about the LV FPGA compilation process. 

The context : 

I'm compiling a FPGA binary for the NI-5644R (viterx6 inisde). the process is quite long (up to 7h depending how full is our CLIP). I'm prospecting any idea to fasten the compilation process.

The fact :

By parsing the log file of the previous compilation, I notice that the translate step is done twice, probably because the first one is failing. the log files extract are copy/pasted hereafter.

Going further, it seems the errors (at least some of them) of the first translate are induce by commented lines of the NI provided UCF file (RfRioFpga.ucf)  

The question : 

Why is the translate step need to be done twice (the first being failed) ? wouldn't it be faster to to do only the second succefull one ? in other words, is it really necessary to to the first failing translate step to get the FPGA binay ?

Any ideas ?

thanks in advance !

Cheers,

Patrice

----

log file extract 1: 

"...

NGDBUILD Design Results Summary:
Number of errors: 387
Number of warnings: 1443

Total REAL time to NGDBUILD completion: 2 hr 16 min 45 sec
Total CPU time to NGDBUILD completion: 2 hr 11 min 21 sec

One or more errors were found during NGDBUILD. No NGD file will be written.

Writing NGDBUILD log file "RfRioFpga.bld"...

Process "Translate" failed

..."

log file extract 2: 

"...

NGDBUILD Design Results Summary:
Number of errors: 0
Number of warnings: 818

Writing NGD file "RfRioFpga.ngd" ...
Total REAL time to NGDBUILD completion: 29 min 17 sec
Total CPU time to NGDBUILD completion: 27 min 33 sec

Writing NGDBUILD log file "RfRioFpga.bld"...

NGDBUILD done.

Process "Translate" completed successfully

..."

[Kyle_G · Accepted solution]

Hi Patrice,

It definitly seems strange that it runs this step twice (and worried me when I first saw it), but there's good reason for this.  Labview inserts constraints for components it adds in, however sometimes the components get optimized out by the compiler.  When the compiler runs into a constraint that points to the now non-existant component, it errors out.  Labview gets around this by running the translate process twice. The first time it may fail. Labview will remove the constraints that fail, then re-run translate.  Unfortunately there's no way to get around this.

[pnouvel]

Hi Kyle_G, 

thanks for this fast answer. It makes sense. 

Is there any way to get the original ucf file and directly comment the non-used constraint ? I suppose this is a crypted or hidden file ?

thanks anyway for your answer

[Kyle_G]

The ucf file does not get encrypted, however the constraints that cause the initial failure are generated at compile time, so it wouldn't be possible to just remove those before compiling it.