FPGA Compile error on remote compile worker - but not on local!?

[Mauritius]

When i compile using Rebuild for building my VI to FPGA on NI cRio-9082 I get this:

Then I kill the compile worker on the develop machine, to use remote compile worker.

Then i get this:

Should the timing constrains not be the same? 

Last lines in Xilinx log:

-------------------------------

....

Process "Generate Post-Place & Route Static Timing" failed
   done.

-------------------------------

[Mauritius]

Can anyone give a hint or are there missing some information?

BTW.

The local compiler is a WIN NT 6.0 and the remote compile worker is a RHEL 5.6 x64.

The compile server is on the WIN NT 6.0 as is the NI Develop Suite.

Any help or suggestions will be appreciated.

[A.Rohde]

Could you try to post the whole XilinxLog.txt?

You are right in that the timing contraints should be the same, but you can never garantee that the PC's will layout the design in the same way. Both PC's use different seed on the compilation (which is partly random), and it will optimize differently on Windows and on Linux. But it should compile especially when you are not using up that many ressources.

If you compile a very simple example (like 2 controls, 1 indicator and an addition) does the remote compile then compile the code correctly?

Have you tried compiling your code a couple of times on the remote machine to see if you get different results?

Best Regards

Anders Rohde

[BradM]

Yes, please post the entire Xilinx log as that last line is like some bad popup error dialog: technically correct but basically useless

[Mauritius]

Sorry for the delay, but needed to recompile using server aka. wait almost 1 hour.. 🙂

Do you need the log from the succesful build also? 

Have compiled som other FPGA code on remote server succesful.

It is just wierd this one fails on remote, but passes on local.. :-S

[Nick-C]

Looks to me like you're failing the place & route phase because you've overmapped IOBs. You can reduce IOB usage by removing front panel items on your top level fpga VI. If you cannot remove any controls / indicators, you can pack data from multiple controls into a single control. For example instead of using 4 16 bit integers, pack all that data into a single 64 bit integer (it's more efficient from a resource standpoint).

-Nick-

[Nick-C]

I think it's likely that your design sometimes succeeds compilation and fails others. How many times have you succesfully the VI as it stands now on the local machine? How many times have you failed compilation on the remote worker?

If you've only tried one or two compilations on each, it may be conincidince that it's failing on the remote worker and succeeding on the local worker. The design pushes resource limitations and may succeed some of the time (the compiler has some random elements to it that make this possible). You might try running several (> 5-10) compilations on the remote server and see if it consistently fails.

-Nick-

[Nick-C]

Mauritius,

Brad and I took a closer look at the Xilinx log and we see a line printed that will hopefully help us narrow down the problem. Immediately after completion of the Analysis phase the log has the following line recorded:

*** glibc detected *** /usr/local/natinst/NIFPGA/programs/xilinx13_4/ISE/bin/lin/unwrapped/trce: double free or corruption (!prev): 0x09fd05e0 **

It seems there is a problem with the linux worker attempting to free the same memory twice which may be causing the compiler to exit during the mapping phase. We have a few more questions and would like to take a closer look into things for you.

1. Will any other designs compile succesfully on this linux worker (even very basic VIs)?

2. If other designs compile, will a simpler version of this design still fail consistently?

3. If the failed compilation seems to be design specific, would you be willing to provide your design for us to try and reproduce the failure?

Feel free to personal message me if necessary.

-Nick-

[Mauritius]

Seems like you have been busy glancing log-files. 🙂

Thanks for input sofar.

1: Yes, another FPGA design, on the 9144 FPGA compiles on both compile-workers.

2: I will try as soon as i got the time for it.

3: I do not think i can, as it is company's property, but i can dump log of the compiled one (9144 FPGA) if needed..

And it is (9082 FPGA code) consistent in failing on remote linux worker and passing on local windows worker.

Can i help in any other way?

[Mauritius]

Just an update.

I do not think the time spend on getting this to work is worth while, so i have uninstalled the linux 5.6 server.

Will try to install 5.6 in a box, so it can be moved around more easily.

If it still fails or work I will let you know. 🙂

Time is at the moment confined, but hopefylly there will be some updates soon 😄

Thanks for help sofar..