Part 9 · Register Model (RAL) · Intermediate

Frontdoor Bus Path

End-to-end frontdoor operation from RAL API call through adapter, sequencer, driver, bus handshake, monitor, and predictor.

What frontdoor actually proves

A frontdoor register access is not just a value write. It validates a chain: model map lookup, adapter packing, sequence arbitration, driver timing, DUT decode, and response-to-mirror reconciliation.

diagram

[RAL][BUS] frontdoor validation surface

  RAL API call
    -> map offset and byte-lane handling
    -> reg2bus conversion
    -> bus sequence arbitration and ordering
    -> driver protocol timing
    -> DUT address decode and side effects
    -> monitor capture
    -> predictor mirror update

  If any stage is wrong, frontdoor checks reveal it.

Frontdoor is the path for protocol, latency, and decode confidence.
Coverage from bus monitors and assertions is meaningful only on frontdoor traffic.
Most signoff feature tests should execute critical accesses frontdoor.

Full sequencer to driver flow

This sequence diagram captures the operational path for a typical ral.ctrl.write(...) call using UVM_FRONTDOOR.

diagram

[RAL][BUS] full frontdoor bus path

  [TEST]  ral.ctrl.write(status, 32'h0000_0001, UVM_FRONTDOOR, .parent(this))
      |
      v
  [RAL]  uvm_reg::write
      |
      +--> resolve register in uvm_reg_map
      +--> form uvm_reg_bus_op (kind=WRITE, addr, data, be)
      |
      v
  [RAL]  uvm_reg_adapter::reg2bus
      |
      +--> create protocol item (apb_item/axi_item/...)
      |
      v
  [BUS]  map sequencer start_item/finish_item
      |
      +--> arbitration among active sequences
      |
      v
  [BUS]  driver gets item and drives interface
      |
      +--> address phase
      +--> data phase
      +--> response phase
      |
      v
  [DUT]  register decode and state update
      |
      v
  [BUS]  monitor samples transfer
      |
      v
  [RAL]  predictor bus2reg + predict()
      |
      v
  [RAL]  mirrored value updated, status returned

systemverilog

task body();
  uvm_status_e   status;
  uvm_reg_data_t read_data;

  // 1) Write by name through map/adapter/bus
  ral.ctrl.write(
    .status(status),
    .value(32'h0000_0001),
    .path(UVM_FRONTDOOR),
    .parent(this)
  );
  if (status != UVM_IS_OK)
    `uvm_error("FD", "frontdoor write failed")

  // 2) Read back through same bus path
  ral.ctrl.read(
    .status(status),
    .value(read_data),
    .path(UVM_FRONTDOOR),
    .parent(this)
  );
  if (status != UVM_IS_OK)
    `uvm_error("FD", "frontdoor read failed")
endtask

Adapter and map wiring checklist

Frontdoor reliability depends on clean map and adapter setup. A partial connection can look fine for writes and still fail on read response or prediction.

systemverilog

function void connect_phase(uvm_phase phase);
  super.connect_phase(phase);

  // RAL frontdoor route
  reg_model.default_map.set_sequencer(apb.sqr, apb_adapter);

  // Prefer explicit prediction in non-trivial benches
  reg_model.default_map.set_auto_predict(0);

  predictor.map     = reg_model.default_map;
  predictor.adapter = apb_adapter;
  apb.mon.ap.connect(predictor.bus_in);
endfunction

diagram

[BUS] frontdoor sanity checks

  map.set_sequencer called?                   YES/NO
  adapter reg2bus and bus2reg consistent?     YES/NO
  read response correctly routed?             YES/NO
  predictor connected to monitor AP?          YES/NO
  auto_predict policy intentional?            YES/NO
  bus monitor sees same addr/data as expected? YES/NO

Mismatch between reg2bus and bus2reg causes subtle mirror drift.
Missing predictor often appears only when mirror checks are enabled.
Read flows require careful response handling, not just request drive.

Timeline walkthrough

A cycle-level view helps debug where a frontdoor access stalls or diverges.

diagram

[BUS] cycle sketch for one frontdoor write

  t0  sequence issues ral write
  t1  reg2bus creates bus item
  t2  sequencer grants item to driver
  t3  driver asserts request/address
  t4  DUT ready accepted
  t5  write data committed in DUT reg file
  t6  monitor samples completed transfer
  t7  predictor updates mirrored value
  t8  write returns UVM_IS_OK

systemverilog

virtual function void bus2reg(uvm_sequence_item bus_item, ref uvm_reg_bus_op rw);
  apb_item item;
  if (!$cast(item, bus_item)) begin
    rw.status = UVM_NOT_OK;
    `uvm_error("ADAPTER", "bus2reg cast failed")
    return;
  end

  rw.kind   = item.write ? UVM_WRITE : UVM_READ;
  rw.addr   = item.addr;
  rw.data   = item.data;
  rw.status = item.slverr ? UVM_NOT_OK : UVM_IS_OK;
endfunction

Key takeaways

Frontdoor validates the entire verification and DUT integration stack.
Correct map, adapter, sequencer, and predictor wiring is mandatory.
Cycle-level tracing pinpoints frontdoor failures faster than log-only debugging.

Common pitfalls

Treating adapter code as boilerplate and skipping review of be/addr semantics.
Leaving auto_predict on while also using explicit predictor without intent.
Ignoring monitor evidence when frontdoor status says UVM_IS_OK but mirror is wrong.

Practice this lessonQuestions tagged for this topic in the bank