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 should be analyzed by
the client. This is also the end of the packet signaled by rx_axis_tlast
asserted for one cycle.