By year seven, interviews stop asking how config_db resolves a clash and start asking what you would do: walk me through your testplan, how long would you need, would you buy an AXI VIP, how would you verify this block. Those are judgement questions, and the strongest answers are not lists of best practice. They are a specific bench, specific numbers and specific gaps, told by someone who has seen their own plan fail.
This topic is that conversation, answered with the DMA bench the whole course built. Each lesson takes one decision a senior engineer owns, makes it on the DMA, the two-DMA subsystem and a chip around them, and ends with the answer you would give in the interview. Where an earlier lesson already teaches a mechanism, these lessons link to it rather than repeating it.
Write a testplan from a spec, with IDs, checks, coverage, tests and honest status, and defend it in a review.
Give a bottom-up effort estimate in ranges, hold a risk buffer, and say plainly what gets cut when the schedule shrinks.
Design a block bench that the subsystem and chip teams reuse without editing, and compose it upwards.
Structure configuration across levels, and decide which checks live where when agents go passive.
Decide whether to buy or build verification IP, and qualify whatever you end up with.
Choose simulation, formal, emulation, gate-level or power-aware simulation per block, with the evidence each produces.
Lesson | The question it answers |
|---|---|
Walk me through your testplan. How would a reviewer know it is complete? | |
How long would you need, and what goes first when you get 30% less? | |
What must a block bench deliver so the next level reuses it unchanged? | |
What does each level add that the level below cannot see? | |
How do you keep configuration sane when the same env runs at three levels? | |
When agents stop driving, which scoreboards keep checking? | |
Would you buy or build an AXI VIP, and how would you trust it? | |
How would you verify this block, and what signs it off? |