Home Articles Main Verification Documents - Love Them, Hate Them, But You Can't Ignore Them

Search

Verification Documents - Love Them, Hate Them, But You Can't Ignore Them PDF Print E-mail
User Rating: / 1
PoorBest 
Thursday, 24 December 2009 15:42

Verification Plan (or Test Plan) and Coverage Plan are two documents that specify the features to be tested in the verification process. The first document usually lists the DUT features that need to be covered and the latter - the coverage points that need to be collected. A third document that usually accompanies these two is called the VE Description Document (or Verification Spec or Whatever-They-Call-It-At-Your-Company Document).


So the purpose of preparing the Verification/Test Plan and Coverage Plan documents is quite self-explanatory. What’s a bit more fluid here is the VE Description document which is not only fuzzy in definition but also harder to write due to lack of clear requirements across the industry. Yet, more often than not you’ll be asked to prepare one, and put it up for review. Ouch!

 

So why do we need to go through the the trouble of writing that document in the first place? Well, it seems reasonable that as soon as you start the verification process, you should be able to write down and explain what you’re going to do and how you’re going to do it (hopefully everybody is beyond the why you’re doing it part). You need to describe the elements of the verification environments, the topology, special verification techniques that are used, guidelines on how to reuse the VE (Verification Environment) at higher levels, etc. These are the explicit (and quite obvious) aspects.

The implicit aspects are more interesting. Politically, the VE Document is up for review by a number of people, usually very experienced engineers or managers, and that’s their only chance to get a glimpse of what a verification environment really is. That’s also their chance to criticize everything they hear. Another implicit reason is that it helps you spot in advance areas that are going to be difficult to verify. And on top of that, maybe most importantly, it gives you a couple of more days to play with ideas, plan and think about your verification mission from a bird’s-eye view. Kind of like your last chance to do that before you take a deep dive down into the coding realm.

Let’s pause now and talk about people (which verification engineers are considered to be a subset of) and two types of characters. The first one represents people who find it really easy to plan ahead and only then start working. The other one represents people who need to get started with something before they can get a clear vision and plan ahead.

I’m not an expert in Psychology but if there is no solid theory about this don’t call me Yaron. So given the vague requirements for the VE Description document (sometimes the requirement is merely to have such a document somewhere in the database regardless of its content), reckless verification engineers might feel slightly confused and will eventually go with their natural tendency - those who find it easier to plan everything ahead will write a long document with a lot of text and tons of details. They might go as far as listing all methods and field names in the document. And those who need to get a little dirt on their hands before they can get a clear vision will write a very short document with a simple block diagram, and an extremely short textual description to support it. So who’s right?

Assuming you’re not working under extreme pressure (crazy start-up) it is worth it to prepare a well thought-out VE Description document. On the other hand, unless you have a hidden agenda in your documents (VIP vendor) then putting too much focus on your VE document might be wasteful because a) features will change several times before Sign-off and b) extra time spent writing documents means less work gets done.
So what are the Do’s and Don’ts for writing your VE Description document? Send in your opinions

 

 
More articles :

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

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

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

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

» Who Wants To Be A Verifier?

Are you looking for a job in verification? Are you pursuing a career in verification? Congratulations! There a few things you might want to consider about your prospective employer before you sign the contract. In today's important article we'll try...

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.