Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW and FPGA C API simultaneous access?

Solved!
Go to solution

Use case: have 7820R, 7858R, 7975R FPGA cards being accessed currently under CentOS 7 via the FPGA C API (not using LabVIEW/CVI). The 7975R is digitizing data that I would like to display (as an oscilloscope display) under LabVIEW running on the same computer at the same time as the C program running. Ideas on what's possible or how to implement?

1. The FIFO on the 7975R is not in use in the C program.

2. Does the underlying NI software subsystem allow two programs to access the same card at the same time?

3. We have a LabVIEW program on Windows that we want to port to LabVIEW Linux.

 

Ideas I'm thinking about:

1. Use the 7975R FIFO on the LabVIEW side, have the FPGA fabric stream the data via the FIFO, at the same time the C API is accessing the FPGA fabric (is this even possible?).

2. Stream the data via the 7975R FIFO to the C program, then push the data to the LabVIEW program via a UDP socket.

3. Install another FPGA card and do peer-to-peer from the 7975R to the other FPGA card, then LabVIEW accesses the other card.

4. Other?

 

Lorn Hartshorn

Electrical and Software Engineer

Amentum Inc.

0 Kudos
Message 1 of 4
(3,629 Views)
Solution
Accepted by Lorn

Using the same FPGA device from LabVIEW and C at the same time is fine, there are a few limitations though.

1. Both LabVIEW and C must use the same bitfile.

2. An individual FIFO can only be used by one process.  If you attempt to use the same FIFO in multiple processes you will get a FifoReserved error.

 

 

One other thing to note, LabVIEW FPGA is currently not supported on linux desktop. This means that the LabVIEW FPGA Host Interface isn't available in LabVIEW for linux desktop.  I'm aware of customers that have successfully used Call Library Nodes to call into the FPGA Interface C API from LabVIEW on linux as an alternative.

Message 2 of 4
(3,598 Views)

I stumbled on your document regarding Python and FPGA interface. I may use Python since I want to combine a digitized waveform from the FPGA with video using OpenCV, under Linux, at the same time a C program is accessing the FPGA. But I noticed in the Python examples, and this probably applies to LabVIEW and C API, wouldn't there be a conflict between opening FPGA sessions in both C and LabVIEW (through a C call node) at the same time, even with the same bitfile (and this would apply to Python also since your document examples show opening a session)? Or would I need to open the bitfile on one side and tell it to run, and open the bitfile on the other side and tell it to do nothing (as in don't run), since the bitfile would already be running? Does opening a session always automatically load the bitfile to the FPGA? You mentioned customers have done the C API call node in LabVIEW Linux, I'm just wondering how one pulls off separate sessions between two programs at the same time without causing a bitfile load conflict. I would only be accessing an FPGA FIFO from one program.

 

https://nifpga-python.readthedocs.io/en/latest/

 

Thanks!

 

Lorn Hartshorn

Electrical and Software Engineer

Amentum

0 Kudos
Message 3 of 4
(3,578 Views)

Opening a Session to an FPGA with either download the bitfile if its not already on the device or just connect to the FPGA if the bitfile is already downloaded. 

 

Using the same device from multiple processes requires a little extra design in how your startup works.  If you are using the Reset and Run methods, you likely only want to call them from a single process.  For your case, it sounds like your C process would start the FPGA and your process that is displaying information would probably just connect to it without changing the state of it. 

 

Note that for more recent driver versions we have added a call to query whether or not the FPGA is already running: https://github.com/ni/nifpga-python/blob/master/nifpga/session.py#L174 That can be helpful in determining what to do during startup.  Its not yet in the shipped C API headers, but should be in the future.

Message 4 of 4
(3,562 Views)