Skip to content
STIMSMITH

end-of-simulation comparison

Concept WIKI v1 · 5/27/2026

End-of-simulation comparison is a reference-model checking method for processor verification in which the same code is run on both the RTL design under test and a golden reference model, and their architectural states are compared only after the test completes. It is simple and inexpensive, but can hide bugs whose architectural effects are later overwritten and can make debugging difficult because the detected mismatch may be far from the original divergence.

Definition

End-of-simulation comparison is a reference-model comparison technique used in processor verification. It runs the same code on both a reference, or golden, processor model and the RTL implementation, then compares their architectural state only after the simulation finishes.[1]

How it works

In the setup described in Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation, the final register-file state and memory contents from both the reference model and the RTL implementation are dumped at the end of the simulation and compared. If any values differ, the mismatch is treated as a failure requiring investigation.[1]

Role in reference-model comparison

Reference-model comparison is based on the expectation that, when the same code is executed on a design under test and a golden model, their architectural states should match. End-of-simulation comparison is one implementation of that idea, distinguished by performing the comparison only once the test completes rather than during execution.[1]

Advantages

The cited paper characterizes end-of-simulation comparison as a "cheap and simplistic setup," because it requires only final-state collection and comparison rather than cycle-by-cycle or commit-by-commit interaction between the RTL and the reference model.[1]

Limitations

End-of-simulation comparison has two main drawbacks identified in the cited source:

  1. A bug that temporarily affects architectural state may be overwritten by later correct execution, hiding the bug from the final comparison.[1]
  2. When a mismatch is detected, debugging can be difficult because the final-state failure may be far from the original point where the RTL and reference model diverged.[1]

Contrast with other approaches

The same paper contrasts end-of-simulation comparison with trace comparison and co-simulation. Trace comparison compares execution logs containing information such as program-counter flow and register or memory writebacks, while co-simulation runs the RTL and reference model in parallel and can halt at a failed state comparison near the point of divergence.[2]

LINKED ENTITIES

1 links
Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation USES

CITATIONS

3 sources
3 citations
[1] End-of-simulation comparison runs the same code on the reference model and RTL implementation, then compares final architectural state by dumping register-file state and memory at the end of simulation. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[2] The cited paper characterizes end-of-simulation comparison as cheap and simplistic, and identifies drawbacks: overwritten buggy architectural effects can be hidden, and detected mismatches can be difficult to debug because they may be far from the point of divergence. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...
[3] Trace comparison uses execution logs such as program-counter flow and register or memory writebacks, while co-simulation runs both models in parallel and can halt on a failed comparison near the divergence. [PDF] Effective Processor Verification with Logic Fuzzer Enhanced Co ...