Part 9 · Register Model (RAL) · Intermediate

Registers, Fields, Access Policies & Reset

Hub - field behavior contracts, configure() details, volatile and reserved modeling, reset value strategy, hw_reset_seq usage, and practical debug pitfalls.

Overview

In RAL, the field model is the behavior contract between software-visible intent and hardware side effects. A register class is only a container; correctness lives in field metadata: access policy, volatility, reset, and layout.

When field metadata is accurate, register sequences produce legal accesses and mirror/predict stays aligned. When metadata is wrong, bring-up time is burned on false mismatches, missing checks, and confusing reset failures.

Lessons in this topic

  1. Access Policy Catalog - RW/RO/WO/W1C/RC/W1S behavior table and side effects.

  2. Field configure() Walkthrough - all uvm_reg_field::configure parameters in context.

  3. Volatile and Reserved Fields - modeling counters, sticky status, and reserved bits safely.

  4. Reset Values Modeling - configure reset semantics, per-field reset kinds, and checks.

  5. uvm_reg_hw_reset_seq Deep Dive - sequence flow, setup, exclusions, and debug.

  6. Field Modeling Pitfalls - common mistakes and a practical failure triage playbook.

Field-centric RAL map

diagram
Legend: [UVM] [RAL] [REG] [FIELD] [BUS] [DUT]

[TEST] sequence intent
   │
   │  ral.ctrl.enable.set(1); ral.ctrl.update(status)
   ▼
[RAL][FIELD] metadata drives operation legality
   ├─ access policy (RW/RO/W1C/...)
   ├─ volatility (mirror trust level)
   ├─ reset value/kind (HARD/SOFT)
   └─ bit position and width
   ▼
[RAL][REG] assemble field operations into register transaction
   ▼
[BUS] frontdoor via map/adapter OR [DUT] backdoor via HDL path
   ▼
[UVM] predictor/mirror update according to field policy
diagram
[RAL] field modeling stack

  Spec text
    "bit[5] irq_status is W1C reset=1"
       │
       ▼
  uvm_reg_field::configure(...)
       │
       ├─ policy      = "W1C"
       ├─ reset       = 1
       ├─ has_reset   = 1
       ├─ is_volatile = 0/1
       └─ lsb/size    = bit mapping
       ▼
  Register methods: read/write/update/mirror/check
       ▼
  Runtime behavior in sequences + predictor

Key takeaways

  • Field metadata is the real source of RAL behavior correctness.

  • Access, volatility, and reset rules must reflect the specification exactly.

  • Most mirror and reset issues trace back to field-level modeling mistakes.

  • Treat each field definition as executable spec, not boilerplate.

Common pitfalls

  • Focusing on register class structure while under-modeling field semantics.

  • Using RW everywhere 'for convenience' and losing side-effect accuracy.

  • Ignoring volatile and reset-kind differences until late integration.

  • No field review checklist against spec text and bit map.