Design Under Test
ConceptA Design Under Test (DUT) is the hardware design whose behavior is exercised, monitored, and checked by a verification or fuzzing methodology. The supplied evidence documents DUT in two distinct settings: (1) a processor implementation in MorFuzz's runtime instruction-morphing co-simulation flow, whose committed program counter, instructions, and write-back values are continuously compared against a reference simulator, and (2) a MIPS-I processor used as the concrete example in a constrained-random verification methodology that drives the DUT with object-oriented SystemVerilog stimulus built from operations, instructions, and instruction scenarios.
First seen 5/25/2026
Last seen 6/9/2026
Evidence 20 chunks
Wiki v5
WIKI
Overview
In the supplied evidence, Design Under Test (DUT) refers to the hardware instance whose behavior is the target of a verification or fuzzing flow. Two complementary usages appear in the evidence:
- In MorFuzz (USENIX Security '23), the DUT is the processor implementation under test that is observed during instruction execution and compared online with a simulator/reference execution. The paper also uses the synonymous phrase processor under test when describing the generated hardware harness.
- In a constrained-random verification (CRV) methodology (EE Times), the DUT is illustrated with a processor supporting the MIPS-I instruction set, and the main stimulus applied to the DUT is a program trace that combines one or more instruction scenarios.
NEIGHBORHOOD
2 nodes · 1 edgesgraph · Design Under Test · depth=1
RELATIONSHIPS
9 connectionsThe SystemVerilog Constrained-Random Testbench evaluates the Design Under Test by driving constrained-random stimulus.
MorFuzz fuzzes a design under test (DUT) comparing its state to a reference model.
Co-simulation runs the design-under-test in parallel with a reference model.
A verification test plan is created to verify a specific design under test.
The Design Under Test is mentioned in the context of the RISCV-DV testbench architecture.
The object-oriented stimulus generation approach targets the processor as the design under test.
Constrained-random verification is applied to evaluate the processor design under test.
Hardware fuzzing tests the design under test for bugs
RTL designs serve as the Design Under Test in verification setups.
LINKED ENTITIES
3 linksObject-Oriented Stimulus Generation EVALUATES Extracted graph relationship
constrained random verification EVALUATES Extracted graph relationship
MorFuzz CONTEXT_OF MorFuzz is the processor-fuzzing framework whose checking flow, state synchronization, and stimulus structure define how the DUT is exercised and observed in the MorFuzz portion of the evidence.
CITATIONS
14 sources14 citations — click to expand
[1] In MorFuzz's checking flow, the DUT first commits its program counter and the executed instruction; the simulator then executes the next instruction and checks whether it matches the DUT's committed instruction. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[2] If the commitment check passes, the simulator records reference write-back data in a scoreboard; the judgment stage later compares the DUT write-back value with the scoreboard reference value. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[3] When mismatched behavior is detected, MorFuzz reports a potential bug and exits the simulation. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[4] Not all mismatched differences are bugs; some arise from implementation differences between the DUT and the simulator, and exiting the simulation on every mismatch would cause the DUT to lose accumulated state and hinder reaching deep processor states. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[5] MorFuzz's synchronizable co-simulation automatically eliminates legal implementation differences by letting the DUT synchronize its state to the reference model; for example, an instruction that accesses a peripheral register not modeled by the simulator can be detected as a legal difference by analyzing the accessed physical address. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[6] MorFuzz seeds determine the fuzzing execution environment, the instruction extensions to be tested, the weights of different testing blocks, the random-number seed, and the intensity of instruction shuffle. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[7] MorFuzz defines seven testing block types covering different hardware functional modules of the DUT: integer arithmetic, floating-point arithmetic, CSR, memory operation, atomic memory operation, system operation, and custom extension; a control-transfer instruction at the end of each block chains them together. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[8] The MorFuzz fuzzing execution environment initializes the processor, configures available instruction extensions, the address translation mode, the page table, and the runtime privilege level, resides in a non-morphable physical area, and handles exceptions and interrupts at the highest privilege level; it also provides page-table randomization functions to mutate page-table entries and evict mapped pages. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[9] MorFuzz uses the starship SoC generator to produce a test harness for the processor under test, including the on-chip interconnect system and a memory model that stores the compiled stimulus template. MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation
[10] In the constrained-random verification methodology, the example design under test (DUT) is a processor supporting the MIPS-I instruction set. Applying Constrained-Random Verification to Microprocessors (EE Times)
[11] The main stimulus for the DUT is a program trace, considered as a collection of one or more instruction scenarios (e.g., a generic boot-code scenario with an exception handler, scenarios that program internal configuration registers to set up hardware watchpoints, and load/store/arithmetic/branch scenarios that may include nested branch loops and randomly introduced exception conditions). Applying Constrained-Random Verification to Microprocessors (EE Times)
[12] Pure random instructions rarely create useful stimulus for the processor to target important design functionalities such as branches/jumps and exceptions; CRV can only create useful stimulus when the stimulus-generation infrastructure is built with enough intelligence about the processor's instruction-set architecture and state, requiring top-down planning. Applying Constrained-Random Verification to Microprocessors (EE Times)
[13] Exception planning for the DUT must cover the occurrence of any one specific exception cause as well as the exception's occurrence probability, and must provide multiple exception conditions simultaneously to test the DUT's exception priority and handling. Applying Constrained-Random Verification to Microprocessors (EE Times)
[14] The CRV methodology models three levels of transaction abstraction for processor verification as SystemVerilog classes — operations, instructions, and instruction scenarios — and implements them in a bottom-up manner. Applying Constrained-Random Verification to Microprocessors (EE Times)