Skip to content

AMBA CHI · Module 3 · Why CHI Exists

AXI Recap (for CHI Context)

AXI answered AHB's single shared bus with five independent channels — write address, write data, write response, read address, read data — each with its own VALID/READY handshake. It added multiple outstanding transactions and out-of-order completion correlated by ID, so throughput scaled and one slow slave no longer stalled everyone. But base AXI is non-coherent: it has no snoop and no cache-state signalling, so cached copies are invisible to each other and sharing data across masters needs software coherency or an external layer. This chapter recaps the AXI model precisely — channels, outstanding, ordering — and draws the exact line that ACE and CHI cross. The AXI here is representative, not the full specification.

Foundation14 min readAMBA CHIAXIAMBAOutstandingInterconnect

Module 3 · Chapter 3.3 · Why CHI Exists

Project thread — 3.2 pinned AHB's ceiling (shared bus, head-of-line blocking, no coherency). This chapter shows how AXI removed the throughput wall — and stopped exactly at coherency, which ACE (3.4) and CHI take up.

1. Learning Outcomes

By the end of this chapter you should be able to:

  • Name AXI's five channels and their directions — AW, W, B (write); AR, R (read).
  • Explain the VALID/READY handshake and why independent channels remove head-of-line blocking.
  • Describe multiple outstanding transactions and out-of-order completion correlated by ID.
  • State the same-ID ordering rule: transactions on the same ID stay ordered; different IDs may reorder.
  • Implement a representative AXI outstanding-read tracker in SystemVerilog, Verilog-2001, and VHDL.
  • Argue precisely why AXI's throughput does not solve coherency — the gap ACE and CHI fill.

2. Why Should I Learn This?

CHI keeps AXI's best ideas — independent channels, deep outstanding, ID-based ordering — and adds the one thing AXI lacks: hardware coherency. You cannot see what CHI added without knowing exactly where AXI stopped. AXI is also the interconnect most engineers meet first and use most; in a CHI-based SoC it still carries the non-coherent traffic. Knowing its model — and its one hard limit — is the setup for everything coherent that follows.

3. Key Terms

4. Previous Chapter Connection

Chapter 3.2 left AHB with two problems: a shared bus that serializes masters, and a shared HREADY that lets one slow slave stall everyone (head-of-line blocking) — plus no coherency at all.

AXI attacks the first two head-on. Independent channels and per-channel VALID/READY mean transfers proceed concurrently; multiple outstanding transactions and out-of-order completion mean a slow response on one ID no longer blocks others. What AXI does not touch is the third problem: coherency. That omission is deliberate — and it is precisely why ACE and then CHI exist.

5. Core Concept — five channels, deep outstanding, no coherency

AXI is defined by four properties. The first three are why it replaced AHB; the fourth is its ceiling.

  • Five independent channels. Writes use AW (address), W (data), B (response); reads use AR (address), R (data). Each has its own VALID/READY, so reads and writes — and address and data — flow concurrently, not through one shared bus.
  • VALID/READY handshake. A beat transfers only on a cycle where the sender's VALID and the receiver's READY are both high. Back-pressure is per channel, not bus-wide — no shared stall.
  • Outstanding + out-of-order. A master may have many transactions in flight, each tagged with an ID. Responses may return out of order across IDs; the master correlates them by ID. Same-ID transactions stay ordered; different IDs may reorder freely. This is the anti-AHB feature — depth, not one-at-a-time.
  • No coherency. Base AXI has no snoop and no cache-state signalling. Each master sees only its own transactions; cached copies in other masters are invisible.

Put together:

AXI turned the shared bus into five concurrent channels with deep, out-of-order pipelines, so throughput scales and no single transfer blocks the rest. But it says nothing about caches: two masters can hold conflicting copies of the same address and AXI will never know. Removing that blind spot — in hardware — is the whole job of ACE and CHI.

6. Engineering Mental Model — a sorting depot with tracked parcels

Picture AXI as a parcel depot, not a single-track railway (AHB).

  • There are separate conveyor lines for each job — outbound labels (AW), outbound goods (W), delivery receipts (B), inbound requests (AR), inbound goods (R). They run at the same time.
  • Every parcel carries a tracking ID. You can have many parcels in transit at once, and they can arrive in any order — you match each to its order by the ID.
  • A slow parcel on one tracking number does not hold up the others (no head-of-line blocking).
  • But the depot only tracks your parcels. It has no idea that a neighbour is holding a newer copy of the same item — there is no shared registry of who has what (no coherency). That registry is exactly what CHI's directory adds.

