· Parameter Registers (Param Regs)
Ethernet MAC and PHY (10GBASE-R)
· Low Latency Ethernet 10G MAC FPGA IP

Core Facts |
|
|
Provided with Core |
|
|
Documentation |
Reference design manual Demo instruction manual |
|
Design File Formats |
Encrypted File |
|
Instantiation Templates |
VHDL |
|
Reference Designs & Application Notes |
Quartus Project, See Reference design manual |
|
Additional Items |
Demo on Arria10 GX, Arria10 SoC, Agilex7 I-Series, and Sulfur Agilex5 E-Series boards |
|
Support |
|
|
Support Provided by Design Gateway Co., Ltd. |
|
E-mail: ip-sales@design-gateway.com
URL: design-gateway.com
· UDP/IP stack implementation
· Support the IPv4 protocol
· Support IP fragmentation
· Enable full-duplex communication using two port numbers for each direction
· Support multiple sessions with the use of multiple UDP10G IPs
· Support jumbo frames
· Align transmitted packet size to 64-bit data bus size
· Align total received data size to 64-bit data bus size
· Provide adjustable Transmit/Receive buffer sizes for balanced resource usage and performance
· Simplify data transfer with a standard FIFO interface and 64-bit data bus
· Use a 32-bit single-port RAM interface for easy control
· Integrate a 64-bit Avalon stream interface with the 10G Ethernet MAC
· Operate in a single clock domain (156.25 MHz for Ethernet Soft IP or 161.133 MHz for Ethernet Hard IP)
· Include reference designs for Arria10 GX, Arria10 SoC, Agilex7 I-Series, and Sulfur Agilex5 E-Series boards
· Customizable features:
· Multicast IP
· Unaligned 64-bit data transfer
· Alternative user interfaces
Table 1 Example Implementation Statistics
|
Family |
Example Device |
Fmax (MHz) |
ALMs |
Registers1 |
Block Memory bit2 |
Design Tools |
|
10AX115S2F45I1SG |
156.25 |
1,494 |
2,071 |
1,179,648 |
Quartus 24.1 |
|
|
Arria10 SX |
10AS066N3F40E2SG |
156.25 |
1,501 |
2,100 |
1,179,648 |
Quartus 24.1 |
|
Agilex5 E-Series |
A5ED065BB32AE5SR0 |
161.133 |
1,684 |
2,525 |
1,179,648 |
Quartus 24.1 |
|
Agilex7 F-Series |
AGFA012R24C3E4X |
161.133 |
1,690 |
2,569 |
1,179,648 |
Quartus 24.1 |
|
Agilex7 I-Series |
AGFB014R24A2E3VR0 |
161.133 |
1,695 |
2,544 |
1,179,648 |
Quartus 24.1 |
Notes:
1) The actual logic resource depends on the percentage of unrelated logic.
2) Block memory resources are based on 64KB Tx Data Buffer size, 16KB Tx Packet Buffer size, and 64KB Rx Data Buffer size which are the maximum buffer size to achieve the best performance.

Figure 1 UDP10G IP Application
The UDP10G IP is an integrated IP core designed to enable high-speed data transfer over 10G Ethernet without relying on a CPU or external memory. This makes it particularly suitable for demanding applications such as video data streaming and real-time monitoring systems, especially in FPGA-based solutions. By default, the IP core supports unicast data transfer, while the broadcast data transfer is available as a customized feature.
Figure 1 illustrates a video camera system where raw video data from the camera is stored in a FIFO buffer and transmitted to a remote system via 10G Ethernet using UDP10G IP. The IP enables full-duplex transfer by utilizing separate port numbers for simultaneous bidirectional communication. This allows the remote system to receive video data in real-time, and send updated control parameters for the system over the same 10G Ethernet connection.
UDP10G IP is optimized for high-speed data transfer but introduces some latency due to internal pipeline registers and buffers. For application requiring ultra-low latency (e.g., FinTech systems), a specialized low-latency IP is recommended. Detailed information about this low-latency is available on the website:
https://dgway.com/Lowlatency-IP_A_E.html

