In Nutaq’s ADP software suite, the Real-Time Data Exchange (RTDEx) library1 lets you benefit from fully tested data transfer pipes between an FPGA carrier with a host computer or between two FPGA carriers. For the Perseus FPGA carrier board2 (used in the Pico series products3,4,5), the RTDEx library supports two types of physical media: Gigabit Ethernet (GigE) and PCI Express (PCIe).

Even if PCIe has higher throughput capability and lower latency, GigE has some significant advantages – the main one being its lower complexity. Nowadays, nearly every desktop computer includes GigE network interface card. You can create a communication link simply by plugging in an Ethernet cable between the Perseus system and the host computer and configuring them to use the same subnet.

RTDEx GigE library

In the RTDEx library, to maximize the GigE throughput, the pcap library6 is used to create and receive raw Ethernet packet instead of using higher-level transmission protocols like TCP/IP. TCP/IP adds overhead in the packet and is more computationally intensive. However, the TCP/IP protocol produces a reliable link, something the Ethernet layer alone cannot guarantee. This limitation with the RTDEx GigE library is not critical though. Being a “real-time” library, it operates in a real-time way: if a packet cannot be received or processed immediately, it should be dropped!

The RTDEx library is also used to retrieve recorded data from the 4 GB of DDR3 memory onboard the Perseus. When the desired data is recorded in memory for offline post-processing, the transfer to the host computer does not need to be in real-time. Thus, since there is no transfer time constraint in this case, it is normal to want a reliable link between the memory and the host computer.

Reliable data retrieving

Once the memory is configured to send data to the host computer, the computer needs to be ready to receive and save all the Ethernet packets. Since the RTDEx GigE library is not reliable, how can you be sure no packet is dropped?

It’s possible to avoid packet loss by increasing the time between two consecutive RTDEx packets in order to give the host computer more time to read the RTDEx buffer. This can be a good approach but the overall transfer throughput will need to be lower than the worst case of the computer’s capability. For example, a computer may be able to handle an average throughput of 100 MB/s, but due to other processor activities, it can sometimes drop momentarily to 30 MB/s. Therefore, the time between RTDEx packets must be configured to provide a 30 MB/s or lower throughput to avoid packet loss. With this modification, the overall transfer time is increased.

Here’s a basic data retrieval example in pseudo-code. One big RTDEx transfer is used to retrieve all the desired data from the DDR3 memory:

RecPlaySetModeRecord                                  // Configure the record

RTDExOpenEth                                                 // Open the RTDEx GigE link

RTDExSetTxFrameGapValEth                        // Set the time between RTDEx packets to avoid any packet loss

RecPlaySetModeRtdexMem2Host                 // Transfer memory data to RTDEx value

RTDExStart                                                        // Start the RTDEx transfer to host

RTDExReceive                                                  // Receive the data on the host computer

Verify packet loss                                             // Verify if all the requested data are received

RTDExCloseEth                                                // Close the RTDEx GigE link

To perform a reliable data transfer, the host application must be programmed to check for missing packets and request a new transfer if required. Asking for a new transfer is possible in this case because the application is not real-time and all the data is saved in the DDR3 memory. In the above example, packet loss is only detected at the end of the program and another big, time-consuming transfer would be launched again, even if only one packet is lost.

The following example shows how to add simple logic to the host application in order to have a reliable data transfer while keeping a good transfer throughput:

RecPlaySetModeRecord                                              // Configure the recordwhile all data not received                                           // Read memory sections until all memory data are received 

      RTDExOpenEth                                            // Open the RTDEx GigE link

      RTDExSetTxFrameGapValEth                  // Set a very small time between RTDEx packets

      RecPlaySetModeRtdexMem2Host          // Transfer a memory section to RTDEx value

      RTDExStart                                                   // Start the RTDEx transfer to host

      RTDExReceive                                             // Receive the data in the host computer

 

Verify packet loss                                                          // Verify if all the data of the requested section is received

If no packet loss

Go to the next memory section

If packet loss

Retry the same memory section

 

      RTDExCloseEth                                               // Close the RTDEx GigE link

 

end while

 

In this code, the frame gap can be set at the computer averaged throughput capability (100 MB/s). Even if a packet is occasionally lost, because the RTDEx transfer is split into multiple small bursts, requesting the same memory section again will not take too much time. Using this new application, transferring the entire memory contents to the host computer is reliable even at higher transfer rates.

References

1.            https://www.nutaq.com/blog/overview-rtdex-library
2.            https://www.nutaq.com/products/perseus-601x
3.            https://www.nutaq.com/products/picosdr
4.            https://www.nutaq.com/products/picodigitizer-125-series
5.            https://www.nutaq.com/products/picodigitizer-250-series
6.            http:/https://www.nutaq.com.wikipedia.org/wiki/Pcap