“CHI Is Only For Arm CPUs”

Module 22 · Chapter 22.6 · CHI Misconceptions Engineers Have

Project thread — 22.5 separated permission from data. 22.6 widens CHI's scope beyond CPUs; 22.7 closes the module on snoop filters.

1. The Misconception

The belief: "CHI is only for Arm CPUs — it's a CPU protocol, an Arm thing, not for accelerators or I/O." It scopes CHI to the one place it is most visible: Arm CPU clusters. It is a Foundation misconception about scope (not mechanics), and it is quietly limiting — it makes the accelerator, GPU, DMA, and I/O engineer think CHI is not their concern, when their block may be exactly a CHI node.

2. Why It's Tempting

The belief is tempting because CHI's origin and flagship users are Arm CPUs.

• CHI came from Arm. It is an Arm AMBA specification — the Arm association is accurate.
• The flagship systems are CPU clusters. Neoverse servers, Cortex clusters, CMN meshes, DynamIQ shared units (Chapter 20.3) — the headline CHI deployments are all CPUs.
• It's where CHI is taught. Most CHI material centers on CPU coherence — so "CHI = CPU coherence" is the impression left.

The seed is real: CHI is Arm's, and CPU clusters are its showcase. The error is turning "most visible in Arm CPUs" into "only for Arm CPUs".

3. Key Terms

4. Previous Chapter Connection

This chapter builds on the node model (Chapter 5) and the case studies (Module 20). The node types — RN-F, RN-I, RN-D — exist precisely to admit different kinds of agent; 20.2 put an AI accelerator on CHI, 20.4 put an I/O-coherent DMA engine on it. Those are not CPUs.

Where earlier myths corrected mechanics (snooping, ordering, transactions), 22.6 corrects scope. It reconnects to 22.1: CHI is a protocol of its own (not extended AXI), and a general coherent-interconnect standard — so its reach is general too. Recognizing that is what lets an accelerator or I/O engineer see their block as a first-class CHI node, not a bystander.

5. The Claim, Precisely

State the myth falsifiably.

Claim: "CHI is only usable by Arm CPU cores — non-CPU agents (accelerators, DMA, I/O) and non-Arm designs cannot be CHI nodes."

Testable. Is there a non-CPU CHI node in real systems? Yes — an I/O-coherent DMA engine is an RN-I (Chapter 20.4); an AI accelerator is a coherent subsystem on CHI (Chapter 20.2). Is CHI usable by non-Arm designers? Yes — it is a published AMBA spec many vendors build IP against. The claim fails on the first accelerator or DMA node.

6. Why It's Wrong — The Core

CHI is a coherent-interconnect standard, and its node model was built to admit many kinds of agent.

• The node types are agent-agnostic. RN-F is any cached agent — CPU, GPU, NPU, accelerator; RN-I is any cacheless requester — DMA, NIC, storage; RN-D adds DVM for agents that translate.
• Coherent accelerators are CHI nodes. A GPU/NPU that caches shared memory joins as an RN-F — full coherence, not a CPU.
• I/O-coherent devices are CHI nodes. A DMA engine or controller that needs coherent access without a cache is an RN-I (Chapter 20.4) — one-way coherence, no CPU.
• It's an open, published standard. CHI is an AMBA spec; many vendors build CHI IP — it is not an Arm-internal, CPU-only interface.

CHI's whole reason to exist is to let a heterogeneous mix of agents share memory coherently — CPUs among them, not only them.

7. The Agent Landscape

CHI node types and the non-CPU agents each admits — the breadth the myth hides.

More than half of these are not CPUs. The node model is a menu for heterogeneous agents — the CPU cluster is one entry, not the whole table.

8. The Mechanism

Why the node model admits non-CPU agents by design.

