Frame Collisions – Half-Duplex Operation Only - 9.0 English

In half-duplex Ethernet operation, collisions occur on the medium as a matter of course; this is how the arbitration algorithm is fulfilled. In the case of a collision, the MAC core signals to you that data might need to be resupplied as follows.

• If there is a collision, the tx_collision signal is set to 1 by the MAC core. If a frame is in progress, you must abort the transfer asserting tx_axis_mac_tlast and tx_axis_mac_tuser.
• If the tx_retransmit signal is 1 in the same cycle that the tx_collision signal is 1, you must then resubmit the previous frame to the MAC core for retransmission, tx_axis_mac_tvalid must be asserted to the MAC core within six cycles of the tx_retransmit signal. If tx_axis_mac_tvalid is asserted later than this, the MAC assumes that the frame is not retransmitted and the number of retransmission attempts counter within the MAC is reset. This case is illustrated in Figure 1.

If any frame presented to the user interface is shorter than the collision window (slot time) as defined in IEEE Std 802.3-2008, a retransmission request can occur after the end of the frame as observed on the user interface. Therefore, the user logic (which might have queued a subsequent frame for transmission) might then have to rewind back to the previous frame. In this case, the current frame has to be aborted by asserting tx_axis_mac_tlast with tx_axis_mac_tuser and the previous frame data should be re-supplied on the tx_axis_mac_tdata[7:0] port within the same six cycles illustrated in Figure 1.

For reference, the collision window (slot time) is 64 validated clock cycles when operating at 10 Mbps and 100 Mbps speeds (corresponding to 64-bytes of frame data), and 512 clock cycles when operating at 1 Gbps speed (corresponding to 512-bytes of frame data).

• If the tx_retransmit signal is 0 in the same cycle that the tx_collision signal is 1, the number of retries for this frame has exceeded the Ethernet specification or the collision has been classed as late, and the frame should be dropped by you. You can then make any new frame available to the MAC for transmission without timing restriction. This case is illustrated in Figure 2.

Identifying the frame that has undergone collision can be difficult for certain traffic scenarios. For example, if the MAC asserts the tx_collision signal when a back-to-back frame transmission is in progress or when a short frame (that is, less than the slot time) is followed immediately by another frame for which the MAC has already accepted two bytes. Here you might not recognize if it was the first or the second frame that has undergone collision and thus not know which frame to present again to MAC for the retransmission. In such cases, you can monitor tx_statistic_vector[0] when collision is indicated to confirm if the first frame has been successfully transmitted. If it has, the collision indication is for the second frame and vice versa.