Verification engineers should think as species and not as individuals

This blog post was inspired by movie Interstellar. Where Dr.Brand considering the duration of inter galactic travel says:  “We must reach far beyond our own lifespans. We must think not as individuals but as a species. We must confront the reality of interstellar travel.”

This is becoming true for the functional verification. Read through as to why.

Time spent on functional verification is ever growing. It will continue to grow in direct proportion to complexity of the designs. To maintain the flexibility for software and to increase the utility of the ASICs, their programmability and configurability has also been on the rise. Some configurable parameters such as multiple data rates supported on high-speed serial bus can directly double the verification space having to run all the tests at different data rates.

With rise in the complexity to make the economics work the lifespan of the complex ASICs has to be extended. This is achieved by doing innovation on few key-differentiating blocks of ASIC and doing incremental updates to rest of the blocks the ASIC. These incremental updates to rest of the blocks could be supporting latest version of standard specifications or bug fixes or minor enhancements.

Functional verification of the blocks undergoing incremental enhancement can become extremely challenging. One might raise eyebrows on this statement. Why does block that has minor changes is a functional verification challenge?

This can become challenging if the verification plan and architecture documentation of the test bench is absent.

Forget all the fancy documentation, sometimes even the basic verification plan containing, test plan, coverage plan and assertion plan are missing. There isn’t any documentation on the test bench architecture. Price has to be paid now.

Along with increase in lifespan of many blocks their complexity continues to accumulate. Take for instance high speed serial interface IPs such as USBx, PCI express which are celebrating decades connecting peripherals with multiple generation of operational speeds.

This longer duration of survival of IP and its verification environment invariably leads to hand off between the verification engineers. These hand offs could be both due to internal and external attrition of engineers.

These hand offs cannot effectively happen unless and until at least there is good verification plan and test bench architecture document.

Without clean hands offs either lack or excessive verification can result:

• Even for incremental updates the backward compatibility needs to be verified. In order to achieve that a good verification plan to spot the list of the tests that are affected and needs re-run becomes important. In the absence of such verification plan there can be resulting redundancy by rewriting of same tests
• Verification engineers are paranoid by nature. They would rather do additional redundant verification over risk of leaving unverified piece of logic. This is additional effort leading to slip in schedules or bloated team
• There can be reverse effects where the incomplete test title and description might convey more than what it’s doing. This can result in leaving holes in the verification

So considering the long duration of the functional verification cycles and hand offs the verification engineer can no longer think as individuals. Verification engineers must think of as species. First step in doing so is writing good verification plans and test bench architecture guides.