Whiteboard rounds test working RTL habits under time pressure. Each lesson below is one realistic question with a model answer, follow-ups, and the mistakes that separate strong candidates.
5 lessons, about 25 min
The interviewer grades the reasoning path: interface first, flags before pointers, guards before optimization, and a test plan. The reviewer grades the same habits in the finished code.
The whole topic on one page, taken from each lesson's Remember box. Read it before an interview, or print it.
Whiteboard: a synchronous FIFO
State the interface first. Occupancy equals accepted pushes minus accepted pops since reset.
Accept a push only when not full and a pop only when not empty. When full, a simultaneous pop is accepted and the push is refused.
Keep a counter, or add one pointer bit, to tell full from empty. Guard DEPTH = 1 when computing the pointer width.
Rule of thumb: never derive both flags from bare pointer equality.
Whiteboard: a priority mux
Always carry a valid flag with the index. Valid means some request is active.
A loop from the high index down lets the lowest active request overwrite last, so it wins.
Select the data in the same block as the index, so grant and data cannot disagree.
Rule of thumb: one priority decision drives every output.
An RTL review in 30 minutes
Work outside in: interfaces, control, reset and clocks, datapath timing, verification hooks.
Report one line per defect: location, trigger condition and consequence, then the fix and the check that closes it.
Flag only what changes function, timing or debuggability, and say the rest was skimmed.
Rule of thumb: a finding without a trigger is only a suspicion.
Framing area, speed and power trade-offs
State which of area, speed or power wins when they conflict, before offering options.
Directions are hypotheses to measure, under the same workload, target and corner. Do not quote gains from memory.
More pipeline cycles do not always raise elapsed latency. A shorter period can recover it if stages were unbalanced.
Rule of thumb: priority first, options second, pick third, then name what would change it.
What senior answers sound like
Order: the one-sentence mechanism, then the options and the pick, then what would prove it.
Evidence is the sharpest separator. Name trade-offs and evidence together.
Say plainly where your knowledge ends, reason from the mechanism, and propose the check that settles the rest.
Rule of thumb: a verdict without a trigger carries no weight.
Mini project: the capstone: a resilient streaming peripheral, stage by stage
Practice question: Synchronous FIFO with full and empty flags
Practice question: Synchronous FIFO RTL design (blocking on full and empty)
Code lab: Synchronous FIFO (4 entries)
Practice question: Priority encoder with parameterised width and valid output
Code lab: 4:2 priority encoder
Interview: run a mock interview on this topic