FPGA: Xilinx Versions supported by Linux Version

[RSteinbrück]

Hey there,

I did not think that I would have to come back to this thread again, but I currently observe a problem with the Linux Compile worker that perfectly fits here.

The installation described above is now running on a work station for quite a while, doing a great job for FlexRIO compilations. The Linux worker is configured for 10 parallel jobs.

Recently I tried to compile a VI in LV2014 SP1 for a cRIO 9063, which requires Vivado 2013.4. The job has been transferred to the worker successfully. But compilation did not succeed without any further information. When I had a look on the Compile Worker window I could see, that the job was jumping around between the 10 workers. It even occupied several workers at once. After a while compilation was interrupted automatically. Restarting Compile Farm Server and Worker did not change the picture.

I suspected my project to be broken, but I could reproduce the behavior with the template project for NI9503 stepper motor module:

.

Can anybody confirm this misbehavior?

[User002]

Hi RSteinbruch,

Have you been able to reproduce this on another system?

Or another version of LabVIEW?

[RSteinbrück]

Hi Charles thanks for your answer.

No, I did not try another system yet, neither for the development system (LV2014 SP1), nor for the compile farm server (LV2015), nor for the Linux compile worker (LV2015).

Only thing I did, was successfully compiling the FPGA code with the local compile worker of the development PC.

I think setting up some virtual machines will be the fastest way to test it. Still it’s quite some work… Any hints where to start?

[QueenSelene]

Hi, 

This is possibly a shot in the dark but is there a way for you to set up a temporary system with just one compile worker, as part of the problem you were seeing was it jumping between the workers? Did you recieve any sort of error message explaining why the compilation was interrupted automatically?

[RSteinbrück]

So no one seems to have seen this problem, yet?! Could have shortened investigations to hit a known bug ...

Setting up test systems is on the way. I post results here ASAP.

[RSteinbrück]

Finaly I found some time to do further testing. I was able to reproduce the error with the following test setup

Virtual Machine #1 (Development System):

- Win7 Prof.

- LabVIEW 2015 Compile Farm Server

- LabVIEW 2014 SP1 -> LV-Project with cRIO9063 target with FPGA target with empty FPGA-VI

Virtual Machine #2 (Compile Worker System)

- Scientific Linux 6.6

- LabVIEW Compile Worker configured for sinlge job with following capabilities: Xilinx 13.4, Xilinx 14.4, Xilinx 14.7, Vivado 2013.4 (32 and 64 Bit each)

Virtual Machines are talking to each other over internal LAN. Compilation is working for FlexRIO as well as cRIO9073 FPGAs.

Trying to compile the empty cRIO9036-FPGA-VI led to an error and following reports:

Same Build Spec compiles succesfully when using the Windows compile worker on Virtual Machine #1.

[RichieTheBard]

There's a bug reported that could be related to what you are seeing here, where at least part of the error that you are getting seems to be the same onethat is reported. In that case it seems to be because of the Xilinx 32 bit compilation capabilities are used, and it shoudn't occur when the 64-bits capabilities are used, which I'm not sure if it could apply in this case, but it would be worth checking into. Unfortunately there's not a ton of details about this bug, but could you confirm if this might apply in your case.

[RSteinbrück]

Like written above the Linux Compile Worker has all capabilities in 32 Bit and 64 Bit. In case of the cRIO9063-FPGA the "Xilinx Vivado 2013.4" tools are needed.

- The worker runs in a 64 Bit Linux

- The 32 Bit LabVIEW (of course FPGA is not available in the 64 Bit version) runs on a 64 Bit Windows 7 Prof.

If this information confirms your assumption I would be happy. Actually it is an open question to me which of the Compilers (32 or 64 Bit?) is chosen and by whom (IDE, Server or Worker?). Hence I can not really tell if this causes the problem.

Can I find the bug report online? If so I'd be happy,if you could supply a link.

I also did not chose, which capabilities to install. I just consecutively executed the Linux Compile Worker installation scripts supplied by NI for LV2012SP1, LV2013SP1 and LV2015 like explained earlier in this thread.

[ahillinaustin]

Hi RSteinbruck,

I think RichieTheBArd is looking further into the bug reports concerning this specific crash. I was curious if you had any other FPGA targets to test this on, and whether you'd seen similar behavior on RIO Targets running Linux RT (as opposed to the 9074 which runs VxWorks).

Additionally, were you able to test this behavior on other VMs besides Scientific Linux?

Sorry for all of the questions, but we appreciate your help making our FPGA compile process better!

[RSteinbrück]

Hi, Thanks for looking into that issue!

Of course I could test this for virtually any cRIO (or other NI FPGA hardware) because I don't need the real hardware. I just add whatever target I want in the project explorer and try to compile an empty FPGA VI for it. At the beginning of course I stumbled over this problem with a real cRIO9063 and a FPGA VI with code. And I tried to compile it on our real Scientific Linux Compile Worker that is successfully working for several other projects. (By the way: the cRIO9063 project is working as well, when it is compiled with the local Windows Compile Worker of the development notebook). But In the end I could break down the issue to the trivial test setup described above without changing the error.

I don't think that the RT-OS is the problem, because the real system is not involved in the process. Maybe it's just coincidence of the new OS with a new FPGA needing a new and still buggy (sorry) worker capability.

No I did not test it with another Linux Distribution. In the past I tried CentOs 6.6 besides Scientific Linux. It behaved more or less identical to SL 6.6. I doubt that it would make sense to try it with CentOs. REHL would maybe be worse a try. But I don’t have a license for it.

If you see any concrete test I could conduct that helps to find the cause of the error, just tell me. I will do it ASAP.