UDP10G-IP Reference Design Manual
2.1.2 10G/25G Ethernet Subsystem
2.1.3 Versal Multirate Ethernet MAC Subsystem
3.6 Function List in CPU Firmware
1 Overview
Compared to the TCP protocol, UDP minimizes protocol mechanisms during data transmission. Unlike TCP, it does not include a handshake or a data recovery process to ensure accurate data reception by the receiver. However, like TCP, UDP provides checksums to maintain data integrity and port numbers for addressing different functions at the source and destination within a network.
Figure 1 illustrates the UDP/IP protocol layers, which consist of four primary layers: Application, Transport, Internet, and Network Access. The Network Access layer is further divided into two sublayers, Link and Physical, to link them with the hardware implementation using an FPGA.
Figure 1 UDP/IP Protocol Layer
The PCS and PMA modules are provided by AMD at no charge for each FPGA, while the Ethernet MAC (EMAC) module can be implemented through several solutions such as the 10G25GEMAC-IP from Design Gateway, the 10G/25G Ethernet Subsystem from AMD, and the Versal Multirate Ethernet MAC (the Hard IP).
The UDP10G-IP implements the Transport and Internet layers of the UDP/IP Protocol entirely in hardware logic, eliminating the need for a CPU or DDR memory. This architecture allows user logic to process UDP payload data directly at the user interface of the UDP10G-IP. The UDP10G-IP is responsible for constructing Ethernet packets by encapsulating user-provided UDP payload data and transmitting them to the Ethernet MAC (EMAC). If the payload size exceeds the Ethernet packet’s maximum size, the UDP10G-IP partitions the data into multiple packets. To form a complete Ethernet packet, the UDP10G-IP processes and appends the UDP/IP header before transmission. When receiving Ethernet packets from the EMAC, the UDP10G-IP verifies each packet. Valid packets result in UDP payload data extraction and forwarding to the user logic, while invalid packets are discarded.
This reference design comprises simple user logic, UDP10G-IP, and Ethernet MAC system designed for data transfer using the UDP/IP protocol. Data transfer can occur with two targets, PC or other FPGA integrating UDP10G-IP. Design Gateway provides a PC test application, named “udpdatatest”, to facilitate single-session UDP data transfer. This application allows users to configure the data direction (send or receive).
To provide flexibility during testing, users can modify test parameters and control the UDP10G-IP demo operation via UART interface integrated with a CPU system. The console enables users to monitor system status and configure test parameters. The CPU firmware is developed using a simple bare-metal OS. Further details of the demo are outlined in subsequent sections.
2 Hardware
Figure 2 Demo Block Diagram
In the test environment, data transfer over a 10G Ethernet connection involves two devices. As illustrated in Figure 2, the first device is an FPGA initialized in Client mode, while the second device can be either a PC or another FPGA initialized in Server mode. When two FPGAs are used, additional initialization options are available, such as Client <-> Fixed-MAC or Fixed-MAC <-> Fixed-MAC. A test application, “udpdatatest”, is provided to facilitate data transfer using the UDP/IP protocol between the PC and FPGA.
The processor system allows users to configure test parameters via a Serial console, monitor test progress, and observe system status. The CPU firmware manages command execution, enabling enhanced interaction, and control over the testing process.
2.1 Ethernet Subsystem
2.1.1 DG 10G25GEMAC-IP
Figure 3 Ethernet Subsystem using DG 10G25GEMAC-IP
This configuration minimizes FPGA resource utilization by allowing the UDP10G-IP to connect directly with the DG 10G25GEMAC-IP, eliminating the need for additional adapter logic. The Ethernet Subsystem is composed of two separate IP cores: DG 10G25GEMAC-IP and 10G Ethernet PCS/PMA.
DG 10G25GEMAC-IP
This IP core implements the Ethernet MAC layer with a 64-bit interface running at 156.25 MHz, making it suitable for 10G Ethernet operations. It directly interfaces between the UDP10G-IP and the 10G Ethernet PCS/PMA from AMD without requiring additional logic. Further details can be found on the Design Gateway website.
https://dgway.com/products/IP/GEMAC-IP/dg_10g25gemacip_data_sheet_xilinx/
10G Ethernet PCS/PMA (10GBASE-R)
The 10G Ethernet PCS/PMA (10GBASE-R) is a no-charge IP core provided by AMD. It features a 64-bit XGMII interface operating at 156.25 MHz, designed for 10G Ethernet speed. More information is available on the AMD website: https://www.xilinx.com/products/intellectual-property/10gbase-r.html
The reference design configuration settings for the 10G Ethernet PCS/PMA IP core using the IP wizard are as follows.
· General/ Select Core : Ethernet PCS/PMA 64-bit
· General/ Speed : 10.3125G
· PCS/PMA Option/ Base-R/KR Standard : BASE-R
· User Interface/ Control and Statistics Interface : Control and Status Vectors
2.1.2 10G/25G Ethernet Subsystem
Figure 4 Ethernet Subsystem using 10G/25G Ethernet Subsystem (Soft IP)
The 10G/25G Ethernet Subsystem from AMD is an integrated solution that combines a 10G Ethernet MAC with a PCS/PMA in BASE-R mode, specifically designed for use with UltraScale and UltraScale+ FPGAs. Although the signal names of the UDP10G-IP and the 10G/25G Ethernet Subsystem are compatible, there are notable differences in the behavior of the ‘valid’ and ’ready’ signals.
The UDP10G-IP requires uninterrupted packet transfer from the start to the end of a data packet, meaning the ‘valid’ and ‘ready’ signals must remain asserted to 1b throughout the packet transfer. In contrast, when connecting to 10G Ethernet connection, the 10G/25G Ethernet Subsystem may de-assert the ‘ready’ signal to pause packet transmission before the final data of the packet is transmitted. This difference necessitates the use of Tx adapter logic (MAC64bTxIF) to bridge the UDP10G-IP and the 10G/25G Ethernet Subsystem for transmission path. Furthermore, the 10G/25G Ethernet Subsystem can connect to 1G/10G Ethernet using Aquantia PHY for speed adjustment. In such cases, the packet transfer in both transmit and receive interface of the Ethernet Subsystem can pause before the final packet data transfer. Consequently, both MAC64bTxIF and MAC64bRxIF submodules must be integrated between the UDP10G-IP and the 10G/25G Ethernet Subsystem, as shown in Figure 4.
Further details about the 10G/25G Ethernet Subsystem can be found on the AMD website:
https://www.xilinx.com/products/intellectual-property/ef-di-25gemac.html
Additional details of MAC64bTxIF and MAC64bRxIF are described subsequently.
MAC64bTxIF
Figure 5 MAC64bTxIF Block Diagram
The Tx interface characteristics of 10G/25G Ethernet Subsystem and UDP10G-IP differ. UDP10G-IP requires continuous data transmission for one packet, while the AMD 10G/25G Ethernet Subsystem does not support this feature. The Ethernet MAC (EMAC) in the Ethernet Subsystem may de-assert the ready signal to pause data reception before the end of the packet.
Figure 6 Timing Diagram for Data Transfer from UDP10G-IP to FIFO
1) Before asserting U2MacReady to 1b for receiving a new packet from the user, two conditions must be met. First, the free space in the FIFO must be sufficient to store the maximum packet size of 9014 bytes. For simplified monitoring logic, the upper bit of FfDataCnt is read to confirm that the amount of data in the FIFO does not exceed 768 (indicating that the free space exceeds 1151 units of 64-bit data). Second, the previous packet must be completely transferred, which is indicated by U2MacReady being 0b.
2) The user starts transmitting a packet by asserting U2MacValid to 1b. The input signals from the user (U2MacData, U2MacKeep, U2MacLast, and U2MacUser) are valid and stored in the FIFO when both U2MacValid and U2MacReady are asserted to 1b. Subsequently, the inputs are stored in the FIFO by asserting rFfWrEn to 1b. The 74-bit write data to the FIFO consists of 64-bit data (U2MacData), 8-bit byte enable (U2MacKeep), end flag (U2MacLast), and error flag (U2MacUser).
3) After receiving the final data of a packet (U2MacLast=1b and U2MacValid=1b), U2MacReady is de-asserted to 0b to pause data transmission for reading FfDataCnt.
4) If FfDataCnt shows that the free space in the FIFO is sufficient, U2MacReady will be re-asserted to 1b in the next cycle.
Figure 7 Timing Diagram for Data Transfer from FIFO to EMAC
1) The transmission of a new packet begins when the FIFO contains some data (FfDataCnt[10:2] ≠ 0) and no packet is currently transmitting (tx_axis_tvalid=0b). To initiate data transmission, tx_axis_tvalid is set to 1b, along with the valid output signals to EMAC: 64-bit tx_axis_tdata, 8-bit tx_axis_tkeep, tx_axis_tlast, and tx_axis_tuser.
2) If data is successfully transmitted to EMAC (tx_axis_tvalid=1b and tx_axis_tready=1b), wFfRdAck is asserted to ‘1’ to retrieve the next data from FIFO.
3) If tx_axis_tready is de-asserted to 0b, wFfRdAck will be de-asserted to 0b to pause reading new data from the FIFO. Consequently, all output signals sent to EMAC hold their values until EMAC re-asserts tx_axis_tready to 1b.
4) After the final data of a packet is completely transferred (tx_axis_tlast=1b and tx_axis_tready=1b), tx_axis_tvalid is de-asserted to 0b to pause data transmission and check the data size in FIFO for transferring the next packet.
5) The next packet is transmitted when the FIFO has enough data, returning to step 1 to transmit the new packet.
MAC64bRxIF
Figure 8 MAC64bRxIF Block Diagram
When the 10G/25G Ethernet Subsystem is connected to the Aquantia PHY to support both 1G Ethernet and 10G Ethernet, the Rx interface of the Ethernet MAC (EMAC) inside the Ethernet Subsystem may not guarantee continuous packet data transfer, as it can de-assert the valid signal before the last packet data transmission. To address this, the MAC64bRxIF is used to buffer a complete received packet before forwarding it to the UDP10G-IP, ensuring uninterrupted packet data transmission.
The FIFO depth inside MAC64bRxIF is 4096, which is sufficient for storing several Ethernet packets. Similar to MAC64bTxIF, it is a First-Word Fall-Through (FWFT) FIFO. The ‘Remain Packet Counter’ indicates the number of packets stored in the FIFO, increasing when a complete packet is received from EMAC and decreasing when a complete packet is forwarded to UDP10G-IP.
The operation of MAC64bRxIF is divided into two parts. The first part handles transferring a packet from EMAC to FIFO, and the second part handles transferring a packet from FIFO to UDP10G-IP. Timing diagrams of each part are displayed in Figure 9 and Figure 10.
Figure 9 Timing Diagram for Data Transfer from EMAC to FIFO
1) Read FfDataCnt to check the available free space in the FIFO. If FfDataCnt is less than 2944 (indicating that the free space in FIFO exceeds 1153), it is sufficient to store the maximum packet size of 9014 bytes. Additionally, rPacTrans must be equal to 0 to confirm that no packet is currently being transmitted. Once these conditions are met, assert rx_axis_tready to 1b to begin data reception from EMAC.
2) When rx_axis_tvalid is asserted to 1b to indicate the start of a new packet transfer, store the data and control signals from EMAC, including 64-bit rx_axis_tdata, 8-bit rx_axis_tkeep, rx_axis_tlast, and rx_axis_tuser, in the FIFO. Assert rFfWrEn to 1b to write the 74-bit data to the FIFO.
3) After the first data of a packet is received, assert rPacTrans to 1b until the end of packet is received. This can be used to monitor the packet transmission status.
4) If the final data of a packet is received and the free space size in the FIFO is insufficient (FFDataCnt≥2944), de-assert rx_axis_tready to 0b to pause data reception.
5) After the final data of a packet is received, de-assert rPacTrans to 0b to indicate that packet transmission status has changed from Busy to Idle.
6) After storing the final data of a packet in the FIFO (rFfWrEn=1b and rFfWrData[72]-last flag = 1b), increment rPacCnt, the counter that shows the total number of packets stored in the FIFO.
7) If the next packet is received while rx_axis_tready is still de-asserted to 0b, the received packet will be dropped and not be stored in the FIFO.
8) Re-assert rx_axis_tready to 1b when no packet is being transmitted and there is sufficient free space size in the FIFO.
Figure 10 Timing Diagram for Data Transfer from FIFO to UDP10G-IP
1) Before initiating the transfer of a packet from FIFO to UDP10G-IP, ensure that at least one packet is stored in FIFO (rPacCnt>0) and data transmission is not paused (rRdPause= 0b). If both conditions are met, packet forwarding begins by setting rFfRdAck to 1b, which remains active until the final data of the packet is transferred.
2) To optimize timing constraints, the data output from the FIFO is first routed through D Flip-Flops being forwarded to the Mac2U I/F. Consequently, Mac2UValid is set to 1b on the clock cycle following the assertion of rFfRdAck[0]. Simultaneously, Mac2UData, Mac2UKeep, and Mac2ULast are set to the values of FfRdData[63:0], FfRdData[71:64], and FfRdData[72], respectively.
3) After the final data of a packet is read (rFfRdAck[0]=1b and rFfRdData[72]=1b) and forwarded, a two-clock cycle pause is generated, matching the 10G Ethernet characteristic. By asserting rRxPause to 1b for a single clock period, Mac2UValid is set to 0b to pause packet transmission for two clock cycles. At the same time, rPacCnt is decremented.
4) Once rRdPause is de-asserted, return to step 1) by checking the remaining packet in the FIFO, indicated by rPacCnt. If a new packet is found, packet transmission can be restarted by setting rFfRdAck[0] to 1b.
2.1.3 Versal Multirate Ethernet MAC Subsystem
Figure 11 Ethernet Subsystem using MRMAC
The Multirate Ethernet MAC (MRMAC) is a versatile integrated Hard IP available in Versal device. It co-operates with the transceiver module to complete both MAC and PHY functionalities for 10G Ethernet operations. Further information of this Hard IP can be found on the AMD website.
https://www.xilinx.com/products/intellectual-property/mrmac.html
MRMAC configuration in the reference design is as follows:
· MRMAC Configuration Preset : 4x10GE Wide
· MRMAC Mode : MAC+PCS
· AXI Datapath Interface : Independent 32b Non-Segmented
To bridge the UDP10G-IP, which operates with a 64-bit AXI4-ST interface at 156.25 MHz, with the MRMAC, which uses a 32-bit AXI4-ST at 322.265625 MHz, specific adapter logics are required. These adapters, MACTxAsync64to32IF and MACRxAsync32to64IF, handle both clock domain crossing and data width conversion, enabling seamless communication between the UDP10G-IP and the MRMAC.
MACTxAsync64to32IF
Figure 12 MACTxAsync64to32IF Logic Diagram
This module facilitates asynchronous data transfer from the 64-bit AXI4 stream interface (operating in the UserClk domain) of the UDP10G-IP to the 32-bit AXI4 stream interface (operating in the MacClk domain) of the Versal Multirate Ethernet MAC Subsystem. To effectively manage data flow, the module employs two First-Word Fall-Through (FWFT) FIFOs: one for buffering the input stream (TxFf). The module’s functionality is divided into two primary operations: writing to and reading from the FIFOs.
For the Write operation, the UserClk frequency must be at least 156.25 MHz to support the 10G Ethernet transfer rate. As data is transmitted, the FIFO may reach capacity, which requires pausing the write operation. The write data count of both TxFf and PacFf is monitored to ensure sufficient space for upcoming packet transfers. If space is insufficient, U2MacReady is de-asserted to 0b, pausing the incoming data stream. Once the last packet data is stored in TxFf (indicated by U2MacLast being set to 1b), dummy data is written to PacFf to signal the completion of packet storage.
For the Read operation, the read operation begins by setting wTxFfRdAck to 1b, initiating data retrieval from TxFf when all data of a packet is available. This is monitored by PacFfRdEmpty and TxFfRdEmpty. Reading from the FIFO only begins if no previous packet data is still being transferred (indicated by MacTxValid being 0b) or when the last packet’s data has been successfully transferred (indicated by both MacTxReady and MacTxLast being set to 1b). Data from TxFf (TxFfRdData) is loaded to shift registers and transmitted to the MRMAC over two clock cycles, converting the 64-bit data into two 32-bit segments. This data is continuously transferred until the packet is fully transmitted. rMacTxDataH indicates whether the current data transfer to the MRMAC is for the lower or the upper 32-bit data set. It is set to 1b when transmitting the upper 32-bit data set.
The status signal, r1stRead, is set to 1b when the next data read from TxFf is the first packet data. This signal controls when wTxFfRdAck is set to 1b. When the last data is read from TxFf, wPacFfRdAck is set to 1b for a single clock cycle to clear the dummy data in PacFf.
MacTxValid is controlled by an S-R FF and remains asserted at 1b throughout the packet transfer. It is de-asserted after the last data transfer is completed.
For more illustration, the timing diagram of the Read operation is depicted in Figure 13.
Figure 13 MACTxAsync64to32IF Timing Diagram
1) During the idle state, when MacTxValid is 0b, a new packet transfer can be initiated once all initial conditions are met: r1stRead is set to 1b (indicating the start of a new packet), and both PacFfRdEmpty and TxFfRdEmpty are 0b (indicating all data of the subsequent packet is available in TxFf). wTxFfRdAck is set to 1b for the first data read, followed by setting MacTxValid to 1b in the subsequent clock cycle to initiate packet transfer. MacTxValid remains at 1b throughout the transfer to ensure continuous transmission of all data within the packet until the last data is transmitted.
2) Assume the first packet includes three data units (D0, D1, and D2). The last flag (TxFfRdData[72]) remains at 0b for the first two data cycles. After the first data is read, r1stRead resets to 0b. wTxFfRdAck can be asserted again when data is present in TxFf (TxFfRdEmpty=0b) and after the upper 32-bit data has been completely transferred (MacTxReady=1b and rMacTxDataH=1b).
3) Since TxFf is the FWFT type, the read data (TxFfRdData) is immediately valid in the same cycle when wTxFfRdAck is set to 1b. Upon assertion of wTxFfRdAck, rMacTxData[63:32] and MacTxData[31:0] are loaded from TxFfRdData[63:0]. The last flags for each 32-bit data sets (rMacTxLast[1] and MacTxLast) are decoded from TxFfRdData[72] (last flag) and TxFfRdData[68] (flag indicating that the number of valid bytes in rMacTxData exceeds 4).
4) Once the data is successfully transferred (MacTxReady=1b), MacTxData and MacTxLast are loaded from rMacTxData[63:32] and rMacTxLast[1], respectively. Additionally, rMacTxDataH toggles to 1b to indicate the current MacTxData contains the upper 32 bits of the 64-bit data. This toggle occurs when MacTxReady is set to 1b.
5) If MacTxReady is de-asserted to 0b during a packet transfer, wTxFfRdAck is immediately set to 0b, pausing the read operation and preserving the current values of MacTxData and MacTxLast.
6) Upon reading the last data from TxFf (indicated by both wTxFfRdAck and TxFfRdData[72] being set to 1b), wPacFfRdAck is set to 1b for a single clock cycle to flush one dummy data from PacFf, reducing the packet count in TxFf and resetting r1stRead to 1b, preparing for the first data read of the next packet.
7) After the successful transmission of the last data (with MacTxReady and MacTxLast both set to 1b), a new packet transfer can be initiated when conditions permit (PacFfRdEmpty and TxFfRdEmpty both set to 0b and r1stRead=1b), iterating to step 1). In this case, wTxFfRdAck is set to 1b during the first data transfer. If the new packet contains only 32-bit data, MacTxLast is set to 1b during the first data transmission, with r1stRead remaining set to 1b after the first read is completed.
MACRxAsync32to64IF
The MacRxAsync32to64IF serves as an adapter for packet transfers from the MRMAC, which operates with a 32-bit AXI4 Stream interface at 322.266 MHz, to the UDP10G-IP, that utilizes a 64-bit AXI4 Stream interface at 156.25 MHz. This adapter manages the differences in clock domains and data bus widths between the two systems. It includes logic for clock-crossing from the MacClk domain to the UserClk domain and for converting data from 32 bits to 64 bits.
While the MRMAC’s output may occasionally pause during any transfer cycle, the UDP10G-IP requires continuous data transfer within each packet. To manage this requirement, the MACRxAsync32to64IF employs an RxFf (FWFT FIFO) to buffer incoming packet data. This data is validated by Error Detection logic before proceeding.
Additionally, a second FWFT FIFO, PacFf, stores dummy data that marks the end of packet written to the RxFf. The FIFO count of PacFf is then used to track and indicate the number of packets stored in RxFf, facilitating data management for retrieval.
As illustrated in Figure 14, the internal logic of the MacRxAsync32to64IF is divided into two groups: the Write FIFO and the Read FIFO. The details of both are explained below.
Figure 14 MacRxAsync32to64IF Logic Diagram
The Error Detection logic continuously monitors the full status of both the RxFf and PacFf through their write data counter outputs. If either FIFO approaches the full threshold, the Error Detection logic halts data writing, asserts an error flag, and sets the last flag, indicating that an error has occurred in the current packet. Any remaining data in the packet is then discarded. Data writing resumes only once sufficient space becomes available in both FIFOs and a new packet is received.
The Write Controller is responsible for converting data from 32 bits to 64 bits. Typically, the RxFf is written after receiving two 32-bit inputs, except when processing the last packet data. If only 32 bits are received, the last data is written to RxFf along with dummy data to maintain alignment. Additionally, the PacFf is written during the last data transfer cycle, signaled when both rRxFfWrEn and rRxFfWrData[72] are set to 1b, marking the end of a data packet.
On the Read side, the process starts by setting rRxFfRdAck to 1b, which initiates the reading of the first data of each packet from RxFf. This action occurs only when the entire packet is confirmed to be available in RxFf, indicated by PacFfRdEmpty and RxFfRdEmpty both being 0b. Once data reading begins, rRxFfRdAck remains asserted until the last packet data is read (marked by RxFfRdData[72]=1b). After reading the last data, rRxFfRdAck is de-asserted for two clock cycles, a requirement by the UDP10G-IP to allow a brief pause after the last packet data. Once another packet is ready, rRxFfRdAck can be re-asserted to 1b.
The detailed operations of the Error Detection and the Write Controller functionalities are depicted in Figure 15 and Figure 16, respectively.
Figure 15 Error Detection of MacRxAsync32to64IF Timing Diagram
1) During the Write side operation, the available space in both RxFf and PacFf is continuously monitored using RxFfWrCnt and PacFfWrCnt. In a normal scenario, as the input stream is received, it is synchronized into DFFs. For example, MacRxData is loaded into rMacRxData. When rDiscardEn[0] is set to 0b, indicating a normal scenario, the data stream from the DFFs is routed to the Write Controller with rRxValid set to 1b, allowing the data stream to proceed.
2) The value of rRxValid is directly linked to MacRxValid, and includes a two-clock cycle latency during transitioning between 1b and 0b. This delay accounts for the required synchronization before the Write Controller can process the data.
3) If the FIFO space reaches a critical threshold, both rFfAFull and rDiscardEn[0] are set to 1b. This condition triggers the cessation of the current data stream being forwarded to the Write Controller. Simultaneously, rRxValid, rRxLast, and rRxError are set to 1b, marking the last cycle of this packet and indicating an error status. Following this, the incoming data of the current packet (e.g., Dn2 and Dn3) is no longer forwarded to the Write Controller, effectively halting further data processing.
4) Upon detecting the end of the current packet, signaled by MacRxLast being set to 1b, the dropped packet function is disabled by de-asserting rDiscardEn[0] to 0b. This action resets the logic, preparing the system for the next packet and allowing the system to resume normal operation without retaining the error state.
Figure 16 Write Controller of MacRxAsync32to64IF Timing Diagram
1) The initial value of rWordHEn, which indicates whether the 32-bit received data is the lower or upper word, is set to 0b at the start of a new packet. Upon receiving the first 32-bit packet data (rRxData[31:0]), along with rRxKeep[3:0], they are loaded into the lower part of rRxFfWrData (bits[31:0] and bits[67:64]). Afterward, rWordHEn is toggled after each data receipt, as indicated by rRxValid being set to 1b.
2) In the next data cycle, where both rWordHEn and rRxValid are set to 1b, the incoming 32-bit data, along with its corresponding control bits, are loaded into the upper part of rRxFfWrData (bits[63:32] and bits [71:68]). During this cycle, rRxFfWrEn is set to 1b, enabling the writing of the complete 64-bit data into the FIFO.
3) When the last data of a packet is received, as indicated by both rRxValid and rRxLast being set to 1b, rRxFfWrEn is always set to 1b to write the data into the FIFO, regardless of the state of rWordHEn. If only the lower data has been received (rWordHEn=0b), the remaining 4 bits of the Keep value for the upper data are set to zero to ensure proper alignment. This guarantees that the data is correctly stored in the FIFO, even when only the lower portion of the data is available.
2.2 UDP10G-IP
https://dgway.com/products/IP/UDP10G-IP/dg_udp10gip_data_sheet_xilinx_en/
2.3 CPU and Peripherals
In the reference design, the CPU system is extended with an additional peripheral to access the test logic. Therefore, the hardware logic must support the AXI4-Lite bus standard to allow for CPU-initiated write and read operations. The LAxi2Reg module facilitates this connection, as shown in Figure 17.
Figure 17 LAxi2Reg Block Diagram
The LAxi2Reg module consists of two submodules: AsyncAxiReg and UserReg. AsyncAxiReg converts AXI4-Lite signals into a simple Register interface with a 32-bit data bus size, similar to AXI4-Lite standard. Additionally, it includes asynchronous logic to handle clock domain crossing between CpuClk and MacClk domains.
UserReg contains the Register file for parameters and status signals associated with the test logic, including UDP10G-IP. Both the data and control interfaces of UDP10G-IP are connected to UserReg.
Further details on the operations of AsyncAxiReg and UserReg are provided in subsequent sections.
2.3.1 AsyncAxiReg
Figure 18 AsyncAxiReg Interface
The signals on AXI4-Lite bus interface are divided into five groups: LAxiAw* (Write address channel), LAxiw* (Write data channel), LAxiB* (Write response channel), LAxiAr* (Read address channel), and LAxir* (Read data channel). For more information on designing custom logic for the AXI4-Lite bus, refer to the following documentation.
In accordance with the AXI4-Lite standard, the write and read channels operate independently, with separate control and data interfaces for each channel. Therefore, the logic inside AsyncAxiReg that interfaces with the AXI4-Lite bus is divided into four functional groups: Write control logic, Write data logic, Read control logic, and Read data logic, as depicted on the left side of Figure 18. The Write control I/F and Write data I/F of the AXI4-Lite bus are latched and then transferred to the Write register interface via clock domain crossing registers. Similarly, the Read control I/F of the AXI4-Lite bus is latched and transferred to the Read register interface. The data returned from the Register Read I/F is transferred back to the AXI4-Lite bus by using clock domain crossing registers. In the Register interface, RegAddr is shared between write and read access, so the address is loaded from LAxiAw for write access or from LAxiAr for read access.
The simple register interface is designed to be compatible with a single-port RAM interface for write transaction. For read transaction, the Register interface is slightly modified from the RAM interface by adding RdReq and RdValid signals to control read latency. Since the address of the Register interface is shared for both write and read transactions, the user cannot perform simultaneous write and read operations. The timing diagram for the Register interface is shown in Figure 19.
Figure 19 Register Interface Timing Diagram
1) Timing diagram to write register is similar to that of a single-port RAM. The RegWrEn signal is set to 1b, along with a valid value for RegAddr (the Register address in 32-bit units), RegWrData (write data for the register), and RegWrByteEn (write byte enable). The byte enable is four bits wide, where each bit indicates the validity of a specific byte within RegWrData. For example, if RegWrByteEn[0], [1], [2], and [3] are set to 1b, then RegWrData[7:0], [15:8], [23:16], and [31:24] are valid, respectively.
2) To read from a register, AsyncAxiReg sets the RegRdReq signal to 1b, along with a valid value for RegAddr. After the read request is processed, the 32-bit data is returned. The slave detects the RegRdReq being asserted to start the read transaction. During the read operation, the address value (RegAddr) remains unchanged until RegRdValid is set to 1b. Once valid, the address is used to select the returned data through multiple layers of multiplexers.
3) The slave returns the read data on RegRdData bus by setting the RegRdValid signal to 1b. After that, AsyncAxiReg forwards the read value to the LAxir* interface.
2.3.2 UserReg
Figure 20 UserReg Block Diagram
Register Block
The address range, mapped to UserReg, is split into two areas: UDP10G-IP register (0x0000-0x00FF) and UserReg registers (0x1000-0x10FF). The Address decoder interprets the upper bits of RegAddr to select the active hardware component. Since the Register files inside UserReg are designed with a 32-bit bus size, RegWrByteEn (Write byte enable) is not used. To write data to the hardware registers, the CPU must utilize a 32-bit pointer to place a valid 32-bit value on the write data bus.
For reading from a register, a multiplexer selects the data to be returned to the CPU, based on the provided address. The lower bits of RegAddr are applied to select the active data within each Register area, while the upper bits are used to select which Register area to read from. The total read latency is one clock cycle, and the RegRdValid is created by asserting a D Flip-flop triggered by RegRdReq. Further details about the address mapping inside the UserReg module are provided in Table 1.
Table 1 Register Map
|
Address |
Register Name |
Description |
|
Rd/Wr |
(Label in “udpxgtest.c”) |
|
|
BA+0x0000 – BA+0x00FF: UDP10G-IP Register Area Further information of each UDP10G-IP I/O signals is described in the datasheet |
||
|
BA+0x0000 |
UDP_RST_INTREG |
Mapped to RST register within UDP10G-IP |
|
BA+0x0004 |
UDP_CMD_INTREG |
Mapped to CMD register within UDP10G-IP |
|
BA+0x0008 |
UDP_SML_INTREG |
Mapped to SML register within UDP10G-IP |
|
BA+0x000C |
UDP_SMH_INTREG |
Mapped to SMH register within UDP10G-IP |
|
BA+0x0010 |
UDP_DIP_INTREG |
Mapped to DIP register within UDP10G-IP |
|
BA+0x0014 |
UDP_SIP_INTREG |
Mapped to SIP register within UDP10G-IP |
|
BA+0x0018 |
UDP_DPN_INTREG |
Mapped to DPN register within UDP10G-IP |
|
BA+0x001C |
UDP_SPN_INTREG |
Mapped to SPN register within UDP10G-IP |
|
BA+0x0020 |
UDP_TDL_INTREG |
Mapped to TDL register within UDP10G-IP |
|
BA+0x0024 |
UDP_TMO_INTREG |
Mapped to TMO register within UDP10G-IP |
|
BA+0x0028 |
UDP_PKL_INTREG |
Mapped to PKL register within UDP10G-IP |
|
BA+0x002C |
UDP_SRV_INTREG |
Mapped to TDH register within UDP10G-IP |
|
BA+0x0030 |
UDP_RST_INTREG |
Mapped to SRV register within UDP10G-IP |
|
BA+0x0038 |
UDP_VER_INTREG |
Mapped to VER register within UDP10G-IP |
|
BA+0x003C |
UDP_DML_INTREG |
Mapped to DML register within UDP10G-IP |
|
BA+0x0040 |
UDP_DMH_INTREG |
Mapped to DMH register within UDP10G-IP |
|
BA+0x0044 |
UDP_RST_INTREG |
Mapped to RST register within UDP10G-IP |
|
BA+0x1000 – BA+0x10FF: UserReg Control/Status |
||
|
BA+0x1000 |
Total transmit length (Low) |
Wr [31:0] – 32 lower bits of 45-bit total transmit length in 64-bit unit. Valid values range from 1 – 0x1FFF_FFFF_FFFF. Rd [31:0] – 32 lower bits of 45-bit current transmit length in 64-bit unit. The value is cleared to 0 when the USER_CMD_REG is written by the user. |
|
Wr/Rd |
(USER_TXLENL_INTREG) |
|
|
BA+0x1004 |
Total transmit length (High) |
Wr [12:0] – 13 upper bits of 45-bit total transmit length in 64-bit unit. Rd [12:0] – 13 upper bits of 45-bit current transmit length in 64-bit unit. |
|
Wr/Rd |
(USER_TXLENL_INTREG) |
|
|
BA+0x1008 |
User command |
Wr [0] – Start Transmitting. Set to 0b to start the transmission. [1] – Data verification enable (0b: Disable data verification, 1b: Enable data verification) Rd [0] – Transmitting data (0b: Idle, 1b: PattGen is busy) [1] – Data verification error (0b: Normal, 1b: Error) This bit is auto-cleared when user starts new operation or reset. |
|
Wr/Rd |
(USER_CMD_INTREG) |
|
|
BA+0x100C |
User reset |
Wr [0] – Reset signal. Set 1b to reset the logic. This bit is auto-cleared to 0b. [8] – Set 1b to clear the latched value of IntOut. Rd [8] – Latched value of IntOut output from the IP (0b: Normal, 1b: IntOut assertion detected) This flag is cleared by a system reset or setting USER_RST_INTREG[8] to 1b. [16] – Ethernet linkup status from Ethernet MAC (0b: Not linkup, 1b: Linkup) |
|
Wr/Rd |
(USER_RST_INTREG) |
|
|
BA+0x1010 |
FIFO status |
[2:0] - Mapped to UDPRxFfRdCnt signal of UDP10G-IP [15:3] - Mapped to UDPRxFfRdCnt signal of UDP10G-IP [24] - Mapped to UDPTxFfFull signal of UDP10G-IP |
|
Rd |
(USER_FFSTS_INTREG) |
|
|
BA+0x1018 |
Total receive length (low) |
[31:0] – 32 lower bits of 45-bit current received size in 64-bit unit. The value is cleared to 0 when USER_CMD_REG is written by user. |
|
Rd |
(USER_RXLENL_INTREG) |
|
|
BA+0x101C |
Total receive length (high) |
[12:0] – 13 upper bits of 45-bit current received size in 64-bit unit. |
|
Rd |
(USER_RXLENH_INTREG) |
|
Pattern Generator
The logics and timing diagram of Pattern Generator (PattGen) are illustrated in Figure 21 and Figure 22, respectively.
Figure 21 PattGen Block
Figure 22 PattGen Timing Diagram
The data counter, rTotalTxCnt, tracks the total amount of data sent to UDP10G-IP. The lower bits of rTotalTxCnt are used to generate the 32-bit incremental data for the UDPTxFfWrData signal. Once the total transmitted data matches the predefined transfer size (rSetTxSize), rTxTrnEn is de-asserted to 0b, signaling the completion of the transmission.
Pattern Verification
The logics and timing diagram of the Pattern Verification (PattVer) are illustrated in Figure 23 and Figure 24, respectively. The verification feature is activated when the verification flag (rVerifyEn) is enabled.
Figure 23 PattVer Block
Figure 24 PattVer Timing Diagram
When rVerifyEn is set to 1b, the verification logic is activated. This logic compares the received data (UDPRxFfRdData) with the expected data (rExpPatt). If the comparison fails, the rRdFail is asserted to 1b, indicating a verification error.
The UDPRxFfRdEn signal is generated by applying a NOT logic operation to UDPRxFfRdEmpty, ensuring that data is read from the FIFO only when data is available. The received data (UDPRxFfRdData) becomes valid one clock cycle after UDPRxFfRdEn is asserted.
To calculate the total size of the received data, rTotalRxCnt is incremented based on rRxFfRdEn, which is delayed by one clock cycle from UDPRxFfRdEn. This counter (rTotalRxCnt) is also used to generate wExpPatt, the expected pattern for comparison with UDPRxFfRdData.
The wExpPatt and UDPRxFfRdEn are valid in the same clock cycle, enabling comparison through the rFfRdEn signal. If the data mismatches, rRdFail is asserted to 1b.
3 CPU Firmware (FPGA)
The reference design utilizes a bare-metal OS for the CPU firmware, enabling direct hardware control. When running the test system, hardware initialization is the first step, as outlined below.
Figure 25 Initialization in Client mode using Default Parameters
Figure 25 illustrates the four-step hardware initialization process:
1) Upon FPGA boot-up, the CPU polls the status of the Ethernet link (USER_RST_INTREG[16]). The CPU waits until the link is established, and then displays a welcome message, including the IP information.
2) A menu is displayed, allowing the user to select the initialization mode of the UDP10G-IP.
· Client Mode: UDP10G-IP sends an ARP request to obtain the MAC address of the target device from the ARP reply.
· Server mode: UDP10G-IP waits for an ARP request, decodes the MAC address from the request, and responds with an ARP reply.
· Fixed-MAC mode: The user manually configures the target MAC address, typically the Gateway MAC address for communication when the FPGA and the target device are on different networks (preventing ARP packet exchange).
The configuration of the initialization mode is recommended as follows.
· FPGA-PC (same network): Use Client mode.
· FPGA-FPGA (same network): Use one board as Client and the other as Server.
· FPGA-FPGA (same network, alternative): Use one board as Client and the other as Fixed-MAC mode.
· FPGA-FPGA (different networks): Configure both boards in Fixed-MAC mode.
3) The CPU displays default network parameters, which include Initialization mode, FPGA MAC address, FPGA IP address, FPGA port number, Target IP address, and Target port number. There are two default parameter sets: Server parameter set (used only in Server mode) and Client parameter set (used in Client and Fixed-MAC modes). In Fixed-MAC mode, an additional parameter, Target MAC address, is also displayed. The user can either proceed with the default parameters or update them via the Reset Parameters menu (detailed in section 3.2).
4) The CPU waits for UDP10G-IP to complete the initialization by monitoring the busy status (UDP_CMD_INTREG[0]=0b). Once the initialization is complete, the message “IP initialization complete” is displayed, followed by the main menu. The main menu provides five test operations, which are described in the following sections.
3.1 Display Parameters
This menu displays the current values of all UDP10G-IP parameters. The following steps are executed to retrieve and display the parameters.
1) Read the initialization mode.
2) Retrieve all relevant network parameters based on the selected initialization mode. These parameters include Source MAC address, Source IP address, Source port number, Target MAC address (available only in Fixed-MAC mode), Target IP address, and Target port number. Source parameters represent local settings for the UDP10G-IP on the FPGA, while Target parameters correspond to remote settings for the PC or another FPGA.
3) Display each parameter value on the console.
3.2 Reset Parameters
This menu allows users to modify certain UDP10G-IP parameters, such as the IP address and Source port number. After updating the values in the UDP10G-IP registers, the CPU resets UDP10G-IP to re-initialize it with the new parameters. The CPU then monitors the busy flag until the initialization is complete. The following steps are executed to reset the parameters.
1) Display all parameters on the console by following the steps in Section 3.1 (Display Parameters).
2) If the user uses the default values, skip to the next step. Otherwise, display the parameter update menu and proceed as follows:
i) Prompt the user to select the initialization mode. If the mode is changed, display the corresponding parameter set.
ii) Receive and validate each remaining parameter from the user. If an input is invalid, that particular parameter will not be updated.
3) Reset the PattGen and PattVer logics by setting USER_RST_INTREG[0] to 1b.
4) Reset the UDP10G-IP by setting UDP_RST_INTREG[0] to 1b.
5) Update all parameters in the UDP10G-IP registers, such as UDP_SML_INTREG and UDP_DIP_INTREG.
7) Monitor the UDP10G-IP busy flag (UDP_CMD_INTREG[0]) and wait for it to de-assert to 0b, indicating that the initialization has completed.
3.3 Send Data Test
1) Receive transfer size and packet size from the user and validate all inputs. If invalid, cancel the operation.
2) Set UserReg registers, including transfer size (USER_TXLENL/H_INTREG), Reset flag to clear initial test pattern (USER_RST_INTREG[0]=1b), and the Command register to start PattGen function (USER_CMD_INTREG=0). The PattGen in UserReg then starts sending data to UDP10G-IP.
3) Retrieve and display recommended parameters for the test application on the PC. The console then prompts the user: “Press any key to start data sending ...”. This message instructs the user to initiate the receive operation on the target device (PC or another FPGA). Once the receive side is ready, proceed by pressing any key.
4) Set the packet size and the total transfer size by writing to the UDP10G-IP registers: UDP_PKL_INTREG and UDP_TDL_INTREG, respectively. Then, trigger the sending process by setting the Send command (UDP_CMD_INTREG=1).
5) Wait until operation is complete by monitoring the busy flag (UDP_CMD_INTREG[0]=0b). During transmission, the CPU reads the current amount of transmitted data from USER_TXLENL/H_INTREG and displays progress on the console every second.
6) Upon completion, calculate performance and display the test results on the console.
3.4 Receive Data Test
In this test, the user specifies the total amount of data to be received and the data verification mode (enabled or disabled. If any inputs are invalid, the operation is cancelled. When data verification mode is enabled, the system verifies the received data from either the PC or FPGA against the 32-bit incremental data. The test sequence is as follows.
1) Receive total transfer size and data verification mode from the user. Validate all inputs. If invalid, cancel the operation.
2) Set the UserReg registers as follows.
i) Reset flag to clear the initial test pattern (USER_RST_INTREG[0]=1b)
ii) Data verification mode (USER_CMD_INTREG[1]): 0b – Read received data only, 1b - Read and verify received data.
3) Display recommended parameters (similar to Step 3 of Send Data Test). Unlike the Send Data Test, the receive operation proceeds automatically to the next step without requiring user confirmation.
4) Monitor incoming data until one of the following conditions is met:
· Completion condition: The total number of received data (USER_RXLENL/H_INTREG) reaches the predefined total transfer size.
· Timeout condition: No new data is received for 100 milliseconds.
While receiving data, the CPU displays the current amount of received data every second. The timeout interrupt of UDP10G-IP is monitored by reading USER_RST_INTREG[8]. If an interrupt is detected, the CPU displays the timeout interrupt status on the console.
5) Verify whether the total received data (USER_RXLENL/H_INTREG) is equal to or greater than the predefined total transfer size. Check the data verification result by reading USER_CMD_INTREG[1]: 0b – Normal operation, 1b – Error detected. If an error is detected, an error message is displayed.
6) Calculate performance and display the test results on the console.
3.5 Full Duplex Test
This menu facilitates full-duplex testing, allowing simultaneous data transfer between the local device (UDP10G-IP on FPGA) and the remote device (PC or UDP10G-IP on another FPGA) in both directions. The user configures four parameters: total data size for both transfer directions, packet size for the FPGA’s transmission logic, data verification mode for the FPGA’s reception logic, and initiator mode to determine which device starts data transmission first.
Initiator mode has two options: “Initiator” and “Target”. The device set as Initiator begins data transmission immediately after the user completes parameter configuration, while the device set as Target waits to receive data before starting its own transmission.
When running the test with a PC, the FPGA must be fully configured in Target mode before starting the test. Once configured, the user runs two instances of the test application (udpdatatest) on the PC – one for sending and another for receiving data using a different port number.
When performing the test with two FPGAs, the Target FPGA must be fully configured first. After confirming that the Target is ready, the second FPGA is set as the Initiator to start data transmission and reception using the same port number.
The detailed steps of full duplex test are outlined as follows.
1) Receive total data size, packet size, data verification mode, and initiator mode. Validate input before proceeding. If any input is invalid, the operation is cancelled.
2) Set UserReg registers, including transfer size (USER_TXLENL/H_INTREG), Reset flag to clear the initial test pattern (USER_RST_INTREG[0]=1b), and the Command register to start the PattGen and PattVer (USER_CMD_INTREG=0 or 2).
3) Display recommended parameters for the PC test application based on the current parameters. After that, the CPU proceeds differently depending on the initiator mode:
· Initiator: Displays “Press any key to start data transfer ...”, prompting the user to ensure the Target device is ready. Once confirmed, pressing any key proceeds to the next step.
· Target: Prepare the Rx side to receive the UDP data. It waits until it receives the first data from the Initiator. After that, proceeds to enable data transmission.
4) Configure UDP10G-IP registers to set packet size (UDP_PKL_INTREG) and total transfer size (UDP_TDL_INTREG). Then, trigger data transmission by setting UDP_CMD_INTREG=1 (Send command). The IP begins sending data when UDP_CMD_INTREG is set to 1b. The receiving is always enabled without requiring additional configuration.
5) The CPU manages full-duplex transmission by performing two main tasks:
· Transmit data (Tx): Waits for completion by monitoring the UDP10G-IP busy flag (UDP_CMD_INTREG[0] = 0b).
· Receive data (Rx): Waits for completion based on two conditions: Total received data (USER_RXLENL/H_ INTREG) reaching the predefined total transfer size (completion condition) or no new data received for 100 milliseconds (CPU timeout condition)
While data transfer is ongoing, the CPU continuously displays transmitted data size (USER_TXLENL/H_ INTREG) and received data size (USER_RXLENL/H_INTREG) on the console every second. Also, the CPU monitors the timeout interrupt from UDP10G-IP by reading USER_RST_INTREG[8]. If a timeout occurs, the CPU displays the interrupt status on the console.
6) Verify whether the total received data (USER_RXLENL/H_INTREG) matches or exceeds the predefined transfer size. Check data verification result by reading USER_CMD_INTREG[1]: 0b – Normal operation, 1b – Data verification error detected. If an error is found, an error message is displayed.
7) Calculate performance and display the test results of both directions on the console.
3.6 Function List in CPU Firmware
This section describes the list of functions used to operate UDP10G-IP.
|
void check_ethlink(unsigned int* status) |
|
|
Parameters |
status: Pointer to a value that stores the returned Ethernet status. 0: Ethernet link down, 1: Ethernet link up. |
|
Return value |
None |
|
Description |
This function reads the Ethernet MAC link status from bit 16 of the ‘USER_RST_ INTREG’ register and returns the result through the ‘status’ parameter. |
|
void init_param(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function resets the network parameters as described in Section 3.2. It calls ‘show_param’ to display the current parameters and ‘input_param’ to receive updated values from the user. |
|
int input_param(void) |
|
|
Parameters |
None |
|
Return value |
0: Valid input, -1: Invalid input |
|
Description |
This function receives network parameters from the user, including initialization mode, FPGA MAC address, FPGA IP address, FPGA port number, Target IP address, Target port number, and Target MAC address (only applicable in Fixed-MAC mode). Each input is validated separately, and only valid values are updated. Once all parameters are received, ‘show_param’ is called to display them. |
|
void show_cursize(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function displays the current amount of data transmitted and received on the console. It reads values from ‘USER_TXLENL/H_INTREG’ and ‘USER_RXLENL/H_ INTREG’ registers, converts them into appropriate units (bytes, KBytes, or MBytes), and then outputs the result on the console. |
|
void show_interrupt(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function displays the interrupt status of UDP10G-IP on the console. The interrupt value is read from the ‘UDP_TMO_INTREG’ register, and its details are displayed. |
|
void show_param(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function displays the current UDP10G-IP parameters, as described in Section 3.1. |
|
void show_result(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function displays the total amount of transmitted and received data. It reads the ‘USER_TXLENL/H_INTREG’ and ‘USER_RXLENL/H_INTREG’ registers, and then retreives the global parameters: ‘timer_val’ and ‘timer_upper_val’ to calculate the total time usage. The time is converted into usec, msec, or sec units. Finally, the transfer performance is calculated and displayed in MB/s. |
|
int udp_recv_test(void) |
|
|
Parameters |
None |
|
Return value |
0: Operation is successful -1: Invalid input or error encountered |
|
Description |
This function executes the Receive data test as described in Section 3.4. During the test, it calls ‘show_cursize’ to display the ongoing data transfer size and ‘show_interrupt’ to display the interrupt status. At the end of the test, ‘show_result’ is called to display the final test results. |
|
int udp_send_test(void) |
|
|
Parameters |
None |
|
Return value |
0: Operation is successful -1: Invalid input or error encountered |
|
Description |
This function executes the Send data test as described in Section 3.3. During the test, it calls ‘show_cursize’ to display the ongoing data transfer size and ‘show_result’ at the end to display the final test results. |
|
int udp_txrx_test(void) |
|
|
Parameters |
None |
|
Return value |
0: Operation is successful -1: Invalid input or error encountered |
|
Description |
This function executes the Full duplex test as described in Section 3.5. During the test, it calls ‘show_cursize’ to display the ongoing data transfer size, ‘show_interrupt’ to display the UDP10G-IP interrupt status, and ‘show_result’ to present the final test results. |
|
void wait_ethlink(void) |
|
|
Parameters |
None |
|
Return value |
None |
|
Description |
This function continuously monitors the Ethernet link status by checking bit 16 of ‘USER_RST_INTREG’ register. It waits until the Ethernet connection is successfully established before allowing further operations. |
4 Test Software (PC)
Figure 26 “udpdatatest” Application Usage
The “udpdatatest” application is executed to send or receive UDP payload data on a PC. It requires five mandatory parameters and two optional parameters. Ensure that the parameter inputs match those configured on the FPGA. The details for each parameter are outlined below.
· Dir : t – Transmit mode (the PC sends data to the FPGA).
r – Receive mode (the PC receives data from the FPGA).
· FPGAIP : The IP address of the FPGA (Default is 192.168.7.42)
· FPGAPort : The port number of the FPGA (Default is 4000)
· PCPort : The port number of the PC for sending or receiving data
(Default is 60001 for PC -> FPGA and 60000 for FPGA -> PC)
· ByteLen : The total size of data to be transferred in bytes. Used in both transmit and receive modes.
The ‘ByteLen’ value must match the total transfer size set on the FPGA console.
Optional parameters
· Pattern : Defines the data pattern in Transmit mode and enable/disable data verification in Receive
mode. (Default value is 1 if not specified by the user)
0 – Generate dummy data in Transmit mode, disable data verification in Receive mode.
1 – Generate incremental data in Transmit mode, enable data verification in Receive mode.
· Timeout : Defines the timeout period in milliseconds when running in Receive mode.
If no new data is received within the specified period, the application times out and terminates.
(Default value is 100 msec if not specified by the user).
Set this value to 100 msec when running with UDP10G-IP.
The sequence of the test application when running in transmit mode and receive mode are detailed below.
1) Obtain and validate the user’s input parameters.
2) Create a socket, configure the socket options, and specify the socket memory size.
3) Establish a new connection using the provided Server IP address and Server port number.
4) Allocate 2 MB of memory for the send buffer.
5) If the dummy pattern is not selected, generate an incremental test pattern to the send buffer.
6) Send data through the socket and track the total amount of data sent.
7) Calculate the remaining data size to be transferred.
8) Display the total amount of data transferred every second.
9) Repeat steps 5) – 8) until all the data has been transferred (the remaining transfer size reaches 0).
10) Calculate the overall performance and display the result on the console.
11) Close the socket and free the allocated memory.
Receive Mode
1) Follow steps 1) – 3) of the Transmit Mode sequence.
2) Allocate 2 MB of memory for the receive buffer.
3) Continuously wait for incoming data stored in the receive buffer, read it, and update the total amount of received data.
4) If data verification is enabled, compare the received data with the incremental pattern. Print an error message if a mismatch is detected. If verification is disabled, skip this step.
5) Display the total amount of received data every second.
6) Repeat steps 3) – 5) until the operation is completed or cancelled, based on the following conditions:
· Completion condition: The total amount of received data reaches the predefined ‘ByteLen’ set by the user. The test is considered successful.
· Timeout condition: No new data is received within the timeout period specified by the ‘Timeout’ parameter. The test is immediately cancelled and a “Timeout” message is displayed.
7) Calculate the overall performance and display the result on the console. If the test is cancelled due to a timeout, the application displays the total number of received and lost data. The total time usage is also adjusted by subtracting the timeout duration.
8) Close the socket and free the allocated memory.
5 Revision History
|
Revision |
Date (D-M-Y) |
Description |
|
2.00 |
4-Feb-25 |
Support Fixed-MAC mode. |
|
1.05 |
20-Mar-24 |
Add ‘check_ethernet’ function |
|
1.04 |
9-Mar-23 |
Update ‘udpdatatest’ features |
|
1.03 |
21-Aug-20 |
Support 10G25GEMAC-IP |
|
1.02 |
8-Mar-19 |
Support FPGA-FPGA connection |
|
1.01 |
16-Nov-17 |
Correct Receive data test sequence |
|
1.00 |
14-Sep-17 |
Initial version release |