{"id":696,"date":"2015-05-15T16:49:00","date_gmt":"2015-05-16T00:49:00","guid":{"rendered":"http:\/\/www.beyond-circuits.com\/wordpress\/?page_id=696"},"modified":"2023-11-12T14:47:33","modified_gmt":"2023-11-12T22:47:33","slug":"part4","status":"publish","type":"page","link":"https:\/\/www.beyond-circuits.com\/wordpress\/tutorial\/tutorial18\/part4\/","title":{"rendered":"Tutorial 18: I2S Receiver, part 4"},"content":{"rendered":"

AXI4 Streaming<\/h1>\n

In this final part of tutorial 18, we’re going to add an AXI4 streaming interface to the I2S receiver. This interface will allow the receiver to play with the Vivado IP tool flow.<\/p>\n

AXI4 Streaming Overview<\/h2>\n

The ARM AXI4 standard has two types of interfaces. First, there’s the memory mapped AXI4 and AXI4-Lite interfaces, of which we have seen the AXI4-Lite before. These interfaces implement a microprocessor bus interface. Transactions are reads and writes of data to memory addresses.<\/p>\n

Streaming interfaces like the AXI4 Streaming interface are different. They don’t have a concept of addresses, and data transfers can only occur in one direction. They’re meant to handle a stream of information\u2013 sort of like a network packet, or audio data like that produced by our I2S receiver. A streaming interface can either be a master or a slave. Master interfaces generate data that are sent to slaves. So, our I2S receiver is a I2S slave interface\u2013 it receives data from an I2S master, so therefore it is an AXI4 Streaming master interface. In tutorial 19 we will design a I2S transmitter interface which is an I2S master and will have an AXI4 slave interface. We will be able to extend our audio loopback design once we have these two IP blocks.<\/p>\n

Signals<\/h2>\n

An AXI4 Streaming interface uses the signals shown in the following table:<\/p>\n

\n\r\n\r\n
Signal<\/th>\n Source<\/th>\n Description<\/th>\n<\/tr>\n<\/thead>\n
ACLK<\/td>\n Clock source<\/td>\n The clock signal for the interface used by both the slave and master. All signals are sampled and generated from the rising edge of this clock.<\/td>\n<\/tr>\n\r\n
ARESETn<\/td>\n Reset source<\/td>\n Active low reset for the interface.<\/td>\n<\/tr>\n\r\n
TVALID<\/td>\n Master<\/td>\n Indicates that the master is driving a valid transfer.<\/td>\n<\/tr>\n\r\n
TREADY<\/td>\n Slave<\/td>\n Indicates the slave is ready to receive the transfer.<\/td>\n<\/tr>\n\r\n
TDATA<\/td>\n Master<\/td>\n The data being transferred.<\/td>\n<\/tr>\n\r\n
TLAST<\/td>\n Master<\/td>\n Indicates that this transfer is the last transfer in the packet.<\/td>\n<\/tr>\n\r\n
TSTRB<\/td>\n Master (optional)<\/td>\n One bit in this bus for each byte in TDATA indicates whether the data byte is valid.<\/td>\n<\/tr>\n\r\n
TKEEP<\/td>\n Master (optional)<\/td>\n Indicates bits which should be kept as part of the data stream.<\/td>\n<\/tr>\n\r\n
TID<\/td>\n Master (optional)<\/td>\n The data stream identifier.<\/td>\n<\/tr>\n\r\n
TDEST<\/td>\n Master (optional)<\/td>\n Routing information for the data stream.<\/td>\n<\/tr>\n\r\n
TUSER<\/td>\n Master (optional)<\/td>\n User defined sideband information.<\/td>\n<\/tr>\n<\/tbody><\/table><\/div>\n

Handshake<\/h2>\n

Information flows from the master to the slave. They both receive the bus clock and reset signals from other sources. The slave generates only a TREADY<\/em> signal to indicate that it is ready to receive data, and the master generates all other signals. A transfer occurs whenever TREADY and TVALID are both high on the rising edge of ACLK<\/em>.<\/p>\n

A master is not permitted to wait for TREADY<\/em> to be asserted before asserting TVALID<\/em>. However, a slave is permitted to wait for TVALID<\/em> to be asserted before asserting TREADY<\/em>. In addition, a slave may assert and de-assert TREADY<\/em> without receiving an intermediate TVALID<\/em>.<\/p>\n

\"TVALID<\/a>

TVALID before TREADY handshake<\/p><\/div>\n

In the timing diagram to the right, the master presents the transfer information and TVALID<\/em>. TVALID<\/em> must remain active until the slave drive’s TREADY<\/em>. The transfer occurs when both TVALID<\/em> and TREADY<\/em> are asserted at the rising edge of ACLK<\/em>. This is shown with the arrow in the timing diagram.<\/p>\n

\"TREADY<\/a>

TREADY before TVALID handshake<\/p><\/div>\n

In the case shown to the right, the slave presents TREADY<\/em> and then subsequently the master asserts TVALID<\/em>. The transfer occurs when both signals are asserted and ACLK<\/em> rises. This is again shown with the arrow.<\/p>\n

\"TVALID<\/a>

TVALID with TREADY handshake<\/p><\/div>\n

In the timing diagram to the right, the master asserts TVALID<\/em> in the same cycle that the slave asserts TREADY<\/em>. The transfer occurs that cycle as indicated by the arrow.<\/p>\n

Signalling<\/h1>\n
\"I2S<\/a>

I2S audio packet transfer<\/p><\/div>\n

In our case, we only need to send the 32 bits of audio data on TDATA<\/em> and indicate the end of the packet with TLAST<\/em>. On the first transfer cycle, we’ll send the left channel data with TLAST<\/em> low, and then on the second transfer we will send the right channel data with TLAST<\/em> high. Our application will not need any of the optional AXI4 Streaming signals.<\/p>\n

Naming<\/h1>\n

In Vivado, we’re going to want to use a naming convention which allows the IP Packager tool to recognize the signals in the AXI4 Streaming interface. To do this, we’ll prefix all of our port names in the interface with M_AXIS_<\/code>. Here is a list of the signal names we need to use:<\/p>\n

\n\r\n\r\n
Signal<\/th>\n Direction<\/th>\n Description<\/th>\n<\/tr>\n<\/thead>\n
M_AXIS_ACLK<\/td>\n Input<\/td>\n This is the clock signal for the module. It is driven in to both the master and the slave.<\/td>\n<\/tr>\n\r\n
M_AXIS_ARESETN<\/td>\n Input<\/td>\n When this signal is low you should reset the M_AXIS_TVALID signal so that you don't indicate you have valid data to drive.<\/td>\n<\/tr>\n\r\n
M_AXIS_TVALID<\/td>\n Output<\/td>\n Indicates that you have valid data to transfer to the slave.<\/td>\n<\/tr>\n\r\n
M_AXIS_TREADY<\/td>\n Input<\/td>\n Indicates the slave is ready to receive your transfer.<\/td>\n<\/tr>\n\r\n
M_AXIS_TDATA<\/td>\n Output<\/td>\n The data being transferred.<\/td>\n<\/tr>\n\r\n
M_AXIS_TLAST<\/td>\n Output<\/td>\n Indicates that this transfer is the last transfer in the packet. There are two transfers per packet. The first is the left data and the last is the right data.<\/td>\n<\/tr>\n<\/tbody><\/table><\/div>\n

Logic<\/h1>\n

You will need to add logic to generate M_AXIS_TVALID<\/em>. This will need to get set when data is available to transfer to the AXI4 Streaming interface. It will need to clear when the data is read by the AXI4 slave, as indicated by M_AXIS_TREADY<\/em>. Also, you will need to reset this to zero when M_AXIS_ARESETN is low.<\/p>\n

You’re going to need to provide some type of selection logic which drives the left or right channel data onto the M_AXIS_TDATA<\/em> output, depending on which channel we are sending.<\/p>\n

Finally, you’ll also need to make a M_AXIS_TLAST<\/em> output which indicates that the right channel is being read.<\/p>\n

Test<\/h1>\n

The test is much like the previous parts for this tutorial, but it also adds a Bus Functional Model<\/em> for the AXI4 slave interface. This model will accept the data transferred by your I2S receiver interface. It\u00a0also uses a Queue model to hold expected data values. Those files along with the test are linked here:<\/p>\n