Architecture Review Checklist

Chapter 15 · Section 15.4 · Interview & Review Preparation · Curriculum Finale

1. Why Review, Not Just Debug

Debugging finds a failure after it has cost you; a review prevents whole categories of failure before they do. Every bug the track dissected — a hardware-updated register not marked volatile, an unconnected predictor, a swallowed-error adapter, overlapping base ranges, an edited generated file, inflated coverage — has a review question that would have caught it at design time, cheaply, as one clear finding instead of a scattered late hunt. A review is where the track's lessons become preventive: you walk a defined set of dimensions, ask the checkable questions each contains, and surface the categories before they become bugs. It is also how you evaluate any register environment — your own, a colleague's, or one you inherit.

2. The Seven Review Dimensions

3. The Checklist, by Dimension

# RAL ARCHITECTURE REVIEW CHECKLIST — walk every dimension; each item is a category-preventing question.
 
# 1. SOURCE & GENERATION (13.1/13.3/13.6)
#  [ ] Is there exactly ONE source of truth (IP-XACT/RALF/spreadsheet/YAML)? (no dual sources that drift)
#  [ ] Is the model GENERATED, and are generated files NEVER hand-edited? (fix the spec, regenerate)
#  [ ] Are docs/headers GENERATED from the same source (not maintained as second sources)?
 
# 2. MODEL FIDELITY (1.x/11.1/14.x)
#  [ ] Correct ACCESS POLICY per field (RW/RO/WO/W1C/W1S/RC)?
#  [ ] VOLATILE on every hardware-updated/owned field (status, count, input, pending bits)?
#  [ ] Correct RESET values (checked with hw_reset), and RESERVED bits handled?
#  [ ] SHARED-STATE registers (interrupt SET/CLEAR/STATUS, aliases) modelled as ONE state, not independent?
 
# 3. STRUCTURE (3.x/12.x)
#  [ ] Hierarchical composition sound; sub-block base RANGES non-overlapping (base..base+size)?
#  [ ] Replicated instances are DISTINCT objects with per-instance BASE + per-instance hdl_path ROOT?
#  [ ] Register ARRAYS create a FRESH instance per element (no aliased handles)?
#  [ ] Configurable structure built from the SAME config as the DUT (dynamic model), with a config-match gate?
 
# 4. INTEGRATION (13.4/12.7/11.3)
#  [ ] Model BUILT + LOCKED before use?
#  [ ] ONE shared model created once and distributed via config_db (components GET it, never re-create)?
#  [ ] Map connected to the agent's sequencer via the ADAPTER; adapter maps bus response to STATUS?
#  [ ] Predictor CONNECTED to the monitor; exactly ONE prediction mode (auto XOR explicit)?
#  [ ] Multi-bus: per-bus maps+adapters over one model; accesses SPECIFY the map?
 
# 5. ACCESS & PERFORMANCE (7.5/13.5/9.x)
#  [ ] Stimulus DRIVES THE MODEL (register/field handles), not hardcoded addresses?
#  [ ] Frontdoor to VERIFY the bus; BACKDOOR for bulk SETUP (not frontdoor-seeding large state)?
#  [ ] Callbacks in the RIGHT hook (post_predict for value-tracking) and RIGHT timing (pre for outgoing)?
#  [ ] Redundant reads use the MIRROR (get_mirrored_value); contiguous memory uses BURST?
 
# 6. VERIFICATION COMPLETENESS (11.6/10.x)
#  [ ] BRING-UP GATES pass (locked, hdl_paths proven, predictor, adapter status via forced error, resets, coverage)?
#  [ ] Coverage ENABLED (both gates), HONESTLY attributed (functional stimulus), and CLOSED (real holes tested)?
#  [ ] Coverage PAIRED with CHECKS (a value exercised AND its behaviour verified)?
#  [ ] NEGATIVE tests are REAL (can produce UVM_NOT_OK) — verified by forcing an error?
 
# 7. PROCESS (13.6/11.4)
#  [ ] Guidelines ENFORCED by review + CI (regenerate-and-fail-on-drift, lint for hardcoded addr / re-created model)?
#  [ ] HDL PATHS proven (uvm_reg_mem_hdl_paths_seq) before any backdoor reliance?
#  [ ] Each dimension REVIEWED, not just 'do the tests pass'?

4. How to Conduct a Review

