Built-in Access and Memory Sequences

Access consistency and why it matters

uvm_reg_access_seq validates that frontdoor and backdoor paths agree. This sequence is high-value because it catches defects that either path alone may hide.

Typical issues uncovered include wrong HDL paths, stale backdoor hierarchy, incorrect adapter mapping, and predictor drift that masks frontdoor errors.

[UVM] [RAL] access consistency intent

  frontdoor write/read
      compared with
  backdoor read/write

  expected:
    same logical register value after legal operations

  detects:
    path asymmetry bugs and map/hierarchy mismatches

• Run on representative register subsets first, then full model.

• Ensure both frontdoor and backdoor paths are fully configured.

• Use deterministic seeds for reproducible triage when failures occur.

Running uvm_reg_access_seq

The sequence compares behavior across access paths. It is often the first sequence to expose hidden HDL path drift after RTL hierarchy refactors.

class ral_access_test extends uvm_test;
  `uvm_component_utils(ral_access_test)
  reg_env env;

  task run_phase(uvm_phase phase);
    uvm_reg_access_seq seq;
    seq = uvm_reg_access_seq::type_id::create("seq");

    phase.raise_objection(this);
    seq.model = env.rm;
    seq.start(null);
    phase.drop_objection(this);
  endtask
endclass

[RAL] access_seq failure hints

  frontdoor pass + backdoor fail:
    likely HDL path issue

  frontdoor fail + backdoor pass:
    likely adapter/driver/map issue

  both fail:
    model reset/policy/address-map likely stale

[BUS] [RAL] [UVM] path cross-check view

  [RAL] op
    |     |  __ backdoor -> HDL path
    |
    ____ frontdoor -> adapter -> bus agent -> DUT

  access_seq compares outcomes from both branches

• If many backdoor failures appear suddenly, audit HDL path generation artifacts.

• If only one address range fails, verify map offset and sub-map base addresses.

• Capture first failing register path and both observed values in logs.

Memory walk/access sequences

For memory regions, run memory-oriented sequences to validate addressing stride, data integrity, and access-mode compliance.

class ral_mem_test extends uvm_test;
  `uvm_component_utils(ral_mem_test)
  reg_env env;

  task run_phase(uvm_phase phase);
    uvm_mem_walk_seq   walk_seq;
    uvm_mem_access_seq acc_seq;

    walk_seq = uvm_mem_walk_seq  ::type_id::create("walk_seq");
    acc_seq  = uvm_mem_access_seq::type_id::create("acc_seq");

    phase.raise_objection(this);

    walk_seq.model = env.rm;
    walk_seq.start(null);

    acc_seq.model = env.rm;
    acc_seq.start(null);

    phase.drop_objection(this);
  endtask
endclass

[BUS] memory-seq checks

  uvm_mem_walk_seq:
    verifies address progression and storage consistency

  uvm_mem_access_seq:
    validates memory read/write accesses through configured paths

  catches:
    bank addressing bugs, stride errors, lane/endianness defects

Practical memory triage checklist

1. Confirm memory declaration size in model matches RTL implementation.

2. Check map base and stride for each memory region.

3. Validate adapter handling of burst/beat semantics if protocol supports it.

4. Compare one failing index via frontdoor and backdoor manually.

5. Inspect byte-enable handling for partial memory writes.

Key takeaways

• uvm_reg_access_seq validates frontdoor/backdoor consistency for registers.

• Memory sequences validate addressing, storage behavior, and path correctness.

• Path asymmetry findings quickly localize adapter-vs-HDL issues.

• These sequences are efficient regression guardrails for map and hierarchy changes.

Common pitfalls

• Running access_seq without valid backdoor paths and misreading expected failures.

• Assuming memory failures are always DUT bugs before checking map stride.

• Skipping manual single-address reproduction for first failure.

• Ignoring byte-enable semantics in memory tests on wide buses.