Skip to content
STIMSMITH

outlier bugs

Concept WIKI v1 · 5/27/2026

Outlier bugs are processor functional bugs that resist conventional simulation-based verification because the event sequences required to trigger them are too complex for random instruction streams or directed tests. In the cited RISC-V verification work, they are also called “simulation resistant super bugs” and are described as requiring execution outside the design’s normal flow or operating parameters to be exposed.

Definition

In processor verification, outlier bugs are functional bugs that evade typical simulation-based verification approaches. Verification engineers also refer to them as simulation resistant super bugs. They are not exposed by random instruction streams or directed tests when the required sequence of events is too complicated to occur under normal verification workloads. Instead, they may only be exposed by exercising the design outside its normal flow or operating parameters. [C1]

Why they are difficult to find

Outlier bugs are tied to rare or complex event sequences that place a processor into a buggy microarchitectural state. In simulation-based verification, finding such bugs depends on creating code sequences that drive the device under test into that state and then produce an architectural-state mismatch against a golden model. [C2]

The cited work notes that even extensive co-simulation and high coverage do not guarantee that a processor is bug-free before fabrication: functional bugs can still escape to silicon and appear during silicon validation or at an end customer. [C3]

Detection approach described in the evidence

The cited MICRO-54 paper presents Logic Fuzzer as a technique for increasing the chance of finding outlier bugs during simulation. Rather than fuzzing input stimuli, Logic Fuzzer fuzzes the processor logic itself by randomizing states or control signals in the device under test in ways that do not corrupt program correctness or program order. Examples include asserting a reorder-buffer full or stall signal when it is not full, modifying branch-predictor tables, or inserting instructions on a mispredicted path. [C4]

The purpose is to push execution outside its normal flow and reach atypical microarchitectural states without requiring engineers to develop additional specialized test programs. The cited results report that Dromajo alone exposed nine bugs across three RISC-V cores, while enhancing Dromajo with Logic Fuzzer increased the exposed count to thirteen without adding verification tests. [C5]

Practical implication

The evidence emphasizes that successfully booting and running Linux is not sufficient proof that a processor core is verified. In the cited evaluation, three RISC-V cores had gone through several tapeouts and claimed to boot and run Linux, yet more than half of the bugs found were operating-system related, and a “well behaved” Linux run would not have exercised most of them. [C6]

CITATIONS

6 sources
6 citations
[1] Outlier bugs are also called simulation-resistant super bugs; they are not exposed by random instruction streams or directed tests because the event sequence is too complicated, and they may require exercising the design outside normal flow or operating parameters. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation
[2] In simulation-based processor verification, exposing a bug depends on developing a code sequence that drives the processor into a buggy microarchitectural state that creates an architectural-state inconsistency with the golden model. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation
[3] Functional bugs can escape to silicon despite extensive co-simulation and high coverage, and may be exposed only during silicon validation or at an end customer. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation
[4] Logic Fuzzer fuzzes the actual logic rather than input stimuli, randomizing states or control signals in the device under test without corrupting functionality or program order; examples include reorder-buffer stall/full signals, branch-predictor tables, and mispredicted-path instructions. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation
[5] Dromajo alone exposed nine bugs in three RISC-V cores, and enhancing it with Logic Fuzzer increased the exposed bug count to thirteen without additional verification tests. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation
[6] The evaluated RISC-V cores had gone through several tapeouts and claimed to boot and run Linux, yet more than half of the found bugs were operating-system related, and a well-behaved Linux run would not have exercised most of them. Effective Processor Verification with Logic Fuzzer Enhanced Co-Simulation