DenseChip

Part 9 · Register Model (RAL) · Intermediate

Access Sequence Cross-Check

Use uvm_reg_access_seq to compare frontdoor and backdoor behavior and expose mapping, path, and policy mismatches.

Why uvm_reg_access_seq matters

The built-in uvm_reg_access_seq is a high-value consistency test: it checks whether frontdoor and backdoor observe the same architectural register behavior.

diagram
[RAL] access_seq value proposition

  detects:
    - adapter address/data mistakes
    - wrong hdl path slices
    - access policy modeling errors
    - stale mirror assumptions

  gives:
    - systematic by-register cross-path evidence

  • Run access_seq early after model and adapter integration.

  • Re-run after RTL hierarchy or map changes.

  • Use failures as localization hints, not just pass/fail badges.

Minimal setup

systemverilog
class reg_access_test extends uvm_test;
  `uvm_component_utils(reg_access_test)
  reg_env env;

  task run_phase(uvm_phase phase);
    uvm_reg_access_seq seq;

    phase.raise_objection(this);

    seq = uvm_reg_access_seq::type_id::create("seq");
    seq.model = env.reg_model;
    seq.start(null);

    phase.drop_objection(this);
  endtask
endclass
diagram
[UVM] prerequisites before starting sequence

  reg_model built and locked
  map sequencer + adapter connected
  predictor policy defined
  backdoor HDL paths registered
  reset state established

  • Null sequencer start is normal for register built-in sequences.

  • Sequence uses model map information to execute accesses.

  • Predictor and mirror policy should be intentional before interpreting mismatches.

Walkthrough of sequence behavior

diagram
[RAL][BUS][HDL] conceptual uvm_reg_access_seq loop

  for each register in model:
    1) frontdoor write test value
    2) backdoor read and compare
    3) backdoor write test value
    4) frontdoor read and compare
    5) evaluate status and access policy exceptions

  report mismatches with register and field context
diagram
[TEST] one-register timeline

  REG: ctrl @ 0x0000_0040

  Step A: frontdoor write 0xA5A5_5A5A
  Step B: backdoor read  -> expected 0xA5A5_5A5A
  Step C: backdoor write 0x5A5A_A5A5
  Step D: frontdoor read  -> expected 0x5A5A_A5A5
  Step E: status + policy checks
systemverilog
class my_access_seq extends uvm_reg_access_seq;
  `uvm_object_utils(my_access_seq)

  // Example extension hook for logging
  virtual task body();
    `uvm_info("ACCESS_SEQ", "Starting access cross-check", UVM_LOW)
    super.body();
    `uvm_info("ACCESS_SEQ", "Completed access cross-check", UVM_LOW)
  endtask
endclass

Triaging failures

diagram
[RAL] failure triage matrix

  Symptom: FD write ok, BD read wrong
    likely causes:
      - wrong add_hdl_path_slice
      - DUT side-effect not modeled
      - stale read due to clock/update timing

  Symptom: BD write ok, FD read wrong
    likely causes:
      - adapter bus2reg/reg2bus mismatch
      - map address offset wrong
      - DUT decode issue

  Symptom: mismatch only on specific fields
    likely causes:
      - access policy mismatch (W1C/RC/volatile)
      - field bit position mismatch in model
systemverilog
function void report_access_failure(string reg_name, uvm_reg_data_t exp, uvm_reg_data_t got);
  `uvm_error(
    "ACCESS_XCHK",
    $sformatf("reg=%s exp=0x%08h got=0x%08h", reg_name, exp, got)
  )
endfunction

  • Always inspect both adapter and HDL path when mismatch appears.

  • Policy-driven fields may need exclusions or customized expectations.

  • Correlate sequence logs with waveforms for stubborn mismatches.

Scoping and exclusions

Some registers are intentionally unsuitable for generic access_seq checks, such as clear-on-read status windows or live hardware counters.

diagram
[REG] common exclusion candidates

  volatile counters changing every cycle
  write-only trigger registers
  debug windows with side effects on read
  security registers requiring handshake unlock
  external-status mirrors updated asynchronously
systemverilog
class access_cfg;
  bit skip_volatile = 1;
  bit skip_trigger  = 1;
endclass

// Keep exclusion rationale documented in source control and review notes.

Key takeaways

  • uvm_reg_access_seq is the best generic cross-path integrity check.

  • Treat its failures as structured localization clues for model, adapter, or RTL issues.

  • Use exclusions sparingly and document every exclusion with reason.

Common pitfalls

  • Skipping access_seq because initial runs fail noisily.

  • Blanket-excluding too many registers and losing test value.

  • Assuming every mismatch is an RTL bug without auditing RAL metadata first.

Practice this lessonQuestions tagged for this topic in the bank