Bus Adapters & Built-in Register Sequences

Why this topic matters in bring-up

The register model API is protocol-neutral, but the DUT bus is not. The adapter is the bridge between those worlds. If this bridge is wrong, every register sequence appears flaky: reads come back wrong, mirrors drift, and scoreboards report false mismatches.

This topic covers the full translation loop from reg2bus to bus2reg, then layers built-in sequences you should run before writing custom register tests.

Lessons in this topic

1. reg_adapter reg2bus - frontdoor translation with full APB example.

2. reg_adapter bus2reg - prediction path from monitor transactions.

3. Adapter configuration - supports_byte_enable and provides_responses.

4. Built-in reset and bit-bash - uvm_reg_hw_reset_seq, uvm_reg_bit_bash_seq.

5. Built-in access and memory sequences - uvm_reg_access_seq, memory walk/access.

6. Adapter debug patterns - wrong addr/data mapping, cast failures, triage flow.

[UVM] [RAL] [BUS] end-to-end adapter context

  test or virtual sequence
      |
      v
  [RAL] reg.write/read/mirror/update
      |
      v
  uvm_reg_map + uvm_reg_adapter
      |
      +--> reg2bus()    [RAL] op -> [BUS] item
      |
      v
  sequencer -> driver -> DUT bus
      |
      v
  monitor -> predictor -> bus2reg() -> mirror

[BUS] [RAL] ownership boundaries

  RAL owns:
    - abstract operation intent (kind/addr/data/status)
    - register policy checks and mirror semantics

  Adapter owns:
    - protocol item creation/parsing
    - field mapping (addr/data/be/read/write)
    - status propagation and cast safety

  BUS agent owns:
    - timing and signal-level handshake
    - protocol legality and error signaling

Key takeaways

• The adapter is the critical protocol bridge for frontdoor RAL access.

• reg2bus drives traffic generation; bus2reg drives mirror prediction.

• Built-in sequences provide fast, high-value confidence during bring-up.

• Debug starts by validating translation and response wiring, not random stimulus.

Common pitfalls

• Assuming RAL API failures are sequence bugs when adapter mapping is wrong.

• Ignoring monitor->predictor->bus2reg path and relying only on write-side updates.

• Skipping built-in sequences and jumping straight to custom tests.

• Treating adapter status handling as optional; it is required for reliable triage.