验证完备性如何保证？

做好验证完备性是保证项目成功的关键，本文抛砖引玉，给出一个checklist，也许还有遗漏，大家可以留言进行补充。

1. UVM环境1.1.测试点和testcase

测试点和testcase评审是项目中必不可少的一个环节，一般由DV人员组织。但是在一些QA流程不规范的公司里，有可能只是在项目初期进行了评审。这样远远是不够的。原因如下：

1） 项目初期设计文档不是最终版，研发过程中可能有变动；

2） 不管是DE还是DV，在项目初期可能都会遗漏一些东西，只有在深入项目后才会对模块有更深刻的理解。

3） 白盒测试要求DV必须基于代码去调整验证思虑，构造corner case。这个在项目初期也是做不到的。

因此，测试点不仅需要在初期进行评审，还需要在项目的中后期进行评审，DE和DV坐一起进行头脑风暴。

1.2.RM

好的RM（reference model）一定是具备以下两个特性的：

1） 代码足够少。

2） 代码可读性强。

所以我们必须要求DV人员在写RM之前，做好抽象，不能像堆料一样堆了几千上万行代码，这样既容易出bug，又不方便DE理解。

1.3.Probe

所谓probe，其实就是在模块内部拉一些信号出来，然后通过时钟采样，并跟环境的模型进行比对。例如项目的数据流是模块A->模块B->模块C，我们可以将A与B，B与C之间的接口拉出来当probe。方便验证快速定位到问题是出现在数据流的哪一段，大大提高debug的效率。

但是在刚开始验证的时候，probe有可能会出现很多的bug，会影响前期的效率。因此，为了尽可能地减少probe的bug，在probe review时，一定要做到认真细致。

1.4.使用约束

在设计中，我们通常会对模块输入进行一些使用上的约束，例如读地址一定要256B对齐等。这些约束通常分成两类：一类来自于需求；一类来自于硬件设计本身。而为了避免过验证或者验证激励给的不符合要求，DV会将这些使用约束写成constraint，然后集成到环境中。

对于使用约束，我们需要check以下几点：

1） DE给出的使用约束是否正确，特别是来自需求的约束，必须给出出处；

2） DV环境里的使用约束是否与DE提供的约束文档完全一致。原则上，DV环境里不能有多或者少。除非是不加额外的约束，会导致数据量巨大，影响runtime。

1.5.环境的平台化及可复用性

“如果你的验证环境不具备平台化和可复用性，你做得再灵活，在花里胡哨。我不但不会欣赏你，还会看不起你！” 这是我的项目经理在一次DV例会上说的原话。

2.回归方式

注意，本章所说的check，并不是DV一句“已经OK“就完事了。每一项的check一定是要有理有据。下面会给出每一项的check方式。

2.1.确定开Probe

故意植错，看probe是否会报错。请截图加以说明。

2.2.确定前后级反压符合要求

如果跟DUT对接的前后级有反压的场景，那么就要check环境中给的反压是否符合要求。包括反压组合，各种反压给的反压值是什么。请截图加以说明。

2.3.带init reg回归

改变VCS的设置选项，将init reg设置成不同的模式，看回归的波形里是否有变化。请截图加以说明。

2.4.带x pro回归

请截图加以说明。

2.5.C model/RTL/RM三者直接同时比对

可故意植错，看有没有报错。请截图加以说明。

2.6.带assertion回归

可故意植错，看有没有报错。请截图加以说明。

2.7.时钟动态切换

查看波形，看时钟是否有动态切换。请截图说明。

3. check波形3.1.时钟频率要跟实际的一致

查看波形，看时钟频率。请截图说明。

3.2.经典场景波形确认

这个需要DE罗列场景（最好做成表格），并一一check。

3.3.memory不能有多写空读

构造corner case，并查看波形。请截图说明。

3.4.前后级接口反压

查看波形，看下反压是否生效，且比较容易在设置的反压值范围内随机。请截图说明。

3.5.不能误报中断

在正常不会报中断的case里，不能随意报中断。这个check项主要是为了避免DV在写环境时有遗漏。可通过assert进行check。

4. 覆盖率4.1.功能覆盖率100%

由DV来收。需要给出文档。

4.2.行覆盖率100%

由DE来收。需要给出文档。

4.3.分支覆盖率100%

由DE来收。需要给出文档。

4.4.条件覆盖率可解释范围之内100%

由DE来收，VCS中一定要打开-cond full选项。需要给出文档。特别是那些waive的地方，一定要反复check。

4.5.翻转覆盖率可解释范围之内100%

由DE来收。需要给出文档。特别是那些waive的地方，一定要反复check。

5. 仿真log确认5.1.VCS环境设置符合预期

在编译log的顶部，请截图说明。

5.2.log不能有error

这个一定是不能存在的。

5.3.log中的warning一一确认

如果最终Log中存在warning，一定要给出文档加以解释。

6. 预防假PASS

如果一个DV，经常搞出假PASS，那他必然会被贴上不靠谱的标签。因此，一个有责任心的DV在汇报PASS之前，一定是做了该做的检查的。一个比较常用的办法就是故意植错，看看是否还会PASS。这个check的证据，也是要截图加以说明的。