Golden Reference Model (GRM)

• Golden Reference Model (GRM) is a deterministic software emulator that accurately implements processor instruction sets as an authoritative ground truth.
• It accelerates hardware verification by decoupling semantic validation from cycle-accurate simulation, enabling rapid detection of functional and security bugs.
• GRMs are integral to fuzzing frameworks like GoldenFuzz and TheHuzz, enhancing test refinement, coverage, and systematic bug triage.

A Golden Reference Model (GRM) is a deterministic, architecturally precise software implementation of a processor’s instruction set and state transition semantics, used as an oracle in differential hardware verification, coverage-guided fuzzing, and bug triaging. The GRM serves as an authoritative ground truth for architectural behavior, separate from microarchitectural or RTL-level implementation details. It acts as a digital twin of the Device Under Test (DUT), enabling fast, fine-grained validation of instruction blocks or traces without reliance on slow, cycle-accurate simulation. The GRM paradigm is fundamental to modern processor fuzzing frameworks, including GoldenFuzz and TheHuzz, which exploit GRMs to scale test refinement, accelerate coverage, and systematically uncover both functional and security-critical hardware flaws (Wu et al., 25 Dec 2025, Tyagi et al., 2022).

1. Formal Definition and Properties

A Golden Reference Model is formally constructed as a deterministic transition system parameterized by the processor's architectural state space $S$ and instruction set $I$:

• $S$ represents all architecturally visible state:
  • General-purpose register file $R$ ($\{r_0,\ldots,r_{31}\}$)
  • Floating-point registers $F$ (if present)
  • Control and status registers $CSR$ (e.g., $mstatus$, $mie$)
  • Memory map $M$ (byte-addressable)
  • Program counter $PC$
• $I$ denotes the set of legal instruction encodings (base and extensions).

The transition function $T: S \times I \to S$ maps a given state and instruction to the next state, implementing the state update as dictated by the ISA. The GRM is subject to compliance constraints: only legal opcode+mode pairs produce architectural results; illegal encodings or privilege violations must deterministically produce the architecturally-specified exceptions.

This property ensures that, for any legal ($i$,$s$), $T(s,i)$ reproduces the specified architectural effect, and any deviation flags a divergence in the hardware implementation rather than in the model (Wu et al., 25 Dec 2025, Tyagi et al., 2022).

2. Architectural Implementation and Compliance

The GRM is implemented as a pure-software emulator (e.g., Spike for RISC-V, or1ksim for OpenRISC) with the following components (Wu et al., 25 Dec 2025):

• State Representation: Software-native structures for registers, CSRs, memory; program counter logic.
• Instruction Pipeline: Fetch/decode, execute, memory access (respecting endianness settings), writeback, and exception/permission checks.
• Memory Model: Byte-addressable array with page-table walking, PMP enforcement, and fault detection.
• Behavioral Semantics: Implements precise architectural retirement effects. No cycle-accurate timing, caches, or speculative execution.

Compliance is verified by executing official ISA compliance suites, comparing outputs to known-good references, and systematically running property-based tests on edge cases (e.g., misaligned accesses, CSR modifications). Whenever a new architectural feature or extension is added, regression tests and compliance checks are re-executed (Wu et al., 25 Dec 2025).

3. Integration into Fuzzing and Verification Pipelines

Both GoldenFuzz and TheHuzz integrate the GRM as the key component in coverage-driven and semantic-driven hardware fuzzing (Wu et al., 25 Dec 2025, Tyagi et al., 2022):

• Fuzzing Workflow:

1. Testcase Generation (GoldenFuzz): A language-model-based fuzzer generates instruction blocks; the GRM rapidly evaluates them for semantic validity, discarding those causing architectural exceptions.
2. Refinement: The LLM's output is guided by preference pairs (valid vs. invalid blocks), maximizing generation of architecturally correct and diverse blocks.
3. RTL Simulation: Only blocks pre-validated by the GRM are passed to cycle-accurate RTL simulation, driving resource-intensive hardware-level coverage.
4. Differential Testing: For each instruction or basic block, the RTL DUT and GRM are both stepped in lock-step; any architectural state divergence is flagged as a bug (functional or security-relevant).
5. Feedback/Scoring: Instruction blocks are scored using hardware coverage metrics (line, branch, FSM). New coverage guides future test case selection, and coverage feedback can bias mutation probabilities (TheHuzz) or LLM fine-tuning (GoldenFuzz).

• Architecture in TheHuzz: The GRM serves as an oracle against which the DUT’s simulated state is compared after every instruction; coverage feedback rewards tests that produce new RTL-intrinsic behaviors (branches, states, toggles, etc.) (Tyagi et al., 2022).

4. Scoring, Selection, and Feedback Mechanisms

Fuzzing frameworks incorporating the GRM utilize a range of metrics for validating and selecting tests:

