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