Predictor Connection: connect_phase Wiring

Why explicit predictor wiring is the default

In integrated environments, explicit prediction is more reliable than implicit auto_predict because it mirrors what was actually observed on the bus, including traffic from non-RAL masters.

[UVM][RAL] connect_phase essentials

predictor.map     = reg_model.default_map
predictor.adapter = adapter
bus.mon.ap.connect(predictor.bus_in)
reg_model.default_map.set_auto_predict(0)

Result:
  monitor traffic -> predictor -> map.predict() -> mirror update

• Monitor output is ground truth for what the DUT bus interface actually saw.

• Predictor must share the same adapter semantics as frontdoor transport.

• auto_predict off avoids double prediction races.

Reference connect_phase implementation

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

  // [RAL] frontdoor path
  reg_model.default_map.set_sequencer(apb.sqr, adapter);

  // [RAL] explicit prediction path
  reg_model.default_map.set_auto_predict(0);
  predictor.map     = reg_model.default_map;
  predictor.adapter = adapter;
  apb.mon.ap.connect(predictor.bus_in);
endfunction

Signal and transaction flow

Write transaction timeline
-------------------------
1. reg.write() called by test
2. map + adapter create protocol item
3. driver drives bus cycle
4. monitor observes completed cycle
5. monitor.ap publishes bus item
6. predictor.bus_in receives item
7. adapter.bus2reg converts item
8. predictor calls map.predict(rw)
9. mirror value updates

Read transaction timeline
------------------------
1. reg.read() called by test
2. map + adapter generate read item
3. driver executes read on bus
4. monitor captures response data
5. predictor updates mirror with observed readback
6. RAL read returns value to test

• Prediction should track completed bus transactions, not intended driver items.

• Connect monitor analysis port, not sequencer ports or driver callbacks.

• If protocol has split transactions, monitor must publish coherent final item.

Multi-monitor and filtered monitoring patterns

Many-to-one predictor input

function void connect_phase(uvm_phase phase);
  super.connect_phase(phase);
  reg_model.default_map.set_sequencer(cpu_agt.sqr, adapter);
  reg_model.default_map.set_auto_predict(0);
  predictor.map     = reg_model.default_map;
  predictor.adapter = adapter;

  // All masters that touch this block feed predictor
  cpu_agt.mon.ap.connect(predictor.bus_in);
  dma_agt.mon.ap.connect(predictor.bus_in);
  dbg_agt.mon.ap.connect(predictor.bus_in);
endfunction

When monitor filtering is required

If one monitor publishes traffic for multiple address regions, add a lightweight filter subscriber before predictor.bus_in so only register-map traffic reaches prediction.

class reg_window_filter extends uvm_subscriber #(apb_item);
  `uvm_component_utils(reg_window_filter)
  uvm_analysis_port #(apb_item) out_ap;
  uvm_reg_addr_t base, limit;

  function void write(apb_item t);
    if ((t.addr >= base) && (t.addr <= limit))
      out_ap.write(t);
  endfunction
endclass

[UVM][RAL] predictor debug probes

Probe A: monitor publish count
Probe B: predictor received count
Probe C: predict() success count
Probe D: mirror mismatch count

A>0, B=0 => connection issue
B>0, C=0 => adapter/map conversion issue
C>0, mismatches remain => model policy or competing writes

Key takeaways

• connect_phase predictor wiring is the backbone of reliable mirror checks.

• Use monitor-observed traffic as prediction source, not intended drive traffic.

• For shared buses, filter by address window before prediction if needed.

Common pitfalls

• Leaving auto_predict enabled while explicit predictor is active.

• Connecting predictor before monitor construction and ignoring null handles.

• Feeding predictor with partial or pre-handshake monitor samples.