Posted by Alex Seibulescu on August 17, 2010
Guess I should start with a disclaimer: I don’t know much about risk management. If I did, I would start an investment outfit call it “Golden Socks”. “Golden Socks” would capitalize on the universal dream of software ownership, help fuel a software bubble and get you to buy software you cannot afford. At the same time “Golden Socks” would bet that you won’t be able to pay maintenance for your software and have to give it back. Or something like that.
My friend Coverage on the other hand, he is an expert. Many people whose responsibility is to decide when enough verification is, well, enough verification, call upon his expertise to help them out. You see, some people would have you believe that verification is all about finding as many bugs as possible. And of course they are right but with one rather important refinement. It’s about finding as many bugs as possible before the time is up. And therein lies the problem. “To tape out or not to tape out: that is the question”, has been driving princes and managers mad ever since Hamlet moved into verification.
If your business is to provide IP for a customer and you’re late, you may find that somebody else is eating at the customer’s table. If you’re in time but there’s smoke coming out of the smoke test you may find yourself in need of a smoke (wait, talk to the Surgeon General first). If you’re in the systems business and you control the IPs, the SoC, the board, the firmware, the apps, etc. it is the market window that controls your destiny and you can ill afford to miss it. If you make it but end up having to recall your chips because a functional bug slipped through, uhh, head hunters may become your new best friends.
Everybody knows there are still bugs, nobody knows how many, is there anybody who can help? Yup, you got it, it’s my friend Coverage. Now mind you, he’s not going to be able to tell you whether you’re ready to send your chip to the backend folks but he’s going to give you one quantifiable dimension into the complex risk management decision you’re facing. If IP is your cup of tea and you properly developed your coverage model and correctly mapped coverage targets to features, the kind of coverage targets you’re hitting should tell you whether the main functionality of your IP is taken care of. You send it to the customer and by the time they get to shine the light in one of its un-covered corners, you’ll have another rev ready with a hopefully decimated bug population in that corner. You made the deadline, the customer is happy. If systems is the name of your game, chances are you won’t get too many shots at getting it right. You need a much more comprehensive coverage model tailored for the block and system level verification and need to prioritize your coverage with a lot more care. If your final coverage results looks like Swiss cheese but it mainly comes from IPs you’ve used to tape out before or otherwise trust, you may turn a blind eye and let it slide. However, if the smell of Swiss cheese comes from your own carefully crafted targets built around fresh code it may be worthwhile biting the bullet and delay tape out cause something may be rotten in Denmark. Bottom line, the risk equation will be different for different applications but coverage will still be one of the main factors you should take into account.
There’s obviously no free pass and there are various other factors to consider but if you thought your coverage model through and if you’ve interpreted your coverage data correctly, you have a powerful tool to gauge your risk. My friend will become yours too.
"Coverage is by now pervasive in most verification flows but has in the modest opinion of this blogger, yet to reach its full potential. Although I have spent most of my 18 years in EDA (ouch!) on the R&D side, I have always been a good listener to our customers' concerns. My hope is that this blog will be an informal venue for all of us to explore how to push the benefits of Coverage and related methodologies to new levels" —Alex Seibulescu