源自：芯司机公众号
作为一家正式的公司，布置任务都会有相对比较规范的流程和验收标准，那么作为数字IC设计流程中重要一环的数字验证，它的验收标准又是怎样的呢？做到什么程度才算完成任务了呢？本文结合了部分IC设计公司的数字验证验收标准，形成一个相对统一的sign off验收标准。
数字验证，在大多数IC设计公司里面都会分成IP level，system/fullchip level和gate level，我们分别来看一下三个层次的验收标准。
ONE IP level
1. 最基本的要求就是所有的测试用例全部pass。每个case最好都能在波形中肉眼仔细检查过一遍，避免验证环境中的checker没写全出现假过的情况。
2. 回归测试regression错误率持续收敛，直到regression的结果保持稳定两周以上，不会出现random的随机错误了。关于regression，每家公司的标准可能不大一样，有些公司是建比较少的case，然后跑几万甚至几十万遍；有些公司是建很多的direct case，跑的次数就少很多。这个取决于每家公司的验证策略。
3. 验证覆盖率coverage
coverage主要包括code coverage，functioncoverage，assetioncoverage等。每家公司的要求不尽相同。有些小公司可能根本就没有coverage这个指标；有些只关注code coverage，比如其中line coverage要求95%以上，有些要求100%。功能覆盖率function coverage也是重要指标，有些公司虽然不做function coverage的统计，但是会对照详细的feature list创建足够多的测试用例来间接保证功能覆盖率。
4. 验证spec的最后review
verificationspec都需要做最后的review，需要叫上尽可能多的相关人员，包括designer，架构工程师，甚至系统工程师，软件工程师等；最大限度保证足够的测试用例和测试点，避免出现没有测到的情况以及和实际运用不相符的情况。
TWO system/full chiplevel
1. 和IP level一样，需要将定义的系统级的所有测试用例跑通，同样最好每个case都仔细通过波形双重确认。
2. 系统级别的regression，一般在这个层次的测试用例，random随机会相对少一些；同样需要保证回归测试regression的结果要稳定相对长一段时间。
3. 做系统集成intergation的时候，顶层信号的连接是很可能出错的。有些公司有专门的工具或者脚本来检查integration的信号连接问题。如果没有专门的工具或脚本，除了通过测试用例来保证之外，需要做一些toggle coverage的统计，尤其是IP模块的输入输出信号的翻转统计，确保主要的信号都翻转过，有被测试用例测试过。如果这些都不做的情况下，至少通过波形把顶层信号的连接关系全部仔细检查一遍。
4. 所有PAD都需要被测试过一次
因为PAD的pin脚是有限的，所以经常一个PAD会被复用很多次，PAD的测试主要可以分成三大类：一类是专门用于DFT信号相关的，这些需要在DFT的case中全部测试；一类是在大多数测试用例中会用到的PAD；剩下一类就是复用的特殊功能，需要专门的一个测试用例来至少进行连接性的检查（从PAD端到内部IP端）。
5. 验证spec的最后review
系统级的verificationspec最后的review更加重要，尤其需要架构工程师、系统工程师，软件工程师等参加，因为他们更清楚芯片的实际运用场景，不要出现你建了一堆测试用例和实际的情况都不一样，就做无用功了。同样需要最大限度保证足够的测试用例和测试点，避免出现没有测到的情况以及和实际运用不相符的情况。
THREE gate level
1. 后仿的时间占用较长，所以需要定义出最需要在后仿中跑的测试用例，尤其是最容易出现timing问题的测试用例。并且完成最终的final review。
2. 所有的测试用例都需要基于最终版的网表和SDF文件跑通，并且需要带三种timing corner的SDF文件（TT/SS/FF）跑通。
3. 用于做IR-DROP功耗分析的测试用例基于最终版的网表和SDF文件跑通，并准备好相应的VCD波形文件。