Figure 2 UDP10G IP Block Diagram
The UDP10G IP core is a hardware logic implementation of the UDP/IP stack that connects with the Ethernet MAC and PHY (10GBASE-R) modules to form the lower layer hardware. The user interface of UDP10G IP consists of two interfaces: the Register interface for control signals and the FIFO interface for data signals.
The Register interface uses a 5-bit address for accessing the registers, including network parameters, command registers, and system parameters. Bi-directional data transfer is achieved using two sessions for each UDP10G IP, with one session assigned for each direction. The network parameters for both sessions must be identical, except for the port number on the target device. The Network parameters must be set before de-asserting the reset signal to initialize the IP. Once the reset operation and parameter initialization are complete, the IP is ready to transfer data with the target device. Network parameters cannot be modified without performing a reset process. The IP also features three initialization modes for obtaining the MAC address of the target device, with further details available in the IP Initialization topic.
To send UDP payload data, the user must specify the total transfer size, packet size, and issue a send command to the IP. The UDP payload data is transmitted via the TxFIFO interface, which operates with a 64-bit data bus. Since the TxFIFO interface lacks a byte enable mechanism, the transmitted data must be aligned to 64-bit boundaries. Similarly, the packet length and total transmitted data must adhere to 64-bit alignment.
When UDP packets are received from the target device, the UDP payload data is extracted and stored in the Rx Data Buffer. The user logic is responsible for monitoring the FIFO status, detecting the amount of received data, and asserting the read enable signal to retrieve data via the RxFIFO interface. Data in the RxFIFO interface can be read only when at least one 64-bit word is available in the Rx Data Buffer. If the total received data is not aligned to 64 bits, the user cannot read the last data until additional data is received to complete the alignment.
To accommodate system requirements and balance resource utilization with performance, the IP provides adjustable buffer sizes for the Tx Data Buffer, Tx Packet Buffer, and Rx Data Buffer. A small Tx Data Buffer may cause the UDP10G IP to pause transmission when the buffer is empty before new data is provided by the user. Conversely, a small Rx Data Buffer may result in buffer overflow if the user delays reading data for an extended period, causing the IP to reject incoming packets from the target device.
The UDP10G IP employs a 64-bit Avalon-Stream interface to interface with the Ethernet MAC. When using the Ethernet Hard IP on Agilex 7 or Agilex 5 devices, adapter logics (MACTxIF and MACRxIF) are required to serve as an interface between the UDP10G IP and the Ethernet MAC. Further information about the internal hardware and architecture of the IP is provided in the subsequent section.
As shown in Figure 2, the UDP10G IP core is divided into three main parts: the Control Block, the Transmit Block and the Receive Block. Each block performs specific functions, detailed as follows.
All parameters of the IP core are configured through the Register interface, which uses 5-bit address signals and 32-bit data signals. The Register interface operates similarly to a single-port RAM interface, as illustrated in Figure 3. The write and read addresses share the same signal. Table 2 provides a description of the available registers and their functions.
Table 2 Register Map Definition
|
RegAddr [4:0] |
Reg Name |
Dir |
Bit |
Description |
|
00000b |
RST |
Wr /Rd |
[0] |
Reset IP. 0b: No reset, 1b: Reset (default value is 1b). Once network parameters are assigned, the user initializes the system by setting this register to 1b and then 0b. This action loads the parameters into the IP. If the parameters need updating, the process must be repeated (set to 1b and then 0b). The RST register controls the following network parameters: SML, SMH, DML, DMH, DIP, SIP, DPN, SPN and SRV. Note: Setting RST to 1b resets both the Transmit block and the Receive block (as shown in Figure 2). As a result, all data stored in the buffers will be cleared. |
|
00001b |
CMD |
Wr |
[0] |
User command. Set 1b to start sending data. The system must be in the Idle state. Confirm Idle state by reading the Busy signal or bit[0] of the CMD register (0b indicates Idle). |
|
Rd |
[0] |
IP Busy flag. 0b: Idle, 1b: Busy during initialization or Send command. This signal maps to the IP’s Busy output signal. |
||
|
00010b |
SML |
Wr /Rd |
[31:0] |
Define the lower 32 bits of the MAC address (bits[31:0]) for the local host. Updating this value requires an IP reset via the RST register. |
|
00011b |
SMH |
Wr /Rd |
[15:0] |
Define the upper 16 bits of the MAC address (bits[47:32]) for the local host. Updating this value requires an IP reset via the RST register. |
|
00100b |
DIP |
Wr /Rd |
[31:0] |
Define the 32-bit IP address for the remote target. Updating this value requires an IP reset via the RST register. |
|
00101b |
SIP |
Wr /Rd |
[31:0] |
Define the 32-bit IP address for the local host. Updating this value requires an IP reset via the RST register. |
|
00110b |
DPN |
Wr /Rd |
[31:0] |
[15:0]: Define the 16-bit port number of the remote target for sending data to the target. [31:16]: Define the 16-bit port number of the remote target for receiving data from the target. Updating this value requires an IP reset via the RST register. |
|
00111b |
SPN |
Wr /Rd |
[15:0] |
Define the 16-bit port number for the local host. Updating this value requires an IP reset via the RST register. |
|
01000b |
TDL |
Wr |
[31:0] |
Define the lower 32 bits (bit[31:0]) of the 48-bit total Tx data length in bytes. The value must be aligned to 8 bytes (bits[2:0] are not used). Valid range is 8 to 0xFFFF_FFFF_FFF8. The upper 16 bits (bits[47:32]) are assigned in the TDH register (01101b). This register must be set before issuing a Send command (CMD=1b). When Busy is asserted to 1b, the IP reads this register, allowing the user to configure TDL/TDH for the next command. If the same values are reused, the user does not need to set TDL/TDH again. |
|
Rd |
The lower 32 bits of the 48-bit remaining transfer length in bytes that have not yet been transmitted. |
|
RegAddr [4:0] |
Reg Name |
Dir |
Bit |
Description |
|
01001b |
TMO |
Wr |
[31:0] |
Define the timeout value for awaiting the return of an ARP reply packet after sending an ARP request packet. The counter operates based on the ‘Clk’ signal provided by the user, with the timer unit equal to 1/Clk. If the ARP reply packet is not received within the specified timeout period, the ‘IntOut’ signal will be asserted to 1b. The optimal timeout value depends on system requirements and network conditions. In the reference design, this register is typically set to 1 second or greater. |
|
Rd |
Provide detailed timeout interrupt status information as follows: [0]-Timeout due to not receiving an ARP reply packet. After timeout, the IP resends repeatedly until the ARP reply is received. [8]-Timeout triggered when the Rx Data Buffer is full. After this condition, all incoming packets are ignored until the buffer has available space. [9]-Timeout caused by a UDP checksum error in the received packet. [10]-Timeout triggered when MacRxError indicates an Ethernet MAC error. |
|||
|
01010b |
PKL |
Wr /Rd |
[15:0] |
Define the UDP data length of each Tx packet, measured in bytes. The value must be aligned to 8 bytes, as bits[2:0] are unused. The valid range is 8 to 8968 bytes, with a default value of 1472 bytes, which corresponds to the maximum size for a non-jumbo frame aligned to 8 bytes. The user must not modify this register while the system is executing a Send data command (Busy=1b). Like the TDL/TDH registers, if the same packet length is used in subsequent commands, the user does not need to reconfigure the PKL register. |
|
01101b |
TDH |
Wr |
[15:0] |
Define the upper 16 bits (bits[47:32]) of the 48-bit total Tx data length, complementing the TDL register. The total data length is defined in bytes, as described in TDL register. |
|
Rd |
Provide the upper 16 bits of the 48-bit remaining transfer length in bytes, indicating the amount of data not yet to be transmitted. |
|||
|
01110b |
SRV |
Wr/ Rd |
[1:0] |
Configure IP initialization mode. 00b: Client Mode (default). When the RST register transitions from 1b to 0b, the IP sends an ARP request to obtain the Target MAC address from the ARP reply. The IP de-asserts the Busy signal to 0b upon receiving the ARP reply. 01b: Server Mode. When the RST register transitions from 1b to 0b, the IP waits for an ARP request packet from the target to acquire the Target MAC address. After receiving the ARP request, the IP responds with an ARP reply and de-asserts the Busy signal to 0b. 1Xb: Fixed-MAC Mode. When the RST register transitions from 1b to 0b, the IP updates all internal parameters and de-asserts the Busy signal to 0b. The Target MAC address is defined by user through the DML/DMH registers, and loaded by the IP during the initialization process. No ARP exchange requires. This mode must be applied if the host and the target are located on different network. In such cases, the MAC address of the gateway must be set to DML and DMH registers. |
|
01111b |
VER |
Rd |
[31:0] |
IP version |
|
10000b |
DML |
Wr /Rd |
[31:0] |
Define the lower 32 bits (bits[31:0]) of the target MAC address when SRV[1]=1b (Fixed-MAC Mode). Updating this value requires an IP reset via the RST register. |
|
10001b
|
DMH |
Wr /Rd |
[15:0] |
Define the upper 16 bits (bits[47:32]) of the target MAC address when SRV[1]=1b (Fixed-MAC Mode). Updating this value requires an IP reset via the RST register. |
The UDP/IP Engine manages the modules responsible for interfacing with the user and transferring packets through the Ethernet MAC (EMAC). The operation of the IP is divided into two phases: initialization and data transfer. Initialization begins when the RST register transitions from 1b to 0b. The initialization mode, which can be set to Client, Server, or Fixed-MAC mode, is determined by the SRV[1:0] register. During this phase, the UDP/IP Engine reads parameters from the Reg module and configures the Transmit and Receive Blocks to facilitate packet transfer with the target device. Once the initialization is complete, the IP transitions to the data transfer phase.
The UDP10G IP supports simultaneous bidirectional data transfer with the target device. During data transmission, the Busy signal is asserted to 1b and remains this value until the transmission process is completed, at which point it is de-asserted to 0b. For data transmission, user data is stored in the Tx Data Buffer and Tx Packet Buffer. The Packet Builder constructs the UDP header using user-defined network parameters and appends to Tx Data Buffer content to the UDP packet. The Transmit Block then sends the completed UDP packet to the target device via the Ethernet MAC.
During data reception, the Busy signal is not asserted. The Receive Block extracts UDP data from incoming packets and forwards it to the user without generating a response packet to the target device. The independent processing of Tx and Rx operations within the UDP/IP Engine ensures optimal performance for data transfer in both directions.
The Transmit block comprises two buffers: the Tx Data Buffer and the Tx Packet Buffer, both of which can have their sizes adjusted through parameter assignments, as outlined in Table 3. The minimum size of these buffers is constrained by the transmit packet size defined by the PKL register. Data from the Tx Data Buffer is segmented into packets based on the specified packet size and temporarily stored in the Tx Packet Buffer. The UDP header, generated using network parameters from the Reg module, is then combined with the UDP payload data from the Tx Packet Buffer to create a complete UDP packet. After a packet is successfully transmitted to the Ethernet MAC, the corresponding data in the Tx Data Buffer is flushed. Once the Send data command is completed, the user can issue the next command to continue the data transmission process.
Table 3 TxBuf/TxPac/RxBufBitWidth Parameter Description
|
Configured Value |
Buffer Size |
TxBufBitWidth (Tx Data Buffer) |
TxPacBitWidth (Tx Packet Buffer) |
RxBufBitWidth (Rx Data Buffer) |
|
9 |
4 KB |
Valid |
Valid |
Valid |
|
10 |
8 KB |
Valid |
Valid |
Valid |
|
11 |
16 KB |
Valid |
Valid |
Valid |
|
12 |
32 KB |
Valid |
N/A |
Valid |
|
13 |
64 KB |
Valid |
N/A |
Valid |
The size of the Tx Data Buffer is determined by the “TxBufBitWidth” parameter, which specifies the address width of the 64-bit buffer. Valid values for this parameter range from 9 to 13, corresponding to buffer sizes detailed in Table 3. To maintain uninterrupted data transmission to the Ethernet MAC, the buffer size must be at least twice the size of the Tx packet size defined in the PKL register. Filling the buffer with data that is at least two times of the PKL value ensures that the UDP10G IP has a sufficient amount of data available for sustained transmission, achieving optimal performance over 10G Ethernet. Larger buffer sizes increase the likelihood that at least two packets of data will be ready for transmission, enhancing throughput efficiency.
The size of Tx Packet Buffer is determined by the ‘TxPacBitWidth’ parameter, with valid values and corresponding buffer sizes provided in Table 3. This buffer must be large enough to store the entire payload of each transmitted packet. Consequently, the PKL value must not exceed the Tx Packet Buffer size (in bytes) minus 32. For instance, if ‘TxPacBitWidth’ is set to 11, the maximum allowable PKL value is 8160 (8192 – 32).
The UDP packet is comprised of a header and data. The Packet builder first receives network parameters from the Reg module and uses them to construct the UDP header. During this process, the UDP and IP checksums are calculated and included in the header to ensure data integrity. Once the header is fully constructed, it is appended to the data retrieved from the Tx Packet Buffer. The complete UDP packet, including the header and payload, is then transmitted to the Ethernet MAC for delivery to the target device.
The Receive block includes the Rx Data Buffer, which temporarily stores data received from the target device. Data is only stored in the buffer if the packet’s header matches the expected values, defined by the network parameters in the Reg module and if the IP and UDP checksums are correct. If these conditions are not met, the received packet is rejected. Increasing the size of the Rx Data Buffer reduces the risk of losing packets due to delays caused by the user logic pausing while reading data.
The Packet Filtering module ensures the validity of received packets by verifying their headers against the following criteria:
1) The network parameters, including MAC address, IP address, and port number, must match the values set in the Reg module.
2) The packet must either be an ARP packet or a UDP/IPv4 packet.
3) The IP header length must be valid, specifically 20 bytes.
4) The IP data length must match the UDP data length.
5) Both the IP checksum and UDP checksum must be correct.
Note: The UDP checksum is not verified for fragment packets.
6) For fragmented packets, the order of received fragmented packets must be correct. Packets are rejected if the fragment offset is skipped or inconsistent.
The Rx buffer serves as a temporary storage area for incoming packets received from the Ethernet MAC. It holds packets when the processing of the previous packet has not yet been completed.
The size of the Rx Data Buffer is configured using the ‘RxBufBitWidth’ parameter, which can range from 9 to 13, corresponding to buffer sizes between 4 KB and 64 KB. To optimize performance and prevent data loss, it is recommended to set the buffer size to at least twice the size of the data in the received packets. To ensure that data is not lost, the user logic must ensure that the buffer’s free space remains greater than the size of the incoming data. Increasing the buffer size reduce the likelihood of buffer overflow and ensures sufficient free space to store new data from the target device.
As illustrated in Figure 2, the user logic is responsible for managing three distinct user interfaces of the UDP10G IP. These interfaces include the Register I/F, utilized for network and system parameter configuration and status monitoring; the Tx FIFO I/F, designed for data transmission; and the Rx FIFO I/F, intended for the reception of data streams.
The user can access the Register I/F through a state machine that can configure the parameters, issue the command, and monitor the status. Both the Tx and Rx data interfaces use a 64-bit FIFO interface without byte enable, so each access requires 64-bit data alignment. These data interface can be directly connected to the FIFO.
The Ethernet MAC and PHY implements multiple protocol layers, including MAC, PCS, and PMA. The UDP10G IP connects to the Ethernet MAC (EMAC) via a 64-bit Avalon Stream Interface. This section describes three Ethernet MAC solutions: the 10G EMAC IP Core from Design Gateway, the Low Latency Ethernet 10G MAC FPGA IP (Soft IP) from Altera, and the Ethernet Hard IP on Agilex 7 or Agilex 5 devices. Further details on each solution are provided below.
Design Gateway provides the 10GEMAC IP, which co-operates with the 10G BASE-R PHY IP (available from Altera without charge). This IP is optimized to minimize resource utilization and data latency, allowing direct integration with the UDP10G IP without the need for additional adapter logic. Detailed specifications for the DG 10GEMAC IP can be found on our website.
https://dgway.com/products/IP/10GEMAC-IP/dg_tengemacip_data_sheet_intel_en/
Altera offers a low-latency Ethernet 10G MAC as a Soft IP core, which the UDP10G IP can connect to directly. Like the DG 10GEMAC IP, this IP requires the 10G BASE-R PHY IP for operation. More information about this IP is available here.
The 10G BASE-R PHY is an IP core by Altera that interfaces with 10G Ethernet MAC via the standard XGMII interface running at 156.25 MHz. It enables a direct connection with an SFP+ optical module. For additional details, please refer to the following website.
The F-Tile Ethernet Hard IP on Agilex 7 devices or the GTS Ethernet FPGA Hard IP on Agilex 5 devices integrate Ethernet MAC, PCS, and PMA functions. The default configuration of the Ethernet Hard IP’s user interface is a 64-bit Avalon Stream Interface running at 161.1328125 MHz. However, this configuration includes pausing packet transfers before the end of packet, which does not match the UDP10G IP core’s requirements. To resolve this mismatch, adapter logic modules (MACTxIF and MACRxIF) are required for both the Tx and Rx interfaces to manage the different data stream characteristics. More information can be found in the following website.
Altera Agliex 7 F-Tile Ethernet Hard IP:
GTS Ethernet FPGA Hard IP:
Table 4 provides detailed descriptions of configurable parameters, while Table 5 outlines the I/O signals for UDP10G IP. The EMAC interface matches the 64-bit Avalon Stream standard.
Table 4 Core Parameters
|
Name |
Value |
Description |
|
TxBufBitWidth |
9 - 13 |
Setting Tx Data Buffer size. Table 3 shows the relation between this value and the actual size. |
|
TxPacBitWidth |
9 - 11 |
Setting Tx Packet Buffer size. Table 3 shows the relation between this value and the actual size. |
|
RxBufBitWidth |
9 - 13 |
Setting Rx Data Buffer size. Table 3 shows the relation between this value and the actual size. |
Table 5 Core I/O Signals
|
Signal name |
Dir |
Description |
|
Common Interface |
||
|
RstB |
In |
Reset the IP core. Active Low. When RstB is set to 0b, the configurable parameters of the IP are reset to their default values. |
|
Clk |
In |
Fixed clock frequency input for user interface and MAC interface of 10G Ethernet (156.25 MHz for Soft IP core and 161.1328125 MHz for Hard IP core). |
|
Control Interface |
||
|
RegAddr[4:0] |
In |
5-bit Register address used for both write and read accesses. The register map corresponding to each address is detailed in Table 2. For a write access, this value must be valid concurrently with the setting of RegWrEn to 1b. |
|
RegWrData[31:0] |
In |
32-bit write value for updating to specified register during a Register write operation. It must be valid concurrently with the setting of RegWrEn to 1b. |
|
RegWrEn |
In |
Asserts to 1b to initiate a Register write operation to the specified register. |
|
RegRdData[31:0] |
Out |
32-bit read value from the designated register. This value becomes valid in the next clock cycle after setting the specified register value to RegAddr. |
|
Busy |
Out |
IP busy status. 0b – IP is Idle, 1b – IP is busy during initialization or Send command processing. |
|
IntOut |
Out |
Timer interrupt that is asserted to 1b for one clock cycle when a timeout is detected or Rx packet is ignored. Additional details about the Interrupt status can be obtained by referencing the TMO[10:0] register. |
|
Tx FIFO Interface |
||
|
UDPTxFfFull |
Out |
Asserted to 1b, signaling the full status of the Tx Data Buffer. User must pause data writing within 4 clock cycles once this signal is set to 1b. |
|
UDPTxFfWrCnt[12:0] |
Out |
Indicate the quantity of data stored in the Tx Data Buffer, measured in 64-bit units. |
|
UDPTxFfWrEn |
In |
Asserts to 1b to write data to the Tx Data Buffer. |
|
UDPTxFfWrData[63:0] |
In |
64-bit write data to the Tx Data Buffer, which must be valid when UDPTxFfWrEn is set to 1b. |
|
Rx FIFO Interface |
||
|
UDPRxFfRdCnt[12:0] |
Out |
Indicate the quantity of data stored in the Rx Data Buffer, measured in 64-bit units. |
|
UDPRxFfLastRdCnt[2:0] |
Out |
Indicate the remaining bytes within the Rx Data Buffer that are not aligned to 64-bit units. The valid range is 0-7 bytes. These unaligned data bytes cannot be read until the IP receives additional data to complete a 64-bit alignment. |
|
UDPRxFfRdEmpty |
Out |
Asserted to 1b, signaling the empty status of the Rx Data Buffer. User must pause data reading immediately when this signal is set to 1b. |
|
UDPRxFfRdEn |
In |
Asserts to 1b to read data from the Rx Data Buffer. |
|
UDPRxFfRdData[63:0] |
Out |
64-bit read data from the Rx Data Buffer, which is valid in the next clock cycle after setting UDPRxFfRdEn to 1b. |
|
Signal name |
Dir |
Description |
|
Tx Ethernet MAC Interface |
||
|
MacTxReady |
In |
Asserts to 1b when ‘MacTxData’ has been accepted. This signal must remain asserted to 1b until the last data of the packet is completely transferred. |
|
MacTxData[63:0] |
Out |
Transmitted data to the Ethernet MAC. |
|
MacTxValid |
Out |
Asserted to 1b to transmit the ‘MacTxData’. Once the first data of the packet is successfully sent, this signal persists at 1b, enabling continuous data transmission until the last data of the packet is completely transferred. |
|
MacTxSOP |
Out |
Asserted to 1b to indicate that this is the first data of the packet. |
|
MacTxEOP |
Out |
Asserted to 1b to indicate that this is the last data of the packet. During this cycle, some data bytes may be unused, which can be monitored using ‘MacTxEmpty’. |
|
MacTxEmpty[2:0] |
Out |
Indicates whether the unused bytes of ‘MacTxData’ for the final word in the frame. Generally, all 64-bit data is considered valid, and this signal is typically set to all zeroes. However, for the last data strobe, it can indicate 0-7 unused bytes. |
|
Rx Ethernet MAC Interface |
||
|
MacRxData[63:0] |
In |
Received data from the Ethernet MAC. |
|
MacRxValid |
In |
Asserts to 1b to transfer the ‘MacRxData’. This signal must remain asserted at 1b during each packet transfer. It must not be de-asserted before the completion of the last data transfer. |
|
MacRxEOP |
In |
Asserts to 1b to indicate that this is the last data. |
|
MacRxError |
In |
Asserts to 1b to indicate that this packet contains an error. This signal is valid during the last data transfer, indicated by ‘MacRxValid’=1b and ‘MacRxEOP’=1b. |
|
MacRxReady |
Out |
Asserted to 1b to confirm the acceptance of ‘MacRxData’. This signal is set to 0b for 2 clock cycles after the last data of the packet is received. The pause ensures the IP completes processing time the most recently received packet before beginning the transmission of a new packet. |
Upon de-assertion of the ‘RstB’ signal to 1b to start the IP operation, the IP needs a waiting period of at least 4 clock cycles to manage its internal reset process. Following this delay, the IP becomes accessible for user interaction via the Register interface, as shown in Figure 3. This figure illustrates an example of configuring the required host and target parameters for the IP initialization process.

