Home Reviews The Miracle Of Verification

Search

The Miracle Of Verification PDF Print E-mail
User Rating: / 2
PoorBest 
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 :

» We Hear Ya!

 During the last months we conducted a poll about what you guys would you like to read more about on ThinkVerification and here are the results: Verification Methodology - 41%SystemVerilog Tutorials - 31%e Tutorials - 13%Interviews - 12%...

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

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

» Debug Like The Pro's

You’ve developed a verification environment, hooked up the DUT, written a bunch of tests and alas! Simulations start to fail So just before you dive in, Think Verification’s tips department recommends the following:

» Progressive Coverage

Progressive Coverage is a method of coverage collection that’s highly applicable in communication devices, but may as well be applied elsewhere. Now before I start to babble about my philosophy on coverage collection why don't I just give you an...

Add comment


Security code
Refresh

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