You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overview

The AxiStreamBatcher takes incoming AxiStreams and combines multiple frames (packets) into a larger super-frame. The AxiStreamDebatcher does the reverse, deassembling the super-frame into the original frames. 

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

Together these features are very useful for sending high rate (>1MHz), small AXI-Stream frame into a CPU.

Version 1 of the packetizer has been designed to allow interleaving of AXI streams

Details

Packet Header

The batcher combines frames in to larger super-frame. The super frame has a 8 (or 16) byte header as follows:

BitsNameDescription
3:0VERSIONVersion info. Should always be 0x1
7:4TYPE0: 64-bit AXI stream

1: 128-bit AXI stream

11:8CRC

0: No CRC
1: CRC Included

31:16SEQPacket sequence number of super-frame
44:32TIMEOUT_CFG
  • Forwards the batcher's timeout configuration
  • zero value defined as no timeout used
  • In units of ms
  • 4.096 second max. timout
  • Used for diagnostics
OtherReservedAll reserved bits (undefined) bit set to zero

If TYPE = 64-bit AXI stream, then header is 8 bytes.

If TYPE = 128-bit AXI stream, then header is 16 bytes.

Packet Tail

Each packet within the super-frame is appended 8 byte tail appended:

BitsNameDescription
7:0TDESTTDEST of AXI-Stream frame
15:8TIDTID of AXI-Stream frame
23:16TUSER_FIRSTTUSER of the AXI-Stream frame
31:24TUSER_LASTTUSER of last transaction of the AXI-Stream frame.
44:32TIMER_VALUE
  • Time between header and tail
  • Units of ms
  • Used for diagnostics
45SOFIndicates that this is the start packet of a frame.
46EOFIndicates that this is the last packet of a frame.
56:48LAST_BYTE_CNTNumber of valid bytes in last transaction of frame
62SOFIndicates that this is the start packet of a frame.
63EOFIndicates that this is the last packet of a frame.
OtherReservedAll reserved bits (undefined) bit set to zero

If TYPE = 64-bit AXI stream, then appended tail is 8 bytes.

If TYPE = 128-bit AXI stream, then appended tail is 16 bytes.

Notes

  • Having tUserFirst/SOF and 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:

 

HeaderDataTail (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.

Contact

Larry Ruckman

ruckman@slac.stanford.edu

  • No labels