Architecture Review Checklist

Module 21 · Chapter 21.1 · CHI Design-Review Checklist

Project thread — Module 20 toured real systems. Module 21 turns the track into review checklists; 21.1 is the pre-RTL architecture review, 21.2 is the RTL review.

1. The Review

The architecture review is a structured pass over a coherent design before any RTL is written — while the node types, topology, home distribution, coherence domains, ordering, deadlock story, and scalability are still decisions on a page. It is the highest-leverage review in the whole flow, because a coherency mistake caught here costs a conversation, while the same mistake caught after RTL and DV costs a respin's worth of rework. This chapter is that review, as a checklist you can actually run.

2. When To Run It

Run the architecture review at the pre-RTL gate — after the coherent architecture is proposed but before it is committed to RTL.

• Trigger: an architecture spec / microarchitecture proposal exists for a CHI subsystem or SoC.
• Precondition: the agents, addresses, and coherence intent are written down — you cannot review what is not yet stated.
• Output: a signed-off architecture, or a list of blocking issues to resolve before RTL starts.
• Cost of skipping: every issue below, if missed here, is found in RTL, DV, or silicon — at 10–100× the cost.

3. Key Terms

4. Previous Chapter Connection

This review is the whole track, reorganized. Node types (Chapter 5), topology and channels (Chapter 6), home-mediated coherence (Chapter 8), ordering and hazards (Chapters 9–10), deadlock freedom and flow control (Chapters 13–14), and the scalability model (Chapter 15) each become a review area with questions. The case studies (Module 20) supply the shapes a good answer takes — a two-level cluster, an I/O-coherent DMA, a NUMA-aware server.

Where the tutorials taught each mechanism, this chapter audits it: for every concept, "is it right in this design, and where is the evidence?" Nothing here is new — that is the point. A review is only trustworthy when it rests on mechanisms the reviewer already understands, so this chapter adds no new theory, only the discipline of checking it before RTL.

5. How To Use This Checklist

The method — run it as a gate, not a formality.

1. Gather the evidence first. For each area, collect the artifact that answers it — an agent/node-type table, an address map, a channel-dependency analysis. No artifact, no tick.
2. Walk the seven areas (sections 7–13) in order. Each is a - [ ] list; a box is ticked only with evidence.
3. Record every gap as a blocking issue — not a "we'll fix it in RTL." Pre-RTL is where it is cheap.
4. Apply the sign-off criteria (section 15) — all areas green, all blocking issues closed.
5. Re-review on change. If the architecture changes materially, re-run the affected areas — coherence is non-local, so one change can break a distant area.

6. The Review Areas

The seven areas of a CHI architecture review, and what each protects.

Each area below is a checklist plus the why. A tick means you have the evidence, not that it sounds right.

7. Checklist — Node Types & Roles

• Every agent has an explicit node type — RN-F / RN-I / RN-D / HN-F / HN-I / SN — with a reason.
• Each caching agent is RN-F (holds state, answers snoops); each cacheless requester is RN-I (or RN-D if it needs DVM).
• No cacheless device is modelled as RN-F (needless snoop/state logic), and no caching device as RN-I (lost coherence).
• Coherent homes are HN-F; I/O / MMIO homes are HN-I — and traffic is routed to the right one.
• DVM support (RN-D / DVM-capable home) exists iff an agent does its own address translation.

Why. The node type is the coherence contract (Chapters 5, 20.4). A wrong type is a structural bug — it changes what snoops, what caches, what orders — and it is invisible later because each block still "works" in isolation.

8. Checklist — Topology & Interconnect

• The interconnect topology (mesh / crossbar / ring) is stated and justified for the agent count.
• Bisection bandwidth scales with the traffic — the fabric is not a future bottleneck (Chapter 15.3).
• Every channel (REQ / RSP / SNP / DAT) has a defined path between every relevant node pair.
• The topology has no structural single point of serialization other than the intended per-address home.
• The chosen topology matches a known-good shape from the case studies (Module 20), or its deviation is argued.

