Reset Values Modeling at Field Granularity

Reset modeling principles

Field reset modeling answers one question: what value should software observe after a specific reset kind, before any software writes? Accurate answers require per-field reset semantics, not one blanket register constant.

In many designs, hard reset and soft reset differ. Some fields retain state across soft reset; others clear. RAL supports this, but only if the model encodes reset kinds explicitly.

[RAL][FIELD] reset dimensions

  Dimension 1: value (what bits should be)
  Dimension 2: reset kind (HARD, SOFT, custom)
  Dimension 3: existence (has_reset yes/no)

  Correct modeling needs all three, per field.

[TEST] reset validation flow

  apply reset in DUT
    ▼
  run register/field reads via selected path
    ▼
  compare against modeled reset(kind)
    ▼
  triage mismatch:
      model issue? map/adapter issue? DUT issue?

• Reset is field-level behavior that can vary within one register.

• Support multiple reset kinds when architecture defines them.

• Use has_reset=0 only for truly undefined reset states.

configure reset and has_reset in practice

The configure call seeds primary reset metadata. This is usually enough for single-reset designs, but multi-reset designs should add explicit per-kind reset values afterward.

cfg_en.configure(this, 1, 0, "RW", 0, 1'b0, 1, 1, 1);
irq_st.configure(this, 1, 1, "W1C", 0, 1'b1, 1, 0, 1);
dbg_nonce.configure(this, 8, 8, "RO", 0, 8'h00, 0, 0, 0); // no deterministic reset

[FIELD] reset intent examples

  cfg_en    has_reset=1 reset=0  -> deterministic control default
  irq_st    has_reset=1 reset=1  -> pending after reset by design
  dbg_nonce has_reset=0          -> unspecified at reset, skip strict checks

• Reset=1 is valid for sticky status bits if spec says so.

• Do not force arbitrary reset values for undefined fields.

• Review reset metadata with RTL reset table, not only software header files.

Per-kind reset with set_reset/get_reset

For designs with HARD and SOFT reset differences, use field APIs to store reset value by kind. This lets tests choose expected value based on reset sequence executed.

class ctrl_reg extends uvm_reg;
  uvm_reg_field mode;
  uvm_reg_field sticky_err;

  virtual function void build();
    mode = uvm_reg_field::type_id::create("mode");
    mode.configure(this, 2, 0, "RW", 0, 2'b00, 1, 1, 1);

    sticky_err = uvm_reg_field::type_id::create("sticky_err");
    sticky_err.configure(this, 1, 2, "W1C", 0, 1'b0, 1, 0, 1);

    // Custom reset semantics
    mode.set_reset(2'b00, "HARD");
    mode.set_reset(2'b01, "SOFT");        // mode retained/biased after soft reset

    sticky_err.set_reset(1'b0, "HARD");
    sticky_err.set_reset(1'b0, "SOFT");
  endfunction
endclass

function void log_soft_reset_expectations(ctrl_reg rg);
  `uvm_info("RESET",
    $sformatf("mode soft reset = %0h, sticky_err soft reset = %0h",
              rg.mode.get_reset("SOFT"),
              rg.sticky_err.get_reset("SOFT")),
    UVM_LOW)
endfunction

[RAL] reset-kind map

  Field       HARD    SOFT
  ─────────────────────────
  mode        00      01
  sticky_err  0       0

  A single reset constant cannot represent this design.

• Use the same reset-kind strings consistently across model and sequences.

• Document any intentional soft-reset retention behavior explicitly.

• Per-kind resets make reset regressions far more diagnostic.

Field-level reset check sequence pattern

When debugging reset failures, field-level checks isolate root cause faster than register-wide hex comparisons.

task check_field_resets(my_reg_block ral, string kind = "HARD");
  uvm_status_e status;
  uvm_reg_data_t rd;
  uvm_reg_field fields[$];
  uvm_reg regs[$];

  ral.get_registers(regs);
  foreach (regs[i]) begin
    regs[i].read(status, rd, UVM_FRONTDOOR, .parent(this));
    regs[i].get_fields(fields);

    foreach (fields[j]) begin
      if (!fields[j].has_reset(kind))
        continue;

      uvm_reg_data_t exp = fields[j].get_reset(kind);
      uvm_reg_data_t got = fields[j].get_mirrored_value();
      if (got !== exp)
        `uvm_error(
          "RST_FIELD",
          $sformatf("%s.%s kind=%s exp=0x%0h got=0x%0h",
                    regs[i].get_name(), fields[j].get_name(), kind, exp, got)
        );
    end
  end
endtask

[TEST] field-level reset debug

  register mismatch?
    ├─ inspect each field expected reset(kind)
    ├─ compare to mirrored/read value
    ├─ narrow to bit-range quickly
    └─ map directly back to spec row

• Field-level logs map better to spec tables than full-register mismatch lines.

• Skip fields without defined reset to avoid false failures.

• Prefer explicit reset-kind argument in reusable reset checks.

Reset modeling integration checklist

Before signing off a block-level RAL model, verify reset assumptions with this compact checklist.

1. Every field has reviewed reset value and has_reset decision.

2. Soft/hard reset differences are encoded with set_reset when needed.

3. Undefined-reset fields are documented and excluded from strict checks.

4. Reset sequences and model use identical reset-kind naming.

5. At least one directed test checks side-effect fields after reset.

[RAL][RESET] common mismatch classes

  Class A: model reset wrong, DUT correct
  Class B: DUT reset wrong, model correct
  Class C: wrong reset kind checked
  Class D: undefined-reset field incorrectly checked
  Class E: map/path issue reads wrong address

Key takeaways

• Reset values should be modeled per field, not inferred per register.

• Use set_reset/get_reset for designs with multiple reset kinds.

• Field-level reset checks accelerate triage and reduce false negatives.

• Explicit has_reset decisions are key to trustworthy reset regressions.

Common pitfalls

• Assuming hard and soft reset are identical without spec confirmation.

• Checking undefined-reset fields as if they were deterministic.

• Keeping reset kind implicit in tests and mixing expectations.

• Debugging reset only at full-register granularity.