Normal Frame Reception - 2.7 English

1G/10G/25G Switching Ethernet Subsystem Product Guide (PG292)

Document ID
Release Date
2.7 English

The client must be prepared to accept data at any time; there is no buffering within the core to allow for latency in the receive client. When frame reception begins, data is transferred on consecutive clock cycles to the receive client.

During frame reception, rx_axis_tvalid is asserted to indicate that valid frame data is being transferred to the client on rx_axis_tdata. All bytes are always valid throughout the frame, as indicated by all rx_axis_tkeep bits being set to 1, except during the final transfer of the frame when rx_axis_tlast is asserted. During this final transfer of data for a frame, rx_axis_tkeep bits indicate the final valid bytes of the frame using the mapping from above. The valid bytes of the final transfer always lead out from rx_axis_tdata[7:0] (rx_axis_tkeep[0]) because Ethernet frame data is continuous and is received least significant byte first.

The rx_axis_tlast is asserted and rx_axis_tuser is deasserted, along with the final bytes of the transfer, only after all frame checks are completed. This is after the frame check sequence (FCS) field has been received. The core keeps the rx_axis_tuser signal deasserted to indicate that the frame was successfully received and that the frame should be analyzed by the client. This is also the end of packet signaled by rx_axis_tlast asserted for one cycle.

Figure 1. Normal Frame Reception – 32-bits

Figure 2. Normal Frame Reception – 64-bits