Why. Topology sets the ceiling on scale and latency (Chapters 6, 15.1). A fabric that cannot scale, or that funnels channels, is a rebuild if found in RTL.

9. Checklist — Home Distribution & Interleaving

• Home nodes are distributed, not centralized — coherence throughput scales with home count (Chapter 15.3).
• The address-interleaving function spreads traffic evenly across homes — no hotspot home (Chapter 15.7).
• The directory / snoop-filter sizing is analyzed against the tracked-line count (Chapter 15.5).
• The system-level cache (if any) is sized to the workload's reuse and distributed across homes.
• A utilisation estimate shows a flat per-home / per-link load, not just a low average.

Why. Distribution and interleaving are how coherence scales (Chapter 20.3). A centralized or hotspot home flattens scaling — and the symptom (a hot link at low average) is exactly the thing a review must catch before it is baked in.

10. Checklist — Coherence Domains & Boundaries

• Every address region is assigned a coherence domain — fully-coherent, I/O-coherent, or non-coherent — deliberately.
• Coherence boundaries between subsystems are first-class interfaces that bridge, not leak (Chapter 20.5).
• No subsystem assumes it is the whole coherent domain — each expects an outside requester.
• The DVM domain (which agents receive TLB-maintenance) is defined and complete — no agent silently outside it.
• I/O-coherent paths are one-way by design (device coherent with CPUs; CPUs do not snoop the device, Chapter 20.4).

Why. Domains and boundaries are where composition breaks (Chapter 20.5). A gap (a region no one keeps coherent) or a leak (a boundary exposing internal state) produces stale data that is brutal to debug post-silicon.

11. Checklist — Ordering, Hazards & Memory Model

• The memory ordering the software model requires is stated, and the architecture provides it (Chapter 9).
• Ordering points are identified — where global order is established (typically the home).
• Every address hazard (overlapping in-flight transactions to one line) has a defined resolution at the home (Chapter 10).
• Write / read ordering guarantees to the same and different addresses are specified, not assumed.
• Barriers / DVM-sync / exclusive semantics are mapped to CHI transactions correctly (Chapters 11–12).

Why. Ordering and hazards are the subtlest coherence bugs (Chapters 9–10). They rarely show on a functional test and surface as one-in-a-billion data corruption — so the architecture must pin them down, not hope RTL gets them right.

12. Checklist — Deadlock Freedom & Flow Control

• The channel dependency graph is drawn and shown to be acyclic — no protocol-level deadlock (Chapter 13).
• Request / response separation is preserved — responses can always drain independently of new requests.
• Credit / flow-control loops are bounded — no agent can be starved indefinitely (Chapter 14).
• QoS / priority cannot create priority inversion or livelock under load.
• Every retry / RetryAck path terminates — no infinite retry storm.

Why. Deadlock is a whole-system hang (Chapters 13–14). It is cheap to prove absent on a dependency graph pre-RTL and catastrophic to discover in a hang no one can reproduce. This area is never optional.

13. Checklist — Scalability & NUMA

• The design's latency at scale is estimated — distant-home and cross-die access costs are quantified (Chapter 15.1).
• NUMA is acknowledged — the architecture exposes locality to software, not a flat/uniform assumption (Chapter 20.6).
• Cross-die / chiplet coherent traffic is planned to be rare, and its cost is budgeted.
• The scaling story is explicit — what happens at 2× / 4× the agents (throughput and latency).
• RAS (poison / error containment) is present if the scale warrants it.

Why. At scale, throughput scales but latency governs (Chapter 20.6). An architecture that ignores NUMA passes every functional test and stalls on real workloads — a failure only a scalability review catches.

14. A Worked Review

Applying the checklist to a small example — a coherent NPU subsystem plus CPUs.