• Coherence is defined by node type, not agent kind. CHI asks "does it cache? does it translate?" — not "is it a CPU?" A GPU that caches is an RN-F by the same rule as a CPU.
• I/O coherence exists for devices. RN-I/RN-D (Chapter 20.4) were added specifically for cacheless and translating devices — non-CPU agents by definition.
• The Home abstracts the requester. The HN serves any RN the same way — it does not care whether the requester is a CPU or an accelerator.
• The spec is public. Being an AMBA standard, CHI is implementable by anyone building conformant IP — not gated to Arm CPUs.

The rule to carry: CHI classifies agents by behavior (cached / cacheless / translating), not by being a CPU — so any block with the right behavior is a CHI node.

9. The Kernel of Truth

Steelman the belief.

• CHI is Arm's, genuinely. It is an Arm AMBA spec — the Arm association is factually correct.
• CPU clusters are the flagship. Arm's own CPU products (Neoverse, CMN, DynamIQ) are the most prominent, best-documented CHI systems — so CHI is most visible there.
• CPU coherence is the hardest case. The full RN-F coherence a CPU needs is CHI's deepest capability — so CPU-centric teaching is reasonable.

The truth: CHI is Arm's and shines in CPU clusters — that part is right. The myth is only the word "only": mistaking the most visible use for the sole use.

10. A Concrete Counterexample

Two non-CPU CHI nodes from this very track.

1. An AI accelerator (Chapter 20.2). An NPU that caches shared model data joins the coherent domain as an RN-F — full coherence, snooped and snooping, exactly like a CPU would — but it is a matrix engine, not a CPU.
2. An I/O-coherent DMA engine (Chapter 20.4). A DMA engine that reads/writes coherent memory without a cache is an RN-I — coherent with the CPUs, never snooped — a pure data-mover, not a CPU.
3. The Home doesn't care. In both cases the HN serves the request by the same rules it uses for a CPU — the node's type (RN-F / RN-I) drives behavior, its being-a-CPU is irrelevant.
4. The conclusion. Two shipping-style CHI nodes, neither a CPU, both first-class on the fabric — the claim "only for Arm CPUs" is false by construction.

The counterexample is inside the track: the case studies already put non-CPU agents on CHI. "CPU-only" contradicts Module 20 itself.

11. What's Actually True

The correct model.

• CHI is a coherent-interconnect standard for many agent kinds, not a CPU feature.
• RN-F admits coherent GPUs / NPUs / accelerators; RN-I/RN-D admit DMA / NIC / storage and translating devices.
• Any block needing coherent or I/O-coherent memory access can be a CHI node.
• CHI is a published AMBA spec — usable by many vendors, not Arm-internal.
• CPU clusters are the flagship, not the boundary — most visible, not the only use.

12. Why The Distinction Matters

Believing "CPU-only" has concrete costs.

• You scope a coherent design as CPU-only. Accelerators and DMA get bolted on late or non-coherently, missing the clean RN-F/RN-I integration CHI offers (Chapter 20.2, 20.4).
• You dismiss CHI as "not my problem." An accelerator/NIC/GPU engineer skips CHI — then can't reason about their own block's coherent integration.
• You mis-architect the fabric. Planning only for CPU RN-Fs under-counts the I/O-coherent and accelerator nodes the real SoC has (Chapter 21.1).
• You assume vendor lock. Believing CHI is Arm-CPU-internal, you overlook third-party CHI IP and interop.

13. Design Implications

What to do once the scope is widened.

• Treat accelerators/GPUs/NPUs as candidate RN-Fs — full coherent participation, if they cache shared data.
• Treat DMA / NIC / storage as RN-I/RN-D — I/O-coherent nodes, planned from the start (Chapter 20.4).
• Plan the fabric for a heterogeneous agent mix — CPUs and non-CPUs as first-class nodes (Chapter 21.1).
• Learn CHI even as an accelerator/I/O engineer — your block's coherent integration is CHI.
• Consider third-party CHI IP — the standard is open, not Arm-CPU-locked.

14. The Trap

15. Related Confusions

