AI Assisted RTL and UVM Debugging:Waveform analysis and register model mismatches

A register read returns the expected value, yet the UVM test reports a mismatch. Before changing the RTL, the verification engineer needs to establish which component disagrees with the specification and whether it observed the completed transaction. A stale register-model mirror can be the result of a missing prediction connection even when the hardware register behaves correctly.

AI-assisted RTL debugging can help retrieve relevant simulation evidence and organise the investigation. The Back-to-the-Future framework, or BTTF, studies how structured waveform data can make natural-language queries useful to verification engineers [1]. Its results provide a research context for the practical UVM example in this article. The example itself is illustrative and was not evaluated in the BTTF benchmark.

The useful outcome is a reproducible explanation of the failure, supported by the relevant transaction, register behaviour and testbench configuration. An AI suggestion should remain a hypothesis until those checks support it.

Why waveform evidence matters

A failing UVM test may originate in the DUT, a bus agent, the register model, a sequence or checking logic. The first reported error is often downstream of the event that caused it. An engineer may need to correlate a write request, protocol completion, the internal register update, a later read response and the RAL mirror.

These observations do not necessarily become available at the same time. A request issued by a driver is not sufficient evidence that the bus accepted it. A completed transfer also does not establish that the monitor published the correct transaction or that the predictor processed it.

Start with the required behaviour and a bounded question. For example, ask why the mirror for a particular control register remained zero after a completed write. Retrieve the smallest relevant interval first, then extend the investigation if the earlier cause lies outside it.

What the BTTF research reports

BTTF converts simulation activity into a relational SQLite representation, with signal declarations separated from timestamped value changes. An orchestration agent routes questions to specialised analysis, verification and evaluation agents. The paper reports the following results [1].

Gemini-2.5-Pro was the default model. The quality comparison used an autorater across five criteria. These figures describe the evaluated setup; they are not production-wide bug-detection accuracy or evidence that BTTF diagnoses UVM RAL predictor failures. Figure 1 is a simplified conceptual interpretation with an added engineer-review stage [1].

Figure 1. Conceptual BTTF-inspired investigation linking a question, waveform evidence and source context. Engineer review and controlled validation are added here as an engineering recommendation.

Understanding the UVM register model

The UVM Register Abstraction Layer, or RAL, provides a class-based model of the DUT registers and address maps. The desired value represents the model value requested through its API and access policies. The mirrored value is the model’s current prediction of register contents. Neither is a direct, continuously updated observation of the hardware [2], [3].

With automatic, or implicit, prediction enabled for a map, completed RAL accesses can update the mirror through the access path. Explicit prediction instead uses observed transactions from a bus monitor, an adapter and a register map to update the appropriate model. This can include traffic generated outside the RAL API, provided the monitored interface and mapping expose that traffic [2].

A predictor can only reflect information available to it. Internal hardware updates, reset events or traffic on an unmonitored interface may need additional observation or prediction. Register side effects must also match the field access policies. A mirror that differs temporarily from a hardware-updated status field does not, by itself, identify an RTL defect.

An illustrative stale mirror failure

Consider a peripheral with a 32-bit control register at offset 0x10. Bit 0 is an ordinary read/write enable field. Bits 31:1 ignore writes and read as zero. The specified reset value is 0x00000000, and a successful write of 0x00000001 must produce that value on a subsequent read, assuming no intervening reset or hardware update.

For this example, one 32-bit bus transfer covers the register. The map and adapter are correct, automatic prediction is disabled with set_auto_predict(0), and there is no other prediction mechanism. The DUT has completed reset and the RAL model has separately been reset to its specified values. An explicit predictor exists, but the monitor’s analysis port is not connected to predictor.bus_in.

The write behaviour and read response meet this simple register requirement. The mirror remains stale because the prediction path missed the transfer. A reported comparison failure still depends on a checker actually comparing the relevant values; stale state does not automatically produce a UVM error.

Tracing the access and prediction paths

Figure 2. Illustrative explicit-prediction fault. The write completes, but the missing monitor-to-predictor connection leaves the mirror stale. Arrows show simplified request and prediction paths; read responses are omitted.

The sequencer arbitrates sequence items, the driver executes the bus protocol, and the monitor reconstructs completed observed transactions. The predictor uses its adapter and map to identify and update the affected register. These responsibilities should be checked separately [2].

Record the mirror before a diagnostic access

The following UVM 1.2-based sequence fragment assumes a valid regmodel handle and a configured frontdoor map. Run it after the write stimulus has completed. It records cached state before issuing a read; it is not a standalone testbench or a predictor-completion check [3].

uvm_status_e status;

uvm_reg_data_t mirror_before;

uvm_reg_data_t read_data;

mirror_before = regmodel.ctrl.get_mirrored_value();

regmodel.ctrl.read(.status(status), .value(read_data),

  .path(UVM_FRONTDOOR), .map(regmodel.default_map),

  .parent(this));

if (status != UVM_IS_OK) begin

  `uvm_error(“RAL_DEBUG”, “Read failed; data is not valid”)

  return;

end

`uvm_info(“RAL_DEBUG”,

  $sformatf(“Mirror before read=0x%08h; read data=0x%08h”,

            mirror_before, read_data), UVM_MEDIUM)

Checking predictor integration and completion

get_mirrored_value() returns cached model state without accessing the DUT. A frontdoor read returns the bus response; mirror updates depend on the configured prediction path. In the disconnected explicit-prediction case above, issuing a read does not repair the missing connection. Save the pre-read mirror because diagnostic accesses can update state in a correctly connected or differently configured environment [2], [3].

