Well, there isn’t one. But, understanding the three laws of verification can help you understand how to optimize your current verification methodology.

(See The First Law of Verification, The Second Law, The Third Law)

The first law says that no matter what methodology is used, verification will be the bottleneck in getting the project completed. The third law tells us that different methods may find the same bug at different points in the verification process. The second law tells us that the same bug may be easier or harder to find depending on the methodology used and the person doing the verification. Based on these observations, we can synthesize a methodology that optimizes verification efficiency:

1. Parallelize the verification effort.
   • have multiple people working independently.
   • have multiple simulations or other automated verification tools running simultaneously.
2. Minimize overlap between parallel efforts.
   • have different people verify different aspects of the design.
   • orchestrate verification automation tools to minimize duplicated effort.
3. Use as many different methodologies as possible.
   • get as many different points of view as possible.
   • minimize the possibility that a bug that is hard to find with one methodology will slip through.
4. Evaluate the efficiency of each methodology used.
   • efficiency = bugs found/effort put in.
   • put more effort into those methodologies with highest efficiency.
5. Start as soon as possible.
   • the first law says you will find bugs at the beginning no matter what you do.
   • the sooner you start, the sooner you fill finish.

Most projects naturally follow the first two guidelines. The next three guidelines come from insight gained in understanding the three laws of verification. The subjective nature of bug hardness means that using a single methodology, even if parallelized, increases the chances of relatively simple bugs slipping through the verification process. The way to overcome this is to use as many different methodologies as possible. The downside to this is that each methodology has development cost associated with it. Therefore, there is a tradeoff between development effort and the number of different methodologies that can be deployed. Generally, smaller teams will end up using fewer different methodologies due to resource constraints and larger teams will be able to use more.

It is important to evaluate methodologies used in order to improve the overall verification process for future projects. You need to be careful here. Don’t throw away all methodologies except for the one that is most efficient. You will have lost the advantage of using different methodologies. If you do decide to remove a methodology because it is not finding bugs, try to replace it with another unique methodology rather than just putting more effort on fewer methodologies. Putting more effort on fewer methodologies just increases the risks of bugs slipping through.

As an example, here are efficiencies of the different methodologies used on the MCU project:

Method	Bugs Found	Effort (Man-Months)	Bugs/Man-Month
code review	44	2	21.0
static checks+unit testing	31	13	2.4
full chip directed testing	70	38	1.8
regression+perturbation	12	9	1.3
coverage improvement	3	4	0.8
assertions	3	4	0.7
full chip random+algorithmic tests	5	8	0.6
emulation	3	28	0.1
overall	171	106	1.6

Based on this data, I would probably look seriously at dropping emulation in the next project.

But, these numbers can be deceiving. Unlike bug hardness, bug finding efficiency does vary with time. This is a big topic, so I will save it for its own post.