Posted by Alex Seibulescu on September 1, 2010
I once had lunch with the CEO of a start-up and asked him what skills he thought I needed to acquire if I wanted to run my own company. He quickly replied I needed to understand Marketing. Now if you come from the Engineering side of our world as I do, your reaction is probably similar to mine at the time: “What?” I thought, “is getting ready for DAC really that important??”. In case this is indeed what you’re thinking, here are 2 must-reads: “Marketing High Technology” by William Davidow and “Crossing the Chasm” by Geoffrey Moore. It turns out that there is a lot more to Marketing than meets the ignorant eye. Among the many interesting concepts, the one that stuck with me is called in one way or another, “The Whole Product”. Its beauty lies, as it often does, in its simplicity, and goes something like this: real success comes from delivering to the market a Whole Product and not just a piece of technology. It is pretty common sense, you don’t just put out a chip or a piece of software and hope somebody will figure out what to do with them, you either build (or make sure somebody else does) complete systems around the chip or integrate your software within existing flows, you strike alliances with other software and/or hardware providers, you build a support infrastructure, delivery channels, prepare documents, trainings, etc. etc. You get the idea and if you don’t, try typing iPhone in your search bar.
So what does all this marketing insight have to do with my friend, you may wonder. Well first, I’d like to convince you that he is not just some superficial dude and that there’s a lot more complexity to his character. Understanding this complexity and its implications will be the key to your friendship and the first step is to realize that you cannot only look at the coverage hole problem, you need to tackle the whole coverage problem. To understand what makes the whole, let’s try to identify its parts.
First, there’s obviously the coverage model. We really want to cover every single path through the design but if we advocate that we risk referral for psychiatric treatment so we need to find some meaningful proxies instead. Various forms of code coverage along with thoughtfully considered functional coverage tailored to one’s specific requirements will have to do for now.
Second, there’s checking the correctness of the implementation. After all the main purpose of verification is to make sure that the implementation matches the specification so whether you use assertions, scoreboards, whatever, there must be a way to infer a pass/fail outcome. Many would argue that this has nothing to do with coverage but to me that’s like touring the country with a blindfold, what good is it that you’ve visited all the landmarks?
Third, there’s interpretation of the coverage results. This is about how to extract useful information out of an ocean of data and presenting it in a form conducive to analysis. Different ways of filtering, projecting, highlighting and customizing the coverage reports are a good start.
Fourth, there’s folding the insight you gained from the coverage results into the overall risk equation of your project (check out my previous blog). This will require you to figure out which uncovered parts of the design constitute a manageable risk and which need to be addressed. May the Force be with you!
Finally, there’s coverage convergence. Random constrained simulation will get you 80% of the way but chances are you won’t hit all your coverage targets and you’re going to have to do some heavy lifting for the ones you didn’t. Understanding how the random variables control the signals sampled in your functional coverage or the branch conditions in your code is of course the key but that may require a brain fusion procedure among various verification and design engineers.
So far I haven’t probably told you something you didn’t already know in some form or the other but what I hope to convince you is that all these elements are tightly connected and that you will have to carefully consider their dependencies in order to solve the whole coverage problem. In the next blog, I’ll take a crack at analyzing these connections and how they affect your coverage planning. For now, keep in mind that just as a whole product strategy is key to marketing success, a whole coverage strategy is key to verification success!
"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