芯片验证系列——验证计划

验证计划是验证策略的更具体实施计划。验证策略是在高层次描述对验证的整体规划(目标制定、时间安排、工作流程、验证方法学、版本管理、总体覆盖率进度等)和对RTL进行哪些层面测试，包括UT/IT/ST/FPGA/Emulation/Formal等。验证策略不会涉及验证的详细计划，验证计划就是对验证策略进一步详细地阐述，包括详细时间安排、人力需求、TB结构、配置、提取Verification feature并划分优先级、TB局限性分析、reuse组件、 testcases规划、覆盖率和每个阶段验收标准等等，甚至可以包含coding guideline。验证计划用于规范验证的行为，不仅仅用于决定何时验证可以结束和peer review，也可用于同一个team同事在实现TB功能和testcases时有依据可循。以下是写验证计划时，需要涉及的一些参考点。

1. 介绍整个验证计划涵盖的内容

比如验证对象(DUT)、参考文献、本文档作者和版本迭代、关键缩略词等。

2. 详细介绍下验证对象(DUT)

RTL的主要功能和interfaces。

3. 列出要验证的verification features

可以参考我的另一篇博客(Testpoints分解链接)，里面有更详细介绍如何从Spec里提取verfication features。主要就是基于interfaces、基于功能(控制流和数据流)、基于性能和基于架构，当然可能还有其它可靠性、可测性等。
这里面可以把一些designer很关注的feature高亮起来，或者priority提高些。更一步的话，把整个feature如何保证完备性也可以补充下。

4. 历史经验

列一些以往类似项目的借鉴经验和问题清单，特别是bug清单，可以用于举一反三，加强验证。

5. 局限性和假设

这里面可以把一些在当前TB无法验证或不好验证的点，然后给出解决方法，比如让top level覆盖？formal覆盖？或者designer加一些辅助验证信号和coverage等等。
要切记，designer加的辅助验证信号一是designer要加assertion验证过的，二是在TB内也有检查下是否是合理的事件。

6. Testbench结构规划

TB采用的方法学、抽象层次，比如UVM、VMM等。
TB由哪些component组成，比如包含哪些激励组件、checker组件、coverage、metrics、register model等。对于每个component，可以简单介绍下，因为验证计划的下文会更详细地描述component结构和功能。

7. Configuration规划

列出RTL的parameter组合配置，有些RTL可能在不同的parameter下，会实现不同的功能，这些parameter都需要验证，因此要详细列出会验证哪些parameter组合。
列出TB中用到的define宏，比如有些macro在Unit level和Top level要取不同的值。
列出会对RTL registers做一些什么配置，比如random初始化、在testcase运行期间随机更改等。

8. Stimulus规划

激励是很重要的一块内容。验证质量的好坏很大程度上有依赖激励是否有能够有效率地产生完备的场景。在这里要详细描述下，各个stimulus的规划，是random，还是direct等等。Random的话，涉及到constraint；direct的话，又是为什么场景而决定的。其实除了在冒烟和收尾阶段可能约束一些direct stimulus，在其它情况下，最好还是采用random stimulus。
也包括reuse stimulus组件和VIP激励的配置和修改等。

9. Checker规划

Checker也是很重要的内容。激励产生对应场景之后，能否找出RTL bug，直接取决于checker是否完备。在这里要阐述清楚每个checker检查的features包括哪些？白盒还是黑盒检查？在testcase里self-check？SVA？然后阐述下每个checker的结构和检查流程等。

10. Testcases规划

Testcases也是包括random和direct，random testcases应该占到大多数，用于产生最多的场景和覆盖率目标。Direct testcases用于RTL刚开始的冒烟测试和最后收集覆盖率时的corner case。
其实最好整理一个表格，写清楚每个testcase所要产生的RTL scenarios。既方便查缺补漏，也方便别人review。
Testcases可能也会包含一些专门的寄存器测试用例，前门和后门之类的，测试register的默认值、RW/RO/RC/WC/WO等属性。RTL register是否可以正常工作也是非常重要的，通常也会在testcase运行过程中，随机插入一些register访问。

11. Coverage规划

Coverage包含code coverage和functional coverage，有些项目可能还会收集assertion coverage、directive coverage等。在指定EDA tools的options后，它们会自动收集code coverage的，这一块我们可能不用过多操心人为引入错误。对于functional coverage一定要提起重视，它是衡量我们stimulus是否要产生想要场景的重要依据。Fcov一般不会直接发现bug，但对于进一步增强stimulus起着关键作用。我个人是认为fcov要尽早开发，而且多review下fcov是否正确实现和完备的。
**Stimulus、checker和coverage是验证的三大重要点。**Stimulus决定RTL场景的发生，checker负责场景发生后，RTL的功能是正确的，coverage负责分析stimulus是否产生了预期的场景。如果fcov实现不足或实现有误，可能直接导致我们漏验证了某些功能features，这还不一定能否很好发现的。CDV(coverage driven verification)，也即基于覆盖率驱动的验证技术，这是一个闭环。如果fcov实现有问题，将直接导致闭环被破坏掉了。
切记，fcov要有完备性和正确性。也可以让designer在RTL里加一些他们感兴趣的cover点。

12. Metrics规划

Metrics可以度量stimulus产生的质量，可以说是coverage的一个补充。比如在验证cpu core的时候，可以实现一个统计各个instruction数目的metrics，用于分析stimulus的合理性，减少simulation在做无用功。很多项目由于进度压力，都不会实现metrics。我是认为如果进度比较紧张，也要实现一些基本的metrics用于分析，防止stimulus走偏了。然后在有充裕时间，再实现其它必要的metrics。
在每个Testcase里可以按照一定的格式在testcase结束时打印metric event的值，然后使用脚本去提取累积起来。想做的更好的话，可以进一步用图表展示出来，更直观。

13. Reuse组件

在一个TB中，不一定所有的组件都要从头开发，有可能组件可能在其它项目有开发过，修改下就可以重用在当前TB，那也是很好的一种选择，节省了开发的时间和精力。
在这里就需要介绍下reuse组件有哪些，它们的功能，会对它们做哪些修改来适配当前TB。

14. VIP的使用

开发一些通用组件所花的时间和经历可能并不划算，比如CHI VIP，关键开发完也不一定是正确的，这时候可以考虑用一些已经开发好了、经过充分验证的VIP，让我们更多地聚焦在RTL上。
在这里列出VIP的版本、功能和使用目的等。

15. 验证基础设施

列一些验证基础设施，比如需要哪些EDA工具及其版本，需要开发和复用的脚本，UVM版本，代码版本管理工具等，这些通用的基础设施在验证策略上应该也会有规定的。因此，这里除了重复的列出之后，还可以列一些特定于当前TB所需要的东西，比如提取log脚本之类的。

16. coding guideline

这个每个项目可能要求不一样。但coding guideline应该是同一个team内，每个人都有遵守的，一方面可以减少coding出错的概率，另一个方面code维护和review起来也方便。这个可以大家一块想，看看有没有好的代码实践经验，都可以放在这里的。
Guideline可以有：变量命名规则，文件结构和文件命名，注释要求，debug log要求，code constructs写法，code对齐，每行最多字符数，变量作用域等等。

17. 时间安排

这个就看整个项目进展规划了。结合项目的关键时间节点作安排当前TB每个阶段需要完成什么事情。比如TB开发程度、regression pass rate、coverage覆盖程度等。

18. 人力安排

根据前面评估的工作量和时间进度，规划需要多少人力才能完成当前TB的验证。

19. 其它