The Miracle Of Verification PDF Print E-mail
User Rating: / 2
Thursday, 24 December 2009 16:47

Is verification really a miracle and verifiers have ceased to be engineers? Not too long ago I wrote an article about some common myths in Verification. Today I would like to talk about a bigger myth which I like to call the "Verification Miracle Myth". Although the acronym suspiciously resembles one of today''s common methodologies, I swear I didn't do it on purpose. So what is the fuss all about?

To anyone other than the people who understand the essence of modern verification, what verifiers exactly do during the course of the project is still a mystery. When verifiers shout "Coverage, Sequences, Constraints, Reuse" at each other, to the typical engineer or manager who isn't part of the verification team this is Gibberish. But, when a complicated bug is found in simulation, the non-verifiers would put on their admiring look and say "Wow, how on earth did you guys do it? We thought that, um.. you know, this state machine was supposed to um...Wow!". It''s the Verification Miracle Myth right there.

The shortcoming of this so-called miracle is the price of explaining why good verification environments are not a matter of witchcraft but rather, the predictable outcome of a serial engineering process from system verification architecture, through chip verification architecture, implementation and debug. Explaining why this process should take up a fair amount of resources is even a bigger challenge.

But what is system verification architecture anyway? Well, it depends and differs from project to project, but generally speaking it''s the overall strategy that tells you how you''re going to verify your chip in the context of its target system. This strategy should tell you what parts of the system should be verified by simulation, what parts should be emulated, what kind of software or firmware verification is required and perhaps the set of protocol-compliance verification measures that should be taken (some might be in simulation of course).

Once we've nailed that one, our focus as verification engineers should be directed to the chip verification architecture which is, in my opinion, the first and foremost engineering challenge in the life of a verification project. It's really where methodology, experience and creativity all converge into one point. At the end of this phase there should be a clear picture of the overall verification environment that is going to be developed, along with a clear definition of the internal components and how they should talk to each other. This is the right place to use all the  magic words - Reuse, Random, Coverage, etc.

And ultimately, there''s the implementation phase where verifiers would be coding their environments and later on hooking up with their DUTs to make the bugs come out.

In the design world you''ll often find a 3-phase engineering process starting at system architecture, chip architecture and then of course, the implementation phase by the RTL designers. The different phases will sometimes fall under the responsibility of different people or even different departments. Things are a bit different in the verification world. Going back to the "Verification Miracle Myth", verification engineers are typically considered as "implementers", much like their counterparts - the RTL designers. The higher level engineering phases in verification such as system verification architecture and chip verification architecture are sometimes mistakenly overlooked at the project planning phase and taken for granted. It''s as if architecting a solid chip verification environment is so straight forward that putting our attention on it would be a waste of time. The "Verification Miracle Myth" would then be reinforced throughout the project by using the term "Testing" rather than "Verification", as if the core engineering effort is the design process, while verifiers are simply there to throw in a bunch of tests towards the end. I would be a sinner if I said that this kind of atmosphere prevails with such intensity at all companies, but at least during my own short career I've seen this mindset in action in several projects at different levels of intensity.

The way I see it, there is no significant difference between design flow (from architecture through implementation) and verification flow (again, from verification architecture through implementation). Whether we like it or not, all chip verification environments have an architecture. How good or bad is it? well, that''s a whole different story. Just because the verification environment serves to simulate and qualify the product and is not the product per-se doesn't mean that it need not be the outcome of a well thought-out engineering process. Verifiers, to the best of my knowledge, have not ceased to be engineers.

The solution I propose is quite simple but very challenging. I believe that the chip design industry should have a better understanding of what functional verification is all about. R&D executives should have more knowledge in verification than they do today. Well, I don''t expect CTO's to start learning e or SystemVerilog, but going forward, I think it''s critical that understanding the essence of verification does not remain the sole interest of verification managers. I would like to see more managers and project leads speak the Verification language, and not only in the sense of buzz words. Why should VLSI managers know all there is to know about Flip-Flops while the term BFM doesn't even ring a bell?

"Knowledge is Power", Francis Bacon once said, and although the more knowledgeable non-verifiers became in Verification the less enjoyable the "Verification Miracle" illusion would be, I guess the power given to them will certainly serve all of us better in future projects.


More articles :

» To Do List 2010

Introducing Philip Americus - a new guest blogger here on Think Verification. Phil is an ASIC veteran who's worked with every phase of ASIC design - from initial concept to tapeout, with an emphasis on verification, including management of both HW...

» Review - Verification Leadership Seminar

How many of you have tried to cut on coffee? or even quit drinking coffee altogether? I guess a lot. Well, personally I’ve given up on trying but you know what? there’s actually something worse than having 8 cups of coffee per day - it’s the...

» Coverage Driven Thoughts

In today’s short post what I’ll try to do is share with you some of the recent trends and ideas that deal with coverage. I won’t go into much technical detail today in order not to wear you (and myself) out, but really - if I want to be more...

» Latest Buzz From The EDA & Verification Community

{loadposition pos101}{loadposition pos102}{loadposition pos103}{loadposition pos104}{loadposition pos105}{loadposition pos106}{loadposition pos107}{loadposition pos108}{loadposition pos109}{loadposition pos110}{loadposition pos111}{loadposition...

» The Cost Of Verification

We spend about one third of our lives in bed, right? doesn’t it make sense then to buy a good bed and not a cheap one? The same can be said for your verification tools as you spend so much of your project time on verification. Buying cheaper tools...

Add comment

Security code

Copyright © 2019 Think Verification - Tips & Insights on ASIC Verification. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.