UVM RAL · Chapter 7 · RAL Sequences

Built-in RAL Sequences (reset, access, walking)

For a large class of register verification you do not have to write anything, because UVM ships a library of ready-made register sequences that walk your entire model and check it in a few lines. The core members are the hardware-reset sequence, which checks every register against its modelled reset value, bit-bash, which exercises every accessible bit, the access sequence, which writes each register and reads it back both frontdoor and backdoor to catch addressing errors, the shared-access sequence for aliased registers, and the memory walk. Two practical facts frame the chapter. There is a sensible order to run them in, and you must exclude registers that are not memory-like so the sequences do not false-fail. This lesson catalogs the library and its run order, then breaks the access sequence run without HDL paths, where its cross-check silently never happens and it passes having verified nothing.

Foundation12 min readUVM RALBuilt-in Sequenceshw_resetaccesswalkingNO_REG_TESTS

Chapter 7 · Section 7.2 · RAL Sequences

1. Why Should I Learn This?

The built-in sequences give you most of your register verification for almost free — reset values, bit reachability and access, frontdoor-versus-backdoor addressing, alias coherence — so knowing the library, its order, and its exclusions is the highest-leverage register-testing skill there is. Not knowing it means hand-writing tests that the library already provides, more slowly and less thoroughly. And knowing their assumptions — that they treat registers as memory-like — is what keeps them from false-failing or corrupting state on the registers that are not.

Learning the built-in sequences as a stimulus library, run in the right order with the right exclusions, is what lets you stand up thorough register verification quickly and read its results correctly. It builds directly on the register sequence of 7.1 (these are register sequences) and leads into the dedicated bit-bash deep-dive (7.3).

2. Industry Story — the access sequence that checked nothing

A team adds the built-in uvm_reg_access_seq to verify addressing — its job is to write each register and read it back both frontdoor and backdoor, comparing the two, which catches wrong offsets, adapter bugs, and byte-lane errors that a frontdoor-only test misses. They run it, it passes, and they check the box: 'addressing verified.'

But HDL paths were never configured on the model (2.5, 4.7). The access sequence's whole value is the frontdoor-versus-backdoor comparison, and the backdoor half needs a working hdl_path to read the RTL. With no HDL paths, the backdoor read cannot run, so the sequence's cross-check silently does not happen — it degrades to (at best) a frontdoor-only pass, or skips comparisons entirely, and reports success. So 'addressing verified' is false: the one thing the access sequence exists to do — cross-check the two paths — never ran, and a wrong offset that a frontdoor-versus-backdoor comparison would have caught sails through. Months later a byte-lane bug that the access sequence should have caught escapes. The post-mortem: the access sequence's value is the frontdoor-versus-backdoor comparison, which requires HDL paths; run without them, the backdoor half cannot run and the cross-check silently never happens, so the sequence passes having verified nothing. The lesson generalizes: a built-in sequence that passes is only meaningful if the thing it checks actually ran.

3. Concept — the library, the order, and the exclusions

The built-in register-sequence library (each is a uvm_reg_sequence you give the model and start):

uvm_reg_hw_reset_seq — reset the DUT, read every register, compare against the modelled reset (1.3). Cheapest, earliest, highest-yield; run it first.
uvm_reg_bit_bash_seq — write and read back every accessible bit of every register per its access policy; catches stuck bits, wrong access, and (via read-your-own-value) overlaps and unreachable registers (7.3).
uvm_reg_access_seq — write each register and read it back frontdoor and backdoor, comparing; catches addressing, byte-lane, and HDL-path errors. Requires HDL paths for the backdoor half.
uvm_reg_shared_access_seq — exercise aliased/multi-map registers for coherence (3.4).
uvm_mem_walk_seq — walk memories across their address range.

The order: run hw_reset first (it needs a clean reset and catches power-on bugs before any writing sequence disturbs state), then the writing sequences (bit_bash, access), then shared/memory. And the exclusions: these sequences assume plain, memory-like RW behaviour, so exclude registers that are not — side-effecting (RC, FIFO), volatile status, write-only (WO), interrupt (W1C/W1S) — with NO_REG_TESTS and the finer per-sequence attributes (3.5), or they false-fail and corrupt state. Here is the recommended run flow:

