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