UDP1G-IP Core Datasheet

Features. 1

Applications. 2

General Description. 3

Functional Description. 4

Control Block. 4

·      Parameter Registers (Param Regs) 4

·      UDP/IP Engine. 6

Transmit Block. 6

·      Tx Data Buffer 6

·      Tx Packet Buffer 6

·      Packet Builder 7

Receive Block. 7

·      Packet Filtering. 7

·      Rx Buffer 7

·      Packet Splitter 7

·      Rx Data Buffer 7

User Block. 8

Ethernet MAC. 8

Core I/O Signals. 8

Timing Diagram.. 10

IP Reset 10

IP Initialization. 11

Data Transmission. 14

Data Reception. 15

Interrupt 17

Ethernet MAC Interface. 18

Verification Methods. 21

Recommended Design Experience. 21

Ordering Information. 21

Revision History. 21

 

 

  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 CycloneV E, ArriaV GX,

Cyclone10 GX, Arria10 SoC,

and Arria10 GX boards

Support

Support Provided by Design Gateway Co., Ltd.

 

Design Gateway Co., Ltd

E-mail: ip-sales@design-gateway.com

URL:    design-gateway.com

Features

·    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 UDP1G IPs

·    Support jumbo frames

·    Provide adjustable Transmit/Receive buffer sizes for balanced resource usage and performance

·    Simplify data transfer with a standard FIFO interface and 8-bit data bus

·    Use a 32-bit single-port RAM interface for easy control

·    Integrate an 8-bit Avalon stream interface with Altera Triple-Speed Ethernet MAC

·    Operate in the same clock domains as Ethernet MAC (125 MHz for 1G Ethernet)

·    Include reference designs for CycloneV E, ArriaV GX, Cyclone10 GX, Arria10 SoC, and Arria10 GX 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

CycloneV E

5CEFA7F31I7

125

1,139

1,833

1,181,696

Quartus 16.0

ArriaV GX

5AGXFB3H4F35C5

125

1,115

1,839

1,181,696

Quartus 16.0

Cyclone10 GX

10GX220YF780E5G

125

1,142

1,860

1,181,696

Quartus 24.1

Arria10 SX

10AS066N3F40E2SG

125

1,161

1,868

1,181,696

Quartus 24.1

Agilex7 F-Series

AGFA012R24C3E4X

125

1,439

2,282

1,181,696

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.

 

Applications

 

Figure 1 UDP1G IP Application

 

The UDP1G IP is a high-performance IP core designed to facilitate high-speed, bidirectional data transfer over 1G Ethernet without requiring a CPU or external memory, making it ideal for applications where real-time performance is crucial, such as video streaming and real-time monitoring systems in FPGA-based solutions. It provides efficient means of transferring data and controlling remote systems using the UDP/IP protocol, supporting unicast (one-to-one) communication by default, with an optional broadcast (one-to-many) feature available as a customization.

Optimized for FPGA implementation, the IP core operates independently of a CPU or external memory, ensuring minimal overhead and high efficiency. It is particularly suited for real-time data transfer applications, such as video transmission, where raw video data from a camera is stored in a FIFO and then transmitted to a remote system over 1G Ethernet. The full-duplex capability enables simultaneous data transmission and reception using separate port numbers, allowing the remote system to receive video data in real-time while sending updated control parameters over the same connection.

While UDP1G IP is designed for performance-sensitive systems, it 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

 

General Description

 

Figure 2 UDP1G IP Block Diagram

 

The UDP1G IP core is a hardware logic implementation of the UDP/IP stack that connects with the Ethernet MAC and PHY modules to form the lower layer hardware. The user interface of UDP1G 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 UDP1G IP, with one session dedicated to each direction. Both sessions must share the same network parameters, except for the port number on the target device. Before de-asserting the reset signal, the Network parameters must be set to initialize the IP. Once the reset operation and parameter initialization are complete, the IP is ready to transfer data with the target device. Any modifications to network parameters require a reset. Additionally, the IP supports three initialization modes for obtaining the MAC address of the target device, with further details available in the IP Initialization topic.

To transmit UDP payload data, the user must specify the total transfer size, packet size, and issue a send command to the IP. The transmission process utilizes the TxFIFO interface, which operates on an 8-bit data bus. Incoming UDP packets from the target device are processed by extracting the UDP payload data and storing it in the Rx Data Buffer. The user logic must monitor the FIFO status, track the received data amount, and assert read enable signal to retrieve data from the RxFIFO interface. Data from the RxFIFO can only be accessed when at least one byte is available in the Rx Data Buffer.

To meet various system requirements and optimize the trade-off between resource utilization and performance, the IP allows buffer size adjustments for the Tx Data Buffer, Tx Packet Buffer, and Rx Data Buffer. A smaller Tx Data Buffer may cause the UDP1G IP to pause transmission if the buffer is empty before the user provides additional data. Similarly, a small Rx Data Buffer may lead to buffer overflow if the user delays reading data for an extended period, causing the IP to discard incoming packets from the target device.

