AXI splits the protocol into 5 independent channels. This architecture allows specific performance optimizations like out-of-order execution and simultaneous read/write.
Unlike AHB which shares buses for Read/Write, AXI has dedicated channels. A Read and a Write can happen at the exact same time.
Write Channels:
1. Write Address Channel (AW) -> Master sends Address & Control
2. Write Data Channel (W) -> Master sends Data
3. Write Response Channel(B) -> Slave sends Status (OKAY/SLVERR)
Read Channels:
4. Read Address Channel (AR) -> Master sends Address & Control
5. Read Data Channel (R) -> Slave sends Data & StatusPrefix: AW. Carries the destination address and transaction control information.
Prefix: W. Carries the write data.
WID was removed in AXI4. Write data is assumed to be in order with Write Addresses from the same Master.
Prefix: B. Confirms completion of the write transaction. Sent by Slave.
Prefix: AR. Identical to Write Address but for Reads.
Prefix: R. Carries data from Slave to Master.
To prevent deadlocks in an AXI system, the protocol defines strict rules about which handshake signals can depend on others. A "dependency" means a signal is not allowed to be asserted until another signal is already high.
A VALID signal must NEVER depend on a READY signal. If a Master waits for READY before asserting VALID, and the Slave waits for VALID before asserting READY, the system will hang forever in a deadlock.
| Scenario | Status | Logic |
|---|---|---|
AWREADY depends on AWVALID |
LEGAL | The slave waits to see a command before saying it's ready. |
WVALID depends on AWREADY |
ILLEGAL | Master must be able to send data regardless of address acceptance. |
BVALID depends on WLAST |
MANDATORY | Slave MUST wait for the last data beat before responding. |
In complex SoCs with dozens of masters (CPUs, GPUs, ISPs), the interconnect must decide which transaction gets priority. This is handled by the QoS signals: AWQOS and ARQOS.
0x0 is usually the default (no priority), while 0xF is the highest priority.Verification Tip: When testing an AXI Interconnect, always verify that a High-QoS transaction can "jump the queue" and be completed before an already-waiting Low-QoS transaction (assuming different IDs).
In simulation, AXI usually works perfectly because models are ideal. In silicon, these channels break for specific reasons:
If a Master issues a transaction to an address NOT mapped to any slave, who responds? If
your Interconnect doesn't have a default slave, the bus hangs forever awaiting
BVALID or RVALID. Always ensure a default slave exists to
return DECERR.
AXI allows out-of-order completion based on IDs. A common bug: Master re-uses an
AWID for a new transaction before the previous transaction with the same
AWID has completed its Write Response (B-channel). This violates the
protocol and corrupts ordering.
A slave waiting for AWVALID before asserting AWREADY is fine. A
slave waiting for WVALID before asserting AWREADY is a
deadlock risk if the Master waits for AWREADY before sending data.
Golden Rule: Valid signals must NEVER wait for Ready.
Before signing off on an AXI Controller, ensure you have coverage for these specific scenarios:
Don't just rely on VIPs. Copy-paste these into your interface to catch 90% of controller bugs.
// 1. Stability: Once Valid is High, Control signals must remain stable until Ready
property p_stable_address;
@(posedge ACLK) AWVALID && !AWREADY |-> $stable(AWADDR) && $stable(AWID) && $stable(AWLEN);
endproperty
// 2. Write Data Consistency: WLAST must be high on the last beat
property p_wlast_check;
@(posedge ACLK) (beat_count == AWLEN) |-> WLAST;
endproperty
// 3. Response Ordering: B-Channel Valid must NOT happen before Last Write Data Beat
// (Simplistic Check)
property p_bvalid_after_wlast;
@(posedge ACLK) BVALID |-> $past(WLAST_seen, 1);
endproperty