From UVM Simulation to Hardware-in-the-Loop

Teams that build a thorough UVM environment for simulation and then start again for hardware-in-the-loop end up maintaining two descriptions of the same intent. They drift. The simulation environment gains a corner case the HIL environment never learns about, and the two stop being evidence about the same thing.

One idea does most of the work

A test describes what to verify. A transport describes where and how the DUT is reached.

Once those concerns are separated, the reusable part of the environment is larger than it first appears. The transaction item, the sequences built from it, the reference model, the scoreboard, the coverage model, and the tests themselves all describe intent. None of them needs to know whether the device under test is an RTL model in a simulator or a bitstream on a board.

What each backend is responsible for

In the AeroDAS training platform, sim_transport drives SystemVerilog interfaces directly, which is the familiar simulation path. hil_transport calls a compact DPI-C API backed by a C++ runtime that moves transactions to and from an AMD Kria KV260 target. The device under test is synthesizable VHDL-2008, so the simulation flow is a deliberate mixed-language Questa example rather than an incidental one.

• The transport layer owns timing, framing, and the mechanics of reaching the device.
• The test layer owns stimulus intent, expected behaviour, and coverage goals.
• The boundary between them is narrow enough to be reviewed and reasoned about.

Why this matters for design assurance

Verification performed against the implemented device carries different weight from verification performed against a model, and at higher design assurance levels that distinction becomes central. An architecture where the same sequences and the same checking run against both backends lets a team make a clear statement: this is the intent, it was exercised in simulation, and it was exercised again on the target with the same expectations applied.

That is a stronger position than two separately maintained environments that happen to test similar things, and it is considerably cheaper to keep true over the life of a program.

Tradeoffs worth being honest about

• A transport abstraction costs something in directness; debugging crosses one more boundary.
• Not every stimulus is reusable — anything depending on simulator-only visibility stays in simulation.
• HIL throughput and observability differ from simulation, so coverage closure strategies differ even when the coverage model does not.