The UDP1G IP employs an 8-bit Avalon-Stream interface for direct connectivity with the Altera Ethernet MAC, enabling operation at 1G Ethernet speed. Further technical details on the internal hardware and IP architecture are provided in the subsequent section.

 

Functional Description

As shown in Figure 2, the UDP1G 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.

Control Block

·        Parameter Registers (Param Regs)

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. Valid range is 1 to 0xFFFF_FFFF_FFFF. 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 valid range is 1 to 16000 bytes, with a default value of 1472 bytes, which corresponds to the maximum size for a non-jumbo frame.

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.

 

·        UDP/IP Engine

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.

Transmit Block

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)

11

2 KB

N/A

Valid

Valid

12

4 KB

Valid

Valid

Valid

13

8 KB

Valid

Valid

Valid

14

16 KB

Valid

Valid

Valid

15

32 KB

Valid

N/A

Valid

16

64 KB

Valid

N/A

Valid

·        Tx Data Buffer

The size of the Tx Data Buffer is determined by the “TxBufBitWidth” parameter, which specifies the address width of the buffer. Valid values for this parameter range from 11 to 16, 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 UDP1G IP has a sufficient amount of data available for sustained transmission, achieving optimal performance over 1G Ethernet. Larger buffer sizes increase the likelihood that at least two packets of data will be ready for transmission, enhancing throughput efficiency.

·        Tx Packet Buffer

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 4. For instance, if ‘TxPacBitWidth’ is set to 11, the maximum allowable PKL value is 2044 (2048 – 4).

·        Packet Builder

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.

Receive Block

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.

·        Packet Filtering

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.

·        Rx Buffer

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. It is designed as an asynchronous buffer, facilitating the conversion of the received data stream from the ‘MacRxClk’ domain to the ‘Clk’ domain for subsequent processing.

·        Packet Splitter

The Packet Splitter module extracts UDP payload from incoming packets by removing the packet headers. The extracted payload is then stored in the Rx Data Buffer.

·        Rx Data Buffer

The size of the Rx Data Buffer is configured using the ‘RxBufBitWidth’ parameter, which can range from 11 to 16, corresponding to buffer sizes between 2 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.

 

User Block

As illustrated in Figure 2, the user logic is responsible for managing three distinct user interfaces of the UDP1G 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 FIFO I/F and Rx FIFO I/F utilize an 8-bit FIFO interface. These data interface can be directly connected to the FIFO.

Ethernet MAC

The Ethernet MAC implements the MAC protocol layer. The UDP1G IP connects to the Ethernet MAC (EMAC) via an 8-bit Avalon Stream Interface. The default reference design of UDP1G IP utilizes the Triple-Speed Ethernet FPGA IP core from Altera. Further details on each solution are provided below.

https://www.intel.com/content/www/us/en/docs/programmable/683402/24-3/about-this-ip.html

Core I/O Signals

Table 4 provides detailed descriptions of configurable parameters, while Table 5 outlines the I/O signals for UDP1G IP. The EMAC interface matches the 8-bit Avalon Stream standard, described in Table 6.

 

Table 4 Core Parameters

Name

Value

Description

TxBufBitWidth

12 – 16

Setting Tx Data Buffer size. Table 3 shows the relation between this value and the actual size.

TxPacBitWidth

11 – 14

Setting Tx Packet Buffer size. Table 3 shows the relation between this value and the actual size.

RxBufBitWidth

11 - 16

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 1G Ethernet (125 MHz).

Typically, this clock is sourced from the Ethernet MAC transmit clock output (mac_tx_clk of Altera EMAC).

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.

 

Signal name

Dir

Description

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[15:0]

Out

Indicate the quantity of data stored in the Tx Data Buffer, measured in bytes.

UDPTxFfWrEn

In

Asserts to 1b to write data to the Tx Data Buffer.

UDPTxFfWrData[7:0]

In

8-bit write data to the Tx Data Buffer, which must be valid when UDPTxFfWrEn is set to 1b.

Rx FIFO Interface

UDPRxFfRdCnt[15:0]

Out

Indicate the quantity of data stored in the Rx Data Buffer, measured in bytes.

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[7:0]

Out

8-bit read data from the Rx Data Buffer, which is valid in the next clock cycle after setting UDPRxFfRdEn to 1b.

 

Table 6 Ethernet MAC Interface

Signal name

Dir

Description

