FPGA: Xilinx Versions supported by Linux Version

[AndyBrown]

We do projects that cover many different versions of LabVIEW and therefore LabVIEW FPGA.  We recently setup a Linux Compile Worker and a Compile Farm Server.  We would like to use this worker for as many types of compiles as possible.  To this point we've been able to find 13.4, 13.4(64-bit), 14.4, and 14.4(64-bit) Xilinix tools for the Linux compiler worker.  Are the other Xilinx compile toolkits that have been used by LabVIEW FPGA available?  More specifically I'm looking for 10.1, 12.4, and 12.4(64-bit).

Thanks,

Andy

[dsFlux]

Hi Andy,

Only the Xilinx 13.4 and 14.4 tools are supported on Linux. This can be seen under the requirements section of "Setting up a Linux-based FPGA Compile Worker". This resource only lists 13.4 since the resource was made previously. I will double check with R&D to see if 10.1 is now supported, but I believe that only 13.4 and 14.4 are supported.

[T-REX$]

No need to check... 10.1, 11.5, and 12.4 are not supported. I know this leaves the Virtex-II boards out for linux compilations (781X). Your only options here (afaik) would be to add a Windows worker to either a new machine, a Windows VM on your Linux box, or the Windows machine that is running the compile server.

Additionally, there are 2 different versions of the 13.4 tools; one for RHEL 5.6, and one for RHEL 6.3. The 14.4 tools only run on RHEL 6.3, so if you want the compile worker to do both, make sure you grab the RHEL 6.3 version of 13.4 (they should all be 64-bit FYI).

[RSteinbrück]

Hi folks,

this thread is somewhat old but the topic fits to my question.

I would like a Linux Compile Worker to support LV2012SP1, LV2013SP1 and LV2014SP1 development.

On a Windows machine I have a parallel installation of LV2012SP1, LV2013SP1 and LV2014SP1. The local Compile Worker lists all corresponding capabilities: XILINX 13.4, XILINX 14.4, XILINX 14,7 and VIVADO 2013.4 each 32 and 64 Bit respectively.

Is this also possible for a Linux compile worker? How would it have to be installed? I tried to install several versions on a Scientific Linux 6.6 machine, but newer versions seem to replace older ones instead of adding capabilities!?

Regards
Reinhard

[Sil.VI]

Hi RSteinbrück, 

I have checked in the following document and for all your LabVIEW and Compile Tools versions the common supported Linux distro would be Redhat Enterprise 6.3. Which means that for the Linux Scientific it has not been tested so we cannot assure the correct funtionallity of the tools.

[RSteinbrück]

Hi S.Jimenez,

thanks for your answer. I'm aware of the compatibility issues.I successfully tested LV2013SP1 and LV2014SP1 FPGA workers individually with SL6.6. Both worked great. What I did not get to work is a Linux worker that supports all requested capabilities at once like the Windows compile worker does.

What is the installation behaviour under RHEL? Does a new version replace an older one or does it add capabilities?

Regards,

Reinhard

[T-REX$]

Hi Reinhard,

I just set up a VM to test the behavior that you're seeing, and didn't actually run into it myself. I wasn't using scientific linux, since I didn't have an ISO handy, but used CentOS instead. Here's my setup

Clean install of CentOS 6.6

[root@localhost home]# more /etc/*-release
::::::::::::::
/etc/centos-release
::::::::::::::
CentOS release 6.6 (Final)

[root@localhost home]# uname -r
2.6.32-504.el6.x86_64

After that, I had to install giflib to resolve some dependencies for the Xilinx Tools Installer (nothing else I have listed in my other post seem to acutally be needed)

[root@localhost home]# yum install giflib

Then, I pulled down and installed 2 different versions of the Linux Xilinx Tools Installer (for LabVIEW 13.0 and 14.1 I think). This corresponds to ISE 13.4 and ISE 14.7

It may be important that I did the 2013 installer, and then the 2014 installer, but I didn't try the other order, so I can't tell you for sure.

And finally... a bit of proof!