1. Node Types (7). The NPU streams and holds no cache → it must be RN-I (or RN-D if it walks page tables), not RN-F. Evidence: an agent table naming each node type with a reason. Tick.
2. Topology (8). Few agents → a crossbar suffices; bisection is ample. Evidence: agent count vs fabric ports. Tick.
3. Homes (9). One home would serialize all NPU + CPU traffic → distribute to two, interleaved. Evidence: interleave function + a flat-load estimate. Was a gap — now a blocking issue, then fixed.
4. Domains (10). NPU data path is I/O-coherent (one-way); config is non-coherent via HN-I. Evidence: an address-map with a domain per region. Tick.
5. Ordering (11), Deadlock (12). Home is the ordering point; the channel graph is acyclic. Evidence: the dependency graph. Tick.
6. Scalability (13). Small, single-die → NUMA not a concern yet; noted for the next size. Evidence: a one-line scaling note. Tick.

The review found the centralized home (area 9) before RTL — a conversation, not a respin. That single catch pays for the whole review.

15. Sign-off Criteria

What "the architecture passed" actually means.

• All seven areas walked, each box ticked with evidence — no bare assertions.
• Every gap logged as a blocking issue and closed before sign-off — none deferred to RTL.
• The deadlock-freedom argument (area 12) is explicit — a drawn acyclic graph, not a claim.
• The node-type table and address/domain map are committed artifacts the RTL team inherits.
• A named reviewer signs, and the evidence is archived — sign-off is accountable, not a meeting.

16. The Pitfall

17. Common Mistakes & Red Flags

• Ticking without evidence. Assumption: it sounds handled. Bug: theatre (the Pitfall). Fix: demand the artifact.
• Deferring gaps to RTL. Assumption: fix it later. Bug: 10–100× cost. Fix: close pre-RTL, it is cheapest here.
• Reviewing an incomplete spec. Assumption: review what exists. Bug: unstated decisions unreviewed. Fix: require agents/addresses/intent written first.
• Skipping the deadlock graph. Assumption: it is probably fine. Bug: an unprovable hang. Fix: draw the acyclic graph.
• Ignoring scale. Assumption: it works today. Bug: NUMA stalls at 2×. Fix: estimate latency at scale.
• Red flag — one home for everything. Centralized serialization; distribute now.
• Red flag — a subsystem that assumes no outside. A boundary leak waiting to happen; require an outside requester.
• Red flag — "we'll define ordering in RTL." Ordering is an architecture decision; pin it now.

18. Quick Revision

Architecture Review Checklist. A structured, pre-RTL pass over a coherent design — the highest-leverage review in the flow, because a coherency mistake caught here costs a conversation and the same mistake caught after RTL/DV costs a respin (10–100×). Run it at the gate after the architecture is proposed and before RTL, with the agents, addresses, and coherence intent written down. Walk seven areas, each ticked only with evidence: Node Types & Roles (RN-F vs RN-I/RN-D, HN-F vs HN-I — the coherence contract, Chapter 5); Topology & Interconnect (scales, no unintended serialization, Chapter 6); Home Distribution & Interleaving (distributed, no hotspot, flat load, Chapter 15.3/15.7); Coherence Domains & Boundaries (no gaps, no leaks, DVM scope complete, Chapters 20.4–20.5); Ordering, Hazards & Memory Model (ordering points, hazard resolution, Chapters 9–10); Deadlock Freedom & Flow Control (an acyclic channel-dependency graph, bounded credits, Chapters 13–14); and Scalability & NUMA (latency at scale, locality, cross-die budget, Chapter 20.6). Sign-off means all areas green with artifacts, all gaps closed before RTL, and the evidence archived. The pitfall is checklist theatre — ticking boxes without evidence, so a wrong node type, a centralized home, a domain gap, or a channel-dependency cycle passes on paper and rides into RTL at a hundred times the cost. No artifact, no tick. Next, 21.2 takes the same discipline into the RTL review.

Coming Next

Chapter 21.2 — RTL Review Checklist. The architecture is signed off; the next review guards the implementation. Chapter 21.2 covers the pre-tapeout RTL review for CHI blocks — the state-machine, flow-control, hazard-logic, exclusive/CMO, and clocking/reset/CDC questions that turn a correct architecture into correct, synthesizable, tapeout-ready RTL, with the same evidence-first discipline this chapter established.