Eternal Sunshine of the Verifier's Mind Print
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 :

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

» Top 10 Verification Myths

Let’s unveil the truth behind some of the common myths out there!

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

» Let The New Game Begin

Things are changing. The EDA industry is changing, and the verification world is changing (check out Janick Bergeron's inspiring at SNUG San Jose for a glimpse of the future of verification). One of the major challenges we’re already facing today...

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