Tx Ethernet MAC Interface (Synchronous to Clk)

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[7: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.

Rx Ethernet MAC Interface (Synchronous to MacRxClk)

MacRxClk

In

Receive Clock from Ethernet MAC to synchronous with Rx Ethernet MAC Interface

(mac_rx_clk of Altera EMAC).

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.

MacRxSOP

In

Unused signal.

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 3 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.

 

Timing Diagram

IP Reset

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.

 

IP Initialization

The UDP1G 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 UDP1G 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 UDP1G 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 UDP1G 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 UDP1G 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 UDP1G 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 UDP1G 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.

 

Data Transmission

Users send data to the IP via the 8-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 8-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.

 

Data Reception

When the UDP1G 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 UDP1G IP offers the UDPRxFfRdCnt signal, indicating the total amount of data stored in the Rx Data Buffer in bytes. By utilizing this Read count signal, users can control 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 determine the amount of received data, observe the UDPRxFfRdCnt signal. For instance, if five bytes of data are available, the user can assert UDPRxFfRdEn for five clock cycles to read all stored data.

2)     When UDPRxFfRdEn is set to 1b, the UDPRxFfRdCnt value updates two clock cycles later. Therefore, after de-asserting UDPRxFfRdEn, the user must wait two clock cycles before reading UDPRxFfRdCnt again to ensure an accurate count before initiating the next read transfer. Upon completing the data transfer, UDPRxFfRdCnt equals zero.

 

Interrupt

The UDP1G 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 by other error conditions, including Rx Data Buffer overflow, UDP checksum error, and CRC error detected. This section focuses specifically on the interrupt signal related to lost ARP reply packet.

The timeout interrupt for lost ARP reply packets is represented by bit[0] of the TMO register. This retransmission process has no predefined retry limit, meaning it will continue until a valid ARP reply packet is received. The following steps describe 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 ARP reply packet is lost and does not arrive within the defined timeout value from step 1), the IntOut is triggered, and bit[0] of the TMO register is set to 1b.

3)     The IP retransmits the ARP request packet to attempt recovery. Since there is no predefined retry limit, steps 2) and 3) repeat until the lost reply packet is successfully received.

4)     Once the ARP reply packet is received, the retry process stops, and the IP initialization is successfully completed.

 

Ethernet MAC Interface

The UDP1G IP utilizes an 8-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.

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 UDP1G 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 UDP1G 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. In addition, UDP1G IP has one limitation that it requires 3-clock cycle gap between each received packet for the post-processing. The timing diagram for this interface has two formats, one for Altera Ethernet IP and another for other Ethernet MAC vendors using Avalon-ST interface. The timing diagram of these two formats are illustrated in Figure 12 and Figure 13, respectively.

When connecting UDP1G IP with Altera Ethernet IP, the valid signal is always de-asserted to 0b to pause data transmission for 3 clock cycles before the end-of-packet. However, UDP1G IP maintains MacRxReady to 1b throughout the whole packet reception, as shown in Figure 12.

 

 

Figure 12 Rx EMAC Interface when Connecting with Altera Ethernet IP

 

1)     UDP1G IP detects the start of the received frame when MacRxSOP and MacRxValid are set 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)     For a packet reception, UDP1G IP needs to receive the packet data continuously. As the result, the last data must be valid on MacRxData to be read by UDP1G IP, even though the control signals of the last data have not been asserted from the Altera Ethernet IP.

3)     Following the behavior of Altera Ethernet IP, MacRxValid is de-asserted to 0b for 3 clock cycles before sending the last data. This period is necessary for 32-bit CRC reception and verification of the Ethernet frame inside the Ethernet IP.

4)     Finally, MacRxValid is set to 1b to send the end of the packet. UDP1G IP reads MacRxError to validate whether the packet contains the valid CRC status. The packet will be ignored when MacRxError is set to 1b in this cycle.

 

Alternatively, UDP1G IP can be connected with other vendors’ Ethernet MAC IP (non-Altera) through Avalon-ST interface. In this scenario, MacRxValid must be set to 1b until the end of the packet and de-asserted to 0b for 3 clock cycle for UDP1G IP post-processing, depicted in Figure 13.

 

 

Figure 13 Rx EMAC Interface when Connecting with non-Altera EMAC

 

1)     UDP1G IP detects the start of a received packet when MacRxSOP and MacRxValid are set to 1b. The first data is valid on MacRxData and MacRxReady is asserted to 1b to accept all data until the end of the packet. MacRxValid is continuously asserted to 1b to transmit the data of the entire packet.

2)     The end of the packet is detected when MacRxEOP and MacRxValid are asserted to 1b. At this cycle, the last data is valid on MacRxData.

3)     After the last data reception, UDP1G IP de-asserts MacRxReady for 3 clock cycles to complete the packet post-processing. Subsequently, MacRxReady is re-asserted to 1b for the next packet reception.

 

Verification Methods

The UDP1G IP Core functionality was verified by simulation and also proved on real board design by using CycloneV E, ArriaV GX, Cyclone10 GX, Arria10 SoC, and Arria10 GX development boards.

 

Recommended Design Experience

Experience design engineers with a knowledge of Quartus Tools should easily integrate this IP into their design.

Ordering Information

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 History

Revision

Date (D-M-Y)

Description

2.00

4-Mar-25

Support Fixed-MAC Mode

1.05

26-Mar-21

Support Arria10 GX devices

1.04

2-Oct-20

Update company information

1.03

26-Nov-19

Support Cyclone10 GX devices

1.02

10-Aug-18

Add SRV register and MacRxReady

1.01

1-Mar-17

Update Figure 12.

1.00

27-Feb-17

Initial release