niFPGA - Python api, cRIO FIFO communication

[Zulsig]

Hi

This is going to be highly theoretical questions mainly concerning the python API for LabVIEW's FPGA control - https://nifpga-python.readthedocs.io/en/latest/

The programming part is not the main concern here, but only to give you an idea of my needs.

My goal is to make a program that by the help of two cRIO-9074 chassis, several digital and analog C-series slots can deliver a signal to a given time. The given values that are to be sent to the C-series slots at the time is to be stored in a matrix send from the computer by the python API. The whole program will then execute at a command. I hope to store something around 50x150 array with True/False and fixed point values, so i hope that the FIFO's will do the job.

The questions - All communication is from the python API from a host pc to the target FPGA:

• How does the session when using the API, establish a connection ? A bitfile is being loaded, and a reference. Is the cRIO's adress saved in that bitfile ?
  
• When make use of the example below and a bitfile containing two FIFO's that writes and read into each other (See picture below), how is the communication carried out ? (TCP/IP, shared variables...)
  (When writing to variables through the API, is it done by the same communication, and is it as fast as the FIFO ?)
  

  from nifpga import Session
  
  # create a list of 100 incrementing values
  data = list(range(0, 100))
  
  with Session("MyBitfile.lvbitx", "rio://hostComputerIP/FPGA_2") as session:
      host_to_target = session.fifos['Host To Target Fifo']
      target_to_host = session.fifos['Target To Host Fifo']
      host_to_target.start()
  
      # stream the data to the FPGA
      host_to_target.write(data, timeout_ms=100)

  
  

[Raz21]

Hello Zulsig,

Thanks for the explanation. 

Let s take the questions one by one. 

How does the session when using the API, establish a connection? A bitfile is being loaded, and a reference. Is the cRIO's adress saved in that bitfile ?

I will add here an image which describes the communication between your Host PC and FPGA. As you can see, everything needs to pass via the RT layer. 

When you run the code, you would need to open the FPGA reference from the RT layer which will indicate where the bitifle is and load it on the FPGA. You must open a reference to the FPGA target before you can communicate between the host VI and the FPGA VI. Why do you ask about the cRIO address? 

When make use of the example below and a bitfile containing two FIFO's that writes and read into each other (See picture below), how is the communication carried out ? (TCP/IP, shared variables...)
(When writing to variables through the API, is it done by the same communication, and is it as fast as the FIFO ?)

This is done via DMA (Direct Memory Access) FIFO. The communication implementation is DMA. A FIFO is a data structure that holds elements in the order they are received and provides access to those elements using a first-in, first-out access policy.

I hope that this is clear.

[Zulsig]

Hi Raz21,

Thanks for the answers.

In the question regarding the session that establishes a connection, you ask why i mention the cRIO address.

- I am having a hard time figuring out how the connection between the host computer and cRIO is established purely from the compiled bitfile and resource link when the same network:

with Session("MyBitfile.lvbitx", "rio://hostComputerIP/FPGA_2") as session:

As the picture you uploaded clearly states, the communication between the host PC and the cRIO is carried out through the Ethernet, therefor some sort of address must be present to tell where to find the cRIO device.

The only way i can make sense of it, is if the address (IP, MAC, or something else) is contained in the bitfile.

I didn't realise that DMA was a communication method thank you for clearing that up!

My follow up question is then how the DMA transmits data. As stated before, the host PC must communicate through ethernet, is that all, or am i missing something ?

Thanks again.

[Raz21]

Hey Zulsig,

Apologize for the late response. 

There are more ways to load an FPGA bitfile to the FPGA chip. For more info check this link. 

You can only have DMA between the RT and FPGA, not RT-PC or FPGA-PC. The data is directly transferred from FPGA to the memory of the RT system without any interruption. 

DMA Overview: 
Direct memory access (DMA) FIFOs transfer data from the FPGA directly to memory on the RT 
target. DMA FIFOs can stream large amounts of data between the FPGA VI and RT VI. This 
allows the FPGA to use the RT target RAM as if it were its own. This offers significant 
performance advantages over using the RT target CPU to read from or write to controls and 
indicators on the FPGA VI. 
With DMA FIFOs, the RT target processor can perform calculations while the FPGA target 
transfers data to the RT target memory. FPGA targets that support DMA FIFOs have direct access 
to write to memory on the RT target without involving the RT target processor. Without DMA 
FIFOs, you can transfer data only through the RT target processor. LabVIEW performs DMA 
transfers through bus mastering. FPGA targets that support DMA FIFOs can master the PCI bus. 
The FPGA target controls the PCI bus and accesses memory directly without needing to access the 
RT target processor. 

Any questions, please let me know. 

[Michael_Strain · Accepted solution]

When you open an FPGA Session with a resource name like "rio://hostname/deviceName" RIO under the hood opens a TCP connection to the NI-RIO Server running on your target.  The session you get back abstracts away the network transfers and for the most part the device will act like a local device.  You are passing in the ipaddress or hostname in the resource string, its not stored in the bitfile or anything.

When you use Read and Write DMA FIFO with a remote session, DMA occurs with the FPGA writing to a buffer on the server side, then the data is transferred over the network connection to the client.  Some functions are not available when using a remote session such as GetPeerToPeerEndpoint, those functions will return the FeatureNotSupported Error.

[Zulsig]

Thank you so much Raz21 and Michael_Strain.

Michael_Strain had the answers i was searching thank you very much! 

But many thanks to you too Raz21, you enlightened me on many things i hadn't realised yet!

[ba_0101]

Not sure about the Python implementation, but with regular LabVIEW I reduced my device's CPU load by 50% by specifying the non-IP related reference. See here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000004BIiSAM&l=en-US

Not sure why LabVIEW can't be smart enough to optimize which reference is used.