In short: not exactly the same as your setup, but I am successfully using a RHEL clone to instantiate different versions of LabVIEW FPGA Compile Farm Workers all on one machine.

[RSteinbrück]

Hi TJ,

Thanks a lot for your efforts! Following your suggestions I tried Centos 6.6 with the following results:

I installed a VM with the "CentOS-6.6-x86_64-netinstall.iso" and chose the "Software Development Option". After system setup I installed all availlable updates. Giflib seems to be included in the "Software Development Option":

[root@localhost rs6082]# more /etc/*-release
::::::::::::::
/etc/centos-release
::::::::::::::
CentOS release 6.6 (Final)
[root@localhost rs6082]# uname -r
2.6.32-504.16.2.el6.x86_64

[root@localhost rs6082]# yum install giflib
Loaded plugins: fastestmirror, refresh-packagekit, security
Setting up Install Process
Loading mirror speeds from cached hostfile
 * base: ftp.fau.de
 * extras: centos.bio.lmu.de
 * updates: ftp.halifax.rwth-aachen.de
Package giflib-4.1.6-3.1.el6.x86_64 already installed and latest version
Nothing to do 

After that I installed compile worker for LV2013SP1 (Xilinx 14.4) and tested it with a compile of an empty FPGA-VI. Connection to FPGA compile server worked without problems. But compilation worked only after installation of the additional packages from your other post:

yum -y update glib2 libuuid

yum -y install glibc.i686 libstdc++.i686 libgcc.i686 libuuid.i686 zlib.i686 glib2.i686 libSM.i686 libXi.i686 libXrender.i686 libXrandr.i686 freetype.i686 fontconfig.i686

Then I installed LV2014SP1 (Xilinx 14.7) and again it killed the older version ...

The Xilinx 13.4 - Tools are to my knowledge part of LV2012SP1. I haven't been able to install this version due to the problems described in this post.

I did not try your suggestion there to build the mono-packages from source so far. I assume I tried with the wrong installer, meant for RHEL5.6. Download of Xilinx13.3 SP1 still needs some hours...

I try your combination 13.4 + 14.7 as soon as possible.

Regards

Reinhard

[T-REX$]

I think I may have discovered the issue here, but I didn't take enough intermediary screenshots, and it will likely involve more testing to prove my theory.

I think the issue lies with 14.4 and 14.7 being installed simultaneously. After getting 13.4 and 14.7 installed side-by side yesterday, I decided to try adding 14.4 thismorning when you said you were still having problems. After this, only 13.4 showed up in the compile worker window. Weird. I looked back through the console spew, and noticed that the older version of the compile worker successfully installed, but Xilinx reported that ISE 14 was already installed, and gave up [bug #1, that version wasn't already installed].

The old version of the worker doesn't know about the new version of the tools, so I think that's forgivable, but I don't think the old version should install over the new version [bug #2].

I then decided to install the Vivado 2013 Xilinx tools (shipped with LV 14.0), and can now see 13.4, 14.7 (again, without reinstalling the tools themselves), and Vivado 2013.4. This makes sense because we're back at the 2014 version of the compile worker that can see the 14.7 Xilinx tools.

I think what's happening in your scenario is similar, except the 14.7 tools are reporting that they're installed when in reality it's the 14.4 Tools. I could be wrong about that though. Will you do me a favor and run:

ls /usr/local/natinst/NIFPGA/programs

I'm going to ask around to confirm what we're seeing before I file bug reports, and that involves sending some emails over seas... so it may be a few days before I have any real confirmation or further update.

As always, let me know if you have any questions or comments.

[RSteinbrück]

First a short update to my VM state: after the observations reported above I tried to reinstall LV2013SP1-FPGA-Worker (14.4). Worker console now looks like this:

Hopefully ls still tells you what you want to know:

[root@localhost rs6082]# ls /usr/local/natinst/NIFPGA/programs/
xilinx14_7

If not, let me know. In that case I'll reproduce the former installation state.

Don't worry if it takes some time to solve the problem. I'm glad, that you're taking care of it!

By the way, I wonder if this issue would also show up on a RHEL 6.5 machine!?