Figure 3 Register Interface After IP Reset
1) Following the transition of RstB from 0b to 1b, the IP remains inaccessible for write and read access on the Register I/F for 4 clock cycles.
2) After this period, users can initiate Register write to define values for the local host and remote target parameters, including SML, SMH, DIP, SIP, DPN, SPN, and SRV registers. For Fixed-MAC mode, DML and DMH registers must also be assigned. These parameters must be valid before de-asserting RST register value to 0b, initiating the IP initialization process. Detailed descriptions of this process are outlined in subsequent section. The timing diagram for Register write is similar to that of Single-port RAM write access. Address (RegAddr) and data (RegWrData) setting must accompany the activation of RegWrEn to 1b to initiate write access to each register.
3) User can verify the set values or access other IP statuses via Register read access. The address for read access shared the signal used for write access, while data is retrieved on RegRdData with a one-clock latency period.
The UDP10G IP begins the IP initialization process when the user updates RST register from 1b to 0b. Before de-asserting the RST register, the user must set the values of SML, SMH, DIP, SIP, DPN, SPN, and SRV registers. For Fixed-MAC mode, the values of DML and DMH registers must also be set. These parameters must retain their values while the RST register remains at 0b, indicating that the IP is not reset. Upon successful completion of IP initialization, the ‘Busy’ flag transitions from 1b to 0b.
The UDP10G IP offers three initialization modes, determined by the settings in the SRV register. Detailed information about each initialization mode is provided in this section.
Client mode (SRV[1:0]=00b)
When the remote target and the local host are installed within the same network, the MAC address of the target can be obtained through ARP packet exchange. For simple usage, it is recommended to set the initialization mode of UDP10G IP to Client mode. The process of initialization in Client mode is described as follows.

