2. Channels Description - muneeb-mbytes/axi4_avip GitHub Wiki
Write Address Channel (AW)
| Signals | Source | Version | Description |
|---|---|---|---|
| AWID[x:0] | Master | AXI3 and AXI4 | Provides ID for each transaction |
| AWADDR[31:0] | Master | AXI3 and AXI4 | Address for write request |
| AWLEN[7:0] | Master | AXI4 | Number of transfers support in each transaction |
| AWSIZE[2:0] | Master | AXI3 and AXI4 | No. of bytes to be transferred in each beat |
| AWBURST[1:0] | Master | AXI3 and AXI4 | Indicates type of burst to be performed |
| AWLOCK Manager | Master | AXI4 | Indicates the atomic characteristics of the transaction |
| AWCACHE[3:0] | Master | AXI3 and AXI4 | This signal indicates the system performance |
| AWPROT[2:0] | Master | AXI3 and AXI4 | Provides system-level security and privileged access to each transaction. |
| AWQoS[3:0] | Master | AXI4 | Use to prioritize the transactions |
| AWREGION[3:0] | Master | AXI4 | Region identifier |
| AWVALID | Master | AXI3 and AXI4 | Use to validate the associated signal in order to pass valid information. |
| AWREADY | Slave | AXI3 and AXI4 | Indicates whether the slave is ready for the transactions. |
Write Data Channel (WD)
To start a write operation, the initiator has to provide both the address information and the data ones. The address information are provided over the Write address channel, in a similar manner as a read operation.
Write transactions are started by request on the AW channel. Master sets AW signals like AWADDR, AWSIZE, AWLEN, AWBURST, etc. Then master raises AWVALID. At the same time master also sets data on W channel and sends each item of write data over the write data channel. The master keeps the VALID signal low until the write data is available like WSTRB, WDATA, WLAST.
| Signal | Source | Description | Version |
|---|---|---|---|
| WID | Master/Manager | Write ID tag. This signal is the ID tag of the write data transfer. The WID value must match the AWID value of the write transaction | AXI3 only |
| WDATA | Master/Manager | Write data to be written in the slave. The write data bus can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide. | AXI3 & AXI4 |
| WSTRB | Master/Manager | Write strobes. This signal indicates which byte lanes to update in memory. There is one write strobe for each eight bits of the write data bus. Therefore, WSTRB[n] corresponds to WDATA[(8 × n) + 7:(8 × n)] | AXI3 & AXI4 |
| WLAST | Master/Manager | Indicates whether this is the last data transfer in a write transaction | AXI3 & AXI4 |
| WVALID | Master/Manager | Write valid. This signal indicates that valid write data and strobes are available: HIGH means write data and strobes available, LOW means write data and strobes not available | AXI3 & AXI4 |
| WREADY | Slave/Subordinate | Write ready. This signal indicates that the slave can accept the write data: 1 = slave ready 0 = slave not ready | AXI3 & AXI4 |
The AXI Master asserts the WVALID signal only when it drives valid write data. The WVALID signal remains asserted until the AXI Slave accepts the write data by asserting the WREADY signal.
Incase if the burst is greater than 1, when WREADY is asserted, the AXI Master must place another data on the bus,
assert WVALID and wait until WREADY is asserted. The process continues until all the bursts are completed. On last beat master asserts WLAST and performs the last beat write operation.
Based on the WSTRB[3:0] value the WDATA is transferred in each cycle. WSTRB has to be given value as 4'b1111 for tranferring 32 bit of data. Each bit represents the each byte of WDATA.
After last WVALID/WREADY with WLAST asserted slave sets signals on B channel like: BID, BRESP and then raises BVALID to signal to master that response to write is done.
Cause for Deadlock Condition during write operation:
If the master is allowed to wait for AW to be accepted even after putting W channel data. This attempt of transferring data into slave is not possible as master has not given any address for writing the data. This condition may create a deadlock.
To prevent a deadlock situation, we must observe the dependencies that exist between the handshake signals. In any transaction: the VALID signal of one AXI component must not be dependent on the READY signal of the other component in the transaction the READY signal can wait for assertion of the VALID signal.
For example:
If the WDATA ,WVALID and WREADY is asserted before asserting the AW channel, then there will be dependency on AW channel for the address of the slave and meanwhile slave is also ready to receive the data but it is still waiting for AW channel to get asserted this creates a deadlock condition(slave does'nt perform any operation untill this active write transaction is completed).
Why AXI4 does'nt support WID:
AXI4 has removed the support for write data interleaving hence data has to strictly follow the AW order. If there is WID signal then it may violate the write data by merging with different WID values.
Write Response Channel (B)
A slave uses the write response channel to respond to the write transactions. All write transactions have the completion signaling on write response channel. The write response is signaled for entire transaction but not for the individual transfers. The slave uses the Write Response (B) channel, to confirm that the write transaction has completed once all WDATA has been received.
Fig : Write Response Channel
Write Response Channel signals
| Signal | Source | Description |
|---|---|---|
| BID | Slave | This signal is the write response tag |
| BVALID | Slave | Write Response Valid. This signal indicates that the channel is giving a valid write response |
| BRESP | Slave | Write Response. This signal indicates the status of the write transaction |
| BREADY | Master | Response ready. This signal indicates that the master is ready to accept write response |
| BUSER | Slave | Optional user defined signal in write response channel. Supported only for AXI4 |
Read Address Channel (AR)
| Signals | Source | Version | Description |
|---|---|---|---|
| ARID[x:0] | Master | AXI3 and AXI4 | Provides ID for each transaction |
| ARADDR[31:0] | Master | AXI3 and AXI4 | Address for write request |
| ARLEN[7:0] | Master | AXI4 | No.of transfers support in each transaction |
| ARSIZE[2:0] | Master | AXI3 and AXI4 | No. of bytes to be transfer in each beat |
| ARBURST[1:0] | Master | AXI3 and AXI4 | Indicates type of burst to be performed |
| ARLOCK | Master | AXI4 | Indicates the atomic characteristics of the transaction |
| ARCACHE[3:0] | Master | AXI3 and AXI4 | This signal indicates the system performance |
| ARPROT[2:0] | Master | AXI3 and AXI4 | Provides system-level security and privileged access to each transaction |
| ARQoS[3:0] | Master | AXI4 | Use to prioritize the transactions |
| ARREGION[3:0] | Master | AXI4 | Region identifier |
| ARVALID | Master | AXI3 and AXI4 | Use to validate the associated signal in order to pass valid information. |
| ARREADY | slave | AXI3 and AXI4 | Indicates whether the slave is ready for the transactions |
Read Data Channel (RD)
| Signals | Source | Version | Description |
|---|---|---|---|
| RID[x:0] | slave | AXI3 and AXI4 | Provides ID for each read transaction |
| RDATA[x:0] | slave | AXI3 and AXI4 | Read data signal |
| RESP[1:0] | slave | AXI3 and AXI4 | Read response signal |
| RLAST | slave | AXI3 and AXI4 | Indicates last transfer for the transaction |
| RVALID | slave | AXI3 and AXI4 | Use to validate the associated signal in order to pass valid information |
| READY | Master | AXI3 and AXI4 | Indicates whether the master is ready for the transactions. |
Descriptions
1. Transfer IDs
The AXI protocol defines an ID signals bus for each channel. Marking each transaction with an ID gives the possibility to complete transactions out of order. The use of transfer IDs enables the implementation of a high-performance to interconnect, maximizing data throughput and system efficiency. This feature can also improve system performance because it reduces the effect of transaction latency.
The ID signal buses are as follows:
• AWID
• WID
• BID
• ARID
• RID
According to the AXI protocol specifications, all transactions with a given ID must be ordered. However, there is no restriction on the ordering of transactions with different IDs.
When working with transfer IDs, follow these rules:
• All transfers must have an ID.
• All transfers in a transaction must have the same ID.
• Masters can support multiple IDs for multiple threads.
• Slaves generally need a configurable ID width.
You should also remember these two important AXI parameters for ID signals:
• The write ID width, which is the number of bits used for the AWID, WID and BID buses
• The read ID width, which is the number of bits used for the ARID and RID buses
2. Data length
AxLEN describes the length of the transaction in the number of transfers.
• For AXI3, AxLEN[3:0] has 4 bits, which specifies a range of 1-16 transfers in a transaction.
• For AXI4, AxLEN[7:0] has 8 bits, which specifies a range of 1-256 data transfers in a transaction.
3. Data size
• AxSize[2:0] describes the maximum number of bytes to transfer in each data transfer. Three bits of encoding indicate 1, 2, 4, 8, 16, 32, 64, or 128 bytes per transfer.
4. Burst type
• AxBURST[1:0] describes the burst type of the transaction: fixed, incrementing, or wrapping.
| Value | Burst type | Usage notes | Length (number of transfers) | Alignment |
|---|---|---|---|---|
| 0x00 | FIXED | Reads the same address repeatedly. Useful for FIFOs. | 1-16 | Fixed byte lanes only defined by start address and size. |
| 0x01 | INCR | Incrementing burst. The slave increments the address for each transfer in the burst from the address for the previous transfer. The incremental value depends on the size of the transfer, as defined by the AxSIZE attribute. Useful for block transfers. | AXI3: 1-16 AXI4: 1-256 | Unaligned transfers are supported. |
| 0x10 | WRAP | Wrapping burst. Similar to an incrementing burst, except that if an upper address limit is reached, the address wraps around to a lower address. Commonly used for cache line accesses. | 2, 4, 8, or 16 | The start address must be aligned to the transfer size. |
| 0x11 | RESERVED | Not for use. | - | - |
5. Atomic accesses with the lock signal
The AxLOCK signal is used to indicate when atomic accesses are being performed.
The AXI protocol provides two mechanisms to support atomicity:
• Locked accesses
A locked transfer locks the channel, which remains locked until an unlocked transfer is generated. When a master uses the AxLOCK signals for a transaction to show that it is a locked transaction, then the interconnect must ensure that only that master can access the targeted slave region,
until an unlocked transaction from the same master completes.
Only AXI3 supports locked accesses. AXI4 does not support locked accesses.
• Exclusive accesses
Exclusive accesses are more efficient than locked transactions, and they allow multiple masters to access a slave at the same time.
Because locked accesses are not as efficient as exclusive accesses, and most components do not require locked transactions, they have been removed from the AXI4 protocol.
In AXI3, the AxLOCK signal consists of two bits with the following values:
• 0b00 - Normal
• 0b01 - Exclusive
• 0b10 - Locked
• 0b11 - Reserved
In AXI4, the AxLOCK signal consists of one bit, with the following values:
• 0b0 - Normal
• 0b1 - Exclusive
6.Cache Memory Access
Bufferable Modifiable Write Allocate Read Allocate
AxCACHE [0] (B) is the bufferable bit.
When this bit is set to 1, the interconnect or any component can delay the transaction from reaching its
final destination for any number of cycles.
The bufferable bit indicates whether the response can come from an intermediate point, or
whether the response must come from the destination slave.
AxCACHE [1] is the cacheable bit in AXI3 or the modifiable bit in AXI4.
This bit indicates that the attributes of a transaction at the final destination do not have to match
the attributes of the original transaction.
For writes, setting the modifiable bit means that several different writes can be merged, or a
single write can be broken into multiple transactions.
For reads, setting the modifiable bit means that the contents of a location can be prefetched, or
the values from a single fetch can be used for multiple read transactions.
AxCACHE [2] is the RA bit. The RA bit indicates that on a read, the allocation of the transaction is recommended, but not mandatory. If either AxCACHE [2] or AxCACHE [3] is asserted, then the transaction must be looked up in a cache as it could have been allocated in this cache by another master.
AxCACHE [3] is the WA bit. The WA bit indicates that on a write, the allocation of the transaction is recommended, but not mandatory. If either AxCACHE [2] or AxCACHE [3] is asserted, then the transaction must be looked up in a cache as it could have been allocated in this cache by another master.
7. Quality of service
Quality of service allows you to prioritize transactions allowing you to improve system performance,
by ensuring that more important transactions are dealt with higher priority.
There is two quality of service signals:
** AWQOS is sent on the Write Address channel for each write transaction.
** ARQOS is sent on the Read Address channel for each read transaction.
Both signals are 4 bits wide, where the value 0x0 indicates the lowest priority and the value 0xF
indicates the highest priority.
8.Region Signaling
Region signaling is a new optional feature in AXI4.
When you use region identifiers, it means that a single physical interface on a slave can provide
multiple logical interfaces. Each logical interface can have a different location in the system address
map.
When the region identifier is used, the slave does not have to support the address decode between
the different logical interfaces.
Region signaling uses two 4-bit region identifiers, AWREGION and ARREGION. These regions
identifiers can uniquely identify up to 16 different regions.
9. RRESP[1:0]
For read transactions, the response information from the slave is signaled on the read data channel using RRESP.
RRESP are composed of two bits, and the encoding of these signals can transfer four
responses, as shown in the following table:
- 00 - OKAY Normal access success or exclusive access failure.
OKAY is the response that is used for most transactions. OKAY indicates that a normal access has been successful.
This response can also indicate that exclusive access has failed. Exclusive access is when more than one master can access a slave at once, but these masters cannot access the same memory range. - 01 - EXOKAY Exclusive access okay.
EXOKAY indicates that either the read or write portion of exclusive access has been successful. - 10 – SLVERR Slave error.
SLVERR is used when the access has reached the slave successfully, but the slave wants to return an error condition to the originating master.
This indicates an unsuccessful transaction. For example, when there is an unsupported transfer size attempted, or write access attempted to a read-only location. - 11 - DECERR Decode error.
DECERR is often generated by an interconnect component to indicate that there is no slave at the transaction address.
10.RID [x:0]
Each transfer in the transaction must have the same id.
Transactions with different IDs can complete in any order.
11.RUSER[x:0]
The AXI4 interface signal set has the option to include a set of user-defined signals, called the User signals.
The AXI protocol does not define the functions of these User signals, interoperability issues can arise if two components use the same User signals in a way that is incompatible.
Read and Write Response Structure
The AXI protocol is responsible for provide response signal for both read and write transactions.
- For read response, the signal is sampled on the read data channel.
- For write response, the signal is sampled on the write response channel.
The responses are signaled by :
- BRESP[1:0], for write transfers.
- RRESP[1:0], for read transfers.
BRESP & RRESP encoding :
| BRESP[1:0] or RESP[1:0] | Response |
|---|---|
| 0b00 | OKAY |
| 0b01 | EXOKAY |
| 0b10 | SLVERR |
| 0b11 | DECERR |
- For write transaction the response signal is sampled for the entire burst but not for the each transfer.
- For read transaction the response signal is sampled for each transfer. For example in read transaction there are 8 transfers in which 7 transfers are returned with OKAY response and 1 transfer might return with an error condition.
- The protocol specifically saying that the transfers or transaction must be performed even if the slave reported an error.
Write & Read Responses :
| Response | Description |
|---|---|
| OKAY | Indicates the normal access is successful and failure of the exclusive access |
| EXOKAY | Indicates the read and write portion of an exclusive access is successful |
| SLVERR | Used when transaction reached slave successful but slave wants to return the slave error condition |
| DECERR | Generated by the interconnect component to indicate there is no slave at the transaction address |
OKAY : Normal access success. OKAY response is the response for most of the transactions. An OKAY response indicates the anyone of the following.
- The success of normal access.
- The failure of exclusive access.
- Exclusive access of a slave that doesn't support exclusive access.
EXOKAY : Exclusive access success. This indicates that the exclusive access is success.
SLVERR : SLVERR indicates that the transaction is unsuccessful. This might have the following reasons for SLVERR response.
- FIFO or buffer overrun or underrun condition
- unsupported transfer size attempted
- write access attempted to read-only location
- timeout condition in the slave
- access attempted to a disabled or powered-down function.
DECERR : Decode error. This response indicates the interconnect cannot successful decode a slave access. If the interconnect cannot decode the slave, it must return decode error. This makes that the interconnect connect with the default slave and this default slave returns the DECERR response.
The AXI protocol says that the all transfers in transactions must be performed if an error condition occur. Any component with DECERR must meet this requirement.
BUSER :
- Optionally, the AXI4 interface signal set can include a set of User-defined signals, called the User signals, on each AXI4 channel.
- Generally, this specification recommends that the User signals are not used, because the AXI protocol does not define the functions of these signals and this can lead to interoperability issues if two components use the same User signals in an incompatible manner.