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 :

» Ignorance Is A Bliss

There is a rather confusing feature in Specman’s coverage engine that I would like to share with you today. I’ve met several people (including myself) who had been struggling to understand what was going on there and gave up Recently I was...

» Prepare For Your Next Job Interview

Succeeding at job interviews requires practice. If you're applying for a verification job you'd better get yourself well prepared both mentally and technically. Nevertheless, a great deal of tension could be avoided if you knew in advance what sort...

» The Miracle Of Verification

Is verification really a miracle and verifiers have ceased to be engineers? Not too long ago I wrote an 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"....

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

» Verification Consulting, What's Next?

Will the demand for Design and Verification services change? How will Functional Verification look like 3 years from now? Think Verification caught Cristian Amitroaie, AMIQ’s CEO, for a quick chat.

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.