Figure 4 IP Initialization in Client Mode
1) Configure the target and host parameters of the UDP10G IP by assigning values to RegWrData while setting RegWrEn to 1b (as shown in Figure 3). Set the SRV register (RegAddr=01110b) to 0 for initialization in Client mode. After setting, these parameters are loaded to the internal registers.
2) Initiate the IP’s initialization process by updating the RST register value from 1b to 0b, setting RegAddr=00000b and RegWrEn=1b.
3) The parameters obtained in step 1) are used to construct an ARP request packet, which will be transmitted to the target.
4) Upon detecting an ARP request packet, the target generates an ARP reply packet to return its MAC address to the local host.
5) Once the ARP reply packet has been received, the remote target’s MAC address is extracted and loaded into the internal registers. Following this, the ‘Busy’ is set to 0b (alternatively monitored on bit[0] of RegRdData when RegAddr=00001b or CMD register), signifying the completion of the IP initialization process.
Server mode (SRV[1:0]=01b)
Server mode is suitable for applications that employ both the UDP10G IPs as the local host and the remote target installing in the same network. If the first device is initialized in Client mode, the subsequent device must be configured to Server mode. The initialization process in Server mode is reverse of that in Client mode, described in detail as follows.

Figure 5 IP Initialization in Server Mode
The steps for Server initialization mostly align with those for Client initialization, with two distinctions. First, the SRV register is set to 1 to select Server mode. Second, the ARP packet transfer operates in reverse compared to Client mode. In Server mode, the IP awaits an ARP request packet to retrieve the remote target’s MAC address and then returns an ARP reply packet, completing the IP initialization process.
Fixed-MAC mode (SRV[1]=1b)
The last initialization mode, known as Fixed-MAC mode, is utilized when the local host and the remote target are installed in different networks. In this mode, the MAC address for the remote target is configured by the gateway’s MAC address, assigned by DML and DMH registers. The initialization process in Fixed-MAC mode is described in detail as follows.

