Overview

Reference model comparison is a verification technique for processors in which the execution of an implementation is compared against a reference, or golden, model. In the cited MICRO-54 paper, the reference model is described as a high-level software model of a processor that is fast, uncomplicated, omits implementation details, and updates architectural state at instruction-level granularity. The core idea is that when the same code runs on the device under test (DUT) and the model, their architectural states should match at any given moment. [C1]

This technique is useful in settings where self-checking is difficult. For randomly generated verification code, the paper notes that self-checking techniques are not applicable because of the random nature of the tests; instead, pass/fail behavior can be determined by comparing execution with a reference model. [C2]

Implementation styles

End-of-simulation comparison

End-of-simulation comparison is a simple and low-cost setup. The same code is run on the reference model and the RTL implementation, and only after the test completes are architectural states compared. In the paper's description, the register-file state and memory from both executions are dumped and compared. [C3]

This approach has two important limitations. First, a buggy behavior that affects architectural state can later be overwritten by correct execution and therefore hidden. Second, if a mismatch is detected only at the end, debugging can be difficult because the observed failure may be far from the original point of divergence. [C3]

Trace comparison

Trace comparison is another way to implement reference-model checking. It requires both models to dump execution logs, typically including program-counter flow and every register or memory writeback. The logs are then compared, and mismatches are flagged. [C4]

However, trace comparison is not well suited to asynchronous external stimuli such as interrupts and debug requests. Because the models run standalone and the comparison happens after execution, a single interrupt can make the logs diverge. [C5]

Co-simulation

Co-simulation addresses the asynchronous-stimulus problem by running the RTL model and reference model in parallel and allowing communication between them. The models start executing the same code and pass messages to each other. [C6]

One class of message is used at specified events such as instruction commit: the RTL model signals the reference to commit an instruction and compare the relevant state. If the comparison fails, execution halts immediately and the stimulus that caused the failure is reported, which simplifies debugging by placing the investigation near the point of divergence. [C6]

A second class of message is needed for asynchronous interrupts. When the RTL flags an interrupt, it must be able to inform the emulator so that the emulator follows the RTL execution path. [C7]

Role in processor verification

Reference model comparison is part of simulation-based or dynamic processor verification. The evidence contrasts it with formal verification: formal methods exhaustively examine possible execution paths but face scalability limits on complex modern processors, while simulation-based verification scales but checks only the finite set of paths exercised by supplied stimuli. [C8]

Related work

The MICRO-54 paper Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation uses reference model comparison as part of its discussion of processor verification infrastructure and co-simulation. [C1]