The DMA's header says that an input word with TLAST before the LEN-th word ends the job early with STATUS.ERR. Does the word that carried the early TLAST go out on the output? The RTL says yes, with TLAST set; the header does not say. Can DONE and ERR be set together? The coverage model once declared it illegal, because the tests always cleared ERR; the RTL allows it, and a scratch run read STATUS = 0x6 (war story 10). Is a GO written while BUSY ignored? The RTL ignores it; the header is silent. Each of these is a decision someone has to make, and none of them is DV's to make alone. How do you get them made, and how do you get designers to act on what you find?
A designer reads the spec to build one implementation; a verification engineer reads it to find every behaviour the implementation could have. That makes DV the team most likely to find ambiguity, and the team with the least authority to resolve it. The way through is not authority but credibility and clarity: questions that are easy to answer, bug reports that are easy to act on, and a record of being right. An editor works with an author this way. The editor cannot rewrite the book, but a precise question ("on page 40 the narrator is in Paris, on page 41 in Rome; which is it?") gets a fast answer and a grateful author.
In a spec review, DV's checklist is about the behaviours a design is most likely to get wrong and a spec most likely to omit. For each register and each interface, ask about reset values, side effects (write-1-to-clear, read-to-clear, triggers), what happens to writes while busy, error behaviour, zero and maximum sizes, concurrent events (a clear and a set on the same cycle), and ordering. On the DMA header that checklist produces exactly the questions in the opening, plus a few more: what COUNT holds after an error, whether LEN = 0 sets DONE (the header says yes, and dma_zero_len_test checks it), and what PSLVERR does to the register state. Every answer becomes a plan row.
A good question is a decision someone can make in two minutes. Structure it so they do not have to reconstruct your context:
Q-07 DONE and ERR both set (STATUS = 0x6)
Observed: after a short packet (ERR) and a second GO without clearing ERR, the next
full job sets DONE while ERR is still 1. Scratch run read STATUS = 0x6.
Spec: silent. The coverage model currently assumes it never happens.
Options: A) legal: ERR is sticky until cleared (current RTL, no change)
B) GO clears ERR (one-line RTL change; firmware loses the old error)
C) GO is refused while ERR is set (RTL change; firmware must clear first)
Recommend: A, and add one spec sentence: "ERR and DONE are independent sticky bits."
Need by: Friday, to fix the coverage model before the next merge.The recommendation matters. Architects are busy, and a question with a proposed answer is usually answered faster than an open one. If they disagree, they will say so, and you have still moved the decision forward.
A designer's first question about any bug report is whether it is real. Answer it before they ask: a one-command repro, the first difference with expected and actual values, the spec sentence, what you ruled out, and the scope. Here is the planted word-6 bug from the mismatch playbook, written up the way a designer wants it:
Title: dma_dut: output word 6 of a job has the wrong XOR key (data path), LEN >= 6
Seen in: dma_smoke_test, dma_rand_test, dma_check_test (RTL built with +define+DMA_BUG_WORD6)
Repro: run.sh dma_tb.sv +UVM_TESTNAME=dma_smoke_test (fails on every seed; 2 min)
First difference: 375 ns, m_axis beat 6 of 8
expected 52c7d685 (input word ^ KEY a5a50f0f, from the observed APB write and input beat)
got ad38297a (= expected with every bit inverted: the word was XORed with ~KEY)
Spec: dma_dut.sv header: "LEN words ... sent to the m_axis output as (word ^ KEY)"
Scope: only word index 5 (the sixth word); words 1-5 and 7-8 match; jobs shorter
than 6 words pass. dma_rand_test fails only on its 10-word job.
Ruled out: the scoreboard: the independent predictor and in-order comparator in
dma_check_test flag the same word (13 matched, 1 mismatched in both).
Waveform: m_tdata, count, key from 355 to 395 ns (attached).Notice what the report does not contain: a guess at the RTL line, or the full log. The designer will find the line in minutes with that report, because it already says "word index 5 only" and "XORed with ~KEY", which points straight at a condition on count.
Schedule cuts are a scope negotiation, not a heroics contest. Rank the plan by risk (new logic, complex interactions, past bug density) and offer what will not be verified in return for the time removed, in writing. Formal proofs for register rules can free simulation time for the data path.
Credibility is your budget. Every bug report that turns out to be a bench bug spends some of it. Triage your own bench first: war story 9's five mismatches looked like a DUT bug, and they were the predictor ignoring a DUT rule. Filed against design, they would have cost a designer a day and made the next report easier to ignore.
Share the goal, not just the finding. "This will show up as a firmware hang at bring-up" moves people more than "assertion a_done_not_busy failed".
Give credit and take blame in public. Designers who see DV thank them for a fast fix, and own its own false alarms, answer DV's next question faster.
It is worth telling war story 9 from the designer's side. A DV engineer runs a scratch test that writes KEY in the middle of a job and gets five SB_MISMATCH errors in both the scoreboard and the comparator. Two checkers agreeing feels like proof, and a bug is filed against the DMA's data path. The designer spends half a day in waveforms before pointing at the header: KEY writes while BUSY are ignored, and the DMA did exactly that. Both checkers shared the same wrong assumption, so their agreement proved nothing. The cost is not only half a day; it is that the next real bug from that DV engineer gets read with suspicion. Before filing, check the expectation against the spec sentence, not against another checker built from the same understanding.
Check that you and they are on the same RTL revision and configuration, and that your repro runs from a clean checkout. Then send the exact command, seed and build defines, the first-difference time and values, and the spec sentence. If their test does not reach the condition (for example, a job shorter than the failing word index), say so: "your test uses LEN 4; the failure needs LEN 6 or more".
You test it, but you also ask. The RTL's behaviour is one implementation, not a decision. Raise it with the spec owner with options (ignored, restart, error) and a recommendation, and mark the plan row provisional until the answer lands in the spec. If you only test the RTL, you lock in whatever the designer happened to write, and firmware may assume something else.
Next: you now have the stories. Telling Your Bug Story turns one of them into an interview answer that holds up under follow-up questions.