Figure 6 IP Initialization in Fixed-MAC Mode
1) Configure the remote target and local host parameters of the UDP10G IP by assigning values to RegWrData while setting RegWrEn to 1b (as shown in Figure 3). DML and DMH are defined by the gateway’s MAC address and are necessary to be configured in this step when aiming Fixed-MAC initialization. After that, set the SRV register (RegAddr=01110b) to 2 for initialization in Fixed-MAC mode. These parameters are loaded to the UDP10G IP internal registers.
2) Initiate the IP’s initialization process by updating the RST register value from 1b to 0b, setting RegAddr=00000b and RegWrEn=1b.
3) Once parameter loading has been completed, the Busy is set to 0b (alternatively monitored on bit[0] of RegRdData when RegAddr=00001b or CMD register), signifying the completion of the IP initialization process.
Users send data to the IP via the 64-bit TxFIFO interface. Parameters related to data transmission, including the TDL, TDH, and PKL registers, are configured using the Register interface. These registers are utilized for setting the total transmitted size (TDH and TDL) and the UDP payload size per Tx packet (PKL). Once all parameters are set, users initiate data transmission by setting the CMD register.
Transmitted data from user is sent via Tx FIFO interface, which provides two flow control signals, the full flag (UDPTxFfFull) and the write data counter (UDPTxFfWrCnt). UDPTxFfWrCnt is updated after asserting UDPTxFfWrEn for two clock cycles, allowing the user logic to write data in burst transfer. UDPTxFfFull serves as an indicator of when the Tx Data Buffer is almost full and is asserted before it reaches its capacity. It is recommended to pause sending data within four clock cycles after UDPTxFfFull is asserted. Further details of the Tx FIFO interface are shown in Figure 7.

