Xilinx AXI Stream tutorial - Part 1
In these series of articles I am going to present the design of an AXI4-Stream master. As I often do in my tutorials, I will try to show the design procedure for the block, starting from a "bare bones" solution and gradually adding features to it.
Xilinx provides a wide range of AXI peripherals/IPs from which to choose. My purpose in making my own block was in learning 'hands-on' the protocol. As a side effect, this tutorial provides you with a (synthesizable) AXI4 Stream master which I have not seen provided by Xilinx. The closest IP provided by Xilinx, that I know of, is an AXI memory mapped to AXI stream block.
But first things first, what is AXI4-streaming? Streaming is a way of sending data from one block to another. The idea on streaming devices is to provide a steady flow of high speed data, so usually one new block of data is transferred every clock pulse. Also, to reduce overhead streaming buses do no have addressing. Streaming connections are point to point, so no addressing is needed.
Examples of streaming interfaces are connection of DACs and ADCs, video buses, etc.
The AXI4 Stream I/F has a high grade of flexibility, it has some signals that are required and many that are optional. The following signals of the bus will be implemented in this tutorial:
- Clock (the AXI stream bus is synchronous)
- Ready and Valid (for data flow control)
- Tlast (end of packet)
On the following figure, adapted from Xilinx's AXI reference guide, two transactions are shown:
The first transaction consists of four data cycles, D0 to D3. The last data clock is marked by the TLAST asserted signal. Note that during the transaction both Tvalid and Tready are always high. The second transaction has 'n' data cycles.
Tvalid and Tready are used for flow control. If the transmitter is not ready to send more data, the Tvalid signal goes to low. Similarly, when the receive side of an AXI stream is not ready to receive more data, it de-asserts the Tready signal.
Typical scenario for Tvalid de-assertion is when a transmit data FIFO is empty. A typical scenario for Tready going low is when the receive data FIFO is full.
On this figure, also adapted from the same Xilinx document, a scenario where both valid and ready signals are toggling is shown. A new data can appear at the bus only when valid and ready were both asserted on the previous clock.
For data 'P0', valid and ready are asserted together only at clock period number five, so at clock number 6 a new data 'P1' can be output. 'P3' also takes three clocks to transfer, since at clock 8 valid is deasserted and at clock 9 ready is deasserted. At clock 10 both are asserted so at clock 11 a new data (not shown) is put on the bus by the master.