Choosing the Right Access Method

Chapter 4 · Section 4.5 · Accessing Registers

1. Why Should I Learn This?

Every access bug you have seen in this chapter came from choosing the wrong method for the intent, and the reason those bugs are so common is that the methods are individually simple but easy to reach for by habit or by name. predict sounds like it programs; set feels complete; the backdoor is fast and tempting. A framework that starts from what you are trying to do — not from which method is convenient — is what turns the toolbox into reliable choices.

Learning to pick by intent lets you avoid the whole family of wrong-method failures, and — most importantly — to never let convenience (the fast backdoor, the no-bus predict) quietly replace the verification the test was supposed to perform. The single highest-stakes version of that is using the backdoor where the frontdoor was needed, because the backdoor works while verifying nothing about the bus.

2. Industry Story — the configuration path nobody exercised

A test's job is to verify that a peripheral can be configured over the bus — that software writing its CFG register actually lands and takes effect. The engineer, wanting the test to run fast and reliably, uses a backdoor poke to set CFG, then checks that the block behaves accordingly. The test passes, quickly, every time.

But the configuration interface — the bus write path that software actually uses to program CFG — was never exercised, because the poke went straight to the flip-flops through the backdoor, bypassing the adapter, the address decode, and the bus handshake entirely. When a later bug breaks the CFG register's address decode (a wrong offset in the RTL), the backdoor-based test keeps passing, because the backdoor does not care about addresses or decode — it pokes the storage directly. Software in the field cannot configure the block, a failure the test existed specifically to catch, and it ships. The post-mortem is stark: the test's goal was to verify the frontdoor configuration path, and it used a backdoor access, which verifies the storage exists but not that the bus can reach it. The lesson: choose the method by the test's goal, not its convenience — if the goal is to verify that software can reach a register over the bus, the access must be frontdoor, because the backdoor proves nothing about the protocol it bypasses.

3. Concept — the two questions, and the intent-to-method map

Any register operation is chosen by answering two questions in order:

• Question 1 — hardware or model? Do you want to change/observe the DUT, or only the model? Model-only operations (set for desired, predict for the mirror) drive no bus and change no hardware — use them to stage intent or record an out-of-band change. Everything else touches the DUT.
• Question 2 (if hardware) — does the bus protocol matter? If you are verifying that software can reach the register — programming it, checking it responds correctly, exercising the interface — the protocol matters and you must go frontdoor (write/read/update/mirror), because only the frontdoor drives the real bus. If the bus is merely in the way — you need a deep state fast, or to sample without side effects — the protocol does not matter and the backdoor (poke/peek) is the right, faster tool.

Mapping intents to methods:

• Program the DUT (verify it can be programmed) — write() or set()+update(), frontdoor.
• Verify the DUT matches an expectation — read() (auto-check) or mirror(UVM_CHECK), frontdoor.
• Reach a hard/deep state cheaply (bus not the point) — poke(), backdoor.
• Sample a register without side effects (observe non-destructively) — peek(), backdoor.
• Stage intent in the model — set() (desired), no bus.
• Record an out-of-band change (after a backdoor poke, a hardware event) — predict() (mirror), no bus.

Here is the decision as a guide from intent to method:

4. Mental Model — pick by goal, and never let convenience replace verification

5. Working Example — the same register, five intents, five methods

One CFG register, accessed five ways, each chosen by intent:

uvm_status_e s;  logic [31:0] got;
 
// 1. Program the DUT (and verify it CAN be programmed over the bus) -> frontdoor write.
cfg.write(s, 32'h0000_0013);            // exercises the real config path
 
// 2. Verify the DUT matches expectation -> frontdoor read (auto-check vs mirror).
cfg.read(s, got);                        // proves the read path returns the right value
 
// 3. Reach a hard state fast (bus not the point) -> backdoor poke.
count.poke(s, 32'hFFFF_FFFE);            // force a near-rollover count; no bus cycles
 
// 4. Sample without side effects -> backdoor peek.
event_count.peek(s, got);                // read an RC counter without clearing it
 
// 5. Touch only the model -> set() (stage) or predict() (record out-of-band change).
cfg.mode.set(2'd2);                      // stage intent; drives nothing until update()
void'(count.predict(32'hFFFF_FFFE));     // record the poked value in the mirror

The methods are not interchangeable; each is the right tool for one intent. Crucially, step 1 uses the frontdoor precisely because its goal includes verifying the configuration path — swapping it for a poke would make it faster and blind. The next section is exactly that swap.

6. Debugging Session — a backdoor where the frontdoor was the point

// The test's GOAL: verify software can configure the block over the bus (the CFG write path).
// It uses a BACKDOOR poke 'for speed and reliability':
cfg.poke(s, 32'h0000_0013);        // BUG: bypasses the adapter, address decode, and handshake
check_block_behaves_as_configured();
// The block behaves configured (the flops were poked), so the test PASSES —
// but the bus write path that software uses was never exercised.

7. Common Mistakes

• Backdoor where the frontdoor was the point. A poke/peek in a step meant to verify the bus proves the storage exists, not that software can reach it.
• predict/set where write was meant. Model-only APIs never program the DUT (4.2, 4.4).
• Frontdoor where the backdoor was the sensible tool. Driving hundreds of cycles to reach a state a poke could set instantly — slow, and not verifying anything by the length of the drive.
• Choosing by convenience or habit. Reaching for the fast/easy method instead of the one the goal requires.
• Not asking whether a step is setup or verification. The answer decides backdoor vs frontdoor as much as the two questions do.

8. Industry Best Practices

• Choose by intent, in two questions. Hardware or model? If hardware, does the protocol matter? — frontdoor when it does, backdoor when the bus is in the way.
• Verify the interface only through the frontdoor. Any step proving software can reach a register must drive the real bus.
• Use the backdoor for setup and non-destructive sampling. Reach hard states with poke, observe side-effecting registers with peek.
• Apply the review test. 'Would this pass if the bus path were broken?' — if yes on a verification step, it is the wrong method.
• Keep model-only APIs (set/predict) out of hardware-changing roles. They stage intent and record beliefs; they never program the DUT.

9. Interview / Review Questions

10. Key Takeaways

• Choose a register access method by intent, using two questions: touch the hardware or only the model?, and if the hardware, does the bus protocol matter?
• Model-only intents use set() (desired) or predict() (mirror); hardware-with-protocol uses the frontdoor (write/read/update/mirror); hardware-without-protocol uses the backdoor (poke/peek).
• The overriding rule: if the goal is to verify software can reach a register, the access must be frontdoor — the backdoor bypasses the bus it would need to verify.
• The signature bug is a backdoor access in a verification step: it passes even when the bus path is broken, so it tests the storage, not the interface.
• The review test — 'would this pass if the bus path were broken?' — catches a backdoor doing a frontdoor job; distinguish setup steps (backdoor is fine) from verification steps (frontdoor required).