Interview Review Checklist

Module 21 · Chapter 21.6 · CHI Design-Review Checklist

Project thread — 21.5 was the debug triage checklist. 21.6 is the last-mile interview revision; Module 22 tackles common misconceptions.

1. The Review

The interview review is a last-mile self-audit — the night before a CHI interview, compressing the whole track into a checklist you run in your head. It is not a cram sheet of terms; it is a set of areas you should be able to reason about out loud, because an interview tests understanding, not recall. The one rule behind every item: for each topic, can you not only state it but explain why — because the interviewer's next question is always "why?"

2. When To Run It

Run this self-audit in the final day or two before the interview — as a confidence and gap check, not first-time learning.

• Trigger: a CHI-focused interview (design or verification) is imminent.
• Precondition: you have worked the track — this is revision, not a substitute for it.
• Output: a confident map of what you can reason through, and a short list of areas to shore up.
• Cost of skipping: walking in able to recite but not reason — and the first "why?" exposes it.

3. Key Terms

4. Previous Chapter Connection

This chapter is the whole track, compressed for recall-under-pressure. The fundamentals (Chapters 1–5), channels (Chapter 6), states (Chapter 4), transactions (Chapter 7), ordering and hazards (Chapters 9–10), deadlock and QoS (Chapters 13–14), and system design (Chapter 15, Module 20) each become a revision area. The interview module (Module 19) supplies the question shapes.

Where every earlier chapter taught to build understanding, this one checks that the understanding is retrievable and explainable on demand. It adds no new content — it is a mirror: run it, and where you can only recite, you have found exactly the area a single "why?" will expose. Fix those before the interview, not during it. And it leads into Module 22, whose misconceptions are the very traps a reasoning candidate avoids and a reciting one falls into.

5. How To Use This Checklist

The method — for each item, answer, then justify.

1. State the fact — quickly; if you cannot, that area needs relearning, not revision.
2. Explain the why — out loud. If you can state but not explain, you have found a gap — the interviewer will.
3. Answer a "what if?" — change a condition and derive the new outcome. This is the real test.
4. Walk the seven areas (sections 7–13) — a box is ticked only when you can reason, not merely recite.
5. Shore up the gaps — spend your last hours where you can recite but not reason, not re-reading what you know.

6. The Revision Areas

The seven areas of a CHI interview self-audit, and the core question each tests.

Each area below lists what to reason through. A tick means you can explain and derive, not just name.

7. Checklist — Fundamentals

• Why coherence exists — multiple caching agents, one memory; without it, stale data (Chapters 1–3).
• RN / HN / SN roles — requester, home (ordering + directory), slave (memory) — and why each exists (Chapter 5).
• RN-F vs RN-I/RN-D — full cache vs I/O-coherent, and why a DMA is RN-I (Chapter 20.4).
• What the home does — serializes, tracks sharers, snoops on your behalf (Chapter 8).
• Why CHI over AXI for coherence — you can explain it (anticipating Module 22.1).

Why. Fundamentals are the first questions and the foundation for the rest. A shaky "why coherence?" makes every later answer wobble — so you must derive the need, not assert it.

8. Checklist — Channels & Flow Control

• The four channels — REQ, RSP, SNP, DAT — and why they are separate (independent flow, deadlock avoidance, Chapter 6).
• Credit-based flow control — why credits, what a credit guarantees (a buffer slot), Chapter 14.
• Why request/response separation matters — a response must not be blocked behind a request.
• What backpressure does — and why a channel with no credit stalls rather than drops.
• You can explain a credit-return cycle end to end.

Why. Channels and credits are core and love a "why separate?" follow-up (Chapters 6, 14). Reciting "REQ, RSP, SNP, DAT" is easy; explaining why four, why independent is the real question.

9. Checklist — Coherence States & Transitions

• The cache states — and what each permits (read? write? is it dirty? is it shared?), Chapter 4.
• Unique vs Shared — why Unique is needed to write, why Shared allows multiple readers.
• Dirty / clean (owned) — who holds the latest copy and who must write it back.
• Why a transition happens — a snoop or a request drives each state change; you can trace one.
• You can map CHI states to the MOESI mental model and explain where it differs.

Why. States are prime interview territory, and the questions are "why" and "what if" (Chapter 4). Knowing the letters is nothing; explaining why you must be Unique to write — and what a snoop does to your state — is everything.

10. Checklist — Transactions

• ReadShared / ReadUnique / ReadOnce — what each requests and why you'd use it (Chapter 7).
• WriteBack / WriteUnique / CopyBack — how dirty data returns to memory or another cache.
• Snoop transactions — how the home snoops sharers, and what a snoop response carries.
• Ownership transfer / cache-to-cache — why data can move cache-to-cache and skip memory (a key insight).
• You can walk a full transaction — request → snoop → data → completion — for a shared line.

Why. Transactions are where you show depth (Chapter 7). The ownership-transfer insight — data forwarded cache-to-cache, no memory write — is a classic "do they really get it?" question.

11. Checklist — Ordering, Hazards & Memory Model

• Coherence vs ordering — you can explain they are different (coherence ≠ sequential consistency, Module 22.4).
• The ordering point — where global order is established (the home), Chapter 9.
• Address hazards — what happens when two transactions target one line, and how the home resolves it (Chapter 10).
• What ordering CHI guarantees — and what it does not (the memory model).
• You can answer "two agents write the same line at once — what happens?" by deriving it.

Why. Ordering is the subtle area that separates candidates (Chapters 9–10). The trap belief "coherence guarantees ordering" (Module 22.4) is a favorite — and only reasoning avoids it.

