Built-in Reset and Bit-Bash Sequences

Why run these first

Before custom scenarios, run the built-in reset and bit-bash sequences. They quickly expose reset mismatches, address-map defects, access-policy mistakes, and adapter translation errors.

[RAL] bring-up sequence priority

  1) uvm_reg_hw_reset_seq
      - verifies model reset values against DUT reset state

  2) uvm_reg_bit_bash_seq
      - toggles accessible bits and checks readback behavior

  then:
    custom register or feature sequences

• These sequences are standardized and simulator-portable.

• Failures usually map to model spec mismatch or adapter wiring issues.

• Running them nightly prevents drift after map/model updates.

uvm_reg_hw_reset_seq in practice

uvm_reg_hw_reset_seq reads registers after reset and compares with model reset metadata. It should be one of the first regressions in any new block environment.

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

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

    phase.raise_objection(this);
    apply_dut_reset();

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

    phase.drop_objection(this);
  endtask
endclass

[UVM] reset-seq troubleshooting map

  reset mismatch on many registers:
    -> likely wrong reset release timing or stale model reset metadata

  mismatch on one field:
    -> likely field reset value/access policy mismatch

  random read failures:
    -> adapter map/protocol read path issue

[BUS] [RAL] reset verification dependencies

  must have:
    - known reset pulse and stabilization delay
    - frontdoor path functioning (or explicit backdoor reset mode)
    - correct model reset definitions

• Align reset sequence timing with DUT reset propagation realities.

• Regenerate model when spec reset values change.

• Capture first-failure register/field in logs for quick triage.

uvm_reg_bit_bash_seq and policy validation

uvm_reg_bit_bash_seq exercises writable bits and confirms behavior through reads. It is excellent for catching wrong field policies (RW vs RO, W1C handling) and lane mapping defects.

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

  task run_phase(uvm_phase phase);
    uvm_reg_bit_bash_seq bb;
    bb = uvm_reg_bit_bash_seq::type_id::create("bb");

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

[RAL] bit-bash behavior intent

  for writable bits:
    write 0/1 patterns and verify expected readback

  for RO or side-effect fields:
    sequence obeys policy constraints from model metadata

  value:
    catches map/policy/adapter coupling bugs early

Recommended execution order

1. Reset DUT and run uvm_reg_hw_reset_seq.

2. Run uvm_reg_bit_bash_seq on same model/map.

3. If failures occur, inspect adapter addr/data mapping first.

4. Then inspect field access policy and reset metadata.

5. Only after clean pass, add custom programming sequences.

Key takeaways

• hw_reset_seq and bit_bash_seq are foundational RAL bring-up tests.

• They validate reset values, access policies, and translation plumbing rapidly.

• Consistent pass on these sequences dramatically lowers custom-test debug cost.

• Use them as CI guardrails whenever model or adapter changes.

Common pitfalls

• Skipping reset stabilization and blaming sequence behavior for DUT timing issues.

• Treating bit-bash failures as random when they often indicate policy mis-modeling.

• Running only custom sequences and missing baseline adapter/map defects.

• Ignoring NOT_OK statuses in logs and focusing only on data mismatch text.