RX and TX FIFO Interfaces to PL - RX and TX FIFO Interfaces to PL

RX and TX FIFO Interfaces to PL - RX and TX FIFO Interfaces to PL - AM026

Versal AI Edge Series Gen 2 and Prime Series Gen 2 Technical Reference Manual (AM026)

Document ID

AM026

Release Date

2025-12-23

Revision

1.3 English

The following table describes the signal names and the direction of the PL I/O for the transmit and receive FIFO interfaces and interface status.

Note:

The transmit FIFO interface inputs must be pre-synchronized to the tx_clk clock domain.

Table 1. Transmit FIFO Interface to PL
Signal Name	PL Fabric	Description
tx_r_data_rdy	Input	When set to a logic 1, indicates enough data is present in the FIFO interface forEthernet frame transmission to commence on the current packet.
tx_r_rd	Output	A single tx_clk clock-cycle wide active-High output requesting a word ofinformation from the external FIFO interface. Synchronous to the tx_clk clockdomain.
tx_r_valid	Input	A single tx_clk clock-cycle wide active-High input indicating that the requestedFIFO data is now valid. Validates the following inputs: tx_r_data[7:0], tx_r_sop,tx_r_eop, and tx_r_err
tx_r_data[7:0]	Input	FIFO data for transmission. This input is only valid when tx_r_valid is High.
tx_r_sop	Input	Start of packet, indicates the word received from the FIFO interface is the first ina packet. This input is only valid when tx_r_valid is High.
tx_r_eop	Input	End of packet, indicates the word received from the FIFO interface is the last in apacket. This input is only valid when tx_r_valid is High.
tx_r_err	Input	Error, active-High input indicating the current packet contains an error. This signalis only valid when tx_r_valid is High. It can be set at any time during the packettransfer.
tx_r_underflow	Input	FIFO underflow, indicating the transmit FIFO was empty when a read wasattempted. This signal is only valid when the GEM has attempted a read byasserting tx_r_rd and the tx_r_valid signal is not yet asserted. tx_r_flushed shouldbe asserted following this event to indicate to the GEM when it is safe to resumereading.
tx_r_flushed	Input	This signal must be driven High and then Low after a major error event to indicateto the GEM that the FIFO interface is flushed. It enables the GEM to resumereading data. Events that require this signal to be set are indicated by assertingany bit of the tx_r_status.
tx_r_control	Input	Set this input High at the start of a packet to indicate that the current frame is tobe transmitted without appending a crc (tx_no_crc). This input is only valid whenboth tx_r_valid and tx_r_sop are High.

Table 2. Transmit FIFO Interface to PL Status Table
Signal Name	PL Logic	Description
dma_tx_end_tog	Output	Toggled to indicate that a frame is completed and status is now valid on thetx_r_status and tx_r_timestamp outputs that can be read by a PL systemelement. This signal is not activated when a frame is being retried due to acollision
dma_tx_status_tog	Input	This signal must be toggled each time either dma_tx_end_tog orcollision_occured are activated, to indicate that the status is acknowledged.
tx_r_status[3:0]	Output	[3]: fifo_underrun[2]: collision_occured[1]: late_coll_occured[0]: too_many_retries

