Skip to content

AXI Lite

farukyld edited this page Jun 24, 2023 · 6 revisions

axi is a communication protocol that aims to suppurt high troughput, out of order transaction completion, burst data transfer.

transaction

a transaction is a complete sequence (we can think of it consisting of two phase: request and response) of meaningful information transfers between a manager (master) and a subordinate (slave). There are two types of transactinos in axi:

  1. read transaction: manager transfers the adress (and other metadata for the read data) via ar (read request) channel. subordinate, then, sends the read data and the read response via r channel.
  2. write transaction: manager transfers the write request (adress and metadata) and the data to be written to the subordinate via aw and w channels respectively. after those, subordinate sends the write response via b channel to the manager.

channel

a channel is the place where a piece of information is transfered in a transaction. a channel from a source to a destination consist of 3 signals:

  1. valid: from source to destination. says if the information is valid it is not a garbage. it also implies that source wants to send information to the destination.
  2. information: from source to destination. the actual piece of data that source wants to send to the destination.
  3. ready: from destination to source. signals that the destination is available to receive information from the source.

handshake

on a channel, when both source and destination agrees on transfering some information, handshaking occurs. handshaking is the time that when both valid and ready signals (which are being watched by manager and subordinate to take neccessary action) are high. handshaking occurs, source knows that information is received for the destination, and destination knows that from know on, it is responsible to take the neccessary actions. (later, destination informs the source that it completed the neccessary actions and the result of the actions via another channel)

AXI protocol says that source must keep the valid high until the handshake once it raises the signal. it cannot wait for the ready signal to be asserted (raised) to raise the valid signal (i.e. it should raise valid as soon as possible). destination, on the other hand, can wait to assert (raise) the ready signal until it sees the valid from source. and it can drop the ready signal before it sees a valid asserted. (i.e., can switch to communitace to another source if the current one is not transfering anything for that moment)

my comment on the restriction on the source

In AXI, the source (transferer) is held in charge for keeping its eye on destination's (transfered) avalability. and the destination has the freedom to communicate whichever source it wants, whenever it wants. This improves the troughput of the communication.

We can understand it better by thinking of the case if we applied the opposite of the method proposed in the protocol. For example, let's say there are two printers, five computers. computers write some files on printers' memory to be printed.

If printer_n was like "okay computer_m, I am waiting for you if you wish to print some file. I have to stay there until you let me go once I raised ready for you, because of the protocol we used instead of AXI. ", the other computers would be like "hey then, what about me, I am waiting for hours for you to take care of me!?". The other computers actually wouldn't be waiting for the availability of the printer_n, rather they waiting for the computer_m to let it go.

For this example, opposers may say that the AXI approach can cause the computers to wait for long queues. This is partially true, but this problem can be handled by a scheduling mechanism. Computers can be scheduled to printers when print requests exist. This can't be done without knowing a computer wants to print something or not.

Okay, releasing charge from the destination end makes sense, but what about removing from the both end? Charging neither source nor destination to stay at the communication channel also doesn't make sense because this would decrease the troughput because they would just be skipping their common available cycles for no reason.

source has the information to send. It has something to do. Therefore it makes sense for the source to have to take action in order to realize a transfer.

Why I Choosed AXI

  • I liked its generalized ideas like channel, transfer, handshake.
  • It supports read and write at the same time.
  • It is a modern, widely used, and well documented.
  • Tile Link is also a well defined and modern one but AXI has a simplified version called AXI-lite.

AXI Lite

AXI lite is a simplified version of axi. The difference is that axi lite doesn't supports burst data transfer. And there is no out of order transaction completion.

Clone this wiki locally