Ten days before a senior DV onsite, most engineers do the same thing: they open a list of "top 100 UVM questions" and start memorising answers. The first interviewer asks what an objection is, and the answer comes out perfectly. Then they ask the follow-up: your test passed, but the last word never reached the scoreboard. Walk me through why. The memorised list has nothing for that, because the follow-up is about a bench you have built and broken, not about a definition.
This course is built for the follow-up. This page explains how each lesson is put together, which order to read them in, and how to fit the course around the other practice material on the site, whether you have two weeks or two months.
A senior interview is a design review in disguise. The interviewer gives you a situation, watches how you reason about it, then pushes on the weakest part of your answer. A good design review has a fixed agenda so nobody wastes time working out where they are; the lessons here work the same way. Once you know the shape, you can skim the parts you already own and slow down on the parts that will be probed.
Block | What it gives you | How to use it |
|---|---|---|
Hook | A failing regression, a false pass or an interviewer's follow-up | Try to answer the closing question before reading on |
The idea | Why the mechanism exists, with one everyday analogy | This is the sentence you open an interview answer with |
The picture | One diagram that carries the mechanism | Redraw it from memory: interviewers ask for whiteboards |
Build it | Code added to the DMA bench, one step at a time | Type it, do not just read it |
Watch it run | The real log, annotated | Learn what correct looks like so a wrong log jumps out |
What breaks | A war story: symptom, log, root cause, fix | Your raw material for "tell me about a hard bug" |
Interview corner | The question, a weak answer, a strong answer, two follow-ups | Say the strong answer out loud and time it |
Check yourself | Two or three scenario questions with reasoning | Answer before opening; a wrong guess is the most useful one |
Next | The problem the next lesson solves | Stop here if you are short of time; the thread picks up cleanly |
The "What breaks" and "Interview corner" blocks carry the most interview weight. A strong senior answer almost always has the same three parts: the mechanism in one sentence, a failure you have seen, and the rule you now follow because of it. The lessons are written so that each one hands you all three.
Reading in order works because every part adds to one testbench, the DMA bench described in The DMA you will verify. Jumping to a topic also works, because every lesson names the bench parts it builds on and links back to where they were introduced. If you jump, read Your first UVM testbench first: it is the map every later lesson assumes.
The sprint assumes about 90 minutes on weekdays and three hours on weekend days. It goes deep on the topics that decide most senior DV loops (end of test, the sequence-driver handshake, agents, scoreboards and debugging) and skims the rest.
Days | Read closely | Then practise |
|---|---|---|
1–2 | Start here; Your first UVM testbench; Testbench architecture | Run the DMA bench on EDA Playground and break it once |
3–4 | Phases, especially objections and end of test | Explain the drain test from memory in two minutes |
5–6 | Write a driver loop and a sequence body without notes | |
7–8 | Sketch a scoreboard for the DMA on paper, then compare | |
9–10 | Register layer, skimmed; Senior debug playbooks | Two timed coding drills |
11–12 | The interview corners of every lesson you read | One full mock interview, recorded |
13–14 | Your weakest two topics again | Rest the day before |
The deep pass reads every lesson in order, roughly one part a week, and builds each lesson's code into your own copy of the bench. By the end you will have extended the bench with backpressure, a register model and new tests, which gives you concrete stories that no question list can supply.
Week | Parts | Your bench at the end of the week |
|---|---|---|
1 | Start here, Foundations | The base bench running, plus one bug you injected and caught |
2 | Phases | A clean end of test and a timeout you can explain |
3 | Factory and config, TLM | A config object and an override that injects a fault |
4 | Sequences | A virtual sequence that programs a job and streams its data |
5 | Agents, Env and test | Backpressure on the output, a reset-aware driver |
6 | Checking | A predictor and an end-of-test check you trust |
7 | Register layer | A register model with an adapter and predictor |
8 | Advanced, Senior | A testplan for the DMA and your three best war stories |
This course teaches the mechanisms and the reasoning. Two other parts of DenseChip train the delivery, and they work best alongside it rather than instead of it.
[UVM coding practice](uvm/coding-practice) holds timed drills (a driver loop, a scoreboard FIFO, a config_db path, a factory override) and full mock interviews that run 45 to 90 minutes. Use a drill the day after you read the matching lesson: recall a day later is what makes it stick.
[DV interview puzzles](dv-interview-puzzles) covers randomization and constraint puzzles, SVA puzzles and scenario-debug puzzles. Those are the questions that test SystemVerilog fluency under time pressure, which this course assumes rather than teaches.
[SystemVerilog Verification](systemverilog) is the place to refresh classes, constraints, clocking blocks and covergroups if a lesson leans on something you have not used in a while.
Interviewers describe this candidate often enough that it is worth telling as a composite. An engineer with eight years of experience prepares for a staff-level loop by reading three UVM books end to end. They know every phase name and every config_db rule. In the scoreboard round they are asked why a test passed with one word missing. They describe objections correctly, then stall: they have never watched a test end while data was still inside the DUT, so they cannot connect the definition to the symptom. The feedback reads "strong knowledge, could not apply it".
The fix was not more reading. It was running a bench, breaking it on purpose, and reading the logs. That is why every lesson here has a "What breaks" block with a real log, and why the drain test in the DMA bench exists at all. When you study, spend at least a third of your time with a simulator open.
Spend days 1–2 on the first-testbench lesson as planned (it is the map), then move most of the agents time to Phases and Checking, because end of test is a phases-plus-scoreboard problem: who holds the objection, and how the scoreboard knows that nothing is still owed. Keep one short session on agents to confirm you can still explain active and passive builds.
Committing to an answer first shows you what you actually believe. If your guess is wrong, the lesson corrects a specific misconception instead of adding one more fact you half-agree with, and the correction is far more likely to stick in an interview.
The reasoning behind the code: why the driver calls item_done() with no argument, why a monitor creates a new object every transfer, what happens when the code is wrong. Drills train speed on the happy path; senior interviews push on failure modes, which is what the lessons' "What breaks" blocks cover.
Next: every lesson verifies the same design, so before writing any UVM, read The DMA you will verify the way a verification engineer reads a spec.