Overview

In the Ibex core's end-to-end RTL/ISS co-simulation verification flow, the debug ROM is a region of code whose execution is carried out by the RTL core but which the chosen golden-model ISS does not simulate. It is one of the classes of code — alongside interrupt handler (trap handler) code — that the ISS trace log does not contain execution information for.

Role in the verification flow

The last stage of the Ibex RTL/ISS co-simulation flow compares trace logs produced by the core and by the golden-model ISS to determine whether a given simulation is correct. The baseline comparison collects every register writeback from both trace logs and checks that the core writes the correct data to the correct registers in the correct order.

This baseline strategy does not extend cleanly to tests that involve external stimulus (interrupts and debug requests). While the ISS can model traps caused by exceptions, it cannot model traps caused by external stimulus. The verification environment therefore relies on the RISCV-DV handshake mechanism (with the testbench signature address 0x8ffffffc) to obtain runtime status from the core for situations such as entering Debug Mode, entering the proper interrupt handler, and updating CSRs correctly.

Impact on register writeback comparison

Because the ISS trace log will not contain any execution information in the debug ROM (or in interrupt handler code), a naive end-to-end register-writeback comparison would yield incorrect results for tests that trigger debug entry. To add another layer of correctness checking on top of the handshake-based runtime checks, the Ibex verification flow uses a modified form of trace log comparison:

• Instead of comparing every register writeback that occurs during the entire simulation, the comparison is restricted to the final values of every register at the end of the test.
• This works because any code executed in the debug ROM (and in trap handlers) is expected to leave the architectural register state of the surrounding program uncorrupted.

In other words, the presence of the debug ROM in the RTL execution path, but its absence in the ISS trace, is the reason a full per-writeback comparison cannot be used once external stimulus is involved.

Related verification constructs

• Register writeback comparison — the verification check whose form is dictated by the existence of the debug ROM in the RTL but not in the ISS trace.
• RISCV-DV handshake mechanism — the runtime status channel used in conjunction with the modified comparison to verify correct debug-mode entry and CSR updates.
• Interrupt / trap handler code — the other class of code whose absence from the ISS trace motivates the same modified comparison strategy.