Silicon Talks

  DESIGN VERIFICATION     ARTICLE 04 OF 06 How I debug a failing regression at 2am: my actual process The test name is tc_random_stress_42891. The error is ‘X propagation on bus_data[7]’. The deadline is tomorrow. Here’s what I actually do.   It’s past midnight. The regression that was supposed to be clean isn’t. You have a test name, a seed, a cryptic error message, and a log file that is, conservatively, the length of a short novel. The tape-out review is in nine hours. This is the part of verification nobody talks about in conference papers. The methodology slides show clean flows: stimulus, checking, coverage closure. They don’t show the 2am session where you’re staring at a waveform trying to figure out why a 32-bit bus decided to go X on bit 7 and only bit 7. What follows is my actual process. Not the idealized version. The one I use when I’m tired, under pressure, and the failure is not obvious. Step 0:  Resist the waveform Th...

  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...