RAL Interview Set

Part 9 · Register Model (RAL) · Intermediate

On this page

The interviewer has your CV open at built a UVM register model and adapter for a DMA subsystem. The first question is easy: what is the difference between the desired and the mirrored value? The second is the same question one level down: so when exactly does the mirror change in your bench? Then: when your bit-bash failed, how did you know it was the mirror and not the DUT? Three questions in, the interviewer knows whether you used RAL or read about it.

This lesson collects the register-layer questions senior DV interviews ask most, each with a weak answer, a strong answer and the usual follow-ups. Every strong answer leans on something this course ran, and links to the lesson that shows the mechanism.

The idea: interviewers probe mechanism, then evidence

A senior RAL question has three layers, like an onion. The first asks for a definition, which everyone has. The second asks for the mechanism: which call moves which value, which component does it, and when. The third asks for evidence: a failure you saw, the log line that told you, and the fix. Strong answers volunteer the second layer and offer the third before it is asked: name the object that does the work, say when it happens, and give the case where it breaks.

The picture: the follow-up chain for a mirror mismatch

Flowchart: from a mirror mismatch, check whether the field is volatile, whether the expected value is one access stale, whether another master wrote it, whether a DUT rule is unmodelled, and only then call it a DUT bug.

The chain interviewers walk down after 'the mirror check failed'. Each branch is one lesson in this topic; a strong candidate names the check that rules each branch in or out.

Notice where "the DUT is wrong" sits: last. Every RegModel error met while building this course's register layer came from the model or the prediction setup, and the one DUT rule the model lacks (LEN ignored while BUSY) is kept as an expected failure in dma_ral_busy_len_test.

Values and prediction

Interview

1. "What is the difference between the desired value, the mirrored value and the DUT value?" (home: the frontdoor path)

Weak: "Desired is what you want, mirrored is what the model thinks the hardware has."

Strong: "Three copies. The DUT value is in the flops. The mirror is the model's belief, changed only by prediction: from an observed access (explicit predictor), from the model's own access (auto prediction), or by predict(), peek() or a mirror read. The desired value is staged by set() or randomize() and pushed by update(). My bench's dma_ral_busy_len_test makes all three differ: LEN written to 9 while BUSY, mirror 9, DUT 4."

Follow-ups: Which call moves the DUT value without changing the mirror? (none from the frontdoor once prediction runs; a backdoor poke() predicts too, so only traffic outside every predictor does). What does `mirror(UVM_CHECK)` do to the mirror after a mismatch? (updates it to the value read).

Interview

2. "Auto prediction or explicit prediction?" (home: the frontdoor path, built-in sequences)

Weak: "Explicit is better, auto is for simple benches."

Strong: "Auto prediction updates the mirror inside the model's own write() and read(), so it sees only accesses made through the model. Explicit prediction feeds a bus monitor into uvm_reg_predictor, so it sees every access on that bus, from any master; that is the default for anything reusable. Its cost is timing: the mirror changes a moment after the access returns. My bit-bash failed 94 bashes with explicit prediction alone, because it compares against rg.get() straight after write(). Those tests add auto prediction; the predictor stays connected."

Follow-ups: Can both be on? (yes; the bench does it for bit-bash and the busy-LEN test). What does auto prediction miss? (any write not made through the model: firmware, another bus, a raw sequence).

Interview

3. "What is `provides_responses` in the adapter?" (home: the frontdoor path)

Weak: "It says whether the bus has responses."

Strong: "It tells the map where read data and status come back. With 0, the map calls bus2reg on the request item after finish_item, so the driver writes rdata and the error flag into the request, as the bench's APB driver does. With 1, the map waits for a separate response (get_base_response), so the driver must send one with matching IDs. Wrong one way, every read returns stale request data; wrong the other way, the register sequence hangs."

Follow-ups: Where does a slave error become `UVM_NOT_OK`? (in bus2reg, which sets rw.status). Does an errored write update the mirror? (version-dependent with explicit prediction: IEEE 1800.2 skips it with a PREDICT_NOK warning; UVM 1.2 updates it).

Interview

4. "What does `volatile` do to a field?" (home: built-in sequences, interrupts)

Weak: "It means the field can change, so the mirror is not reliable."

Strong: "It sets the field's compare to UVM_NO_CHECK, so mirror and read checks skip it, and reading its mirror warns. The consequences people miss: the reset sequence skipped STATUS and COUNT entirely on my bench, bit-bash skips volatile bits, and needs_update() is always true for a volatile writable field, so update() writes it every time. Volatile is right for hardware-updated fields and wrong as a way to silence a mismatch: it removes the check instead of fixing the model."

Follow-ups: How do you check a volatile counter then? (explicit read and expectation, or an active-mirror backdoor during the job). Volatile or a callback for a double-buffered register? (a callback: keep the check, model the rule).

Access methods and their traps

Interview

6. "What are the traps with `update()`?" (home: interrupts)

Weak: "It writes the desired values to the hardware, one burst for the whole block."

Strong: "It writes each register whose needs_update() is true, one access per register, not a burst. Two traps. A trigger: after ctrl.write(3) the mirror holds GO = 1, so go.set(1); ctrl.update() writes nothing, as a scratch run confirmed. And volatile W1C status always needs an update, and update() writes the inverse of desired for W1C, so a block-level update() wrote 0x6 to STATUS, clearing any pending DONE or ERR. I write triggers and status explicitly."