Table 3. Receive FIFO Interface to the PL Table
Signal Name	Input/Output	Description
rx_w_wr	Output	A single rx_clk clock-cycle wide active-High output indicating a write to theFIFO interface.
rx_w_data[31:0]	Output	Received data for output to the FIFO interface. This output is only valid whenrx_w_wr is High.
rx_w_sop	Output	Start of packet, indicates the word output to the FIFO interface is the first in apacket. This output is only valid when rx_w_wr is High.
rx_w_eop	Output	End of packet, indicates the word output to the FIFO interface is the last in apacket. This output is only valid when rx_w_wr is High.
rx_w_eop	Output	End of packet, indicates the word output to the FIFO interface is the last in apacket. This output is only valid when rx_w_wr is High.
rx_w_status[44:0]	Output	Status signals: [44]: rx_w_code_error indicates a code error. [43]: rx_w_too_long indicates the frame is too long. [42]: rx_w_too_short indicates the frame is too short. [41]: rx_w_crc_error indicates the frame has a bad crc. [40]: rx_w_length_error indicates the length field is checked and is incorrect. [39]: rx_w_snap_match indicates the frame is SNAP encoded and has either no VLAN tag or a VLAN tag with the CFI bit not set. [38]: rx_w_checksumu indicates the UDP checksum is checked and is correct. [37]: rx_w_checksumt indicates the TCP checksum is checked and is correct. [36]: rx_w_checksumi indicates the IP checksum is checked and is correct. [35]: rx_w_type_match4: received frame is matched on type ID register 4. [34]: rx_w_type_match3: received frame is matched on type ID register 3. [33]: rx_w_type_match2: received frame is matched on type ID register 2. [32]: rx_w_type_match1: received frame is matched on type ID register 1. [31]: rx_w_add_match4: received frame is matched on specific address reg 4. [30]: rx_w_add_match3: received frame is matched on specific address reg 3. [29]: rx_w_add_match2: received frame is matched on specific address reg 2. [28]: rx_w_add_match1: received frame is matched on specific address reg 1. [27]: rx_w_ext_match4: received frame is matched by ext_match4 input signal. [26]: rx_w_ext_match3: received frame is matched by ext_match3 input signal. [25]: rx_w_ext_match2: received frame is matched by ext_match2 input signal. [24]: rx_w_ext_match1: received frame is matched by ext_match1 input signal. [23]: rx_w_uni_hash_match: received frame is matched as a unicast hash frame. [22]: rx_w_mult_hash_match: received frame matched as multicast hash frame. [21]: rx_w_broadcast_frame: received frame is a broadcast frame. [20]: rx_w_prty_tagged: VLAN priority tag detected with received packet. [19:16]: rx_w_tci[3:0]: VLAN priority of a received packet. [15]: rx_w_vlan_tagged: VLAN tag detected with a received packet. [14]: rx_w_bad_frame: a received packet is bad. [13:0]: rx_w_frame_length: number of bytes in a received packet.
rx_w_err	Output	Error, active-High output indicating the current packet contains an error
rx_w_overflow	Input	FIFO overflow, indicates to the MAC that the RX FIFO has overflowed
rx_w_flush	Output	FIFO flush, active-High output indicating that the RX FIFO should be cleared.

The tx_r_data_rdy signal indicates to the MAC that there is sufficient data in the FIFO to commence transmission. Once this signal becomes active, the transmit module initiates a read cycle by asserting tx_r_rd for one tx_clk cycle. The FIFO indicates valid data at the FIFO interface by asserting tx_r_valid for a single cycle. The latency between the read and valid cycle as the tx_r_rd request. Once a read commences, it must be terminated with tx_r_valid or tx_r_underflow, even if tx_r_data_rdy is deasserted. The MAC transmitter searches for start of packet (SOP), indicated by a tx_r_sop, and transmission commences once this input becomes valid coincident with tx_r_valid. The MAC continuously searches for tx_r_sop when tx_r_data_rdy is set. Once the SOP is read, data is extracted from the FIFO on the tx_r_data input every time the tx_r_valid is set. The MAC continues to read the frame from memory using tx_r_rd and transmission takes place. The end of frame is indicated by setting tx_r_eop coincident with tx_r_valid. For frames smaller than the data width, both the SOP and end of packet (EOP) indicators must be set in the same data transfer. If two SOPs occur with no intervening EOP, then there is an underrun and both frames are lost, unless the second SOP occurs on the same cycle as EOP in which case the second SOP is ignored. A properly configured system should not generate two SOPs with no intervening EOP.The tx_r_err signal can be asserted at any stage in the frame, it is driven coincident with setting tx_r_valid.

