Backdoor Permissions and Simulator Setup

Permission model for backdoor access

Backdoor relies on simulator infrastructure that can inspect and modify HDL variables at runtime. If visibility is optimized away, path access fails even when model metadata is correct.

[HDL] backdoor permission stack

  RAL model has valid path definitions
      |
      v
  UVM HDL package available (uvm_hdl_*)
      |
      v
  simulator build keeps hierarchical visibility
      |
      v
  runtime switches allow VPI/DPI access
      |
      v
  testbench process has access to targeted scope

• Backdoor is a simulator capability problem as much as a RAL problem.

• Aggressive optimization settings often remove required debug visibility.

• Treat simulator flags as part of your verification configuration contract.

DPI and visibility requirements

Most UVM implementations use a C bridge for HDL access APIs. Build and run commands must include required shared libraries and signal visibility options.

[UVM][HDL] requirements checklist

  compile:
    - UVM package with HDL access support enabled
    - DPI/VPI bridge objects linked
    - no optimization that removes targeted register nets/vars

  run:
    - visibility enabled for hierarchical reads/writes
    - optional debug database if triage required

# Generic pseudo-commands (flags vary by simulator/version)

# Build
sim_compile \
  -f filelist.f \
  +define+UVM_NO_DEPRECATED \
  <enable_uvm_dpi_and_visibility_flags>

# Run
sim_run \
  +UVM_TESTNAME=reg_access_test \
  +UVM_VERBOSITY=UVM_LOW \
  <enable_hierarchical_access_flags>

• Use a shared run wrapper so all engineers get consistent backdoor behavior.

• Version-control simulator switch sets by tool version.

• Log effective flags in regression artifacts for reproducibility.

Simulator flag examples

Exact switches are tool-specific. Keep examples in infra scripts and verify against your simulator manuals.

[SIM] common categories (tool-specific names differ)

  category A: preserve hierarchy / signal accessibility
  category B: enable VPI/VHPI/DPI callbacks
  category C: load UVM DPI shared library
  category D: waveform/debug visibility for triage

  Validate category coverage, not just one single switch.

# Example style only - not universal syntax

# VCS-like style
vcs -sverilog -ntb_opts uvm -debug_access+all -kdb -lca ...
./simv +UVM_TESTNAME=bd_smoke

# Questa-like style
vlog -sv +acc ...
vsim -sv_lib dpi -c work.tb_top -do "run -all"

# Xcelium-like style
xrun -uvm -access +rwc -sv_lib dpi ...

[HDL] warning signs of missing permissions

  uvm_hdl_read returns 0/fail
  path not found errors on known-good hierarchy
  backdoor reads constant X/Z unexpectedly
  backdoor writes appear to succeed but DUT value unchanged

Security and governance

Backdoor is powerful and can bypass realistic software access constraints. Use it intentionally and keep auditability in regulated or safety-critical environments.

[REG] governance recommendations

  classify tests:
    - setup backdoor allowed
    - signoff proof must include frontdoor evidence

  require logs:
    - register, value, path, reason for backdoor write

  review process:
    - code review checks for unjustified backdoor-only assertions
    - CI policy gates for signoff suites

function void bd_audit(string reg_name, uvm_reg_data_t value, string reason);
  `uvm_info(
    "BD_AUDIT",
    $sformatf("reg=%s value=0x%08h reason=%s", reg_name, value, reason),
    UVM_MEDIUM
  )
endfunction

Key takeaways

• Backdoor success requires simulator visibility plus proper UVM HDL plumbing.

• Treat simulator flags and libraries as controlled infrastructure, not ad-hoc shell tweaks.

• Use backdoor with audit discipline to preserve verification evidence quality.

Common pitfalls

• Assuming path errors imply model bug when simulator visibility is disabled.

• Using undocumented local flags that regressions cannot reproduce.

• Allowing backdoor-only signoff claims without frontdoor corroboration.