Walk me through how you would structure any UVM whiteboard answer in the first two minutes.
WHITEBOARD CHAIN
1. DECLARE interfaces / types / ports you need
2. SKELETON class extends + utils macro + key methods
3. MECHANISM fill one critical method while narrating
4. PITFALL name one bug juniors make on this pattern
5. TEST how you would smoke-test the component1. DECLARE — "I need a txn class, analysis imports, and a compare function."
2. SKELETON — class extends uvm_scoreboard + macro + write_* stubs
3. MECHANISM — implement one write_act or compare() with narration
4. PITFALL — "Juniors often compare before both FIFOs non-empty"
5. TEST — "I'd run one directed seq, check UVM_INFO mismatch count"State what you know: interfaces, txn fields, check type (scoreboard vs checker).
Draw boxes: monitor → analysis → scoreboard — fill one arrow.
Ask clarifying question: in-order vs OOO? reset behavior?
Think aloud — silence reads as confusion.
Use protocol names (APB setup/access) not only signal toggles.
Cite one pitfall unprompted per component.
TIMED DRILL — 10 minutes
2 min DECLARE+SKELETON for any component name interviewer gives
5 min MECHANISM on one method
3 min PITFALL + TESTFramework first — details second.
Pitfall unprompted differentiates senior candidates.
Writing full env before answering the asked component.
Perfect syntax with no narration.