TOE200GADV-IP Core Datasheet

Note: The actual logic resource depends on the percentage of unrelated logic.

Applications

The TOE200GADV IP core serves as a fully offloading engine designed for TCP/IP packet processing, eliminating the need for CPU and external memory usage. This IP allows for the seamless transmission of TCP/IP packets at the full 200G Ethernet line rate.

Within the Host system, the host processor takes on the responsibility of selecting four performance-sensitive TCP sessions, handled by the TOE200GADV IP. Concurrently, the host processor processes the remaining Ethernet packets via Host2MAC module to support the remaining TCP sessions and other protocols that do not require high-performance handling. User data processed by TOE200GADV IP is directly transferred to the Host memory by DMA engine, allowing applications running on the host processor to access this data.

In contrast, other Ethernet packets transferred through the Host2MAC module are stored separately within the host memory, awaiting the host processor decoding before they can be utilized by the applications. The incorporation of the TOE200GADV IP core significantly enhances the performance of TCP data transfer within the Network interface application.

The NVMe/TCP protocol facilitates remote access to storage systems equipped with NVMe SSDs through network connectivity. It requires at least two TCP sessions for the distinct transfer of commands and data. The incorporation of the TOE200GADV IP core empowers the system to concurrently handle up to four TCP sessions. Consequently, the Initiator logic can write and read data with two NVMe SSDs installed within the remote target system concurrently. Eliminating the necessity for TCP/IP implementation within the Initiator logic simplifies the logic design, allowing it to be exclusively dedicated to supporting NVMe commands. Using a pure-hardwired logic design optimizes data transfer performance, making it possible to upload high-resolution video data to remote storage in real-time.

General Description

The TOE200GADV IP core serves as a complete offloading engine designed for processing TCP/IP packets. It provides four distinct user interfaces to facilitate the transfer of TCP payload data across four separate TCP sessions. While most network parameters are uniform across these sessions, the TCP port number can be individually configured for each. Moreover, the size of the TCP buffer, for both transmit and receive directions within each TCP session, can be configured independently to accommodate the specific characteristics of each session. The TOE200GADV IP utilizes a 1024-bit Avalon-ST interface for Ethernet packet transfer to and from the Ethernet MAC via the TOEMACIF module, which functions as the adapter logic.

The TOE200GADV IP's logic can be categorized into three main blocks: Control block, Transmit block, and Receive block. The Control block is connected to the Control I/F of the user interface and is responsible for configuring commands, managing network parameters, and monitoring the operational status of the IP. Within the Control block, the MainCtrl component receives user command requests and stores associated user parameters in Param Regs. After validating the command, MainCtrl generates a command request for the respective TCP engine. The system incorporates four TCP engines, each dedicated to managing the operations of individual TCP sessions.

The Transmit block manages the TCPTx I/F, facilitating the transmission of TCP payload data through a 1024-bit Avalon stream I/F. Data received from the user interface must be re-aligned before being stored in the TxTCP buffer. When a user requests data transmission, the Packet builder retrieves payload data from the TxTCP buffer to construct TCP/IP packets, which are then transferred to TOEMACIF module.

Conversely, the Receive block manages the TCPRx I/F, receiving TCP payload data from the Ethernet Hard IP via a 1024-bit Avalon stream I/F. The operation of the Receive block is reverse of the Transmit block. Received packets undergo validation through Packet Filtering, and the TCP payload data extracted from valid packets is subsequently stored in the RxTCP buffer. When data is available in the RxTCP buffer, and the user is ready to receive it, the RxAligner transfers received data to the user.

Design Gateway also includes the TOEMACIF module as an encrypted file in the TOE200GADV IP core release package. This module serves as an adapter logic, bridging the connection between the Ethernet MAC interface of TOE200GADV IP (1024-bit Avalon-ST I/F) and the user interface of the F-Tile Ethernet Hard IP on Agilex-7 device (512-bit MAC Segmented I/F). Due to the Ethernet Hard IP's operation in a distinct clock domain (MacClk) from the user logic, TOEMACIF incorporates two asynchronous buffers in the Transmit block and Receive block, namely the TxMAC buffer and the RxMAC buffer, to facilitate data streaming across clock domains.

