Interface Descriptions

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.

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.