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...

» About UVM And You

There’s been a lot of buzz about the lately and for a reason. The Universal Verification Methodology is about to change the rules of the game pretty soon, if not already. That is interesting because not too long ago verification engineers...

» Get Organized Even On Windows

Here’s a cool (and free) application that can make your life a bit more organized if you tend to have many open windows.

» Is ABV Becoming Mainstream?

Is Assertion-Based Verification (ABV) becoming mainstream? This question popped up today at Mentor’s ABV . Assertions in general and ABV in particular make another approach that you can use to verify your design. Usually ABV alone is not...

» Eternal Sunshine of the Verifier's Mind

To be successful in verification you not only need to possess the right technical skills, but you also need to possess the right mindset. Possessing the right mindset will lead you to success rapidly. Here are 3 things that I’ve found very...

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.