Auto Predict vs Explicit Predict

Two prediction modes

RAL can update mirrors automatically from API operations via set_auto_predict(1) or explicitly from observed bus traffic via uvm_reg_predictor. Both are valid; each encodes different trust assumptions.

[RAL] prediction mode definitions

  Auto predict (map-level):
    mirror updates based on RAL operations themselves
    (write/read calls through that map)

  Explicit predict:
    mirror updates from monitor-observed traffic
    through adapter + uvm_reg_predictor

  Core difference:
    auto predict trusts intent path;
    explicit predict trusts observed reality path.

• Auto predict is simple and can be enough in tightly controlled single-master setups.

• Explicit predict scales better when external masters or firmware can modify registers.

• Combining both requires clear intent to avoid double-update confusion.

• Default recommendation for frontdoor verification: explicit prediction with auto_predict off.

Tradeoff matrix

Use this matrix during architecture reviews. It turns a vague style preference into explicit decision criteria.

[UVM] set_auto_predict tradeoff matrix

  Criterion                           Auto Predict ON                    Explicit Predictor
  ─────────────────────────────────────────────────────────────────────────────────────────────────
  Setup complexity                    low                               medium
  Handles non-RAL external writes     weak                              strong
  Mirrors true observed bus traffic   partial                           strong
  Debug transparency                  medium                            high (traceable monitor events)
  Multi-master robustness             low to medium                     high
  Risk of hidden stale assumptions    higher                            lower
  Bring-up speed                      fast                              moderate

  Rule of thumb:
    - block-level smoke bring-up: auto may be acceptable
    - subsystem/chip and long regressions: explicit is safer

[CHECK] common mistaken assumptions

  "auto_predict means predictor unnecessary forever"
    -> false when any actor outside RAL API writes CSRs.

  "explicit prediction is overkill for all cases"
    -> false for environments with firmware, DMA, or multi-agent traffic.

  "enable both to be extra safe"
    -> can create ambiguous debug unless carefully reasoned and documented.

Configuration examples

Choose one baseline and document why. The snippets below show intentional configurations for both modes.

// Mode A: Auto predict (simple block-level setup)
function void connect_phase(uvm_phase phase);
  super.connect_phase(phase);
  reg_model.default_map.set_sequencer(apb.sqr, adapter);
  reg_model.default_map.set_auto_predict(1);
  // predictor not connected in this mode
endfunction

// Mode B: Explicit prediction (recommended robust setup)
function void connect_phase(uvm_phase phase);
  super.connect_phase(phase);
  reg_model.default_map.set_sequencer(apb.sqr, adapter);
  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

Mixed-mode caution

• If both auto and explicit are enabled, document why and verify no double-model artifacts.

• Mixed mode can obscure root cause when mirror changes unexpectedly.

• Prefer one dominant source of truth per map for maintainability.

Migration and governance

Many teams start with auto predict and migrate to explicit later. Do this in steps so regressions remain interpretable.

1. Add predictor wiring while still logging mirror transitions.

2. Flip `set_auto_predict(0)` in a controlled branch and run fixed-seed equivalence tests.

3. Investigate mismatches as likely stale assumptions previously masked by auto updates.

4. Codify mode choice in env comments and review checklist.

5. Keep a dedicated regression target that exercises external-writer scenarios.

[CHECK] migration success criteria

  - no unexplained increase in mirror(UVM_CHECK) false failures
  - predictor logs show expected transaction coverage for target CSR space
  - external writes are reflected in mirror without direct RAL API calls
  - debug latency decreases because mirror changes are traceable to monitor events

Key takeaways

• Auto predict optimizes simplicity; explicit predict optimizes correctness under concurrency.

• For production frontdoor environments, explicit predictor is usually the safer default.

• Treat prediction mode as architecture, not a local coding preference.

• Document mode decisions to prevent accidental regressions during refactors.

Common pitfalls

• Using auto predict in multi-master systems and trusting mirror as ground truth.

• Switching modes without fixed-seed baseline comparisons.

• Running mixed mode silently and creating ambiguous mirror update provenance.