UVM RAL Checklist

The most common bug is building the predictor but never connecting it to the monitor's analysis port, which silently leaves the mirror on auto prediction so it tracks only the model's own writes and desyncs from anything the DUT does. The setup looks complete — the predictor is created, the map and adapter are set — but without the connection agent.mon.ap.connect(predictor.bus_in), no observed bus traffic reaches the predictor, so the mirror only updates when the model itself issues an operation. That is fine for a plain RW register the testbench owns, which is why those check out and the bug hides. But any register the DUT changes on its own — a read-only status bit the hardware sets, a self-clearing or write-one-to-clear field, a register another master touches — changes without the model issuing anything, so the mirror never sees it and stays stale. Then a mirror check fails because the model's expected value diverges from the DUT, even though the DUT is correct and the bus transfers are correct. The danger is twofold: the false failure wastes debug time chasing a non-bug, and worse, the symmetric case — a register the testbench wrote that the DUT silently failed to update — can pass against a stale-but-matching mirror, hiding a real bug. The fix is to connect the predictor for explicit prediction and to confirm the mirror is synced with a backdoor cross-check. The understanding to convey is the unconnected-predictor silent desync, why DUT-driven registers expose it, and that a check against a stale mirror gives false confidence — which is exactly the RAL bug an interviewer is probing for.

Auto prediction updates the model's mirror from the model's own operations, while explicit prediction updates it from the actual bus traffic observed by a predictor connected to the monitor — and you need explicit whenever a register can change outside the model's own writes. With auto prediction, the register layer assumes each frontdoor operation it issues succeeds as modeled and updates the mirror immediately; it is simple and needs no predictor wiring, but it is blind to any change the model did not initiate. With explicit prediction, a uvm_reg_predictor is connected to the bus monitor's analysis port, observes every transfer including ones the model did not initiate, and updates the mirror from the observed traffic through the adapter's bus2reg. The rule for when you need explicit is any DUT-driven register: a read-only status bit the hardware sets, a self-clearing or write-one-to-clear field, a counter the DUT increments, or any register another master can write — because auto prediction cannot see those changes and the mirror would drift. For a register only the testbench writes, auto prediction tracks it correctly. The trade-off is setup versus completeness: auto is less wiring but only tracks the model's operations, explicit needs the predictor connected but tracks all register activity. In practice most real designs have DUT-driven registers, so explicit prediction with a connected predictor is the standard, and the common mistake is building the predictor but forgetting to connect it, which silently leaves you on auto. The understanding to convey is auto-tracks-model-ops versus explicit-tracks-observed-bus, and that DUT-driven registers require explicit, which shows you understand the RAL prediction internals.

You use frontdoor to verify the real access path and backdoor for fast setup and non-intrusive checks. Frontdoor performs the register operation as a real bus transaction through the adapter and agent, so it exercises the address decode, the access policy, and the bus protocol, consuming real simulation time — you use it when the point is to verify the register is correctly accessible over the bus, which is the access you must do to actually verify register access. Backdoor reads or writes the register directly through its hierarchical path in the DUT, with no bus activity and in zero time — you use it for speed and for setup or checking that is not the object of the test, like initializing many registers instantly before the real test, checking a value without perturbing the bus, or confirming a field changed without a bus read. A powerful idiom combines them: write frontdoor and check backdoor, or vice versa, to confirm the bus path and the actual storage agree. The key discipline is that a test cannot rely solely on backdoor, because backdoor bypasses the access path and therefore does not verify it — a test that only backdoors never confirms the bus can actually access the register, so the real path goes untested. The trade-off is that frontdoor verifies the path but is slow and only as good as the bus model, while backdoor is instant and direct but bypasses the path and depends on correct hierarchical paths in the model. The understanding to convey is frontdoor-verifies-the-path versus backdoor-is-fast-but-bypasses, the cross-check idiom, and the rule that you cannot sign off register access on backdoor alone.

Because the access policy is the model's expectation of how the register behaves, so a policy that does not match the spec makes the model expect the wrong thing and either fails a correct DUT or hides a real bug. Each field's policy — RW, RO, W1C, RC, WO and so on — tells the model what happens on a read and a write: an RW field holds what you write and returns it; a RO field ignores writes and returns what the DUT drives; a W1C field clears the bits you write one to; an RC field clears on read. The model uses the policy to predict the value after an operation and to check reads. If you model a field with the wrong policy, the prediction and the check diverge from the DUT's real behavior. Model a RO status bit as RW, and the model expects your write to stick and the bit to read back what you wrote, so when the DUT correctly ignores the write and returns its own status, the check fails against a correct DUT. Conversely, model a W1C field as plain RW, and the model expects a write to set the bits rather than clear them, so the check can pass or fail in ways that do not reflect the real clear-on-write-one behavior, potentially hiding a bug in that logic. So the policy must be transcribed exactly from the spec, and it is one of the first things to verify in a model. The understanding to convey is that the access policy is the model's behavioral expectation, and a mismatch makes checks meaningless — failing correct hardware or masking real bugs — which is why matching the spec exactly is a must-check model item.

You confirm it with a backdoor cross-check: read a few registers backdoor to get the true DUT values, compare them against the model's mirror, and confirm they agree, which proves the predictor is actually keeping the mirror synced before you trust any frontdoor check. The risk in RAL is that the setup builds and runs but the mirror is silently stale — usually because the predictor was not connected — so a mirror check could fail falsely or pass against a stale value that happens to match. A backdoor read bypasses the model entirely and reads the register's actual storage, so it gives you ground truth independent of the prediction path. Comparing that ground truth to the mirror tells you whether the mirror reflects reality: if they agree, the predictor is updating the mirror; if they diverge with no predictor connection, you have found the silent desync. I would do this especially for DUT-driven registers, since those are where auto prediction silently fails, and during bring-up before any register test is trusted. Beyond the cross-check, I would confirm the predictor is connected to the monitor, the adapter round-trips status, the access policies match the spec, and the addresses are right — but the backdoor-versus-mirror comparison is the single most direct confirmation that the whole chain, model plus adapter plus predictor, is actually keeping the mirror honest. The understanding to convey is the backdoor cross-check as the ground-truth confirmation that prediction works, and that you verify the mirror is synced before trusting checks rather than assuming a building-and-running setup is correct.