The tx_r_status information must be acknowledged by the TX packet FIFO interface by toggling the tx_r_status_tog input to the MAC each time status is taken. This causes thetx_r_status bus to be cleared until the next end-of-frame or collision occurs. For reception, once it is determined that a frame should be written to memory, the MAC receiver writes data to the FIFO using rx_w_wr and rx_w_data. SOP is indicated by rx_w_sop and EOP uses rx_w_eop. Rx_w_sop and rx_w_eop are not asserted in the same cycle.

The rx_w_err signal is set when the MAC encounters a reception error, such as a frame too short or a CRC error. An rx_w_status bus is available to give status about the frame being received (such as the frame length, matched internally or in the I/O, broadcast, and/or multi-cast).The rx_w_eop signal is always asserted in the same cycle as rx_w_err. The rx_w_overflow input signal can be asserted in the rx_clk domain when an the FIFO fails to receive a frame from the FIFO interface to the PL. If rx_w_overflow is asserted sometime between the SOP and EOP writes, the remainder of the packet continues to be written out, but at the end of the packet, rx_w_err is asserted together with rx_w_eop. Additionally, if rx_w_overflow is asserted, then the receive statistics registers do not countthe frame as good. The rx_w_overflow signal must be asserted no later than one cycle after the rx_w_eop signal is asserted.rx_w_flush is asserted when the 10GbE receive path is disabled in the network control register. If you disable frame reception while a frame is being transferred on the FIFO interface, you will not see an rx_w_eop indication. rx_w_flush is an rx_clk timed signal that is used to clear the receive FIFO when receive is disabled.

FIFO Interface Timing Criteria

The following figure shows the detailed timing relationships for a frame on the FIFO interface (MAC transmit) with one cycle between the read request and data valid.

Figure 1. MAC Transmit with One Cycle

The following figure shows the detailed timing relationships for a frame on the FIFO interface (MAC transmit) that incorporates a 2-byte frame with an SOP and an EOP in the same transfer.

Figure 2. MAC Transmit with SOP and EOP in the Same Transfer

The following figure shows the detailed timing relationships for a frame on the FIFO interface (MAC transmit) with a frame error.

Figure 3. MAC Transmit with a Frame Error

The following figure shows a frame on the FIFO interface (MAC receive).

Figure 4. FIFO Interface MAC Receive

The following figure shows a frame on the external FIFO interface (MAC receive) with a frame error.

Figure 5. MAC Receive with a Frame Error

Note: The FIFO interface exists only in MMI PL. Since the FIFO interfaces require the TX/RX MAC Clock, both clocks will route out to PL as well. The read request from controller requires the read data to be return the very next cycle. Due to the number of pipeline stages in the design to the PL and back, additional buffer is added in the int_wrap to account for the latency. Due to the number of pipeline stages in the design to the PL and back, additional buffer is added in the int_wrap to account for the latency. During lower speed(1G/2.5G) GEM will need longer time to process next available data. we need to guarantee start of next packet (tx_r_sop) is long enough until we receive read request(tx_r_rd) from GEM.

Figure 6. FIFO Interface for 5G and 10G

Figure 7. FIFO Interface for 1G and 2.5G

Note: A FIFO output signal (tx_r_fixed_lat) is generated by the FIFO adapter to signal to the 8-bit FIFO interface when the latency on that internal interface is fixed. Only when the tx_r_fixed_lat signal is asserted can the latency through the design be assumed as fixed, then used to insert the correction field and/or timestamp fields into the datastream. For a 32-bit MAC datapath, the output signal is asserted later than the 22nd read on the 8-bit FIFO interface (mapping to offset 22 in the Ethernet frame). Only the assertion of this signal is of value, your design logic should detect the rising edge of this signal to determine when latency is fixed and ignore the deassertion.