AXI4-Stream Data Interface

In addition to the basic AXI4-MM interface, the SGDMA IP also provides a streaming AXI4-Stream user logic interface. This interface uses a non-addressed transfer mechanism, enabling high throughput and low-latency transmission of large data streams. It is particularly suitable for continuous data transfer scenarios, such as video streams, network packet transmission, and sensor data collection.

While the CTH and HTC can be configured with different user interfaces, the two interfaces cannot be used simultaneously.

The SGDMA provides an AXI4-Stream interface for streaming transfer mode, enabling the transfer of SGDMA data between the host and the device. The HTC AXI4-Stream interface is used to transfer HTC SGDMA data to external user logic, while the CTH AXI4-Stream interface handles the transfer of CTH SGDMA data to the host. The user-side interface of the SGDMA channel supports the AXI4-Stream bus.

When data is transferred from the host to the user side, the source address is obtained from the host, but the destination address in the descriptor is not used. Stream-based data can be divided into multiple descriptors for transfer, with the end of each data packet indicated by the EOP bit in the descriptor. When transferring a descriptor containing the EOP bit, the AXI4-Stream bus sets the tlast signal high on the last data beat.

When selecting AXI4-Stream port mode, the IP allocates a dedicated AXI4-Stream port on the user logic side for streaming SGDMA transfers. The packet boundary is identified by the combined EOP flag in the descriptor and the tlast signal of the AXI4-Stream interface, ensuring accurate data packet segmentation. Note that channel interleaving is not supported in this mode. All port switching operations must be strictly aligned with the packet boundary, meaning that port switching is only allowed when EOP/tlast is asserted.

The tkeep bits must be set to all 1s for every data transfer in a packet, except for the last packet. On the last transfer—when tlast is asserted—you may use a tkeep value with fewer than all 1s to indicate that the final data cycle is not fully occupying the datapath width. In such cases, the the asserted tkeep bits must be packed toward the least significant bits, representing contiguous valid data. Note that asserting tlast with all zeros in tkeep is invalid and may result in unpredictable DMA behavior.

For CTH transfers, when the CTH engine is enabled and detects a valid descriptor, it receives the data stream from the user side through the AXI4-Stream bus. The engine transfers data byte-by-byte according to the address parameters in the descriptor until it encounters the end-of-packet (EOP) flag or completes the data transfer as specified in the current descriptor. Once the transfer is complete, the CTH engine writes the completion status information to the pre-configured write-back address on the host side. This information includes the execution result of the current descriptor and the actual transferred byte length. It should be noted that this write-back information is completely isolated from the polling-mode status registers, and follows an incremental, descriptor-based state feedback mechanism.

The write-back mechanisms of HTC and CTH are fundamentally different. HTC uses polling registers to obtain global status, while CTH uses descriptor chains to provide fine-grained task completion notifications.