Figure 7 Data Transfer via Tx FIFO Interface
1) During the reset condition (when bit[0] of the RST register is set to 1b), UDPTxFfFull is asserted to 1b, preventing the user from sending data. Once the reset is cleared (when bit[0] of the RST register transitions from 1b to 0b), UDPTxFfFull is de-asserted to 0b.
2) When UDPTxFfFull is de-asserted to 0b, users can send data to the Tx Data Buffer by setting UDPTxFfWrEn to 1b and transferring the 64-bit data via the UDPTxFfWrData signal.
3) For continuous transfer in burst mode, the user logic must utilize the FIFO data counter (UDPTxFfWrCnt) to ensure sufficient space is available for the next burst. Note that there is a two-clock-cycle latency for updating UDPTxFfWrCnt after UDPTxFfWrEn is asserted. Consequently, the current read value of UDPTxFfWrCnt may be two less than the actual count.
4) When the Tx Data Buffer almost reaches its capacity, UDPTxFfFull is asserted to 1b. In such cases, UDPTxFfWrEn must be de-asserted to 0b within four clock cycles to prevent buffer overflow by pausing data transmission.
5) Data transmission can resume once UDPTxFfFull changes back to 0b.
When the UDP10G IP receives data from the remote target, it verifies the packet header. If it is validated, the received UDP payload data is stored in the Rx Data Buffer, accessible to users via the Rx FIFO interface. UDPRxFfRdEmpty and UDPRxFfRdCnt signals are provided to allow users to track the available data within this buffer.
Further details on receiving data under different conditions can be found in this section.
Data Transfer Using Empty Flag of Rx FIFO Interface
The Rx FIFO interface is used to retrieve data stored in the Rx Data Buffer. The Empty flag (UDPRxFfEmpty) serves as an indicator of data availability. Users can use this flag to trigger the read enable signal, allowing them to retrieve data, similar to a standard FIFO read interface, as illustrated in Figure 8.

