I once found a silicon bug in a protocol spec — not in the RTL
A hardware verification engineer shares a close call from an AXI interconnect project just two weeks before tapeout.
Stock photo for illustration only, not from the actual event
- An AXI interconnect project passed over 500k simulation cycles with code coverage exceeding 98% before DV sign-off.
- A senior architect raised a crucial question about AWLEN wrapping around 256 when AWBURST is INCR.
- The spec classified it as undefined behavior, causing the testbench to skip it while a latent state machine hang hid in the RTL.
- Hardware verification is not about proving the RTL matches the spec, but proving the spec is correct beforehand.
This true story stems from an AXI interconnect project where our slave component was thoroughly verified. We achieved over 500,000 simulation cycles and pushed code coverage past 98%, leading the verification team to sign off just two weeks prior to tapeout.
However, right before the target milestone, a senior architect posed a straightforward question: What happens if AWLEN wraps around 256 when AWBURST is INCR?
Upon reviewing the documentation, that specific scenario was labeled as undefined behavior. Consequently, our testbench entirely skipped those undefined sequences, leaving a latent state machine hang lurking silently within a corner of the RTL code.
"What happens if AWLEN wraps around 256 when AWBURST is INCR?"
Senior Architect
The ordeal provided a profound lesson regarding hardware verification. It is not merely about confirming whether the RTL aligns with the specification, but ensuring the specification itself is entirely sound before any RTL implementation takes place. These two represent completely different engineering challenges.
In hardware engineering, reaching tapeout and sending a design to fabrication carries immense financial stakes and long turnaround times. Catching corner-case logic flaws through critical inquiries prevents costly respins, as standard automated verification tools often miss scenarios dismissed as undefined behavior in early protocol drafts.
Stock photo for illustration only, not from the actual event
Bugs necessitating costly respins typically do not reside within the written code itself. Instead, they hide inside underlying assumptions that nobody ever bothered to challenge. If you work as a verification engineer, your ultimate asset is not mastering UVM frameworks, but knowing which vital questions to ask when spec authors leave blanks.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment