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.

DUT in MorFuzz's checking flow

MorFuzz observes the DUT during instruction execution and compares its behavior with a simulator/reference execution.

• In the commitment stage, the DUT commits its program counter and the executed instruction.
• After receiving the commit request, the simulator executes the next instruction and checks whether that instruction is consistent with what the DUT committed.
• If the check passes, the simulator records the reference write-back data in a scoreboard.
• In the judgment stage, once the DUT's write-back data is ready, MorFuzz compares the DUT write-back value with the scoreboard's reference value to determine whether the instruction executed correctly.
• If mismatched behavior is detected, MorFuzz reports a potential bug and exits the simulation.

This evidence shows the DUT as the concrete hardware instance whose committed instructions and resulting state are checked online.

DUT state synchronization

The MorFuzz paper notes that not all mismatched differences are bugs. Some differences arise from implementation differences between the DUT and the simulator. If the simulation exits immediately on every mismatch, the DUT loses its accumulated execution state, which makes it harder for fuzzing to reach deep processor states.

To address this, MorFuzz introduces a synchronizable co-simulation approach. The goal is to automatically eliminate legal implementation differences by allowing the DUT to synchronize its state to the reference model/simulator so that execution can continue. The paper gives an example where an instruction accesses a peripheral register that the simulator does not model; MorFuzz analyzes the physical address, treats the difference as legal if appropriate, and synchronizes hardware state to the simulator instead of reporting a bug.

DUT-oriented stimulus structure (MorFuzz)

MorFuzz organizes test generation around hardware functionality of the DUT.

A seed determines:

• the fuzzing execution environment,
• the instruction extensions to test,
• the weights of different testing blocks,
• the random-number seed, and
• the intensity of instruction shuffle.

MorFuzz defines seven testing block types to cover different hardware functional modules of the DUT:

1. integer arithmetic test,
2. floating-point arithmetic test,
3. CSR test,
4. memory operation test,
5. atomic memory operation test,
6. system operation test, and
7. custom extension test.

A control-transfer instruction is placed at the end of each testing block to chain blocks together.

DUT execution environment and harness (MorFuzz)

The supplied evidence also describes the surrounding infrastructure for running the DUT.

The fuzzing execution environment:

• initializes the processor,
• configures available instruction extensions,
• sets the address translation mode and page table,
• sets the runtime privilege level,
• resides in a non-morphable physical area, and
• handles exceptions and interrupts with the highest privilege level.

It also provides interfaces for fuzzing the system environment, including page-table randomization functions that can mutate page-table entries and evict mapped pages.

For the hardware side, 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.

DUT in constrained-random verification (MIPS-I example)

In the CRV methodology described in the EE Times article, the DUT is a processor supporting the MIPS-I instruction set and the verification problem is the typical microprocessor verification challenge: complex instruction sets, multiple pipeline stages, in-order or out-of-order execution, instruction parallelism, fixed- and floating-point scalar/vector operations, and other features that create a seemingly never-ending list of corner cases to exercise.

Stimulus for the DUT.

• The main stimulus for the DUT is a program trace, considered as a collection of one or more instruction scenarios.
• One scenario can be a generic boot code for the processor with an exception handler; another can be a set of instructions to program the processor's internal configuration registers with dynamic contents to set up hardware watchpoints; the remaining scenarios can consist of one or more instructions with load/store, arithmetic, and branch operations, possibly including nested branch loops. Exception conditions can be introduced at random inside these scenarios.

Why simple random stimulus is not enough.

• Pure random instructions rarely create useful stimulus for the processor to target important design functionalities such as branches/jumps and exceptions. The CRV approach can only create useful stimulus when the stimulus-generation infrastructure is built with enough intelligence about the processor's instruction-set architecture and state, which requires top-down planning.

Exception planning for the DUT.

• From a stimulus-generation perspective, planning for a processor's exception conditions must cover the occurrence of any one specific exception cause as well as the exception's occurrence probability.
• The test plan should provide multiple exception conditions simultaneously to test the DUT's exception priority and handling.
• Because these considerations affect the modeling of the properties and constraints between transaction objects, planning must begin early.

Object-oriented stimulus layering for the DUT.

• The article models three levels of transaction abstraction for processor verification as SystemVerilog classes: operations, instructions, and instruction scenarios.
• These classes are implemented in a bottom-up manner, because it is essential to create the lower-level building blocks before raising the level of abstraction to stimulus descriptions.

Scope of this article

Based on the provided evidence alone, the term DUT is documented here in the specific context of:

• MorFuzz's processor fuzzing and co-simulation flow, where the DUT is a processor implementation that is stimulated, monitored, and compared against reference behavior while embedded in a generated hardware harness and fuzzing environment; and
• A constrained-random verification methodology for microprocessors, illustrated with a MIPS-I processor DUT, where the DUT is exercised with a program trace built from operations, instructions, and scenarios.

The evidence supports the DUT as the hardware processor instance being stimulated, monitored, compared against reference behavior, and executed inside a generated harness and configurable verification environment.