为什么必须做功能覆盖率？and How ？

为什么是功能覆盖率？现在的主流的验证语言是systemverilog，其特点之一就是约束下的随机。相比较定向测试，它的验证效率更高，定向测试需要对每个功能点，每个测试维度去构造不同的用例测试，只能是想多少测多少，激励空间是已知的。而随机化的验证，其激励空间要大的多，远远大于定向测试的激励空间。定向测试好处是每个用例测试激励明确，只要测试通过了，用例的目标也就达成了，而随机化的验证问题是测试激励不明确，虽然它的激励空间更大，但是怎样知道用例执行完成后，覆盖到了哪些激励空间，没有覆盖到哪些激励空间呢？所以需要一个衡量标准，这就是功能覆盖率。

怎样做功能覆盖率？
需求！需求！需求！重要的事情说三遍，经过提取、整理和评审一致通过的验证需求，是做功能覆盖率的依据，要保证每个需求的充分验证，有哪些点必须验证到，这个是必须具体化、量化的，想不清楚这个问题就是没有真正理解需求，验证质量又如何保证呢。
Systemverilog语言对于功能覆盖率有很好的支持，其中覆盖点和交叉覆盖的概念非常重要。覆盖点对应的是上面提到的量化后的需求，这只是点，多个点就是一条线，是一个维度的覆盖；一个设计诸多功能并不是完全孤立的，所以单单验证一个点、一条线远远的不够的，交叉覆盖率就是来把这些点、线连接起来，织成了一张网。通过这张网把所有需求囊括其中。
基于功能覆盖率驱动的验证：有被动驱动和主动驱动两种。
所谓被动驱动，有点“马后炮”的嫌疑，在用例执行完成后，通过查看覆盖率报告来对未覆盖到的点补充定向用例覆盖；而主动驱动，是在用例执行过程中，以功能覆盖率100%或预期的百分比作为退出条件，否则会一直进行随机测试，“不达目的誓不罢休”。
所谓行百里者半九十，做随机化验证也存在着越临近终点，需要付出的更多，因为越到最后随机重复的概率越大，随机成千上万次可能才能有一个新覆盖点，命中率越来越低。针对这个问题，如果采用主动驱动方法，可以提前筛选掉重复的随机，只采用对覆盖率有贡献的随机值，将命中率提高到100%。
但被动驱动方法也有其优势，覆盖组是对所有用例的随机进行采样，而主动驱动是针对单一用例来实现的。通过诸多项目经验来看，首推主动驱动方法，效率更高。
结论
理解清楚验证需求，具体量化验证需求，用功能覆盖率编织的一张大网，把所有的覆盖点一网打尽，采用主动、被动驱动方法做到攻守兼备，让验证工作更加高质、高效。