Skip to content
STIMSMITH

Differential Testing

Technique

Differential testing is a comparison-based validation technique in which an implementation under test is executed on the same testcases as one or more reference implementations, and their observable results are checked for equality. In instruction-set-simulator verification, coverage-guided fuzzing can generate instruction-stream testcases, after which the simulator under test is compared against reference ISSs using register values, selected memory contents, crashes, and other mismatches as triage signals.

First seen 5/28/2026
Last seen 6/8/2026
Evidence 13 chunks
Wiki v2

WIKI

Overview

Differential testing is a comparison-based testing technique: an implementation under test is executed on the same testcase as one or more reference implementations, and the resulting observable behavior is checked for equality. In the instruction-set-simulator (ISS) verification setting described by Verifying Instruction Set Simulators using Coverage-guided Fuzzing, the ISS under test is verified by comparing its execution results with those of other reference ISSs, which may include multiple references.

The compared observations can include normal execution results as well as failures. The ISS-verification workflow reports mismatches, including crashes, and checks equality over result data such as register values and selected memory content.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

10 connections
ProcessorFuzz ← implements 95% 6e
ProcessorFuzz uses differential testing by comparing ISA simulator output with RTL simulator output.
DiFuzzRTL ← implements 90% 3e
DIFUZZRTL uses differential testing to detect bugs in processors.
ISA Simulation uses → 100% 2e
Differential testing uses ISA simulation as a reference model to compare against RTL simulation.
RTL simulation uses → 100% 2e
Differential testing compares RTL simulation output against ISA simulation output.
hardware fuzzing ← uses 90% 2e
Hardware fuzzing uses differential testing to compare RTL and ISA simulator outputs.
Examiner ← uses 100% 2e
Examiner uses differential testing to compare instruction execution between emulators and real devices.
CPU state comparison uses → 100% 2e
Differential testing uses CPU state comparison to identify inconsistent instructions between emulators and real devices.
APSR status register uses → 100% 2e
The differential testing engine includes the APSR status register as part of the CPU state for comparison.
ISA simulation uses → 95% 1e
Differential testing in processor fuzzing compares ISA simulation results against RTL simulation results.
Verifying Instruction Set Simulators using Coverage-guided Fuzzing ← uses 95% 1e
The paper uses differential testing by comparing execution results across multiple ISSs.

LINKED ENTITIES

1 links
Verifying Instruction Set Simulators using Coverage-guided Fuzzing USES Extracted graph relationship

CITATIONS

6 sources
6 citations — click to expand
[1] Differential testing in the ISS-verification setting compares execution results from an ISS under test with one or more reference ISSs. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[2] The workflow checks equality of results and can report mismatches including crashes, using observations such as register values and selected memory content. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[3] Coverage-guided ISS verification first generates a testset with a fuzzer and then evaluates that testset by comparing the ISS under test with reference ISSs. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[4] Generated binary bytestreams are interpreted as instruction sequences, embedded into ELF testcases, and run with template code that initializes a shared initial state and collects results. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[5] The ISS-verification approach considers instruction sequences including illegal instructions to exercise uncommon error cases. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[6] Mismatches require analysis because configuration differences, such as memory size or peripheral mappings, can cause differing behavior without representing ISS bugs. Verifying Instruction Set Simulators using Coverage-guided Fuzzing