AxiStreamPacketizer Protocol Version 2

Overview

The AxiStreamPacketizer takes incoming AxiStreams and breaks them into smaller sub-frames (packets). The AxiStreamDepacketizer does the reverse, reassembling a packetized stream into the original frames.

The packetization protocol also takes AXI-Stream sideband data (TDEST, TID, TUSER) and inserts it in the data stream as part of the packetization format.

Together these features are very useful for sending an AXI-Stream over an external transport such as UDP.

Version 2 of the packetizer has been designed to allow interleaving of packet chunks.

Version 2 requires a 64-bit axi-stream, not more or less. If your AXI stream has a different configuration, it will need to be adapted to 8 bytes before it is fed into the AxiStreamDepacketizer.

Details

Packet Header

The Packetizer breaks stream frames in to smaller chunks called packets. Each packet contains an 8 byte header as follows:

Word	Bits	Name	Description
0	3:0	VERSION	Version info. Should always be 0x2.
0	7:4	CRC_TYPE	0: No CRC 1: CRC over just DATA 2: Calculate CRC over HEAD, TAIL, and DATA
0	15:8	TUSER_FIRST	The TUSER of the AXI-Stream frame
0	23:16	TDEST	TDEST of AXI-Stream frame
0	31:24	TID	TID of AXI-Stream frame
1	15:0	SEQ	Packet sequence number of frame
1	30:16	UNUSED
1	31	SOF	Flag indicates first packet of a frame

Packet Tail

Each packet also has a 8 byte tail appended:

Word	Bits	Name	Description
0	7:0	TUSER_LAST	TUSER of last transaction of the AXI-Stream frame.
0	8	EOF	Indicates that this is the last packet of a frame.
0	15:9	UNUSED
0	19:16	LAST_BYTE_CNT	Number of valid bytes (0-8) in last transaction of frame
0	31:20	UNUSED
1	31:0	CRC	Running CRC of the frame data

Notes

Having tUserLast/EOF in a tail allows the packetizer to function in streaming fashion and not have to buffer each packet worth of data in a FIFO.
TDest, TId and TUserFirst are placed in the header of every packet, even though they don’t change after the first packet of the frame.
TUserLast data is only valid if the EOF bit is 1.

CRC Notes

In CRC-type 2 mode the CRC computation only spans the 32 least-significant bits of the tail word (i.e., not the CRC field itself). The resulting CRC is inserted in the CRC field (byte-swapped, see below).
The "little-endian, ethernet" polynomial (0xedb88320) is used; the CRC is initialized with 0xffffffff (and bits are processed in lsb->msb order).
The resulting 32-bit CRC is byte swapped before being stored in the tail word! E.g., the example frame:

Header	Data	Tail (32 lsb)
0x8000000000000222	0xAFFECAFEFEEDBEEF	0x00080102

yields a CRC of 0x9c9c571e and is transmitted as

0x8000000000000222
0xAFFECAFEFEEDBEEF
0x1E579C9C00080102

If CRC-support is not enabled in the firmware then the CRC bits are all zero and no CRC is checked on incoming traffic (but the CRC field must be zero).
If CRC-support is enabled in firmware then the peer must provide a CRC.
Note that the 8 - LAST_BYTE_CNT (arbitrary) bytes which are not part of the payload must be included in the CRC computation. While these bytes are not part of the payload they are still part of the (de-)packetizer frame.