Interface Descriptions

Zynq UltraScale+ Device Technical Reference Manual (UG1085)

Document ID
UG1085
Release Date
2022-09-15
Revision
2.3 English

Table:  Transmit FIFO Interface to PL through Table: Receive FIFO Interface to the PL describe 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 34-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 for Ethernet 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 of information from the external FIFO interface. Synchronous to the tx_clk clock domain.

tx_r_valid

Input

A single tx_clk clock-cycle wide active-High input indicating that the requested FIFO 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 in a 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 a packet. 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 signal is only valid when tx_r_valid is High. It can be set at any time during the packet transfer.

tx_r_underflow

Input

FIFO underflow, indicating the transmit FIFO was empty when a read was attempted. This signal is only valid when the GEM has attempted a read by asserting tx_r_rd and the tx_r_valid signal is not yet asserted. tx_r_flushed should be asserted following this event to indicate to the GEM when it is safe to resume reading.

tx_r_flushed

Input

This signal must be driven High and then Low after a major error event to indicate to the GEM that the FIFO interface is flushed. It enables the GEM to resume reading data. Events that require this signal to be set are indicated by asserting any 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 to be transmitted without appending a crc (tx_no_crc). This input is only valid when both tx_r_valid and tx_r_sop are High.

Table 34-2:      Transmit FIFO Interface to PL Status

Signal Name

I/O

Description

dma_tx_end_tog

Output

Toggled to indicate that a frame is completed and status is now valid on the tx_r_status and tx_r_timestamp outputs that can be read by a PL system element. This signal is not activated when a frame is being retried due to a collision.

dma_tx_status_tog

Input

This signal must be toggled each time either dma_tx_end_tog or collision_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 34-3:      Receive FIFO Interface to the PL

Signal Name

I/O

Description

rx_w_wr

Output

A single rx_clk clock-cycle wide active-High output indicating a write to the FIFO interface.

rx_w_data[31:0]

Output

Received data for output to the FIFO interface. This output is only valid when rx_w_wr is High.

rx_w_sop

Output

Start of packet, indicates the word output to the FIFO interface is the first in a packet. 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 a packet. 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 data is controlled using the tx_r_valid response, which can be returned during the same 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.

 

IMPORTANT:   The PL can assert the tx_r_err signal to flush the FIFOs when an error occurs. A subsequent bit is set in the tx_r_status signal (assuming the error happens after the first four bytes of the frame). When this bit set, a tx_r_flushed signal must be set to indicate the FIFO is flushed and is ready to start running following the error.

In applications where the FIFO interface is required to operate in a half-duplex system, the tx_r_status information is available to indicate where collisions, excess collisions, late collisions, and under runs have occurred. Upon each of these conditions, it is necessary to flush the FIFO and the MAC must wait for this operation to complete before commencing further frames. A falling edge on the tx_r_flushed input signal indicates when the flush is complete. If a collision occurs, it is necessary for the FIFO interface to repeat the transfer of the current frame, so that the frame can be successfully retransmitted.

 

TIP:   The tx_r_flushed input signal must be driven High and then Low after a major error event to indicate to the GEM that the FIFO is flushed. This process enables the GEM to resume reading data. Events that require the tx_r_flushed signal to be set are indicated by asserting any bit of the tx_r_status signal. Before queuing a new frame, wait until the error is fully resolved. Set the tx_r_data_rdy signal after the flush is complete to indicate to the GEM that there is a new frame to transmit. The tx_r_status signal expects a new SOP with VALID after the GEM responds with the first tx_r_rd bit. If the tx_r_err signal is set, avoid sending a new frame into the core until the cleaning process is completed. One caveat to this process is that if a tx_r_err bit is set within the first four bytes of the frame, the tx_r_status signal is not set and the frame is silently dropped by the GEM. To handle the lack of a tx_r_status signal, continue without cleaning up and carry on with the next frame.

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 the tx_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 count the 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 GEM 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.