7. Engineering Diagram — the five AXI channels

AXI five-channel structure. A Manager connects to a Subordinate through five independent channels: AW write address, W write data, and AR read address flow manager to subordinate; B write response and R read data return subordinate to manager. Each channel has its own VALID/READY handshake. There is no snoop or coherency channel between managers.Managerissues transactionsAWwrite addressWwrite dataBwrite responseARread addressRread dataSubordinatememory / slave12
Figure 1 — representative AXI channel structure. Five independent channels connect manager and subordinate: AW, W, AR flow from manager to subordinate; B and R return from subordinate to manager. Each has its own VALID/READY handshake, so writes and reads proceed concurrently — but there is no channel that lets one manager observe another's cache, so AXI is non-coherent.

Every arrow is one direction of one channel. Note what is missing: no path between managers, and no cache-state channel. AXI moves data superbly and knows nothing about coherency.

8. Worked Example — outstanding reads, out of order by ID

Two reads issued back to back on different IDs, returning out of order. The master issues without waiting for the first to complete, and matches each response by ID.

StepChannelIDWhat happens
1ARID0Manager issues read A (ID0); AR handshake completes
2ARID1Manager issues read B (ID1) without waiting — two outstanding
3RID1Read B's data returns first — out of order, matched by ID1
4RID0Read A's data returns second, matched by ID0

Two facts to carry forward: (1) the manager had two transactions outstanding at once — impossible on AHB's depth-one pipeline; (2) responses came back out of order, and only the ID made that safe. Same-ID transactions would have had to stay in order; different IDs are free to reorder. None of this involves coherency — the data is whatever memory held, with no check on other caches.

9. Transaction Walkthrough — one AXI read via AR and R

A single read, channel by channel:

  1. Address (AR). The manager drives ARADDR, ARID, ARLEN (burst length) with ARVALID. When the subordinate raises ARREADY, the address transfers on that cycle. The transaction is now outstanding.
  2. Concurrent issue. The manager may immediately issue another AR (a different ID) — it does not wait for data. Reads and writes on their own channels proceed in parallel.
  3. Data (R). The subordinate returns beats on the R channel: RDATA, RID (matching the request), RRESP, and RLAST on the final beat, handshaken by RVALID/RREADY.
  4. Completion. On the beat where RVALID, RREADY, and RLAST are all high, the read retires. The manager matches it to its request by RID.

At no point does anything check whether another master holds a newer copy of that address. AXI faithfully returns what the subordinate has — correctness of shared data is the software's problem, not AXI's.

10. RTL / Hardware View — a representative outstanding-read tracker

AXI's defining capability over AHB is depth: many reads in flight at once. Here is the minimal hardware that enforces it — a counter of outstanding reads that permits a new issue only while below the limit. Representative and simplified — no full channel logic, IDs, or bursts beyond RLAST.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// Representative AXI outstanding-read tracker (educational, not full AXI).
// An accepted AR (ARVALID & ARREADY) adds one in-flight read; an accepted final
// read beat (RVALID & RREADY & RLAST) retires one. Permits up to MAX_OUTSTANDING
// concurrently — AXI's depth, versus AHB's single outstanding transfer.
module axi_outstanding_tracker #(
  parameter int MAX_OUTSTANDING = 4
)(
  input  logic aclk,
  input  logic aresetn,
  input  logic arvalid, arready,          // read-address handshake
  input  logic rvalid,  rready,  rlast,   // read-data handshake (final beat)
  output logic can_issue,                 // room for another outstanding read
  output logic [3:0] outstanding
);
  logic [3:0] cnt;
  wire issue  = arvalid && arready;                // AR accepted
  wire retire = rvalid  && rready && rlast;         // read fully returned
 
  always_ff @(posedge aclk or negedge aresetn) begin
    if (!aresetn) cnt <= 4'd0;
    else begin
      case ({issue, retire})
        2'b10:   cnt <= cnt + 4'd1;    // one issued this cycle
        2'b01:   cnt <= cnt - 4'd1;    // one retired this cycle
        default: cnt <= cnt;           // both or neither -> unchanged
      endcase
    end
  end
 
  assign outstanding = cnt;
  assign can_issue   = (cnt != MAX_OUTSTANDING[3:0]);  // gate new issues