• Only CPUs can be RN-F. No — any cached coherent agent (GPU, NPU) can be an RN-F.
• Accelerators just use AXI. They can — but if they need coherence, they are CHI nodes (RN-F / RN-I).
• CHI is Arm-internal. No — it is a published AMBA spec many vendors build to.
• I/O devices can't be coherent. No — RN-I/RN-D give devices I/O coherence (Chapter 20.4).
• Learning CHI is only for CPU designers. No — accelerator and I/O engineers integrate as CHI nodes too.

16. Answering It In An Interview

If asked "is CHI just for Arm CPUs?" — the strong answer:

1. Concede origin and flagship. "CHI is an Arm AMBA spec, and Arm CPU clusters (Neoverse/CMN) are the flagship — that's where it's most visible."
2. Widen the scope. "But CHI is a coherent-interconnect standard. Its node model admits non-CPU agents: RN-F for a coherent GPU/NPU, RN-I/RN-D for DMA/NIC/storage."
3. Cite real nodes. "An AI accelerator is an RN-F; an I/O-coherent DMA engine is an RN-I — neither is a CPU."
4. Note the openness. "It's a published standard — third-party IP builds to it; not Arm-CPU-internal."

That concedes the kernel, widens the scope with the node model, cites real nodes, and notes openness — reasoning, not recital (Chapter 21.6).

17. Key Takeaways

• CHI is a coherent-interconnect standard, not a CPU-only feature.
• The node model admits coherent GPUs/NPUs (RN-F) and DMA/NIC/storage (RN-I/RN-D).
• Any block needing coherent or I/O-coherent memory access can be a CHI node.
• CHI is a published AMBA spec — usable by many vendors, not Arm-internal.
• Kernel of truth: CHI is Arm's and CPU clusters are its flagship — most visible, not the only use.
• The trap: scoping a coherent design CPU-only and bolting on accelerators/DMA late.

18. Quick Revision

"CHI Is Only For Arm CPUs" — refuted. A scope myth, not a mechanics one. The kernel of truth is real: CHI is an Arm AMBA specification, and its flagship, most-visible systems are Arm CPU clusters — Neoverse processors, Cortex clusters, CMN meshes, DynamIQ shared units (Chapter 20.3). But that is where CHI is most visible, not the limit of its use. CHI is a coherent-interconnect standard whose purpose is to let a heterogeneous mix of agents share memory coherently, and its node model was designed to admit non-CPU agents: RN-F is any cached coherent agent — a CPU or a GPU, NPU, or accelerator; RN-I is any cacheless I/O-coherent requester — a DMA engine, NIC, or storage controller; RN-D adds DVM for a device that translates its own addresses. CHI classifies agents by behavior (does it cache? does it translate?), not by being a CPU — so any block needing coherent or I/O-coherent memory access can be a CHI node, and the track's own case studies prove it (an AI accelerator as an RN-F, Chapter 20.2; an I/O-coherent DMA engine as an RN-I, Chapter 20.4 — neither a CPU). CHI is also a published AMBA spec many vendors build IP against, not an Arm-internal interface. The trap is scoping a coherent design CPU-only, so accelerators, DMA engines, and I/O-coherent devices are not planned as the first-class CHI nodes they are — bolted on late, integrated non-coherently, or forcing software cache maintenance the CHI I/O-coherent path removes. Ask of every memory-touching block: "could this be a CHI node, and which type?" CPUs are flagship CHI nodes, not the only ones. Next, 22.7 closes the module: snoop filters are not always perfect.

Coming Next

Chapter 22.7 — "Snoop Filters Are Always Perfect". The module's final myth returns to the directory's limits. Chapter 22.7 refutes "snoop filters are always perfect" — why a finite snoop filter can only approximate the true set of sharers, why capacity pressure forces evictions that produce false-positive snoops (and back-invalidations), and how an imperfect filter trades a little extra snoop traffic for bounded storage — the practical reality behind the directory this module has leaned on throughout.