Microarchitecture Review Checklist

A microarchitecture review is the moment when a design is checked by people who did not build it, and a checklist is what stops a review from relying on memory. Most serious bugs and missed targets fall into known categories: a full queue nobody handled, a reset value nobody set, a flush that leaves something behind. This article gathers the questions from across this tutorial into one practical list, organized by block, with an explanation of why each question matters and how to run a review.

11 min read | Intermediate

What You'll Learn

• Run a microarchitecture review with a clear structure
• Check a pipeline, a cache and a memory interface for common omissions
• Review traps, power, reset and debug support
• Record decisions and follow up on them

Why Use a Checklist

Reviewers are skilled, but they are human, and a long meeting wears down attention. A checklist makes sure the dull questions get asked. Those are often the ones that matter: nobody finds "what is the reset value?" exciting, but missing reset values have stopped many chips from booting.

Use this list for a design review, for a spec review, or as your own check before showing your work to anybody. Not every question applies to every design. A small core has no reorder buffer, and an embedded core may have no MMU. Skip what doesn't apply, and add what your project has learned.

Running a Review

A good review has some structure:

1. Send material ahead. Reviewers should read the spec before the meeting.
2. Invite the right people. An architect, an RTL designer from a neighboring block, a verification engineer, a physical designer, and for some blocks a software engineer.
3. Start with the goals. What must this block achieve, and how do we know?
4. Walk through the normal flow, then the corners. Spend most of the time on the corners.
5. Record actions, with an owner and a date. A review with no list of actions was only a presentation.

Keep it focused on the design, not on the designer. The aim is for everyone to find problems while they are cheap to fix.

Goals and Requirements

• Are performance, power, area and frequency targets written down, with the workloads and conditions?
• Is each target backed by a model, or by measurement? Performance Modeling explains how.
• What's the margin on each budget?
• What is out of scope, and does everybody agree?
• Which assumptions could change, and what would be affected?

Pipeline

• Is there a table of what each stage does and what each pipeline register holds?
• Is each data dependence handled by forwarding or a stall, for every distance and operand, including store data?
• Does forwarding exclude x0, check the write enable, and pick the newest value?
• Is the load-use case detected exactly, with no false stalls on instructions with no source registers?
• If stall, flush and freeze occur together, is the priority defined?
• Does a flush clear every side effect, including counters and any state update?
• Does a value being forwarded survive a pipeline freeze?
• Which is the critical path, and is there a plan for it?

Data Hazards and Forwarding and Load-Use Stalls and Control Hazards explain each of these points.

Front End

• What happens on a BTB or predictor miss, and on a false hit?
• Is the predictor read within one cycle? If not, what is lost on each taken branch?
• Are history and the return stack repaired after a flush?
• What's the misprediction penalty, and is it verified?
• Does fetch handle an instruction that crosses a line or a page?
• What happens if a fetch error occurs on a wrong path? It must not trap.

Memory System

• Are cache size, ways, line size and policies stated, along with the hit latency?
• Do valid bits clear at reset, and how does cache invalidation at start-up happen?
• Is a dirty victim always written back, including during a flush?
• Does each load check the store buffer, handling partial overlaps?
• What happens when each queue fills: store buffer, miss queue, write buffer?
• Are device regions non-cacheable, and non-speculative?
• Is the memory ordering model stated, and are fences implemented?
• How do DMA and coherence work? Who cleans the caches?
• What happens on a bus error, on a read, on a write and on an instruction fetch?
• What protects memories against soft errors: parity, ECC, or nothing?

The questions on full queues are the classic gap. A design with only a normal path often hangs when a store buffer fills up while a load waits for it, in a pattern no one drew on the whiteboard. Look for deadlock: a cycle of things all waiting for each other.

Virtual Memory

• Are TLB sizes, associativity and replacement stated?
• Is the walker's behavior defined on a fault at each level?
• Does the hardware set A and D bits, or does it raise a fault?
• How does sfence.vma work, with and without an address and ASID?
• Do cache index bits fit within the page offset, or how are aliases handled? Caches and Virtual Memory explains.
• Does a misaligned access crossing a page handle a fault on the second page?

Traps and Privilege

• Is each exception cause listed, with its priority and with what goes in mtval?
• Are exceptions precise, in every case?
• Is it clear which stage takes a trap, and how interrupts are attached to an instruction?
• What's the worst-case interrupt latency, and what makes it worse?
• Can a long operation be interrupted?
• Are CSR side effects handled, by a flush after writes that change behavior?
• Are illegal encodings detected, including illegal CSR accesses?
• Does wfi wake correctly with interrupts disabled? Interrupts and Interrupt Latency covers it.

Reset and Clocks

• Does every state element have a defined reset value, or a reason not to?
• Is reset release synchronized to the clock?
• Which memories are unknown after reset, and who initializes them?
• What's the first instruction address, and how is it set?
• Are clock domain crossings listed and synchronized? Clocks and Resets in a System covers these.

In simulation, unknown values can hide reset bugs, because some tools turn unknown values into known ones. Run a test with random initial values for all uninitialized state.

Power

• Which clocks are gated, and is the design tested with gating on?
• What power states exist, and what state is lost in each?
• What wakes the core, and how long does it take?
• Are wide structures idle when they aren't in use?
• Are power estimates based on realistic activity, rather than a guess?

Debug and Observability

• Can a debugger halt the core, read registers and set breakpoints?
• Are there enough performance counters for the events needed to analyze silicon?
• Can a hung core be diagnosed, and is there visibility into its queues?
• Is there an instruction trace?
• If something fails after tape-out, what could be changed by software, and is there any way to turn a feature off?

That last point is often worth a small amount of logic. A bit in a CSR that disables a new prefetcher or predictor can turn a fatal bug into a small loss of performance. Such chicken bits have saved many chips.

Verification

• Does each requirement in the spec link to a test or an assertion?
• Is there a reference model and a commit-trace comparison?
• Do tests randomize memory latency and interrupts?
• Are functional coverage goals agreed, and on track?
• Which logic is suited to formal proof?
• Has a real operating system been booted, on an emulator or an FPGA?
• Are performance regressions run?

Verifying a CPU explains these methods.

Security

• Can user code reach any privileged state or any secret?
• Do predictors and caches leak information across privilege or process boundaries?
• Can speculative accesses reach protected memory?
• Are CSR fields safe against unusual values?
• Is debug access locked down in production?

Software and Toolchain

• Is the compiler's scheduling model updated for this pipeline?
• Are instruction latencies and restrictions documented?
• Does the ISA string in the build match what the hardware provides?
• Are optional extensions reported correctly in misa?
• Is there a plan to handle errata in software?

After the Review

A review only helps if its results are acted on. Write down each action with an owner and a date, and track them to closure. Record decisions and the reasons for them, so that the same discussion doesn't happen again. Then update the checklist itself: if the review found a new kind of problem, add it. After tape-out and bring-up, compare what happened with what the reviews said, and feed the lessons into the next project.

Common Mistakes