Follow-ups: How would you make GO work with `update()`? (a callback that sets GO's predicted value back to 0, the trigger's real read value). Is `update()` atomic across fields? (one register access per register; fields in different registers are separate writes).

Interview

7. "How do you model a write-1-to-clear status bit?" (home: access policies and callbacks)

Weak: "As RW, and the predictor clears it when you write 1."

Strong: "With the "W1C" access policy, volatile because hardware sets it. The policy is applied by do_predict, so writing 1 predicts 0 and writing 0 predicts no change, for explicit and auto prediction alike; no custom predictor code. Modelling it as RW is the classic bug: the model then believes a written 1 stays 1. Around it: the ISR reads, decides from the returned value and writes back exactly the bits it read; coverage counts a clear only when the bit was set before the write."

Follow-ups: What does `set(1)` do to a W1C field's desired value? (applies the policy: it stages a clear, not a 1). What policy is a bit that clears when read? ("RC"; and a debug read of it is a side effect, so it needs care in bit-bash and in debug sequences).

Backdoor, built-in sequences and structure

Interview

9. "Which registers do you exclude from bit-bash, and how?" (home: built-in sequences)

Weak: "The read-only ones."

Strong: "Read-only bits are handled by the sequence. I exclude registers whose writes have side effects: CTRL, because a write with GO set starts a job; W1C status, because writes clear live bits; FIFO windows and anything that kicks a state machine. I set NO_REG_BIT_BASH_TEST, or NO_REG_TESTS for every built-in test, in uvm_resource_db under REG:: plus the full name; only the resource's existence matters. And I read the log: bit-bash on COUNT took half the time of LEN because it only bashed the 16 unmodelled upper bits."

Follow-ups: Where must the attribute be set, and when? (scope REG:: plus the full name, before the sequence reaches the register). Why did your bit-bash once fail on nearly every bit? (explicit prediction lag).

Interview

10. "How does your model handle a register written by two masters?" (home: multiple maps)

Weak: "The mirror might be wrong, so we disable checking for those registers."

Strong: "If both masters are buses, the register is in two maps, each with its own sequencer, adapter and predictor, and both predictors update the one mirror. If the second writer is the hardware, the field is volatile or has a callback that models the rule. If it is invisible to the bench (firmware on a CPU model, a JTAG VIP driving pins), I add a monitor and predictor on that path, or document the registers the model cannot track."

Follow-ups: Why one predictor per map? (the predictor decodes with its own map's get_reg_by_offset). What does 'RO' rights in a second map do? (fields are RO through that map; the write is still issued and predicts no change).

What breaks in an interview answer

Reciting the API. "write, read, set, get, update, mirror" proves nothing. Say which value each one moves and when.
"The predictor fixes it." The predictor applies field policies; it cannot know DUT rules (LEN ignored while BUSY) or masters it cannot see.
Silencing instead of modelling. volatile, UVM_NO_CHECK and NO_REG_TESTS are legitimate only with a reason you can state. "It kept failing" is not one.
No evidence. One real log line ("read 4, mirrored 9") is worth more than a paragraph of theory.

Check yourself An interviewer asks: "Your mirror(UVM_CHECK) on LEN fails with read 4, mirrored 9. Walk me through it." Give the first three questions you ask yourself, in order.

Is LEN volatile? No (and if it were, it would not be compared at all). Is the expected value one access stale? Check whether the 9 was written just before and whether prediction had finished; with auto prediction on, it had. Did something else write LEN, or does the DUT have a rule that blocks the write? Here the DUT ignores LEN writes while BUSY, which the model does not know: the mismatch is the model's gap, shown by the bench's busy-LEN test.

Check yourself "Why not just turn auto prediction on everywhere and drop the predictor?"

Because auto prediction sees only accesses made through the register model. Any other writer (firmware, a second bus, a raw sequence, the DUT itself) leaves the mirror stale and the next check fails or, worse, a check passes against a stale value. The explicit predictor watches the bus, so it sees everything on it. Auto prediction is a timing aid for specific tests, added on top.

Next: this is the end of the register topic. Go back to the topic map for any lesson you skimmed, or continue with the course's advanced topics.

Navigate

The idea: interviewers probe mechanism, then evidence

The picture: the follow-up chain for a mirror mismatch

Values and prediction

Access methods and their traps

Backdoor, built-in sequences and structure

What breaks in an interview answer

Related topics

RAL Interview Set

The idea: interviewers probe mechanism, then evidence

The picture: the follow-up chain for a mirror mismatch

Values and prediction

Access methods and their traps

Backdoor, built-in sequences and structure

What breaks in an interview answer

Related topics

The idea: interviewers probe mechanism, then evidence

The picture: the follow-up chain for a mirror mismatch

Values and prediction

Access methods and their traps

Backdoor, built-in sequences and structure

What breaks in an interview answer

Related topics

Up next

The idea: interviewers probe mechanism, then evidence

The picture: the follow-up chain for a mirror mismatch

Values and prediction

Access methods and their traps

Backdoor, built-in sequences and structure

What breaks in an interview answer

Related topics

Up next