I love to see the look on fellow DV engineer's faces when I tell them "bugs screw up my productivity"...
I love to see the look on fellow DV engineer's faces when I tell them "bugs screw up my productivity". It seems that most engineers still see verification in terms of finding bugs. I see DV's task as making sure the chip succeeds -- or at least, if it fails, it's not due to an RTL problem. What do you think? Please leave a comment.
On the surface it may seem that it's a pedantic debate over different sides of the same coin. In practice, however, it's more like night & day. What eclipses bugs? Coverage.
As a sound-bite you could say that coverage focuses on what we want -- bugs on what we don't want. Dig deeper, and the implications are significant.
"bugs" don't differentiate: a goal of going out and "finding bugs" places equal value on all prospective bugs, fatal and minor alike. More importantly: "bugs" are 1) unschedulable and 2) can never tell you when you're done.
A crucial task in ASIC development is schedule. Get to tape-out, so that you can meet the fab's production schedule, so that you can get to market, etc. Bug-related tracking is useless for this endeavor. The worst-case is when the team gets to its maximum bug throughput. (An engineer can handle a few bugs per day at most.) At that point the whole process is open-loop, and a manager has no way of knowing how far along the team is or when the pain will end. Even if all hell doesn't break loose, if all you have to go on is bug-count, how do you know when you're done?
Coverage, on the other hand, never goes open-loop, is inherently schedule-related, and priority-driven. You know you're done when you've covered all the features necessary for customer success.
I confess: I share in the perverse pleasure -- schadenfreude -- of logging a bug against a design. That pleasure quickly fades in the drudgery of moving a bug through the process of logging a repeatable testcase, verifying the fix, and adding the test to the regression heap. (We could have a whole 'nother discussion on the logic behind a fixed-bug-related regression heap.) None of this bug-related activity actually moves us toward the goal of coverage closure. To the extent that my productivity is based on getting the product out the door -- via coverage closure -- bugs indeed screw up my productivity.
If you found this article to be of interest, visit EDA Designline
where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here
to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).