My friend Coverage turned into a revolutionary. We live in tumultuous times so this may not come as a surprise but seeing my friend pacing up and down the room, threatening imaginary adversaries was unnerving so I had to get to the bottom of it. What could possible turn my mild mannered friend into a raging firebrand? Once he settled down a bit, things started to clear up. Turns out that for a while now, people have been turning a blind eye on those last few percent of coverage holes as long as they did not belonged to the elite of cover targets, those that always need to be properly taken care of. “Even if there’s a bug in that area, we can always come up with a workaround or fix it in software” people would say, and who can blame them? Deadline pressures are not for the faint of heart and 2%-3% of obscure coverage targets are not going to stand in the way of tape-out bliss, right? Well, it turns out that with the relentless increase of design sizes and complexity and the worrisome shortening of the verification cycle, the number of second class coverage targets has swollen, their voice has become louder and they now threaten the verification establishment. It is ever more likely that continuing to ignore an increasing number of coverage holes will eventually lead to a silicon bug for which no quick ECO or software fix will be available and disaster will strike.
There are many of them these days. They used to be multi-millionaires but you know how these things go. Now, before you get too excited to find out the latest scoop on the yacht sailing, private jet flying, Davos skiing crowd, remember that I don’t typically hang out with Larry, Steve or Mark, I hang out with my friend Coverage. So this is not about the folks on the cover of Forbes Magazine, it’s about our favorite chips and the billion transistors they pack these days. More precisely it’s about verifying that a billion switches turning on and off, somehow harmoniously join forces to perform billions of instructions per second, transfer the proverbial Library of Congress across the country in minutes or make your picture on the iPad look better than the reality. How do we make sure that these ever growing billionaires do what they’re supposed to without collapsing under the enormous amount of verification data they generate?
The other day I listened in while my friend Coverage told the neighborhood kids the Thanksgiving story. It went something like this. Once upon a time the verification engineers in the Old World design houses were not free to practice verification the way they wanted. Instead, they had to follow a strict directed test methodology imposed to them by long standing traditions. One day a group of them gathered a few of their test benches, boarded a chartered bus they called “Randflower” and left to join a new company where they could practice their own verification methodology rooted in the principles of freedom. From then on verification engineers would be free to write coverage targets based on verification plans written in a language that everybody could understand and even testbench variables would be free to take whatever values they wanted as long as they were following some constraints. However, the road to success was not to be an easy one. They had to work long hours, come up with new methodologies and tools to take advantage of them. The long nights and weekends of hard work soon started taking their toll. Many of them quit and moved to the software industry and those who stayed turned weak with frustration and exhaustion. But then one day a miracle happened. The indigenous designers in the company who had been working there for many years gathered together and shared their knowledge about the design with the verification engineers! This gave them the strength required to close on the remaining coverage targets and finally the fruits of their hard work were ready to be harvested. The verification engineers had a huge Tape-Out Feast where all the designers were invited to jointly celebrate the Turnkey Verification Environment they developed and thank their design counterparts for their invaluable help in their hour of need. They vowed that from then on they will write testbenches that can be easily shared among many verification groups and that they will share methodologies and best-practices for the benefit of the entire verification community.
You may remember the suggestive metaphor of a butterfly flapping its wings in California and causing a tornado on the other side of the globe. No, I am not attempting to apply chaos theory to coverage (although… ;-)), I am merely picking up where I left off last time and make a case that the various parts that collectively define the coverage problem are tightly connected and that the decisions we take for each part will inevitably have a profound effect on the others. Let’s take a look at some of these connections and the potential pitfalls if we ignore them.
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.