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 :

» Plug, Play and Reuse!

Time to talk about module-to-system reuse, a very important topic. If you plan your verification environment properly (using one of the common methodologies in the market today or your own) you’ll be able to easily build a system level...

» UVM Users: Here Are Some Great Tips [Video]

A couple of years ago I wrote here about how the UVM was becoming the next big thing in the verification world.And guess what? I was right. Not that it was too hard to predict... but anyway, the industry has finally standardized on language (SV) and...

» My Story With Certitude

Long time no see. My website has been down for a while (technical issues - web experts contact me if you want to help) but now it's up again. And going through some of my old articles here (well, they're all old, I should probably do something about...

» How To Choose Your Verification Service Provider

If you’re looking for an outsourcing solution for your verification problem then a quick look around will tell you that there are many alternatives out there. The number of verification contractors has grown rapidly over the recent years and today...

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

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.