Overview

RTL simulation is a hardware-simulation step used in dynamic, simulation-based verification of processor designs. In the cited processor-verification workflow, simulation-based verification uses tailored inputs to simulate the design under test (DUT) and check whether the DUT output meets expectations. The evidence contrasts this with static formal verification and notes that simulation-based verification is more prevalent in practice because formal verification has scaling limits on complex designs. [simulation-based-verification]

Role in processor fuzzing

In processor fuzzing workflows, RTL simulation appears in the hardware-simulation phase. The RTL code of the DUT is translated into a host executable binary file, and the fuzzer runs the simulation while using hardware instruments to collect coverage for the current input. The same evidence describes processor fuzzing as a multi-phase process: generating and mutating instruction streams, simulating the hardware, and then verifying architectural state. [processor-fuzzing-rtl-simulation]

MorFuzz usage

MorFuzz uses RTL simulation to simulate hardware RTL designs. Its evaluation setup uses Synopsys VCS, described in the evidence as an industry-standard commercial tool, but the authors state that MorFuzz does not rely on features exclusive to commercial tools. In that setup, hardware modules are translated to Verilog and compiled into a host executable binary through the Synopsys VCS RTL simulator. [morfuzz-vcs-rtl-simulation]

Coverage instrumentation during simulation

The evidence also connects RTL simulation to coverage collection. MorFuzz is described as compatible with existing hardware coverage matrices and uses control-register coverage for comparison with DifuzzRTL. Control registers are defined as registers whose values are used for multiplexer select signals. The instrumented circuits count different states triggered in a module and sum them as final coverage. The authors caution that coverage is used to evaluate the effect of inputs and mutations, and that high DUT coverage does not imply the design is bug-free. [morfuzz-coverage]

Verification context

The processor model in the evidence treats a processor as a finite state machine with microarchitectural and architectural state. The DUT state evolves each cycle based on the current state and external input, such as instructions. Verification checks whether the DUT implementation function is a valid subset of the specification-defined function. RTL simulation supports the dynamic side of this verification context by executing the DUT under inputs and enabling output, state, or coverage checks. [processor-verification-model]