Silicon Talks

  DESIGN VERIFICATION   ·   ARTICLE 03 OF 06 Coverage closure isn’t done when the number hits 100% Your functional coverage report says 100%. Your manager wants to tape out. You’re not sleeping well. Here’s why — and what to do about it.   Coverage closure is one of the most misunderstood milestones in design verification. Not because the concept is complicated — measure what you’ve tested, keep going until you’ve tested enough — but because the number that represents it, the percentage on a dashboard, is far easier to trust than it deserves. I’ve seen projects tape out with 100% functional coverage and come back from the fab with silicon bugs that were, in retrospect, entirely predictable. Not because the simulation didn’t run. Because the coverage model didn’t ask the right questions. This article is about the difference between coverage that is complete and coverage that is correct. It’s also about the sign-off criteria that are actually worth defe...

  DESIGN VERIFICATION   ·   ARTICLE 02 OF 06 UVM anti-patterns I see in almost every new project UVM is powerful. It’s also one of the easiest frameworks to misuse in ways that quietly destroy your testbench maintainability for years.   Let me describe a project I’ve seen more than once. A new block arrives for verification. The schedule is tight. A DV engineer — competent, experienced, and under pressure — copies an agent from the last project, renames a few things, and gets to work. Three months later, the testbench is running regressions. Six months later, a second engineer joins and finds the code nearly impossible to follow. A year later, when the next chip revision requires reuse, it turns out the testbench can’t be integrated without a near-complete rewrite. This is not a story about bad engineers. It’s a story about the UVM anti-patterns that appear when the framework’s flexibility — its strength — is used without a shared set of conventions. ...