ASIC Point Explore

← Design Verification Interviews

Interview Question · Concept

Frontdoor vs Backdoor Register Access

L1 JuniorL2 Mid-Leveluvmralbackdoor

The interviewer asks

What is the difference between a frontdoor and a backdoor register access? When would you use each?

Reveal the Model Answer

A frontdoor access runs a real bus transfer through the adapter and the agent. It takes clock cycles and tests the bus decode and the register logic. A backdoor access reads or writes the register storage directly, in zero time. Use the frontdoor to verify the registers themselves. Use the backdoor to set up state quickly, or to check a value without disturbing the bus.

Frontdoor and Backdoor Reach the Same StorageArrows are calls or transfers, labelled with what crosses them. The frontdoor goes through the map, the adapter and the APB driver. The backdoor goes from the register straight to the design's variables.
Frontdoor and backdoor reach the same storageArrows are calls or transfers, labelled with what crosses them. The frontdoor goes through the map, the adapter and the APB driver. The backdoor goes from the register straight to the design's variables. component Test Calls read, peek, pokeor write onregs.count model regs.count Register model: mirrorand access policy RC component map +apb_adapter Address 0x0C; buildsan apb_item component APB driver Setup and accessphase, 30 ns component incr_backdoor read_func and writeuse hierarchicalreferences design tb.dut.count The design's storage;a bus read clears it register callUVM_FRONTDOORapb_itemAPB transferUVM_BACKDOOR,peek, pokereads or assigns thevariable
  1. 60 ns: peek

    peek calls the backdoor's read_func, which returns tb.dut.count = 3. No transfer and no side effect; the mirror records 3.

    Follow the calls, values and waits
    1. call peek(st, v): Test → regs.count
    2. call peek(st, v): regs.count → incr_backdoor
    3. return count = 3 (variable read): tb.dut.count → incr_backdoor
    4. return count = 3 (variable read): incr_backdoor → regs.count
    5. return count = 3 (variable read): regs.count → Test
  2. 70 ns: frontdoor read

    The map sends an APB read of 0x0C to the driver, which puts it on the pins.

    Follow the calls, values and waits
    1. call read(st, v), frontdoor: Test → regs.count
    2. call read(st, v), frontdoor: regs.count → map + apb_adapter
    3. data apb_item: read 0x0C: map + apb_adapter → APB driver
    4. data apb_item: read 0x0C: APB driver → tb.dut.count
    5. Waiting: Test — inside read() until 90 ns
  3. 85 ns: the design answers

    The design returns 3 and clears COUNT at 85 ns.

    Follow the calls, values and waits
    1. return prdata = 3: tb.dut.count → APB driver
  4. 90 ns: the read returns

    The 3 travels back through the driver and the map. The access policy is RC, so the mirror predicts 0.

    Follow the calls, values and waits
    1. return prdata = 3: APB driver → map + apb_adapter
    2. return v = 3, mirror predicts 0: map + apb_adapter → regs.count
    3. return v = 3, mirror predicts 0: regs.count → Test
    4. Released: Test
  5. 130 ns: backdoor read

    The model reads 2 through the backdoor, sees the RC policy and writes 0 back through the same backdoor, imitating the bus. The mirror keeps the 2 it read.

    Follow the calls, values and waits
    1. call read(st, v, UVM_BACKDOOR): Test → regs.count
    2. call read(st, v, UVM_BACKDOOR): regs.count → incr_backdoor
    3. return count = 2 (variable read): tb.dut.count → incr_backdoor
    4. data count = 0 (RC write-back): incr_backdoor → tb.dut.count
    5. return count = 2 (variable read): incr_backdoor → regs.count
    6. return count = 2 (variable read): regs.count → Test
  6. Both routes update one mirror

    Each route ends by predicting the same register's mirror, but not always to the value now stored. After the frontdoor read the mirror is 0, like the design; after the backdoor read it is the 2 that was read, while the design holds 0.

Read the diagram as text
  • Test: Calls read, peek, poke or write on regs.count
  • regs.count: Register model: mirror and access policy RC
  • map + apb_adapter: Address 0x0C; builds an apb_item
  • APB driver: Setup and access phase, 30 ns
  • incr_backdoor: read_func and write use hierarchical references
  • tb.dut.count: The design's storage; a bus read clears it
  • Test → regs.count: register call
  • regs.count → map + apb_adapter: UVM_FRONTDOOR
  • map + apb_adapter → APB driver: apb_item
  • APB driver → tb.dut.count: APB transfer
  • regs.count → incr_backdoor: UVM_BACKDOOR, peek, poke
  • incr_backdoor → tb.dut.count: reads or assigns the variable

The route decides whether the design sees an access, and which value the mirror records. The register object is the same either way.

Frontdoor

regs.ctrl.write(status, 8'h5a);

Bus cycles; tests decode, byte lanes and side effects

Backdoor

regs.ctrl.poke(status, 8'h5a);

Zero time; touches only the storage

Self-Check

Tick each key point you covered in your answer.

What Interviewers Listen For (Junior)

A good junior answer names one thing a backdoor cannot test, such as address decode. It also names one place where the backdoor saves time.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

What IfProve ItBreak ItCompareScale It

  1. Frontdoor vs Backdoor Register Access
  2. CompareHow Each Door Updates the MirrorL2 Mid-Level

    Compare how the mirror is updated after a frontdoor access and after a backdoor access.

    Reveal the Model Answer

    A backdoor access always updates the mirror, because the model knows the exact value it deposited or read. A frontdoor access updates it only through auto-prediction or through a predictor watching the bus. So a frontdoor write with neither one leaves the mirror stale.

    Self-Check

    Tick each key point you covered in your answer.

  3. What IfDid the Write Land in the Right Register?L1 JuniorL2 Mid-Level

    What if a frontdoor write seems to work, but you suspect it went to the wrong register?

    Reveal the Model Answer

    Write through the frontdoor, then peek() the intended register through the backdoor. Peek its neighbours too. If the value landed somewhere else, the address decode is wrong. The built-in uvm_reg_access_seq does this for every register: it writes one way and reads the other.

    Self-Check

    Tick each key point you covered in your answer.

  4. Break ItA Backdoor That Reads the Wrong SignalL2 Mid-Level

    How can a backdoor check pass while the register is broken?

    Reveal the Model Answer

    Say the HDL path points at the wrong signal, such as the next-state value instead of the flop. The backdoor then reads what it expects. uvm_reg_mem_hdl_paths_seq only checks that each path exists. A wrong path that exists still passes it. Only a frontdoor and backdoor comparison, such as the access test, catches it.

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "The HDL path sequence proves the backdoor is right."

    It checks that the path can be accessed, not that it names the register's storage. An existing but wrong signal passes.

    Source uvm-core 2020.3.1 (IEEE 1800.2 library) source, reg/sequences/uvm_reg_mem_hdl_paths_seq.svh (uvm_hdl_check_path)

  5. Scale ItBackdoor Paths in Gate-Level SimulationL3 Senior

    Scale it: what happens to backdoor paths when the same tests run on the gate-level netlist?

    Reveal the Model Answer

    Synthesis renames, flattens or merges register signals, so the RTL paths no longer exist. Teams either keep a second path map for the netlist, under its own HDL path kind, or use only the frontdoor there. Plan this before the netlist arrives, because a broken backdoor makes many tests fail at once.

    Self-Check

    Tick each key point you covered in your answer.

  6. Prove ItSolve U14.2.1: The Overflow Flag That Would Not Stay SetSimulator-graded

    Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

    Open Problem U14.2.1

What People Get Wrong

Common wrong answers and why they fail.

Misconception

"A backdoor write behaves exactly like a bus write."

It deposits bits into the storage. Logic that reacts to a bus write, such as starting a transfer, never runs. The model can apply a field policy, but the design never sees a write.

Source Verification Academy, UVM Cookbook, Registers: frontdoor and backdoor trade-offs (PDF p362)

Half-Truth

"Use the backdoor everywhere; it is faster."

Then the bus path is never tested. A wrong address decode or byte lane passes every test, because no test used them.

Tool as Truth

"A backdoor works the same on every simulator."

The default backdoor uses the simulator's HDL access routines. Some tools lack them or need switches. On this site's Verilator runner they are stubs, so lesson U14.1 writes its own backdoor class.

Source Lesson U14.1 review claims: uvm_hdl_deposit and uvm_hdl_read are stubbed on the Verilator runner

Learn It, Then Prove It