• Walk the dimensions in order. Source → fidelity → structure → integration → access → verification → process — each dimension's questions catch a category, so covering all seven covers the failure space.
• Ask the checkable question, don't eyeball. 'Is IN volatile?', 'do sub-block ranges overlap?', 'does bus2reg map status?' — concrete questions, not impressions.
• Automate what you can (Process dimension). CI that regenerates-and-fails-on-drift, runs the bring-up gates, and lints for hardcoded addresses / re-created models enforces several dimensions mechanically.
• Review early and at sign-off. Early catches structural/source decisions cheaply; sign-off confirms verification completeness. A review is a gate, not a one-time event.
• Treat a finding as a category, not a one-off. A single edited generated file or one overlapping range signals a process gap — fix the class, not just the instance.

5. Common Review Mistakes

• Reviewing 'do the tests pass?' only. Passing tests miss silent bugs (swallowed status, inflated coverage) and process gaps — walk the dimensions.
• Skipping the silent dimensions. Adapter status, coverage honesty, and HDL-path resolution have no obvious symptom — ask their questions explicitly.
• Not checking for one source of truth. Dual sources drift silently — confirm generation from a single source.
• Eyeballing structure. Overlapping sub-block ranges and aliased instances need checked ranges/handles, not a glance.
• Treating the review as one-time. Architecture decisions and verification completeness are checked at different stages — review early and at sign-off.

6. Best Practices for RAL Architecture Review

• Use the seven-dimension checklist every time. A structured pass covers the failure space; ad-hoc review misses categories.
• Automate the enforceable dimensions. Generation-drift, bring-up gates, and lint checks in CI make the review partly self-running.
• Prove the silent things. Force an error (adapter status), disable-during-setup (coverage honesty), run the HDL-path check (backdoor).
• Review at design time, not just sign-off. The cheapest place to catch a structural or source-of-truth decision is before it is built on.
• Close findings at the category level. Fix the process gap a finding reveals, so the whole class cannot recur.

7. The Whole Track, in One Frame

A RAL architecture is sound when all seven dimensions hold, and — looking back — every chapter of this track was about one of them:

• Source & Generation — how production RAL is really built (Chapter 13).
• Model Fidelity — registers, fields, policies, volatile, reset, side effects, shared state (Chapters 1–2, 9, 14).
• Structure — maps, hierarchy, arrays, dynamic models, multi-instance (Chapters 3, 12).
• Integration — adapters, prediction, memories, lifecycle, config_db, multi-bus (Chapters 4–8, 13).
• Access & Performance — access methods, sequences, backdoor, performance (Chapters 4, 7, 13).
• Verification Completeness — coverage and the bring-up gates (Chapters 10, 11).
• Process — debugging methods and coding guidelines made into enforcement (Chapters 11, 13).

The through-line of all of it: a register model must faithfully reflect the hardware, keep its mirror coherent across every way a value can change, be accessed efficiently and verified completely, and be built and maintained by a disciplined, enforced process. That single sentence is the whole track — and this checklist is how you hold an architecture to it.

8. Interview / Review Questions

9. Key Takeaways

• An architecture review is proactive prevention — catching whole failure categories at design time, cheaply, as clear findings — versus debugging, which finds failures after they cost you; every bug the track dissected has a review question that prevents it.
• Review a RAL architecture as a structured pass over seven dimensions: Source & Generation, Model Fidelity, Structure, Integration, Access & Performance, Verification Completeness, and Process — each a set of checkable questions, not impressions.
• Surface the silent dimensions explicitly — adapter status (force an error), coverage honesty (disable-during-setup), and HDL-path resolution (the path check) have no obvious symptom, so they must be asked about and forced open.
• Automate the enforceable dimensions in CI (generation-drift, bring-up gates, lint), review early and at sign-off, and close findings at the category level — a single instance usually signals a process gap.
• The whole track reduces to one frame: a register model must faithfully reflect the hardware, keep its mirror coherent across every way a value can change, be accessed efficiently and verified completely, and be built and maintained by a disciplined, enforced process — and this checklist is how you hold an architecture to it. This completes the UVM RAL curriculum — from what a register model is, through modelling, maps, access, adapters, prediction, memories, callbacks, coverage, debugging, advanced structures, production generation, real peripheral case studies, and interview/review readiness — the full path from understanding RAL to building, debugging, shipping, and reviewing it.