本来以为coverage这件事情很多人会写文章讲，结果在公众号上搜了一圈也没找到几篇，那么今天就和大家聊聊coverage。
早期的验证方法学是通过direct test去保证设计的质量。这个阶段是directed-test driven的，但是随着设计规模和复杂度变大，这种直接测试导向会遗漏掉很多问题。于是验证方法学发展到了第二个阶段coverage driven。
Coverage driven这里的coverage主要有功能覆盖率（function coverage） 和代码覆盖率（code coverage）。功能覆盖率覆盖点(coverage point)和断言覆盖率(assertion coverage)，代码覆盖率分为行覆盖（linecoverage），翻转覆盖（toggle coverage），分支覆盖（branch coverage），条件覆盖（condition coverage），状态机覆盖（FSM coverage）等。这也是目前大部分公司在执行的验证策略。实际 coveragedrive能够覆盖到大部分问题，但是有些可能因为设计有漏掉，然后写function coverage的时候也有漏掉，导致规格书上有些部分没有真正实现。
所以第三代验证方法学推出Metric driven，这种方法学是将验证过程中收集到的coverage数据反标到spec中，从而得到一个可视化的验证结构，保证验证的完备性，目前这种方法学应用还比较少。
验证工程师很大一部分工作在收集coverage，对于80%的coverage我们可能通过几基本的test就能打到，但是剩下的20%会花很长的时间去打。
为此我们需要建立regression的环境，创造随机的test，跑大量的regression去补齐最后20%的部分。
别看只有20%，对于大的设计，去review code 会发现几万行的代码没有打到。所以这个时候靠regression是非常有必要的。但是我们经常会发现一个奇怪的现象，随着coverage的提升，regression能打到的点越来越少。这表现在虽然每周都在进行regression，但是coverage却越涨越慢，甚至到后期都不涨了。一般到这个时候，运气好的话coverage能到了90%了。
接下来将是一个非常痛苦的过程，很多公司的做法就会去review code，如果DV的能力比较强，看懂code自己补test，但是到最后发现还是有补不完的。designer的参与就非常有必要了，designer会帮忙一起review，然后几个轮回的造test跑simulation把coverage补齐。
有时候好不容易把coverage收到99%了，突然designer说要改动一个feature，完蛋，前面的工作又得再走一遍，特别是之前调好了针对某段代码设计的direct test因为时序改变，又得重新调，如果在短时间内，coverage database 没有产生，原来的coverage database 又和现在的设计不匹配，系统推送给projectleader的周报告显示coverage 分数掉下来，被leader追杀那叫一个胆战心惊。
实际上我们跑regression的test大部分都在撞击同一段代码，因此很多test跑2遍和跑100遍的效果是一样，对于没有cover到部分可能要某只test跑几万次才能撞到，这一点也不夸张，当你去看function coverage里面coverage bin被撞到的次数，你就会明显看到这个现象，因此随机的regression不一定是收集coverage的有效方式，有时适当的direct test 更加有帮助。在这方面很多人也在研究，比如让一次regression的结果作为下次regression的输入去约束一些随机值，从而使设计的覆盖率快速收敛。
当然目前也有很多公司采用一些tool去收集coverage，比如用formal去验证某些代码是无法被覆盖到的，这样就省去人力去看，这种方法非常高效。
对于收集coverage这件事情，你们还遇到过什么问题，都有哪些小技巧，欢迎留言讨论。
作者：IC bug 猎人
原文链接：https://mp.weixin.qq.com/s/nm6Io6fYPT6HHVIouJc-vw
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏。
