installing NI-LVFPGA un ubuntu 20

[ensegre]

Has anyone succeeded in some way to get it functional? I'm trying to set up a modern development environment for a project using a legacy PCIe-7852R. That demands ISE 14.7; On windows 10 that in turn is recognized by the FPGA installation of LV2014, but not supported on more recent versions of LV. The solution hinted by NI is to move to a win7 platform, but I haven't found one available at the moment.

What I did is, as I usually do, grab all the rpms from the content of the iso I downloaded from https://www.ni.com/en-il/support/downloads/software-products/download.labview-fpga-compilation-tool.html#346211, move them to a /tmp directory and run on them alien --install --scripts *.rpm (and solving some small conflicts on the way). I chose the 2019 version for installing on a machine with LV2019 and 2021 already installed in the same way.

At the end of the process I'm left with respectable directories /usr/local/natinst/nifpgacompileworker (15MB), /usr/local/natinst/NIFPGA/ (9.4GB) and /usr/local/natinst/mono (94MB), but neither LV2019 seems to be aware of a FPGA module (would it?), nor I know how otherwise run the compilation tool (e.g. for example to convince the win10 machine that the linux one could act as compilation server).

Any idea? How is the FPGA module really working on a supported linux target, rpm based, where it is installed using the proper INSTALL script provided by NI?

[Rolf Kalbermatter]

On 11/11/2021 at 9:41 AM, ensegre said:

Has anyone succeeded in some way to get it functional? I'm trying to set up a modern development environment for a project using a legacy PCIe-7852R. That demands ISE 14.7; On windows 10 that in turn is recognized by the FPGA installation of LV2014, but not supported on more recent versions of LV. The solution hinted by NI is to move to a win7 platform, but I haven't found one available at the moment.

What I did is, as I usually do, grab all the rpms from the content of the iso I downloaded from https://www.ni.com/en-il/support/downloads/software-products/download.labview-fpga-compilation-tool.html#346211, move them to a /tmp directory and run on them alien --install --scripts *.rpm (and solving some small conflicts on the way). I chose the 2019 version for installing on a machine with LV2019 and 2021 already installed in the same way.

At the end of the process I'm left with respectable directories /usr/local/natinst/nifpgacompileworker (15MB), /usr/local/natinst/NIFPGA/ (9.4GB) and /usr/local/natinst/mono (94MB), but neither LV2019 seems to be aware of a FPGA module (would it?), nor I know how otherwise run the compilation tool (e.g. for example to convince the win10 machine that the linux one could act as compilation server).

Any idea? How is the FPGA module really working on a supported linux target, rpm based, where it is installed using the proper INSTALL script provided by NI?

LabVIEW realtime and LabVIEW FPGA are pure Windows (32-bit only before 2021) extensions. The Linux downloads you found are for the Xilinx toolchain. You can install them under Linux, then setup your Windows FPGA compile interface to interface to them just as it does when you use the NI cloud compile solution.

[ensegre]

Thanks Rolf. So far what I understood, after some search on NI site and getting more familiar with the terminology ("compilation worker", "target support driver", etc.), is that NI decided not to include the PCIe-7852R target support in versions of the Windows LV FPGA module past 2014, even though with LV up to 2021 it installs ISE 14.7 as part of the toolchain which, as for Xilinx is concerned, might support it. So even if I was able to set a linux compile worker and point it to an appropriate machine (and in fact I can - to the NI FPGA cloud), I'm still stuck with LV 2014 for development. For this particular project, I think I'll split it to a FPGA backend built with 2014, whereas the fancy UI and business logic could be in 2021, with some intercommunication between the two - udp, datasocket, VI server, something.

The academic question about whether it is possible to install the compile worker on ubuntu still stands though... I remember that, digging into, the compile worker would have been launched with mono, and launching complained about a missing dll. Tomorrow I might be more precise about the error I got.

[ensegre]

that is,

$ /bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe'

Unhandled Exception:
System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.so
  at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
  at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Drawing.Graphics.FromHdcInternal (IntPtr hdc) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11..ctor () [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11.GetInstance () [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUI..cctor () [0x00000] in <filename unknown>:0
  
  
$ locate libgdiplus.so
/usr/local/natinst/mono/lib64/libgdiplus.so
/usr/local/natinst/mono/lib64/libgdiplus.so.0
/usr/local/natinst/mono/lib64/libgdiplus.so.0.0.0

Edited November 14, 2021 by ensegre

[Rolf Kalbermatter]

On 11/14/2021 at 9:20 AM, ensegre said:

that is,

$ /bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe'

Unhandled Exception:
System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.so
  at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
  at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Drawing.Graphics.FromHdcInternal (IntPtr hdc) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11..ctor () [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUIX11.GetInstance () [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.XplatUI..cctor () [0x00000] in <filename unknown>:0
  
  
$ locate libgdiplus.so
/usr/local/natinst/mono/lib64/libgdiplus.so
/usr/local/natinst/mono/lib64/libgdiplus.so.0
/usr/local/natinst/mono/lib64/libgdiplus.so.0.0.0

Most likely that compile worker is a 32-bit application and you only have 64-bit libgdiplus installed?

Or another possibility, the /usr/local/natinst/mono/lib64 directory was not properly added to the /etc/ld.so.conf file and/or ldconfig was not executed afterwards

Edited November 18, 2021 by Rolf Kalbermatter

[ensegre]

The download page says that the package is for 32bit, but all the rpms provided in it are x86_64, and so assumes the INSTALL file at quick skimming through it; OTOH

$ file /usr/local/natinst/nifpgacompileworker/CompileWorker.exe
/usr/local/natinst/nifpgacompileworker/CompileWorker.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

I added /usr/local/natinst/mono/lib64 to /etc/ld.so.conf and sudoed ldconfig, but I remained at the same point. I think I'll leave it as "whatever", for now, I see that for the project in question I have other compilation options, so I can live without. But thanks anyway for the feedback, Rolf!

[ensegre]

Coming back to it, after one year.

It turned out, my installation of the worker does run, it was only the gnome menu item which fails: its associated command

/bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe'

fails because of mono, as reported above. Omitting mono, or even just running /usr/local/natinst/nifpgacompileworker/CompileWorker.exe directly, the worker comes up, and I do connect to a Windows machine on which LV14 runs as a compilation server. So far so good.

  

Now if I launch the FPGA compilation on the Windows machine, the preliminary steps are done, the job is submitted to the linux worker (I see logs of it both in the compilation window and on stdout of the linux machine). However, the compilation errors out at its very beginning. The log tells essentially

/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory

which looks to me as a bitness problem. To test, I have tried to launch

$ export LD_LIBRARY_PATH=$DIR:/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/lib/lin/:$LD_LIBRARY_PATH; /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg
/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory

whereas I note that I have also lin64 directories, and indeed to call

$ export LD_LIBRARY_PATH=$DIR:/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/lib/lin64/:$LD_LIBRARY_PATH; /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin64/_cg
The XILINX environment variable is not set or is empty.

seems to bring one step forward.

Any idea how I could move on from here? I thought of renaming various lin64 directories to lin, but it looks to me like running into a rabbithole.

Additional detail, in the meantime I upgraded to "LabVIEW 2020 FPGA Compilation Tool for ISE 14.7". These are not yet officially supported on Ubuntu, so alien --install --scripts.

Edited December 22, 2022 by ensegre

[ensegre]

Wow,

cd /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE
sudo mv lin lin32
sudo ln -s lin64 lin

just did it. Compilation time on the linux machine in this case turned out to be 33% larger than locally on the windows machine, but anyway.