Figure 1 — running the built-in register-sequence suite. First mark non-RW registers to skip (NO_REG_TESTS: side-effecting, volatile, write-only, interrupt — 3.5). Then run in order: hw_reset first (cheapest, catches power-on bugs before writing sequences disturb state), then bit_bash (every bit + reachability), then access (frontdoor vs backdoor — REQUIRES HDL paths), then shared/mem. Each sequence is a uvm_reg_sequence: set its model and start it. Read a failure critically — a sequence only verifies what actually ran.

4. Mental Model — a ready-made test suite that only proves what it actually ran

Mental Model — the built-in sequences are a free suite, but a pass means only what ran

The built-in sequences are the register equivalent of a standard test suite you get for free — but like any test, a green result means something only if the test actually exercised what it claims.

Think of the library as a pre-written regression suite for your register map: reset-value checks, bit-writability checks, addressing checks, alias-coherence checks — all walking every register, all for a few lines of setup. Running them is enormous leverage. But a built-in sequence passing is only meaningful if the thing it checks actually ran, and two things can quietly stop that: a dependency it needs is missing (the access sequence's frontdoor-versus-backdoor comparison needs HDL paths; without them the backdoor half cannot run and the cross-check silently does not happen), or the registers it ran on were the wrong ones for it (a memory-like sequence on a W1C register false-fails, 3.5). So the discipline with the built-in suite is not just 'run it and read green,' but 'confirm the check it claims actually executed': that HDL paths exist for the access sequence's backdoor, that non-RW registers are excluded so failures are real, that the reset sequence ran on a truly reset DUT. A free suite that reports success on checks that never executed is worse than no suite, because it certifies the thing it did not verify.

Two habits:

Run in order, with exclusions. Reset first, then writing sequences; exclude non-RW registers so failures are real (3.5).
Confirm the check actually ran. The access sequence needs HDL paths for its cross-check; a pass without them verifies nothing.

5. Working Example — running the suite with exclusions and HDL paths

Set up the model (exclusions and HDL paths), then run the built-in sequences in order:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// In build(): exclude non-RW registers so the memory-like sequences do not false-fail (3.5),
// and configure HDL paths so the access sequence's BACKDOOR half can run (2.5, 4.7).
uvm_resource_db#(bit)::set({"REG::", int_status.get_full_name()}, "NO_REG_TESTS", 1, this);
status.add_hdl_path_slice("status_q", 0, 32);   // ... HDL paths for every register ...
reg_model.default_map.set_hdl_path_root("tb.dut");

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// In a test's run_phase: run the built-in suite, in order, each given the model.
uvm_reg_hw_reset_seq  rst  = uvm_reg_hw_reset_seq::type_id::create("rst");
uvm_reg_bit_bash_seq  bash = uvm_reg_bit_bash_seq::type_id::create("bash");
uvm_reg_access_seq    acc  = uvm_reg_access_seq::type_id::create("acc");
 
rst.model  = reg_model;  rst.start(bus_sqr);   // 1. reset values (first)
bash.model = reg_model;  bash.start(bus_sqr);  // 2. every bit + reachability
acc.model  = reg_model;  acc.start(bus_sqr);   // 3. frontdoor vs backdoor (uses HDL paths)
// The access sequence's cross-check runs because HDL paths are configured — the next section
// is what happens when they are not.

Each built-in sequence is a uvm_reg_sequence given the model and started (7.1). With exclusions set (so failures are real) and HDL paths configured (so the access sequence's backdoor half runs), the suite thoroughly and honestly verifies the register map. Omit the HDL paths, and the access sequence's cross-check vanishes.

6. Debugging Session — the access sequence with no HDL paths

Running the access sequence without HDL paths means its frontdoor-versus-backdoor cross-check cannot run, so it passes having verified nothing

ACCESS SEQ NEEDS HDL PATHS

Buggy Code

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// HDL paths are never configured on the model, but the access sequence is run to 'verify addressing':
// (missing) reg_model.default_map.set_hdl_path_root("tb.dut"); + add_hdl_path per register
uvm_reg_access_seq acc = uvm_reg_access_seq::type_id::create("acc");
acc.model = reg_model;
acc.start(bus_sqr);   // BUG: the backdoor half needs hdl_path; with none, the cross-check can't run
// The sequence reports success -> 'addressing verified' -> but the frontdoor-vs-backdoor
// comparison, the whole point, NEVER HAPPENED.

Symptom

The access sequence passes, and the team records 'addressing verified' — but a wrong offset or byte-lane bug that a frontdoor-versus-backdoor comparison would have caught is not caught, and escapes to later testing or silicon. Nothing in the run flags a problem, because the sequence completes and reports success; the failure is silent under-verification. The tell, visible only if you look, is that the backdoor accesses never ran (no HDL-path activity, or the sequence's internal comparison count is zero) — the sequence went through the motions frontdoor-only or skipped its comparisons, and reported the green of a test that did not test.

Root Cause

The access sequence's entire value is the frontdoor-versus-backdoor comparison — it writes each register and reads it back both ways to catch addressing, byte-lane, and path errors that a single path cannot. The backdoor read requires a working hdl_path to reach the RTL storage (4.7). With no HDL paths configured, the backdoor half cannot run, so the comparison — the thing the sequence exists to perform — silently does not happen, and the sequence degrades to a frontdoor-only pass (or skips comparisons) and reports success. The model, the map, and the sequence are all otherwise fine; the missing dependency (HDL paths) removed the sequence's actual verification while leaving it reporting green.

Fix

Configure HDL paths on the model (a root plus a path/slice per register, 2.5/4.7) before running the access sequence, so its backdoor half runs and the frontdoor-versus-backdoor comparison actually executes; verify the paths with uvm_reg_mem_hdl_paths_seq first (4.7). The rule the bug teaches: the access sequence's value is the frontdoor-versus-backdoor cross-check, which requires HDL paths; run without them, the backdoor half cannot run and the cross-check silently never happens, so a pass verifies nothing. More generally, a built-in sequence passing is meaningful only if the check it claims actually ran — confirm the dependencies (HDL paths for backdoor cross-checks, exclusions for real failures) are in place, or the free suite certifies what it never verified.

7. Common Mistakes

Running the access sequence without HDL paths. Its frontdoor-versus-backdoor cross-check cannot run; it passes having verified nothing.
Running the suite without exclusions. Memory-like sequences false-fail and corrupt state on non-RW registers (3.5).
Wrong order. Run hw_reset first (before writing sequences disturb state); it is the cheapest, highest-yield check.
Trusting a pass without confirming the check ran. A green built-in sequence means something only if its check actually executed.
Hand-writing tests the library already provides. Reset, bit-bash, access, and alias checks are ready-made — run them.

8. Industry Best Practices

Run the built-in suite as standard register bring-up. hw_reset, bit_bash, access, shared_access, mem_walk, in order.
Configure HDL paths before the access sequence. And verify them with uvm_reg_mem_hdl_paths_seq (4.7), so the backdoor cross-check runs.
Exclude non-RW registers. NO_REG_TESTS and finer attributes for side-effecting, volatile, write-only, and interrupt registers (3.5).
Run hw_reset first on a truly reset DUT. Cheapest and highest-yield; catches power-on bugs before writing sequences.
Confirm each sequence's check executed. A pass is meaningful only if the thing it verifies actually ran.

9. Interview / Review Questions

10. Key Takeaways

UVM ships a library of ready-made register sequences — hw_reset (reset values), bit_bash (every bit + reachability), access (frontdoor vs backdoor), shared_access (aliases/multi-map), mem_walk (memories) — each a uvm_reg_sequence you give the model and start.
Run in order: hw_reset first (cheapest, on a pristine DUT), then the writing sequences, then shared/memory — and exclude non-RW registers (NO_REG_TESTS) so failures are real (3.5).
The access sequence requires HDL paths for its backdoor half; its value is the frontdoor-versus-backdoor cross-check.
The signature bug is running the access sequence without HDL paths: the cross-check silently cannot run, so it passes having verified nothing — silent under-verification.
A built-in sequence's pass is meaningful only if its check actually ran — confirm dependencies (HDL paths) and exclusions; a free suite that certifies un-run checks is worse than no suite.