For the active-agent integration used here, the environment’s connect_phase includes the following connections. The predictor is a uvm_reg_predictor parameterised with the same bus transaction type published by the monitor; it and the adapter must already have been constructed [2].

virtual function void connect_phase(uvm_phase phase);

  super.connect_phase(phase);

  regmodel.default_map.set_auto_predict(0);

  regmodel.default_map.set_sequencer(

    bus_agent.sequencer, reg_adapter);

  reg_predictor.map = regmodel.default_map;

  reg_predictor.adapter = reg_adapter;

  bus_agent.monitor.ap.connect(reg_predictor.bus_in);

endfunction

The adapter must translate the observed transaction’s address, operation, data, status and byte enables where applicable. On protocols with separate request and response channels, observation must account for their association and completion. A transfer that reports an error must not be treated as an ordinary successful write.

After reconnecting the path, rerun the write and confirm that the predictor receives and processes the completed transaction. Inspect the mirror after that processing, using an environment-specific completion observation or synchronisation mechanism. Sampling immediately when the driver finishes, or relying on a fixed delay, can confuse a scheduling race with a missing prediction.

Agreement between the RTL value and mirror is insufficient if both are being interpreted against an incorrect requirement. Compare at a defined observation point and account for legitimate side effects.

Giving AI the evidence needed for diagnosis

A useful request identifies the failing register, the completed transfer, the observation time and the expected behaviour. Supply the register specification, bus protocol, relevant hierarchy, RAL configuration and failing simulation seed. Ask the assistant to cite the evidence for each observation and list the checks needed to distinguish its hypotheses.

An ordinary RTL waveform dump may not contain UVM class state, monitor publications or predictor configuration. Include appropriate UVM logs, transaction recordings or explicit instrumentation. All artefacts must refer to the same run and source revision. Missing information in a trace must remain an evidence gap until the recording configuration has been checked.

Retain the original simulation artefacts and record any exclusions from the query database. A non-toggling signal can still explain a failure, for example when an enable never asserts. Queries involving reset, clock edges or unknown values need the applicable timing, sampling and X/Z information. Checking rules against recorded activity does not establish a formal proof over all legal executions.

Figure 3. Proposed engineering workflow for the illustrative RAL investigation. A hypothesis is accepted only after its explanation and correction are checked against the specification.

Validating a correction before accepting it

Reproduce the failure with the original source revision, simulator and UVM versions, seed, test configuration and prediction settings. Preserve the relevant waveform interval and UVM observations before changing the environment. This establishes what the proposed correction must explain.

For the example, make the smallest controlled change: restore the monitor-to-predictor connection without changing the DUT or register requirement. Confirm that the monitor reports the completed write, the predictor processes it and the mirror becomes 0x00000001. A later successful read must still return the specified value.

Then test the conditions that could invalidate a simple fix. The scope depends on the register and protocol, but a review should consider:

• Reset assertion and release, with explicit coordination of DUT and RAL reset state.
• Back-to-back accesses and simultaneous or independent initiators on monitored interfaces.
• Partial writes and byte enables where supported, including preservation of unaffected bits.
• Read/write side effects, hardware-updated fields and field access policies.
• Bus errors, unsuccessful transfers and response ordering where applicable.
• Related tests, assertions and regressions that could expose unintended changes.

Record why the old configuration failed and how the change restores the intended observation path. Disabling comparisons, weakening assertions or forcing the mirror to the expected value may suppress an error without fixing the integration. A passing rerun is useful evidence only when the original cause has also been explained.

Keep AI access bounded to approved data and tools. Proprietary RTL and traces require suitable confidentiality controls. Treat comments and logs as engineering inputs, restrict execution privileges, and require review before an assistant changes the DUT, checker or verification configuration.

Applying the approach within Alpinum workflows

Alpinum’s AI in Design Verification services address AI adoption within existing engineering processes. AlpinumDV describes specification-driven UVM generation, simulation and testbench self-debugging. Those capabilities provide related context; this article does not claim a BTTF integration or a demonstrated AlpinumDV RAL diagnostic implementation.

Engineers who need deeper knowledge of adapters, prediction, mirroring and debug can explore Alpinum’s Design Verification Training with SystemVerilog and UVM. The course includes RAL integration and register-access methods alongside verification practice.

Conclusion

A stale mirror can make a correct register look suspicious. The investigation must establish whether the write completed, what the hardware did and which testbench component observed it. AI can help retrieve and correlate the evidence, but its explanation still needs to survive those checks.

For this example, the decisive correction is a restored prediction connection supported by a reproducible rerun. The resulting evidence should explain the original failure, show the required register behaviour and demonstrate that the surrounding verification environment still works as intended.

References

[1] J. Yang, I. Lobov and T. Karpati, “Back to the Future: Rethinking EDA Infrastructure for Agentic Systems in Chip Design Verification,” arXiv:2610.06790v1, 5 October 2026, Sections 3-4 and Appendix A https://arxiv.org/abs/2610.06790

[2] Accellera Systems Initiative, Universal Verification Methodology (UVM) 1.2 User’s Guide, 8 October 2015, Chapter 5, particularly Sections 5.3 and 5.9. https://www.accellera.org/images/downloads/standards/uvm/uvm_users_guide_1.2.pdf 

[3] Accellera Systems Initiative, Universal Verification Methodology (UVM) 1.2 Class Reference, June 2014, uvm_reg, uvm_reg_map and uvm_reg_predictor. https://www.accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf 

FAQs