The 5 Channels of AXI

AXI splits the protocol into 5 independent channels. This architecture allows specific performance optimizations like out-of-order execution and simultaneous read/write.

Channel Architecture

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 & Status

1. Write Address Channel (AW)

Prefix: AW. Carries the destination address and transaction control information.

  • AWADDR: Target address.
  • AWLEN: Number of transfers in burst.
  • AWSIZE: Size of each transfer.
  • AWBURST: Burst type (Fixed, Incr, Wrap).
  • AWID: Transaction ID (for out-of-order).
  • AWVALID / AWREADY: Handshake.

2. Write Data Channel (W)

Prefix: W. Carries the write data.

  • WDATA: The data payload.
  • WSTRB: Write strobes (byte enables).
  • WLAST: Indicates the last beat of the burst.
  • WVALID / WREADY: Handshake.

Note

WID was removed in AXI4. Write data is assumed to be in order with Write Addresses from the same Master.

3. Write Response Channel (B)

Prefix: B. Confirms completion of the write transaction. Sent by Slave.

  • BRESP: Status (OKAY, EXOKAY, SLVERR, DECERR).
  • BID: Matches the AWID of the transaction being acknowledged.
  • BVALID / BREADY: Handshake.

Write Transaction Flow

4. Read Address Channel (AR)

Prefix: AR. Identical to Write Address but for Reads.

  • ARADDR: Read Address.
  • ARLEN, ARSIZE, ARBURST: Burst control.
  • ARVALID / ARREADY: Handshake.

5. Read Data Channel (R)

Prefix: R. Carries data from Slave to Master.

  • RDATA: Read data payload.
  • RRESP: Read status (OKAY, etc.).
  • RLAST: Last beat indicator.
  • RVALID / RREADY: Handshake.

Why This Breaks in Real Designs

In simulation, AXI usually works perfectly because models are ideal. In silicon, these channels break for specific reasons:

1. The "Default Slave" Trap (DECERR)

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.

2. ID Reuse Collision

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.

3. Valid/Ready Dependency Deadlocks

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.

Verification Checklist (The "Golden" List)

Before signing off on an AXI Controller, ensure you have coverage for these specific scenarios:

  • Channel Independence: Can you drive Read Address (AR) while Write Data (W) is stalled?
  • Back-to-Back Bursts: Does the design handle immediately consecutive transactions without handling bubbles?
  • Interleaved R-Channel: If multiple Read Address commands are outstanding with different IDs, does R-data return interleaved correctly?
  • Write Response Latency: Does the master handle a B-response that comes 1000s of cycles after the last data beat?
  • 4K Boundary Crossing: (For Masters) Do you erroneously create a burst that crosses a 4KB address boundary? (Instant protocol violation).

Critical Assertions (SVA)

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

Senior Interview Questions

Q: A Slave is ready to accept data (WREADY=1) but not address (AWREADY=0). Is this allowed?
Yes. All 5 channels are independent. A slave might have space in its write data FIFO but its address command queue is full. A verified Master must handle this mismatched backpressure correctly.
Q: Can a Master issue a Write Response (from earlier transaction) before the current Write Data finishes?
No. The Master DOES NOT issue Write Responses; the Slave does. This is a trick question to check if you know flow direction. The Slave sends B-channel responses.
Q: Why is the separation of Address and Data channels critical for performance?
It allows for "Address Pipelining". The Master can issue the address for Transaction N+1, N+2, and N+3 before the Data for Transaction N has even finished. This hides memory latency (latency hiding) compared to protocols like AHB where Address and Data phases are tightly coupled.
Q: What happens if you assert RREADY=1 only when RVALID=1?
It works, but it causes 50% throughput performance (1 bubble cycle for every transfer). For 100% bandwidth, RREADY (and all Ready signals) should ideally be defaulted to 1 (Pre-Ready) to accept data on the very first cycle it is valid.