Figure 8 Data Transfer Using Empty Flag of Rx FIFO Interface
1) After the IP finishes reset process, there is no data in Rx Data Buffer and UDPRxFfEmpty is set to 1b.
2) Check the UDPRxFfEmpty flag to confirm data availability. When data is ready (UDPRxFfEmpty=0b), set UDPRxFfRdEn to 1b to read data from the Rx Data Buffer.
3) The UDPRxFfRdData signal is valid in the next clock cycle.
4) Reading data must be immediately paused by setting UDPRxFfRdEn=0b when UDPRxFfEmpty is equal to 1b.
Data Transfer Using Read Count of Rx FIFO Interface
The UDP10G IP offers the UDPRxFfRdCnt signal, indicating the total amount of data stored in the Rx Data Buffer in 64-bit units. In cases where received data does not align with a 64-bit unit, the remaining bytes stored in the Rx Data Buffer, yet to be read, are indicated by the UDPRxFfLastRdCnt signal. Leveraging the Read count signal, users can activate UDPRxFfRdEn to retrieve multiple data from the Rx Data Buffer, as illustrated in Figure 9.

Figure 9 Data Transfer Using Read Count of Rx FIFO Interface
1) To verify the amount of received data, observe the UDPRxFfRdCnt signal. For instance, if four 64-bit data are stored, user can assert UDPRxFfRdEn for four clock cycles to read all available 64-bit data.
2) After setting UDPRxFfRdEn to 1b, UDPRxFfRdCnt updates its value two clock cycles later. Therefore, upon de-asserting UDPRxFfRdEn, wait for two clock cycles to confirm the accurate UDPRxFfRdCnt value before initiating the next read transfer.
3) In this scenario, two bytes of data remain in the Rx Data Buffer, indicated by UDPRxFfLastRdCnt. This data cannot be read and must await new data to align with 64-bit data units.
4) Let’s assume the target transmits a subsequent packet containing 14 bytes of data. Currently, the Rx Data Buffer holds a total of two 64-bit data, as indicated by UDPRxFfRdCnt=2.
5) Users assert UDPRxFfRdEn for two clock cycles to read all remaining data. Upon completing the data transfer, both UDPRxFfRdCnt and UDPRxFfLastRdCnt will be zero.
The UDP10G IP features a timer to monitor the response time for ARP reply packets when the IP is initialized in Client mode. If an ARP reply packet is lost, the ‘IntOut’ signal is asserted to 1b for a single clock cycle, notifying the user of the event and indicating that the ARP request packet will be retransmitted.
In addition to monitoring ARP replies, the ‘IntOut’ signal is triggered for other error conditions, including the Rx Data Buffer reaching full capacity, detection of a UDP checksum error, and detection of a CRC error from the Ethernet MAC.
This section shows the interrupt signal related to a lost ARP reply packet.
The timeout interrupt for lost ARP reply packets is represented by bit[0] in the TMO register. This retransmission process operates without a predefined maximum limit for retry attempts. The following steps outline an example of the packet transmission process to handle recovery when an ARP reply packet is lost.

