Skip to content
STIMSMITH

Device Under Test (DUT)

Concept

In hardware validation, the device under test (DUT) is the specific component or system that a testing framework exercises, observes, and characterizes, while supporting infrastructure isolates, controls, and monitors its execution. The DUT abstraction is used across contexts ranging from integrated-circuit system-level test and generative hardware fuzzing (e.g., GoldenFuzz) to photonic physically unclonable functions.

First seen 6/13/2026
Last seen 6/14/2026
Evidence 9 chunks
Wiki v2

WIKI

Device Under Test (DUT)

The term device under test (DUT) denotes the specific hardware component or system that is the subject of an experimental or validation procedure. It is the target being exercised, observed, and characterized, and is conceptually distinguished from the surrounding infrastructure that drives and instruments it.

Role in System-Level Test of Integrated Circuits

READ FULL ARTICLE →

NEIGHBORHOOD

2 nodes · 1 edges
graph · device under test · depth=1

RELATIONSHIPS

3 connections
GoldenFuzz ← uses 100% 2e
GoldenFuzz targets the Device Under Test in its second fuzzing stage.
Fuzzilicon ← uses 92% 1e
Fuzzilicon's framework isolates the device under test to ensure safe and deterministic execution.
The bare-metal hypervisor-based fuzzing framework isolates and controls the device under test.

CITATIONS

9 sources
9 citations — click to expand
[1] In system-level test (SLT) of integrated circuits, the DUT is the IC whose non-functional properties must be characterized, and there are no systematic approaches for test-program generation targeting these properties. Large Language Models to Generate System-Level Test Programs Targeting Non-functional Properties
[2] GoldenFuzz uses a customized GPT-2-style language model (1.5B parameters, 50,000+ token vocabulary) with a per-opcode/per-operand tokenization scheme for RISC-V that reduces token length by more than half compared with BPE. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[3] GoldenFuzz operates in two stages: GRM fuzzing, where test-case validity is judged by a Golden Reference Model, and DUT fuzzing, where each generated test case is executed on the DUT and hardware coverage from Synopsys VCS is used as feedback. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[4] Each GoldenFuzz test case contains 5 instruction blocks of 6 instructions each, with 80 IBs sampled from the fuzzing memory per iteration to seed generation of 5 new IBs. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[5] Preliminary experiments in GoldenFuzz indicate that around 30 carefully chosen instructions are generally sufficient to detect vulnerabilities, consistent with state-of-the-art hardware fuzzers. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[6] DUT-stage coverage metrics in GoldenFuzz include finite state machine (FSM) coverage, condition coverage, and line coverage. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[7] Mismatches between the GRM and the DUT are characterized by exception details (privilege level, instruction type, register values, exception details), and recurring mismatches are automatically classified to reduce manual analysis. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[8] The GoldenFuzz model is trained for 50,000 epochs at learning rate 1e-6 (~1 hour on one NVIDIA A6000 GPU), with the learning rate lowered to 2e-7 during fuzzing policy refinement for stable fine-tuning. GoldenFuzz: Generative Golden Reference Hardware Fuzzing
[9] In reconfigurable integrated optical interferometer network research, the DUT is a tunable interferometric device containing Mach-Zehnder interferometers evaluated for use as a physically unclonable function (PUF). Reconfigurable Integrated Optical Interferometer Network-Based Physically Unclonable Function