Part 9 · Register Model (RAL) · Intermediate
When to Use Each Path
Decision framework and scenario table for selecting frontdoor, backdoor, or mixed access patterns by verification intent.
Decision principles
Choose access path by test intent, not convenience. Ask: are you proving integration behavior, or shaping/observing state rapidly?
[RAL] path decision rule
Goal = prove bus + decode + protocol side effects
-> frontdoor
Goal = fast setup, non-intrusive peek, or debug surgery
-> backdoor
Goal = both speed and signoff confidence
-> mixed flow with explicit cross-checkFrontdoor gives confidence in externally visible behavior.
Backdoor gives speed and low perturbation observability.
Mixed strategy is usually best for large regressions and feature tests.
Frontdoor vs backdoor decision table
Scenario Frontdoor Backdoor Recommended
────────────────────────────────────────────────────────────────────────────────────────────────
Block bring-up reset-value smoke Optional Strong YES Backdoor init + selective frontdoor check
Protocol/decoder signoff Strong YES No Frontdoor
Long randomized feature regression Strong YES Optional Mixed (backdoor precondition + frontdoor main)
Debugging internal sticky bit behavior Useful Strong YES Backdoor first, then frontdoor reproduce
Coverage closure for bus assertions Strong YES No Frontdoor
Mass register preload before scenario Expensive Strong YES Backdoor
Cross-validating RAL model vs RTL implementation YES YES Both with uvm_reg_access_seq
Post-silicon model parity planning YES Useful Primarily frontdoor[BUS][HDL] risk tradeoff
frontdoor-only risk:
- slower regressions for heavy state setup
backdoor-only risk:
- no bus-path confidence
- decode and side-effect bugs can escape
mixed risk (if undisciplined):
- mirror incoherence and false diagnosticsDefault to frontdoor for user-visible behavior claims.
Use backdoor where simulation cost dominates and bus confidence is unchanged.
Document intent in test names and logs to avoid ambiguity.
Scenario walkthroughs
Scenario A - preload then feature test
Preload 200 registers using backdoor, then run feature sequence frontdoor so only behaviorally important traffic consumes bus cycles.
[TEST] Scenario A flow
Phase 1 (setup):
backdoor write bulk configuration
Phase 2 (proof):
frontdoor stimulus on key control registers
Phase 3 (check):
monitor coverage + scoreboard + selective backdoor diagnosticsScenario B - protocol side-effect validation
A W1C interrupt status bit must clear on bus write semantics. This is fundamentally a frontdoor claim even if setup uses backdoor.
[TEST] Scenario B path choice
backdoor can set initial interrupt state quickly
but clear behavior must be checked with frontdoor write
so protocol side effects and decode path are provenOperational policy template
[REG] team policy template
1) Bring-up smoke:
allow backdoor-heavy tests for speed
2) Feature signoff:
require frontdoor for requirement-linked accesses
3) Nightly integrity:
run uvm_reg_access_seq weekly or nightly
4) Mixed tests:
require explicit comments:
- why backdoor is used
- what frontdoor still proves
- how mirror coherence is ensuredKey takeaways
Path choice should be requirement-driven and explicit.
Decision tables reduce accidental overuse of one path.
Mixed strategies work best when intent and mirror policy are documented.
Common pitfalls
Using backdoor everywhere because it is fast.
Using frontdoor everywhere and paying unnecessary runtime cost.
No team-level policy, leading to inconsistent evidence quality across tests.