The timing of a normal inbound frame transfer is represented in the following figures. 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.
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 the 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 must be analyzed by the client.
This is also the end of the packet signaled by rx_axis_tlast asserted for one cycle.