HDL Backdoor Access Routines

RAL Backdoor Access covered peek()/poke() — RAL's backdoor equivalents of read()/write(), resolved through an HDL path configured on a register. Underneath, both resolve to the same small set of primitive routines this page covers directly: uvm_hdl_deposit, uvm_hdl_force, uvm_hdl_force_time, uvm_hdl_release, and uvm_hdl_read. They work the same way, but on any HDL signal reachable by hierarchical path — not just ones wrapped in a uvm_reg, and useful even in testbenches with no register model at all.

The five routines

bit ok;

ok = uvm_hdl_deposit("tb_top.dut.ctrl_q", 32'h1);
ok = uvm_hdl_force("tb_top.dut.status_q", 32'h1);
ok = uvm_hdl_force_time("tb_top.dut.status_q", 32'h1, 100);
ok = uvm_hdl_release("tb_top.dut.status_q");
ok = uvm_hdl_read("tb_top.dut.ctrl_q", value);

Every one of these takes a plain string hierarchical path — the exact same kind of path RAL Backdoor Access's add_hdl_path_slice() configured on a register, just used here directly rather than through a uvm_reg. Each returns a bit success status, and — same theme as uvm_config_db::get() from Resource DB & Config DB — a typo'd path fails silently unless that return value is actually checked.

deposit vs. force: a soft write vs. a hard override

These two are easy to treat as interchangeable, and they aren't:

• uvm_hdl_deposit() is a one-shot procedural assignment — it sets the signal's value once, the same way SystemVerilog's $deposit does, but the very next thing that drives the signal (the DUT's own always block, a continuous assignment, anything) overwrites it on the next evaluation. It doesn't fight for ongoing control of the signal at all.
• uvm_hdl_force() takes hard, ongoing priority over every other driver of that signal — the same effect as a procedural force statement. Once forced, the signal stays pinned at that value regardless of what the DUT's own logic tries to drive onto it, until an explicit uvm_hdl_release() call gives control back.

An unreleased force doesn't just linger — it can hide real bugs

A forced signal cannot show a genuine RTL conflict underneath it — two drivers fighting over the same net, a stuck-at condition, anything — because the force is actively overriding all of that for as long as it's active. Forgetting to release() before continuing normal simulation doesn't just leave a stray override in place; it can make an otherwise-detectable DUT bug invisible for the rest of the run, with nothing in the log to flag that a signal is still being forced.

force_time: force with a built-in expiry

uvm_hdl_force_time("tb_top.dut.status_q", 32'h1, 100);

uvm_hdl_force_time() forces the same way uvm_hdl_force() does, but automatically releases after the given duration (100, in simulation time units, here) — useful for a bounded override (holding a status bit artificially high for exactly one known window) without needing a matching explicit release() call tracked separately elsewhere in the sequence.

read: a non-destructive sample

bit [31:0] value;
uvm_hdl_read("tb_top.dut.ctrl_q", value);

uvm_hdl_read() only samples the signal's current value — it never drives anything, and has no interaction with any active force. It's the routine uvm_reg::peek() calls underneath, the same way uvm_hdl_deposit() is what poke() calls for an unforced backdoor write.

When to reach for these directly instead of RAL's peek()/poke()

RAL's backdoor methods only exist for signals wrapped in a uvm_reg with an HDL path configured. Plenty of useful backdoor targets aren't registers at all — an internal FSM state variable, a scoreboard-adjacent counter, a pipeline stage's contents — and for those, these five routines are the only way in, with no register-model layer to go through first.

What's next

Backdoor access, both through RAL and directly through these primitive routines, is now covered end to end. The next page turns to a different kind of mechanism entirely: the singleton pattern — already used, without being named directly, by custom phases and a couple of other places earlier in this curriculum.