Functional Description

The TOE200GADV IP has two sets of functions: common functions, which are employed for every TCP session, and session-specific functions that operate within each session. The common functions facilitate communication with the remote target device, while the session functions are responsible for managing individual TCP session, as illustrated in Figure 4.

Common States

1. Reset: When the TOE200GADV IP is powered-on, the default state is Reset. This state is designed to wait for the user to configure network parameters for both the local host and the remote target, including MAC address and IP address. Once all parameters, including the initialization mode (DstMacMode), are set, the user can de-assert RstB to 1b to initiate the target's initialization.
2. Target Initialization: This state is used to obtain the MAC address of the target and store the user-assigned network parameters in internal registers. There are three modes, determined by DstMacMode, for acquiring the remote target's MAC address: Client (generating ARP request packet), Server (waiting for ARP reply packet), and Fixed-MAC (user-defined value). Once the target's MAC address is successfully obtained, the initialization process is completed, and the TOE200GADV IP is ready to establish a connection with the target.
3. Target Ready: After successful target initialization, the main function remains in this state until a reset is asserted. In this state, the user can send command request specifying the active session (Session#0–Session#3) and the operation (Open, Close, and Reset) to be performed by the main function. If the operation request is invalid, such as sending a Close request to an inactive session, the main function will reject the request. Valid requests are forwarded to the session-specific function, which returns either a completion or an error status to the main function after executing the operation.
   Additionally, it is important to note that the session's status may also change without any request from the main function if the remote target device sends a request to open, close, or reset the session.

Session States

1. Session Inactive: Following a reset, each session function enters the Inactive state. In this state, the session function awaits an open session request from the main function (active open) or the remote target device (passive open). Session establishment is initiated upon receiving the open session request.
2. Create Session: Session creation involves a three-way handshake process using SYN, SYN-ACK, and ACK packets. The first SYN packet can be sent by either the TOE200GADV IP (active open) or the target (passive open). Another device responds with a SYN-ACK packet if it accepts the connection request. Finally, the process is completed when the first device that initiated the SYN packet sends an ACK packet. Once the connection is successfully established, it becomes ready for data transfer, and the session function reports its status upon completing this process.
3. Session Ready: The TCP protocol facilitates bidirectional data transfer, allowing for the simultaneously transmission and reception of data within the same session. This is achieved by assigning unique sequence and acknowledge numbers for each data transfer direction to indicate the position of transmitted and accepted data.
4. Send Data: Each session possesses its dedicated data interface, compatible with a 1024-bit Avalon-ST interface, designed for transmitting data to the target. However, TOE200GADV IP permits only one session to transmit packets at a time. Each session includes a TxTCP buffer for storing data transmitted by the user. The sequence number of the transmitted packet is updated after data is sent from the TxTCP buffer to the target. The data is removed from the buffer once the target updates the acknowledge number to confirm the amount of received data. If all data is successfully transmitted, the session state returns to the 'Ready' state. If the session is terminated, the TxTCP buffer is automatically flushed.
5. Receive Data: Each session includes an RxTCP buffer for storing data received from the remote target. In accordance with the TCP protocol, the available space in the RxTCP buffer corresponds to the value of the received Window size specified in the transmitted packet. Consequently, the target can continuously send data to TOE200GADV IP without waiting for an updated acknowledge number until the amount of unacknowledged data reaches the Window size limit. While receiving data, the sequence number of received packet is monitored to ensure the correctness of the received data sequence. Packet retransmission is triggered if any received data is lost during this process. Once the RxTCP buffer is completely filled with data, the TOE200GADV IP generates a packet to update the acknowledge number, which is then sent back to the target. The RxTCP buffer is automatically cleared during the session establishment process. User can read data from the RxTCP buffer through the 1024-bit Avalon-ST interface for each session individually, so simultaneous data reading from multiple sessions is possible.
6. Terminate Session: Session can be terminated either by the TOE200GADV IP (active close) or the remote target (passive close). The first packet used to initiate connection termination is the FIN packet. If termination request is accepted by another device, it responds with FIN and ACK packets, which can be transmitted in single or multiple packets. Finally, the initiating device sends an ACK packet to complete the process. Upon the successful termination, the session function transitions back to the Inactive state. The session function provides a status update upon the completion of this termination process.

Control Block

MainCtrl

The main controller, known as MainCtrl, involves the main functions (common block in Figure 4), which were elaborated upon in the preceding section: Reset, Target initialization, and Target Ready. It decodes the user-assigned commands and parameters to determine the subsequent processes.

For instance, it manages distinct sequences for transmitting and receiving packets to accommodate three types of initialization process. It generates various request types for the transmit and receive blocks, facilitating the creation or interpretation of ARP request and ARP reply packets. Once the MAC address of the remote target is acquired, the result is stored in Param Regs for utilization by other submodules.

In scenarios where a user's command cannot be supported under specific conditions, the main controller will reject the command and issue an error status.

Param Regs

The parameters stored at Param Regs can be received from the local user assignment or retrieved from the receive block. The local user-defined parameters include both the local host and the remote target parameters such as the MAC address, the IP address, and the port number. While the decoded parameters from the receive block are the remote target parameters such as the MAC address and the port number which are used in specific conditions.

Furthermore, various configuration parameters, including timeout values, initialization mode, initial Maximum Segment Size (MSS), and threshold values, are also assigned by local user and stored within Param Regs for utilization by the main controller.

TCP Engine

The TCP Engine manages the operations of each individual TCP session, as described in the session-specific functions shown in Figure 4.

The establishment of a connection can be triggered by either of two devices. In active open mode, the TCP engine prompts the transmit block to send SYN and ACK packets while instructing the receive block to validate a SYN-ACK packet. Conversely, for passive open mode, the packet types of the transmit block and the receive block are reverse.

To send data, once the amount of data in the TxTCP buffer reaches a certain threshold, the TCP engine calculates the sequence number for the transmitted packet. It instructs the transmit block to continuously send data until the total amount of transmitted data reaches the designated value, determined from the latest target window size retrieved by the receive block. The TCP engine will pause the transmit module if the window size and acknowledge number from the remote target are not updated. In case of lost transmitted data, which are indicated by the generation of duplicate ACK packets by the target, the TCP Engine will suspend the operation of the transmit block and generate the new parameter sets to initiate data retransmission through the transmit block. TOE200GADV IP provides a status signal indicating the remaining amount of transmitted data yet to be received by the remote target, allowing the local user to monitor the progress of the transmission operation. The send operation is considered completed when there is no remaining transmitted data in the TxTCP buffer.

To receive data, the TCP engine continuously monitors the sequence number of the received packet, retrieved from the receive block. This information is used to calculate the quantity of received data. When the received data reaches a specified threshold, the TCP engine computes the acknowledge number and configures it to the transmit block. This action triggers the sending of a packet, which serves to update the current values of acknowledge number and the window size of the RxTCP buffer. If the sequence number of a received packet is skipped, it indicates a data loss situation. In such cases, the TCP engine instructs the transmit block to generate duplicated ACK packets for the recovery of the missing data.

When operating in receiving data only, the local user can configure how quickly the TCP engine triggers the transmit block for sending an ACK packet. This feature allows tuning of ACK packet frequency, helping to avoid excessive or overly frequent ACK packet submitting that might unnecessarily consume the network bandwidth.

Additionally, the TCP engine offers the local user the flexibility to define a threshold value for generating TCP window update packets. This feature is useful when the user logic stops reading data from the RxTCP buffer until it is full. During this period, the target cannot send more data to this session. However, once the user resumes data reading and the free space within the RxTCP buffer increases to the specified threshold value, the TCP engine instructs the transmit block to send an ACK packet, updating the TCP window size based on the RxTCP buffer's free space. Then, the target can resume data transmission.

The connection termination can be done by either of two devices. In active close mode, the TCP engine prompts the transmit block to send FIN and ACK packets while instructing the receive block to validate FIN and ACK packets. Conversely, for passive close mode, the packet types of the transmit block and the receive block are swapped.

Transmit Block

Tx Aligner

User logic transmits data to TOE200GADV IP using a 1024-bit Avalon-ST interface that is consistently valid for all 1024-bit data, except for the last data beat. This last data beat can be configured to specify the number of unused bytes, indicated by the 'empty' signal. Consequently, TxAligner is responsible for adjusting the alignment of the subsequent transmitted data when the previous one is not aligned. A Tx Aligner module is shared among all four transmitted data interfaces used by the user, so only one interface can transfer data at a time. Since the same Ethernet MAC is shared by four TCP sessions, one user interface provides sufficient data bandwidth to achieve the maximum performance of 200G Ethernet. The realigned data from TxAligner is then stored in one of four TxTCP buffers, depending on the active user number.

TxTCP Buffer

The TxTCP buffer serves as the buffer for transmitted data from the user in each TCP session. The size of this buffer is configurable through the parameter TxBufBitWidth<i>, where i corresponds to the session number (ranging from 0 to 3). A mapping table to show the relationship between TxBufBitWidth and the actual size of TxTCP buffer is provided in Table 3.

The maximum data payload size of each transmitted packet is constrained by the negotiated MSS value, which is determined during the connection establishment process. If the amount of transmitted data exceeds this limitation, the data must be divided and transmitted across multiple packets. Each segmented payload data for each TCP packet is then sent to the Packet Builder to construct complete TCP packets.

The transmitted data remains stored in the TxTCP buffer until the TCP Engine confirms that the data has been received by the target. Consequently, having a large TxTCP buffer size allows for continuous data transmission to the target without waiting for updated ACK packets from the target for extended periods. If the target finishes processing the received data and issues an ACK packet before the TxTCP buffer reaches its capacity, data transmission can be transferred seamlessly without pauses, enabling the achievement of the maximum data rate of 200G Ethernet. However, it is essential to note that this advantage does come at the cost of significant FPGA memory resources.

Packet Builder

To encapsulate TCP payload data within an Ethernet packet, various layers of header data must be appended, including parameters such as MAC addresses, IP addresses, port numbers, sequence number, acknowledge number, window size, TCP flags, and checksums. This module is responsible for computing the checksums for both the TCP and IP layers and substituting these calculated values into the packet header. Once the header is fully assembled, it is merged with the segmented payload data obtained from the TxTCP buffer before being transmitted to the TOEMACIF.

In addition to creating TCP/IP packets, the packet builder must also support for generating ARP request and ARP reply packets, which may be required during the IP initialization process.

Since the Packet Builder is shared among four TCP sessions, it must be capable of switching the active TCP session after transmitting a packet for one session to handle packets for the remaining sessions once their data is ready for transmission.

Receive Block

RxPac Buffer

TOEMACIF can transmit Ethernet packets to TOE200GADV IP at any time, whereas the TOE200GADV IP requires a short pause time while processing each Ethernet packet. Consequently, the RxPac buffer must be included for storing Ethernet packets when the receiving logics of TOE200GADV IP are not ready to accept new data. In specific scenarios, the RxPac buffer may become full, leading to the incomplete storage of incoming packets. As a result, the interrupt is asserted by TOE200GADV IP at TOEMACRx I/F to signal that the most recent packet has been discarded. However, if TCP engine detects the loss of a packet, it will initiate a data retransmission process to recover the missing packets. Increasing the frequency of the user logic's clock domain (Clk) decreases the likelihood of the RxPac buffer reaching full capacity.

Packet Filtering

This module is responsible for validating incoming packets. To be considered valid, a packet must meet the following criteria:

1. Network parameters, such as MAC address, IP address, and Port number, must match the local user-defined settings established during initialization.
2. The packet must either be an ARP packet or a TCP/IPv4 packet without a data fragment flag.
3. The IP header length must be 20 bytes, and the TCP header length must be within the range of 20 to 60 bytes.
4. Both the IP checksum and TCP checksum must be correct.
5. The data pointer, as determined by the sequence number, must be within a valid range.
6. The acknowledge number must also be within an acceptable range.
7. Time To Live (TTL) must not be equal to 0.

If a packet meets these validation criteria and contains TCP payload data, the Packet Filtering will extract the TCP payload data and store it in the appropriate RxTCP buffer, determined by the port number value. After the received packet has been fully processed, a signal is generated to notify the TCP Engine to update the current status. In specific scenarios, the TCP Engine may request the Transmit block to generate a packet with updated information, such as acknowledge number and window size, for transmission to the target.

RxTCP Buffer

The RxTCP buffer serves as the buffer for received TCP payload data from the remote target in each TCP session. Its size can be configurable through the parameter RxBufBitWidth<i>, where i corresponds to the session number (ranging from 0 to 3). Table 3 provides a mapping table to show the relationship between RxBufBitWidth and the actual size of RxTCP buffer.

Data received from the target remains stored in the RxTCP buffer until the user reads it via the 1024-bit Avalon-ST I/F. The target continues to transmit TCP payload data until the RxTCP buffer becomes full. Therefore, using a larger RxTCP buffer size increases a chance that the target can continuously send data to the TOE200GADV IP without a pause if the user consistently reads data to free the buffer during operation. As a result, a peak performance can be achieved. Besides, the TCP Engine utilizes the remaining space of RxTCP buffer as the TCP window size in transmitted packets when it needs to update information to the target.

Rx Aligner

The purpose of the Rx Aligner is to transfer and align received data from the RxTCP buffer to the user via the 1024-bit Avalon-ST interface. The 1024-bit data from RxTCP buffer can be directly transmitted to the user logic without requiring alignment for every data beat, except for the last beat, which may contain only a portion of valid bytes. Data that follows unaligned transmission to the user logic must realigned by the Rx Aligner.

TOEMACIF

TxMAC Buffer and RxMAC Buffer

TxMAC and RxMAC buffers are asynchronous buffers integrated into the Transmit and the Receive blocks. They serve to convert the clock domain of data stream between the user clock domain (Clk) and the Ethernet Hard IP clock domain (MacClk).

TxMAC Adapter and RxMAC Adapter

The TxMAC adapter and RxMAC adapter logics are designed to convert data stream format between Avalon-ST interface and MAC Segmented interface. Additional details about the Tx MAC Segmented interface and Rx MAC Segmented interface can be found on the Intel website.

User Logic

As illustrated in Figure 3, the user logic is responsible for managing three distinct user interfaces of the TOE200GADV IP. These interfaces include the Control I/F, utilized for network and system parameter configuration and status monitoring; the TCPTx I/F, designed for data transmission; and the TCPRx I/F, intended for the reception of data streams.

Configuring network and system parameters for the TOE200GADV IP, such as timeout values, can be accomplished by specifying constant values or by utilizing user-defined registers. Furthermore, overseeing the signals responsible for initiating command requests and monitoring operational status can be achieved through a state machine. This approach facilitates the customization of command values and enables real-time tracking of operations, including error detection.

Both the Tx and Rx data interfaces employ a 1024-bit Avalon-ST bus interface. This design choice offers users flexibility, enabling them to map the Data interface of the TOE200GADV IP to other components that are compatible with the Avalon-ST bus.

F-Tile Ethernet Hard IP

The Intel Agilex7 F-Tile Ethernet Hard IP implements both Ethernet MAC and PHY functions and supports various Ethernet data rates. In TOE200GADV IP reference design on the Agilex 7 FPGA I-Series board, the Ethernet Hard IP has been configured with the following parameters:

• Ethernet mode: 200GE-4
• Client interface: MAC segmented
• Tx maximum framesize: 9014
• Rx maximum framesize: 9014
• Enable TX Packing: Not selected

Core I/O Signals of TOE200GADV IP

Table 4 provides detailed descriptions of configurable parameters, while Table 5 outlines the I/O signals for TOE200GADV IP. The TOEMAC interface matches the 1024-bit Avalon stream standard.

Table 5 — User I/O Signals

Core I/O Signals of TOEMACIF

Table 6 and Table 7 provide the I/O signals of TOEMACIF for interfacing with TOE200GADV IP and Ethernet MAC, respectively. The Ethernet MAC interface is designed using 512-bit Segmented Avalon-ST interface.

Timing Diagram — IP Initialization

The TOE200GADV IP begins the IP initialization process when the reset signal (RstB) transitions from 0b to 1b. Prior to de-asserting the reset signal, users must configure the following common parameters: DstMacMode, SrcMacAddr, DstMacAddrIn (only applicable in Fixed-MAC mode), SrcIPAddr, DstIPAddr, WindowThres, MSSInitValSet, TCPCtlTimeOutSet, TCPRxTimeOutSet, and TCPAckDlyTimeSet. These common parameters must retain their values for at least 4 clock cycles after the de-assertion of RstB. Once the IP initialization is successfully completed, InitFinish is set to 1b.

The TOE200GADV IP can be initialized using three different modes, determined by DstMacMode.

Client Mode (DstMacMode = 00b)

When the 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 to Client mode.

1. Set the common parameters, including DstMacMode=00b, with asserting RstB to 1b. The IP initiates initialization in Client mode, loading all common parameters into internal registers. After setting RstB to 1b, user must maintain all inputs for 4 clock cycles. Subsequently, these parameters can be modified as needed.
2. Utilize the MAC address and IP address to construct an ARP request packet, which will be transmitted to the target.
3. Upon detecting an ARP request packet, the target generates an ARP reply packet to return its MAC address.
4. Once the ARP reply packet has been received, the remote target's MAC address is extracted and loaded into the internal registers. The IP sets InitFinish to 1b, signifying the completion of IP initialization. DstMacAddrOut reflects the remote target's MAC address.

Server Mode (DstMacMode = 01b)

Server mode is suitable for applications that employ both the TOE200GADV 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.

Fixed-MAC Mode (DstMacMode[1] = 1b)

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

Timing Diagram — Connection Establishment

After completing the IP initialization, users can issue a command request to establish a connection for data transfer. The IP offers two options: active open and passive open. The TOE200GADV IP has the capacity to manage up to four TCP sessions.

Active Open / Client Mode (TCPConnCmd[1:0] = 00b)

1. Configure session parameters, including TCPDstPort, by setting TCPConnReq to 1b for a single clock cycle. The session number is determined by TCPConnCmd[3:2]. Note: Before sending the command request, ensure InitFinish=1b, TCPConnOn[i]=0b, and TCPConnStatus[(64*i)+4]=0b.
2. The IP validates the inputs and initiates operations. TCPConnReady is set to 0b for 2 clock cycles to pause new command requests.
3. The IP allows new command requests; TCPConnReady set to 1b. Session#0 state changes from 0000b to 0001b (Active open processing).
4. A SYN packet for session#0 is sent to the target. If the target accepts, it responds with a SYN-ACK packet. The IP then generates an ACK packet to confirm connection establishment. TCPConnStatus[4] indicates packet transmission busy status.
5. Upon receiving the SYN-ACK packet, TCPConnOn[0] is set to 1b. Session#0 state transitions to 0100b (Connection ready). Target connection status (MSS, window scaling) available in TCPConnStatus[52:32].
6. IP signals command completion via TCPConnCpl=1b. Details of completion in TCPConnCplStatus[4:0]: bit[4]=1b (success), bits[3:0]=TCPConnCmd value.

Passive Open / Server Mode (TCPConnCmd[1:0] = 01b)

Multiple Command Requests

The TOE200GADV IP supports up to four simultaneous TCP sessions, allowing users to issue multiple command requests (one per session) without waiting for previous commands to complete. Please note that the completion order may differ from the submission order of the commands.

Flush Operation of the RxTCP Buffer During Connection Opening

When users initiate an active or passive open command, the RxTCP buffer undergoes a flush operation. The TxTCP buffer is flushed upon connection termination.

Timing Diagram — Connection Termination

Terminating a connection can be initiated by either the TOE200GADV IP (active close) or the remote target (passive close). For an active close command, users specify the session number and configure the TCPConnCmd value. It is recommended to issue an active close command after there is no remaining data stored in the TxTCP buffer.

Active Close (TCPConnCmd[1:0] = 10b)

Passive Close

Session Reset

In cases where unusual events are detected within a specific session, necessitating a reset process, a reset session command is available. This command enables the execution of a reset process for the specific session without interrupting the operation of the remaining sessions.

Timing Diagram — Data Transmission

Data transfer can commence once the connection has been established and is not in the process of termination. The TOE200GADV IP provides four TOETx interfaces utilizing four TCP sessions. The IP accepts only one set of user data for transmission to the Ethernet MAC at a time.

According to TCP/IP specification, the maximum payload size in each Ethernet packet is constrained by the negotiated MSS. The TOE200GADV IP offers two additional features to expedite the ACK packet, configured by TCPLastMode[1:0]: duplicated data mode (00b) and PSH flag mode (1Xb).

Data Transmission Using a Single Connection With Timeout

Data Transmission With TCPLastMode = 00b (Duplicated Data)

Data Transmission With TCPLastMode[1] = 1b (PSH Flag)

Data Transmission Using Multiple Connections

While there are four user interfaces available, they all share a common TOEMAC Tx interface capable of transmitting only one packet from one session at any given time. The active user interface can switch to the next channels in the sequence 0, 1, 2, 3, 0, ... when the active user pauses transmission or sends the last data packet.

Timing Diagram — Data Reception

The port numbers inside the received packet header are decoded to determine the user interface number (0–3) responsible for transferring the TCP payload data. Each interface transfers data for each session independently, allowing simultaneous data transfer to the user through multiple sessions.

The TCPRx interface includes the EOP flag. The EOP flag can be set to 1b under three conditions: when the last data in the RxTCP buffer aligns with 1024 bits; when the last data is unaligned and reaches a timeout; and when subsequent data follows unaligned data transmission.

Data Reception With 1024-bit Alignment

Data Reception With 1024-bit Misalignment

When the total amount of received data is not aligned to 1024 bits, the data is initially transferred with 1024-bit alignment. Subsequently, if no additional data is received until the timeout configured by TCPRxTimeOutSet, the last portion of unaligned data is transmitted with the EOP flag set to 1b. If additional data arrives after this point, the first portion of that new data is also unaligned, and its length equals (128 – valid bytes of previous unaligned data).

Data Reception Using Multiple Connections

Data Reception With TOEMACRxInt Assertion (RxPac Buffer Overflow)

Acknowledgement With Delay to Respond the Data Reception

Upon receiving TCP data, the TOE200GADV IP returns an updated acknowledgment number to the target device. Users can configure an ACK delay using the TCPAckDlyTimeSet parameter to reduce unnecessary ACK traffic and improve network efficiency.

Timing Diagram — IP Interrupts

The TOE200GADV IP supports two distinct interrupt types: TCPRtrInt (triggered when error is detected and recovery is feasible) and TCPRstInt (activated when error requires RST packet transmission). These interrupt types are determined using 80-bit status signals divided into five groups (common + four session groups, 16 bits each).

The retry process sets a maximum limit of 15 attempts in most cases. If the lost packet remains unresolved after 15 retry attempts, the interrupt transitions to TCPRstInt, initiating RST packet transmission.

Retry Interrupt for Lost ARP Reply Packet (TCPRtrIntStatus[0])

The retry interrupt for lost ARP reply packets (bit[0] of TCPRtrIntStatus, common group) operates without a maximum limit on retry attempts. Similarly, bit[22] and bit[23] of TCPRtrIntStatus (session#0) are unrestricted for lost received data and reverse packet detection respectively.

Retry Interrupt for Lost SYN-ACK Packet (TCPRtrIntStatus[16])

In most cases, the retry process is limited to a maximum of 15 attempts before switching to the TCPRstInt interrupt type. Table 8 details the bit assignment for session interrupt with maximum limit.

Retry Interrupt for Lost ACK Packet During Data Transmission (TCPRtrIntStatus[20])

The TCPRtrIntStatus[20] interrupt is generated when: (a) expected ACK not received within TCPCtlTimeOutSet timeout, or (b) first duplicate ACK packet received (subsequent duplicates with same ACK value are ignored). Upon either condition, IP retransmits unacknowledged data and asserts both TCPRtrInt and TCPRtrIntStatus[20]. After 15 retries without resolution, a reset interrupt is asserted.

Reset Interrupt for Lost SYN-ACK Packet (TCPRstIntStatus[16])

Reset Interrupt Without Retry (TCPRstIntStatus[18])

The reset interrupt can also be triggered without any retry process. Table 9 details the bit assignments for session interrupt without retry process.

The User Interface of TOEMACIF

The TOEMACIF module serves as the interface connecting the TOE200GADV IP and the 200G Ethernet Hard IP (Agilex7 F-Tile Ethernet Hard IP). It is provided separately from the TOE200GADV IP, enabling users to integrate additional modules for Ethernet packets transmission through the 200G Ethernet Hard IP.

The TOEMACIF comprises two submodules, allowing for concurrent packet transfer in both transmission and reception directions. The user interface of TOEMACIF is compatible with the 1024-bit Avalon stream bus, but it does not include a 'Ready' signal to pause data transmission in the Rx user interface.

TOEMACIF Tx Interface

While TOEMACTxSOP is provided as an input, TOEMACIF does not use this signal to indicate the start of a packet. It detects the first data of the packet when it is received after the end of the preceding packet or after a reset. Given that the Ethernet Hard IP necessitates continuous data transmission for each packet transfer, TOEMACIF requires the Tx user interface to maintain TOEMACTxValid asserted until the last data of packet is completely transmitted. If the TxMAC buffer becomes full, TOEMACTxReady is set to 0b to temporarily pause packet transmission.

TOEMACIF Rx Interface

When data is available in the RxMAC buffer, TOEMACIF initiates packet transfer by setting TOEMACRxValid to 1b. Packet transmission may pause temporarily when no more data remains in the RxMAC buffer. During the last data transfer cycle, the user must verify TOEMACRxError to ensure the packet does not contain any errors.

MACRxInt Assertion When RxMAC Buffer Overflows

TOEMACIF includes a 64KB RxMAC buffer designed to store received packets from the Ethernet Hard IP. In the theoretical situation where continuous reception of 64-byte Ethernet packets occurs with a 'Clk' frequency lower than the 'MacClk' frequency (402.832 MHz), the RxMAC buffer may reach its storage limit. The MACRxInt signal indicates when the RxMAC buffer reaches full capacity, prompting TOEMACIF to discard the incoming packet and await the next packet.

Connection Termination of Unusual Cases

• When the TOE200GADV IP receives an active close command, it sends a FIN packet. If a FIN packet with SeqNum=N and AckNum=M is emitted, the expected response is SeqNum=M and AckNum=N+1. If these expected packets are not received within the designated timeout period, without any retry attempts, the TOE200GADV IP transmits a RST packet to terminate the connection.
• Following active close, the TOE200GADV IP ceases to accept additional data from the target. Any received packet containing data is discarded. Only FIN and ACK packets that match the expected values of SeqNum and AckNum are accepted.
• If the target initiates connection termination by sending a FIN packet while the TOE200GADV IP still has remaining data for transmitting, the TOE200GADV IP accepts the termination request and halts data transmission. It responds with FIN and ACK packets. Users can determine the amount of unsent data by monitoring the TOETxStat[19:0] signal.

Verification Methods

The TOE200GADV IP Core functionality was verified by simulation and also proved on real board design by using Agilex 7 FPGA I-series development Kit.

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 at the top of this datasheet.

Revision History