Figure 10 TMO[0] Assertion
1) Users initialize the timeout value in the TMO register by writing to RegAddr as 01001b and asserting RegWrEn to 1b. The time unit specified in RegWrData is determined based on the ‘Clk’ signal frequency.
2) In this scenario, assuming the IP is initialized in Client mode, where it transmits an ARP request packet and awaits the return of an ARP reply packet from the target. If the expected ARP reply packet is lost and does not arrive within the defined timeout value from step 1), the IntOut triggers, and bit[0] of the TMO register is set to 1b.
3) The retry process begins by retransmitting the ARP request packet. With no predefined maximum retry count limit for this interrupt type, steps 2) and 3) repeat until the lost packet is successfully received.
4) Upon receiving the awaited ARP reply packet, the retry process concludes, marking the successful completion of the IP initialization process.
The UDP10G IP utilizes a 64-bit Avalon Stream (Avalon-ST) bus to transfer Ethernet packets with an Ethernet MAC. It is important to note that this IP necessitates uninterrupted packet transfer in both directions. Pausing transmission or reception during packet transfer is not supported.
Due to this Avalon-ST characteristic, special adapter logics with FIFO (MACTxIF and MACRxIF in Figure 2) are required for connecting the UDP10G IP to an Ethernet Hard IP. On the contrary, an Ethernet MAC IP implemented as a Soft IP can directly connect to the UDP10G IP without additional logic.
Tx EMAC interface
During packet transmission, the MacTxReady signal needs to be consistently asserted to 1b from the transmission of the first data until the transmission of the last data within each packet. Only when the interface is in an Idle state before starting the transmission of the subsequent packet, MacTxReady can be de-asserted to 0b.

Figure 11 Tx EMAC Interface Timing Diagram
1) The UDP10G IP asserts both MacTxSOP and MacTxValid to 1b when initiating transmission of the first packet data through the MacTxData signal. These signals maintain their value until the confirmation of data acceptance by asserting MacTxReady to 1b.
2) Once the first data is acknowledged, MacTxReady must remain set to 1b to receive all subsequent packet data from the UDP10G IP until the completion of the packet transmission. This ensures a continuous transfer of all data within each packet.
3) While transmitting the last data of the packet through MacTxData, both MacTxEOP and MacTxValid are asserted to 1b.
4) Upon completion of the transfer of the last packet data, MacTxReady can be set to 0b, enabling the pause of transmission for the next packet.
Rx EMAC interface
The Receive EMAC interface also requires continuous receipt of packet data, similar to Transmit EMAC interface. The MacRxValid signal must remain asserted at 1b from the start of the packet to the end of the packet without interruption, as shown in Figure 12.

Figure 12 Rx EMAC Interface Timing Diagram
1) The UDP10G IP detects the start of the received frame when MacRxValid changes from 0b to 1b. In this cycle, the first data is valid on MacRxData. Afterward, MacRxReady is asserted to 1b to accept all data of this packet until the end of the packet. To continuously send the data of each packet, MacRxValid must remain set to 1b.
2) The end of the packet is detected when MacRxEOP=1b and MacRxValid =1b. In this cycle, the last data of the packet is valid on MacRxData, and the MacRxError is monitored to check the packet status.
3) After the final data of the packet has been transferred, the UDP10G IP de-asserts MacRxReady for 1 clock cycles to complete the packet post-processing. Therefore, the interface module must support pausing data packet transmission for 1 clock cycles.
Note: Typically, Ethernet MAC of 10G speed has a minimum idle state of two clock cycles between each received packet. This interval allows for the reception of Ethernet FCS, EFD, and IFG.
The UDP10G IP Core functionality was verified by simulation and also proved on real board design by using Arria10 GX, Arria10 SoC, Agilex7 I-Series, and Sulfur Agilex5 E-Series boards.
Experience design engineers with a knowledge of Quartus Tools should easily integrate this IP into their design.
This product is available directly from Design Gateway Co., Ltd. For pricing and additional information about this product, please refer to the contact information on the front page of this datasheet.
|
Revision |
Date (D-M-Y) |
Description |
|
2.00 |
4-Mar-25 |
Support Fixed-MAC Mode |
|
1.03 |
17-Oct-23 |
Add UDPTxFfWrCnt signal, update PKL range, and update Register Interface timing diagram |
|
1.02 |
2-Oct-20 |
Update company information |
|
1.01 |
22-Mar-18 |
Support Arria10 SoC |
|
1.00 |
19-Sep-17 |
Initial release |