You take over DV for the two-DMA subsystem: five engineers, the block bench, the subsystem bench, the register layer and the interrupt agent. The nightly regression is 82% green. You ask who is looking at the red 18%, and three people each say they looked at "their" part, while two failure signatures have been in the log for nine days without a ticket. Nobody is lazy; the work is simply not assigned. What structure makes every failure, every plan row and every piece of the bench somebody's job?
A team of good engineers still drops work when ownership is shared, because each person reasonably assumes someone closer to the problem has it. The fix is boring and effective: every item that can go wrong has exactly one named owner, and everything that arrives without an owner goes to one person whose job this week is to assign it. A hospital ward works this way. Each patient has a named nurse, and a rotating on-call doctor takes whatever arrives at 3 a.m. Nobody asks "who is looking at bed 4?"
In DV there are three kinds of things to own: plan rows (does feature X get verified?), bench code (is the APB agent correct?) and regression results (why did last night's run fail?). They need different owners, because the person who knows the interrupt feature is not always the person who wrote the interrupt agent.
Model | Owner of | Works well when | Fails when |
|---|---|---|---|
By block | Everything for one block: plan, bench, results | Blocks are independent and benches are separate | Subsystem and chip benches share agents; nobody owns the seams |
By feature | Plan rows for one feature, across benches | Features cross blocks (interrupts, reset, power) | Nobody owns the shared bench code the features use |
By component | One agent, the scoreboard, the register model | The bench is large and reused | Nobody owns the question "is feature X verified?" |
Most teams that work well use two at once: features own the plan, components own the code. On the DMA team that might read: one engineer owns the data path and TLAST (plan rows len=*, tlast=*), one owns registers and interrupts (clear=*, irq_en=*, the register layer tests), one owns reset and backpressure; separately, each agent, the scoreboard, the predictor and the register model has a code owner who reviews every change to it. The plan-item tally that dma_coverage prints already uses plan names, which makes "who owns gap=0?" a question with an answer.
One person per week reads the nightly, buckets failures by first-error signature (the triage lesson builds the script), and makes sure every new signature has a ticket and an owner by the end of the day.
The rotation assigns; it does not fix everything. A rotation that must fix every failure becomes a punishment and is skipped. Its output is a short note: new signatures, owners, anything blocking.
Everyone rotates, including the lead and the newest engineer (shadowed for the first week). Triage is the fastest way to learn the whole bench.
A failure nobody can classify goes to the feature owner, not back into the pool. "Unclear" is a category with an owner, not a reason to wait.
A new engineer becomes useful fastest by running, breaking and extending the real bench in small steps, each with a log to show. On the DMA bench a first week could be:
Day | Task | Evidence they bring back |
|---|---|---|
1 | Run | "8 words matched" and what each number means |
2 | Build with | The first-error line and the word index, before opening a waveform |
3 | Add a TLAST check to the scoreboard as a factory override | A run under the TLAST fault showing |
4 | Shadow the triage rotation for one nightly | Their own bucket list, compared with the rotation's |
5 | Close one plan hole ( | The tally line with the hole gone |
By Friday they have touched the scoreboard, the factory, the plan and the regression, each through a change someone reviewed. That is better onboarding than a week of reading documents, and it also tests the bench: day 3 is exactly the TLAST check whose absence let the fault campaign miss fault 7.
The regression itself needs an owner: someone who keeps the test list, seeds, run time and farm usage healthy. The dashboard is how the team and its managers see the state without asking. Keep it to numbers people act on, each with its denominator; Metrics and Sign-off explains how each metric misleads.
Pass rate with the denominator, trended: "58 of 61 runs", not "95%".
Open failure signatures with age and owner. Age is the number that shows dropped work; nine days with no owner should be impossible to miss.
Plan items hit in the merged result, by feature owner.
Bug find rate plotted against regression volume, so a shrinking nightly is not mistaken for a converging design.
The course's own sign-off sheet has a line that shows the failure mode: the plain build crashed 0 of 20 times, the coverage build 8 of 20. On a team without a regression owner, that line is everyone's and therefore no one's. The person running coverage reruns the crashed seeds; the person who wrote the coverage model assumes the farm team knows; the farm team has never heard of it. Weeks later, someone notices the merged coverage comes from twelve runs instead of twenty, which quietly changed which plan items look covered. Assigning it on day one (a ticket, an owner, a rule that sign-off numbers come only from complete runs) costs ten minutes.
The triage person assigns it, and the natural first owner is the feature owner for the data path, who decides whether it is a DUT bug or a bench bug. If it is the scoreboard's fault, it moves to the scoreboard's code owner. Both roles are legitimate; the rule that prevents a stand-off is that the first assignment is explicit and named.
Because the log already says everything needed: the first SB_MISMATCH line gives the time, the expected and actual words and, from the time, the word index. Learning to read the log first is the habit that makes triage fast; a waveform is for confirming a hypothesis, not for starting one.
The open signatures and their ages: 2% of a large nightly can be several distinct failures, one of them untouched for a week. Then the regression volume next to the find rate, and whether any waivers or demotions were added recently, since both can raise a pass rate without anything getting better.
Next: ownership decides who looks at the code. Code Review and Mentoring decides what they look for.