• Validity Scoring (GoldenFuzz): $V(b) = 1$ if the block $b$ executes on the GRM without raising exceptions, $0$ otherwise. Only valid blocks proceed to slow RTL exposure (Wu et al., 25 Dec 2025).
• Coverage-Driven Scoring (GoldenFuzz, TheHuzz): Combination of intra- and inter-test coverage metrics, designed to maximize exploration of previously unvisited conditions, branches, FSM states, and hardware-specific toggles.
• Preference-Guided Updates: In GoldenFuzz, a SimPO (preference-based offline RL) loss is minimized based on observed coverage rewards, supporting stability and coverage depth. Rolling memory of top-exemplar blocks prevents overfitting (Wu et al., 25 Dec 2025).

Coverage Metrics Used

Metric	Description	Collected by
Statement	Line/source statement execution	RTL coverage APIs
Branch	If/case condition outcome	RTL coverage APIs
FSM State	Symbolic FSM entered states	RTL coverage APIs
Toggle	DFF state changes (0→1, 1→0)	RTL coverage APIs
Floating Wire	HDL wire transitions to/from 'z'	RTL, GRM for comparison only
Expression	Combinational expression values	RTL coverage APIs
Condition	Subcondition values in compound guards	RTL coverage APIs

Blocks or tests yielding new coverage points are prioritized for exploitation or further mutation.

5. Performance Characteristics and Impact

The use of a GRM as a digital twin yields significant improvements in fuzzing throughput and bug detection efficacy:

• Speed: GRM-based semantic evaluation is 2–3 orders of magnitude faster than cycle-level RTL simulation (0.004 s/test on CPU for the GRM in GoldenFuzz).
• Coverage: GoldenFuzz achieves up to 15% higher condition coverage and 10% higher line coverage than the prior state-of-the-art after 20,000 tests, despite generating orders-of-magnitude shorter instruction sequences (30 vs. 10,000 instructions).
• Vulnerability Discovery: The GRM-supported pipeline enables systematic rediscovery of all known RISC-V core vulnerabilities and rapid surfacing of new, severe bugs; GoldenFuzz discovered five previously unknown vulnerabilities in open-source cores and two in a commercial core extension (Wu et al., 25 Dec 2025). TheHuzz similarly uncovered bugs missed by formal tools, including those exploitable from software (Tyagi et al., 2022).
• DUT Bottleneck: By pre-filtering instruction blocks using the GRM, slow and resource-demanding RTL testing is reserved for the most promising candidates, doubling high-value test throughput compared to monolithic approaches (Wu et al., 25 Dec 2025).

6. Insights, Limitations, and Future Directions

Key Insights

• Decoupling semantic validation from coverage exploration using a GRM enables efficient exploration of the architectural state space, yielding more valid and higher-utility test cases (Wu et al., 25 Dec 2025).
• The lock-step, state-by-state comparison isolates functional bugs at architectural boundaries, serving as a precise differential oracle for bug triage (Tyagi et al., 2022).
• Block-wise test generation aligns fuzzer search complexity with both LLM policy granularity and architectural constraints, optimizing the trade-off between learning stability and test diversity (Wu et al., 25 Dec 2025).

Limitations

• ISA Fidelity Gap: The GRM, as an architectural model, does not capture microarchitectural timing effects, metastability, or undocumented behaviors, which can yield spurious bug reports or false negatives (Wu et al., 25 Dec 2025).
• GRM Availability: ISAs lacking an open-source, architecturally complete software model cannot leverage this methodology (Wu et al., 25 Dec 2025).
• Human Triage: Differential testing may yield a high rate of mismatches, requiring manual analysis to filter systematic RTL-vs-GRM discrepancy patterns (5–30 min per new bug).
• No Floating-Wire Modeling: GRMs typically do not model analog or 4-state (‘x’, ‘z’) logic, so floating-wire bugs are only detected in RTL by mismatch against GRM outputs (Tyagi et al., 2022).

Future Directions

• Model Extraction: Automating GRM derivation directly from DUT RTL may close fidelity gaps.
• Retrieval-Augmented Fuzzing: Conditioning LLM-based fuzzers with hardware design documents or formal spec fragments to increase semantic reach.
• Cross-ISA Adoption: Extending the GRM paradigm beyond RISC-V and OpenRISC by integrating QEMU-based (or equivalent) models for ARM, x86, and other architectures (Wu et al., 25 Dec 2025).

7. Related Methodological Context

The GRM paradigm represents a convergence of software-based formal verification, LLM-assisted constrained test generation, and hardware fuzzing. Its practical adoption is seen across generative fuzzing pipelines (GoldenFuzz (Wu et al., 25 Dec 2025), TheHuzz (Tyagi et al., 2022)), differential bug triage, and hardware security analysis. These frameworks establish the GRM as a central reference point for faithful processor validation, scalable bug discovery, and robust coverage feedback in modern-scale CPU design and analysis workflows.