12. Checklist — Deadlock, QoS & Fairness

• Why CHI is deadlock-free — channel independence + an acyclic dependency structure (Chapter 13).
• How a deadlock would form — a cycle of waits — and how the protocol prevents it.
• QoS — what it prioritizes, and why it only matters under load, Chapter 14.
• Starvation and fairness — how forward progress is guaranteed for every requester.
• You can sketch a dependency argument for freedom from deadlock.

Why. Deadlock freedom is a depth question (Chapters 13–14). Anyone says "it's deadlock-free"; explaining why — the acyclic dependency argument — is what a strong answer contains.

13. Checklist — System Design & Scalability

• Home distribution & interleaving — why homes are distributed, how coherence scales (Chapter 15.3).
• Directory & snoop filters — why they beat broadcast, and their limits (Chapters 15.5–15.6, Module 22.7).
• NUMA & locality — why latency governs at scale, why placement matters (Chapter 20.6).
• The big-SoC design question — you can architect a coherent SoC out loud (Chapter 19.10, Module 20).
• You can reason about a trade-off (cluster size, SLC size, home count) — not just list components.

Why. System design is the senior question (Module 20). It rewards reasoning about trade-offs — home count vs latency, SLC size vs area — the opposite of a memorized parts list.

14. A Worked Self-Audit

One area, at interview depth — the ownership-transfer question (area 10).

1. Recite. "A dirty line can be forwarded cache-to-cache on a snoop." You have the fact.
2. The "why?". Why skip memory? Because the owning cache already holds the latest data; forwarding it directly is faster and saves a memory write — the home directs the snooped cache to supply the data.
3. The "what if?". What if the requester wants it Unique (to write)? Then the snoop must invalidate the owner as it forwards — the requester ends Unique, the owner ends Invalid, memory still untouched (unless a writeback is required by the state).
4. Deeper. Who writes it back eventually? Whoever holds it dirty when it is finally evicted — ownership carries the writeback obligation.
5. Result. You stated, explained, and derived — the signal of real understanding, not recall.

Reciting step 1 alone is where most candidates stop — and step 2's "why?" is where the interview actually begins. The pitfall (section 16) is stopping at step 1.

15. Sign-off Criteria

What "I'm ready" actually means.

• For every area, you can state, explain the why, and derive a what-if — not merely recite.
• You can walk a full transaction and sketch a deadlock-freedom argument unaided.
• You can architect a coherent SoC out loud, reasoning about trade-offs.
• You can explain coherence vs ordering and why CHI over AXI — the classic traps (Module 22).
• Your last hours went to areas you could recite but not reason — the gaps, not the comforts.

16. The Pitfall

17. Common Mistakes & Red Flags

• Memorizing without understanding. Assumption: knowing names is enough. Bug: the "why?" collapses it (the Pitfall). Fix: learn mechanisms.
• Cramming new material. Assumption: learn it the night before. Bug: shallow, fragile. Fix: revise what you built; shore up gaps.
• Revising your strengths. Assumption: re-read what feels good. Bug: gaps unfixed. Fix: spend the last hours on weak areas.
• Confusing coherence with ordering. Assumption: they're the same. Bug: a classic trap (Module 22.4). Fix: reason the difference.
• Listing, not reasoning, in system design. Assumption: name the parts. Bug: no trade-off depth. Fix: reason the trade-offs.
• Red flag — you can state but not explain a fact. That is the exact area a "why?" will expose; fix it tonight.
• Red flag — a "what if?" freezes you. You are reciting, not deriving; practice changing a condition and re-deriving.
• Red flag — "it just works that way." A non-answer; every CHI behavior has a mechanism you can name.

18. Quick Revision

Interview Review Checklist. A last-mile self-audit — the night before a CHI interview, compressing the whole track into a checklist you run in your head. Not a cram sheet: a set of areas you must be able to reason about, because an interview tests understanding, not recall. Run it in the final day or two as a gap check on material you have already worked. For each area, state the fact, explain the why, and derive a what-if — a box ticks only when you can reason, not merely name. The seven areas: Fundamentals (why coherence, RN/HN/SN, Chapter 5); Channels & Flow Control (why four separate channels, credits, Chapters 6/14); Coherence States (what each permits, why Unique to write, Chapter 4); Transactions (Read/Write variants, ownership transfer cache-to-cache skipping memory, Chapter 7); Ordering, Hazards & Memory Model (coherence ≠ ordering, the ordering point, Chapters 9–10); Deadlock, QoS & Fairness (the acyclic dependency argument, QoS under load, Chapters 13–14); and System Design & Scalability (home distribution, NUMA, the big-SoC answer, Chapter 15/Module 20). Sign-off means you can state, explain, and derive in every area, walk a transaction, sketch deadlock-freedom, architect an SoC aloud, and you spent your last hours on recite-but-not-reason gaps. The pitfall is reciting names without reasoning — memorizing transaction names and state letters while missing the mechanism, so the interviewer's inevitable "why?" or "what if?" collapses the answer and exposes the fluent first reply as hollow. Know the mechanism beneath every fact — the track was built to teach exactly this. Next, Module 22 confronts the misconceptions a reasoning engineer refutes and a reciting one repeats.

Coming Next

Chapter 22.1 — "CHI Is Just AXI With Coherency". The checklists are complete; Module 22 turns to the myths engineers carry about CHI. Chapter 22.1 opens Module 22 — CHI Misconceptions Engineers Have by refuting the most common one: that CHI is merely a coherency layer bolted onto AXI. It is a distinct, layered, packet-based coherent protocol — and understanding why that belief is wrong cements everything this track built.