endmodule

The same behavior in Verilog-2001:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// Representative AXI outstanding-read tracker (Verilog-2001).
module axi_outstanding_tracker #(
  parameter MAX_OUTSTANDING = 4
)(
  input        aclk,
  input        aresetn,
  input        arvalid, arready,
  input        rvalid,  rready, rlast,
  output       can_issue,
  output [3:0] outstanding
);
  reg  [3:0] cnt;
  wire issue  = arvalid & arready;
  wire retire = rvalid  & rready & rlast;
 
  always @(posedge aclk or negedge aresetn)
    if (!aresetn) cnt <= 4'd0;
    else case ({issue, retire})
      2'b10:   cnt <= cnt + 4'd1;
      2'b01:   cnt <= cnt - 4'd1;
      default: cnt <= cnt;
    endcase
 
  assign outstanding = cnt;
  assign can_issue   = (cnt != MAX_OUTSTANDING[3:0]);
endmodule

And in VHDL:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
-- Representative AXI outstanding-read tracker (VHDL).
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
 
entity axi_outstanding_tracker is
  generic ( MAX_OUTSTANDING : integer := 4 );
  port (
    aclk, aresetn         : in  std_logic;
    arvalid, arready      : in  std_logic;
    rvalid, rready, rlast : in  std_logic;
    can_issue             : out std_logic;
    outstanding           : out std_logic_vector(3 downto 0)
  );
end entity;
 
architecture rtl of axi_outstanding_tracker is
  signal cnt    : unsigned(3 downto 0) := (others => '0');
  signal issue  : std_logic;
  signal retire : std_logic;
