True story from an AXI interconnect project.
We had a well-verified slave. 500k+ simulation cycles. Code coverage > 98%. The DV team signed off. Tapeout was 2 weeks away.
Then a senior architect asked a simple question: "What happens if AWLEN wraps around 256 when AWBURST is INCR?"
The spec said it was "undefined behavior." Our testbench skipped undefined sequences. The RTL had a latent state machine hang hiding in that corner.
We caught it. Others don't.
What I learned: Verification is not about proving the RTL matches the spec. It's about proving the spec is correct before the RTL implements it. These are two completely different problems.
The bugs that cause respins aren't usually in the code. They're in the assumptions nobody thought to question.
If you're a verification engineer reading this — your most valuable skill isn't knowing UVM. It's knowing which questions to ask that your spec author forgot to answer.
Hashtags: #HardwareVerification #ASIC #AXI #ChipDesign #Tapeout #SystemVerilog #SiliconEngineering
Top comments (1)
"The testbench skipped undefined sequences based on the spec's guidance" is the sentence that should scare people, because it means your coverage number was measured inside the spec. 98% of what the spec said existed. The undefined region isn't low coverage — it's outside the coordinate system the metric is drawn on, so it can't show up as a gap no matter how long you simulate.
I hit a much smaller version of this in a much cheaper domain. I build internal tools as a non-developer, and I seeded my static security scanner with ten known-bad patterns to verify it could actually see — caught seven, wrote rules for the rest, felt done. The limit took me longer to notice: I can only plant flaws I already know are flaws. The seeds are drawn from my own model of what can go wrong, so the test proves the scanner matches my spec, exactly like your testbench proving RTL matches a spec nobody had audited. Every category I've never heard of has a permanent, invisible 100% pass rate.
Which is why the architect's question is the part I'd emphasize over the process. Nothing in 500K cycles produced that question; a person holding the spec at arm's length did. I don't have an architect, so the closest substitute I've found is publishing what I built and letting strangers ask the equivalent — and the two most expensive holes in my setup this year were both found that way, by people who never saw the code and just questioned an assumption in the description. Different scale entirely, same mechanism: the assumption nobody thought to question stays unquestioned until someone outside the frame reads it.