Home Reviews Eternal Sunshine of the Verifier's Mind


Eternal Sunshine of the Verifier's Mind PDF Print E-mail
User Rating: / 6
Wednesday, 03 March 2010 16:39

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 important to keep in mind with everything you do in verification:


Verification vs. Debugging – Verification may be defined as “proving or establishing authenticity or validity” or “evidence that establishes or confirms the accuracy or truth of something”. Perhaps the lexical meaning of the word should account for it, but the verification process sometimes wrongly begins with the premise that the design process delivers a more-or-less working RTL and the verification process is merely there as a safety net just to be a 100% sure that everything is working well. Kind of like Quality Control or something. Experienced verifiers and managers are very unlikely to err here, but others may easily fall into this conceptual pitfall, including many designers and project managers. This kind of premise is not only half true but also quite dangerous. In reality, the RTL design process produces RTL code. That’s it. The verification process produces RTL code that works. And  there’s a big difference.

As a matter of fact, if I had my way, I would split verification into 3 distinct areas – A) VIP Development – that’s the part where verification IP is being developed. This is a pure software engineering effort. B) Simulation – that’s the part where fresh or immature RTL is being simulated and debugged. C) Closure – that’s the part where the RTL is in good shape and regression suites are available to test and cover corner cases. Phase A is pretty much a standalone, self-contained, bounded effort. The other ones (and especially phase B) are totally opposite in nature. Design and Verification during these phases need to work hand in hand. Program the right mindset into your brain – i.e. that verification and design cannot be separated – and you’re on your way to success.


Automation – “Manual verification” or “Features verified by visual inspection” are history. Verification is all about building an automated system that eventually will check your design and find bugs in a push-button fashion. With everything you do in verification, you should keep that thought in mind. Interestingly enough, tool vendors promote automation in different ways, always wanting to take it to the next level (e.g. vManager, VMM Planner, etc.) but many users are not so enthusiastic about going there and prefer to keep it simple. Some of their concerns are valid – fully blown automation requires a significant effort to ramp and might be more suitable for big companies. Nevertheless, even in small teams, keeping automation in mind can do wonders to overall productivity. In these cases, Perl and similar scripting languages can do the job well. Don’t settle for “visual inspection” or “manual testing”. Instead, make your environment smart, make it robust, so that every single test provides a definitive pass/fail indication. Don’t leave holes in your checkers and use scripts to help you in launching and handling simulations. Remember, the most valuable asset is your time – let the machine do the hard and repetitive work.


Safety Nets – Verification is and always will be a matter of redundancy. Why? Because it’s done by humans and holes may exist in any verification layer. Coverage, for instance, is in many ways a safety net that validates and measures the quality of your generation (In the early days, when coverage had not yet been a metric for progress, it was merely used as a feedback on generation). When you’re building a verification environment, keep “safety nets” in the back of your mind. For example, let’s say you have a generic scoreboard that compares each item that comes out of the DUT with the respective item that comes in. If a mismatch occurs, an error is issued. But what if for some reason the input channel to the DUT is blocked in such a way that no items ever enter the scoreboard and nothing ever comes of the DUT? If you don’t have an orthogonal checker that makes sure that at least one item has entered/exited the DUT you might fall into the infamous pitfall of “0 items in, 0 items out, TEST PASSED”. There are, of course, less trivial examples. So what to do? A good methodology (not base class library) should be able to cover up for some user mistakes – for example, sampling coverage from monitors rather than generators will help make sure that the data you’re sampling has really entered the DUT. But safety nets can also be much less sophisticated (albeit not less powerful). For example – In the regression phase, add a script that makes sure that no test has been left untested after a full regression run. Simple, but powerful. Remember, the more safety nets you add, the more confidence you have in your verification system.

More articles :

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

» Another Step Forward For VMM

While the move from 1.0 to 1.1 and its later flavors did not involve a major paradigm shift, VMM1.2 (beta) introduces several fundamentally new concepts that you should be aware of. Some of the new concepts are the natural result of an evolving...

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

» What Makes A Great Verification Team GREAT?

Your tool provider won’t tell you that, nor will those fancy methodology books, but verification is not all about mastering technical skills. True, those will help you very much in your daily work but verification is first and foremost TEAM WORK....

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


0 #1 2010-03-04 08:31
Basic stuff, but well worth saying especially when it's said as neatly as this - should be required reading for anyone starting out on a verification career. Thanks!

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.