begin
  issue  <= arvalid and arready;
  retire <= rvalid and rready and rlast;
 
  process(aclk, aresetn)
  begin
    if aresetn = '0' then
      cnt <= (others => '0');
    elsif rising_edge(aclk) then
      if issue = '1' and retire = '0' then
        cnt <= cnt + 1;
      elsif issue = '0' and retire = '1' then
        cnt <= cnt - 1;
      end if;                       -- both or neither: hold
    end if;
  end process;
 
  outstanding <= std_logic_vector(cnt);
  can_issue   <= '0' when cnt = to_unsigned(MAX_OUTSTANDING, cnt'length) else '1';
end architecture;

All three track depth — the number of reads in flight — and gate new issues with can_issue. That a manager can have several outstanding at once, and complete them out of order, is exactly what AHB could not do.

11. Timing View — outstanding and out-of-order by ID

AXI's identity is cycle-level, so it is worth seeing: two reads issued back to back, their data returning out of order and matched by ID.

AXI: two outstanding reads, responses out of order, correlated by ID

6 cycles
AXI: two outstanding reads, responses out of order, correlated by IDissue two readsissue two readsresponses (reordered by ID)responses (reorderedby ID)two reads outstanding (ID0, ID1)two reads outstanding (ID0,ID1)ID1 returns first -> out of orderID1 returns first -> out oforderACLKARVALIDARIDID0ID1ID1ID1ID1ID1RVALIDRID000ID1ID0ID0t0t1t2t3t4t5
Figure 2 — representative AXI read timing. ARVALID issues ID0 then ID1 on consecutive cycles (two outstanding). On the R channel the data for ID1 returns before ID0 — out of order — each matched to its request by RID. A slow response on one ID does not block the other.

The reorder at cycle 3 is safe only because RID names which request each response belongs to. Strip the IDs away and out-of-order completion would be ambiguous — which is why AXI ordering is defined per ID.

12. Verification View — the outstanding count stays bounded

Two properties keep the tracker honest: the count never exceeds the limit, and it never retires more than it issued.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// Bind to axi_outstanding_tracker (MAX_OUTSTANDING = 4).
// 1. The in-flight count never exceeds the configured maximum.
property p_no_overflow;
  @(posedge aclk) disable iff (!aresetn)
    outstanding <= MAX_OUTSTANDING;
endproperty
assert property (p_no_overflow);
 
// 2. A retire never happens with nothing outstanding (no underflow).
property p_no_underflow;
  @(posedge aclk) disable iff (!aresetn)
    (rvalid && rready && rlast) |-> (outstanding != 0);
endproperty
assert property (p_no_underflow);

The system point, beyond the two checks:

AXI's power is depth — many transactions in flight, completing out of order by ID. But depth has a cost the protocol pushes onto both sides: the subordinate must buffer every outstanding response, and the manager must track every ID it has open. Get the accounting wrong and you overflow a reorder buffer or lose a response. What AXI never asks — and cannot — is whether another master holds a newer copy of the data. That question is coherency, and it needs a different mechanism entirely.

  • What it proves: the outstanding count is bounded and consistent — issues and retires balance.
  • What it does not prove: coherency (AXI has none), or same-ID ordering (a separate ID-tracking check).
  • Bug signature: count exceeds the max (overflow — a manager issuing past can_issue, the DebugLab) or underflows (a spurious response with no matching request).

13. Testbench — watch the outstanding count

Deterministic issue/retire stimulus; the count and can_issue are checked after each edge.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
module tb_axi_outstanding_tracker;
  logic aclk = 0, aresetn;
  logic arvalid, arready, rvalid, rready, rlast;
  logic can_issue;
  logic [3:0] outstanding;
  int errors = 0;
 
  axi_outstanding_tracker #(.MAX_OUTSTANDING(4)) dut (.*);
  always #5 aclk = ~aclk;
 
  task automatic step(input logic iv, input logic rv,
                      input logic [3:0] exp_cnt, input string tag);
    arvalid = iv; arready = iv;             // model an accepted AR when iv=1
    rvalid = rv; rready = rv; rlast = rv;    // model a retired beat when rv=1
    @(posedge aclk); #1;
    if (outstanding !== exp_cnt) begin
      errors++; $display("FAIL [%s] outstanding=%0d exp=%0d", tag, outstanding, exp_cnt);
    end else
      $display("PASS [%s] outstanding=%0d can_issue=%b", tag, outstanding, can_issue);
  endtask
 
  initial begin
    aresetn = 0; step(0, 0, 4'd0, "reset"); aresetn = 1;
    step(1, 0, 4'd1, "issue -> 1");        // one outstanding
    step(1, 0, 4'd2, "issue -> 2");        // two outstanding
    step(1, 0, 4'd3, "issue -> 3");
    step(0, 1, 4'd2, "retire -> 2");       // out-of-order retire, count drops
    step(1, 1, 4'd2, "issue+retire -> 2"); // both -> unchanged
    step(0, 1, 4'd1, "retire -> 1");
    step(0, 1, 4'd0, "retire -> 0");
 
    if (errors == 0) $display("ALL TESTS PASSED");
    else             $display("%0d FAILURE(S)", errors);
    $finish;
  end
endmodule

Expected output:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
PASS [reset] outstanding=0 can_issue=1
PASS [issue -> 1] outstanding=1 can_issue=1
PASS [issue -> 2] outstanding=2 can_issue=1
PASS [issue -> 3] outstanding=3 can_issue=1
PASS [retire -> 2] outstanding=2 can_issue=1
PASS [issue+retire -> 2] outstanding=2 can_issue=1
PASS [retire -> 1] outstanding=1 can_issue=1
PASS [retire -> 0] outstanding=0 can_issue=1

14. DebugLab — issuing past the outstanding limit

1

Issuing past the outstanding limit

IGNORING can_issue -> OUTSTANDING OVERFLOW -> DEADLOCK
Symptom

Under bursty read load, read data comes back corrupted or missing, and eventually the read channel hangs — RVALID never arrives for some IDs. Light load is fine; it only breaks when many reads are issued quickly.

Evidence

The outstanding count climbing past what the subordinate supports:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
cyc  arvalid  arready  can_issue  outstanding  note
 3      1        1         1           3        filling up
 4      1        1         1           4        at MAX_OUTSTANDING
 5      1        1         0           4        can_issue LOW -> must stop
 6      1        1         0          (5)       manager issued anyway -> overflow
 ...                                            subordinate buffer exceeded

At cycle 5 can_issue is low, but the manager keeps ARVALID high and the subordinate accepts — pushing beyond its reorder-buffer depth.

First Divergence

Cycle 6: an AR is accepted while can_issue was low. From here the number of in-flight reads exceeds what the subordinate can track, so at least one response has nowhere to go.

Root Cause

The manager did not respect can_issue. AXI's depth is bounded by how many outstanding transactions each side can hold; issuing past that overflows the subordinate's reorder buffer. Unlike AHB (which simply stalls via shared HREADY), AXI trusts each side to honor its outstanding limits — break that contract and responses are lost.

Fix

Gate new address issues on the outstanding limit: assert ARVALID for a new read only while can_issue is high (or track outstanding per ID against the negotiated depth). The broader lesson: AXI trades AHB's blunt shared stall for depth, and depth must be accounted for on both sides. This bookkeeping — who has what, how much is in flight — is also what makes coherency hard, and why CHI formalizes it with credited, tracked flows.

15. Common Mistakes

  • Thinking AXI is coherent. Assumption: a modern, high-performance bus keeps caches consistent. Bug: stale shared reads across masters (Chapter 1.8). Prevention: base AXI is non-coherent; coherency is ACE/CHI.
  • Assuming responses stay in order. Assumption: reads complete in the order issued. Bug: matching data to the wrong request. Prevention: completion is out of order across IDs; correlate by ID; only same-ID stays ordered.
  • Ignoring outstanding limits. Assumption: issue as many as you like. Bug: reorder-buffer overflow, dropped responses (the DebugLab). Prevention: honor the negotiated outstanding depth per side / per ID.
  • Serializing reads and writes. Assumption: one transfer at a time like AHB. Bug: throughput left on the table. Prevention: read and write channels are independent — run them concurrently.
  • Reusing an ID before completion. Assumption: IDs are just labels. Bug: same-ID ordering rules entangle unrelated transactions or alias responses. Prevention: manage IDs so same-ID transactions are genuinely ordered.
  • Treating this tracker as full AXI. Assumption: an outstanding counter is the protocol. Bug: missing per-ID ordering, bursts, WSTRB, responses, QoS. Prevention: it models depth only — a representative slice.

16. Engineering Checklist

  • Identify all five channels (AW/W/B, AR/R) and their directions.
  • Treat back-pressure as per channel (VALID/READY), not bus-wide.
  • Budget outstanding depth on both sides; gate issues so it is never exceeded.
  • Correlate responses by ID; keep same-ID transactions ordered, allow different IDs to reorder.
  • Never assume coherency — AXI has none; shared data needs software or ACE/CHI.
  • Reserve AXI for non-coherent throughput even inside a CHI-based SoC.

17. Key Takeaways

  • AXI replaces AHB's shared bus with five independent channels, each with its own VALID/READY — reads and writes flow concurrently.
  • Multiple outstanding and out-of-order completion (correlated by ID) give depth AHB never had, and remove head-of-line blocking.
  • Same-ID transactions stay ordered; different IDs may reorder — ordering is defined per ID.
  • Base AXI is non-coherent: no snoop, no cache-state signalling, so cached copies are invisible across masters.
  • That coherency gap — not throughput — is what ACE (broadcast) and CHI (directory) were built to close.
  • The AXI here is representative — enough to place it and see its ceiling, not the full specification.

18. Quick Revision

AXI recap. Five independent channels: AW/W/B (write), AR/R (read), each with its own VALID/READY handshake — concurrent, per-channel back-pressure, no shared stall. Multiple outstanding transactions and out-of-order completion correlated by ID: same ID stays ordered, different IDs may reorder. Depth, not AHB's one-at-a-time; no head-of-line blocking. But base AXI is non-coherent — no snoop, no cache state — so shared data needs software coherency or an external layer. That gap is exactly what ACE (broadcast snoops) and CHI (directory) close. Representative AXI, not the full specification.

Coming Next

Chapter 3.4 — ACE Introduction. With AXI's non-coherence pinned down, the next chapter adds the missing piece: AMBA Coherency Extensions layer snoop channels on top of AXI so masters can finally see each other's caches. We will trace how ACE turns AXI into a coherent fabric — and set up why its broadcast approach, powerful as it is, runs into a wall that only a directory-based design like CHI clears.