SystemVerilog验证教程（一）--Test Plan and Design Verification Environment

转载请标明出处：
原文发布于：浅尝辄止，未尝不可的博客
https://blog.csdn.net/qq_31019565

SystemVerilog 验证教程（一）–Test Plan and Design Verification Environment

Test（Verification） Plan

Test Plan是决定验证好坏的一个决定性的因素。往往在正常的验证工作中，对于TestPlan的多次Review是验证的重要工作之一，实际的coding只是一个Plan的翻译过程，反而需要的时间相对较少。
切记：想清楚再动手，Plan–>Code

其实从最开始的验证这个角度想，给你一个设计。你要对它进行Verify，那么你都会有什么样的问题。说到底就是怎么去验证。 what will you do ? or what is your plan? 这正是一个验证计划思路形成的过程。你可以遵循一个固定的Flow。

现在开始问问题。
第一个问题，要验证什么样的设计？
第二个问题，用什么工具来验证？
第三个问题，应该验证这个设计的哪些内容？
第四个问题，如何将想要验证的内容转化到设计的输入？
第五个问题，如何考量设计的输出结果？
第六个问题，如何判定要验证的点，已经周全？
第七个问题，达到怎样的程度，这个验证工作才算结束？

其实可以问的问题有很多，每个人的思考角度也不一样，比如第二个问题来说，如果是TeamLeader，他拿到一个设计，可能考虑的问题就不局限于工具，比如还有人力资源，按照能力分工，充分利用，这样对Schedule也会有保证。工具的话，硬件验证的一些东西，scripts、license、ip、vip。第三个问题，要区分IP和SOC，IP的话可能是一个个功能点，SOC可能就是一些大的抽象的情景，需要连接哪一些接口，时序，clock。第四个问题，是对验证策略的考量，random的方式，还是列举法进行，还是加constraint两者结合使用，根据需求来调整自己的策略。第五个问题，是用到了一个Model的知识点，涉及了reference model的实现。第六个问题呢是衡量Verification进行到了哪一些程度，涉及到Coverage的问题。

以上的这些都是TestPlan所可以涉及的东西。最终会有一个成型的轮廓，如果考虑更多的问题，那么将会是有更完美的方案。

下面的是一个设计周期中Design和Verification之间的相互关系：

要关注的是VerificationEngineers的部分，这是一个总体的芯片设计周期。从拿到Design Spec开始，着手进行Verification Plan的编写，到了节点1 ，是一个Review PLan结束的节点，这时候将会是下一个阶段的开始。在这个Test进行的过程中，Design会更新代码和Spec，同时我们也会更新TestPLan和其他的内容。到了节点2，是一个验证完成的过程,其实也是前端工作完成的一个过程。节点3是Tape Out。

开始进入本小节的正题，TestPlan。其实根据前面的问题，已经基本罗列的差不多了。一份比较正式的TestPlan会包含以下的一些内容：

1. 对于我所验证的Design的一个综合性的描述（Verification Level）（block->IP->SOC）
2. 验证过程中所需要的Tool。
3. 整个流程的Risk以及互相依赖关系。
4. 所需要验证的一些功能。
5. 验证语言及相对应的方法学
6. 覆盖率的需求
7. 所需要的其他资源
8. 具体的时间表。

对以上内容做一个详细的描述：
第一点，既然是做验证，首先要明确所做的Verification Level。如果是IP验证的话，这时候需要与Design做一个详细的沟通，是一个Spec Review的过程，了解详细的功能点，在这个模块当中有哪些非常容易出错要重点关注的地方，这是一个互相支持协作的过程。而对于SOC验证的话，格外注意的是接口时序关系，或者SOC场景应用。弄清楚这些，我们可以对整个的验证有一个总体的把握，这样无论的后续验证的执行还是Schedule的保证，都会有很好的效果。
第二点，验证工具的话，常用的一些仿真工具比如VCS、Modusim、Questasim；形式验证的一些工具，但是DV的话基本很少用；处理Assertion的工具；波形工具 Verdi、DVE；FPGA验证；Veloce和Palladium硬件加速；已经开发好的Verification的工具库或者已经开发好的小的IP。
第三点，整个验证流程中的各个节点的依赖关系以及风险点。比如Tool的版本升级；新增工具的认识及学习；每个人的接受学习时间的不同；Design RTL提供的及时性，如果按时提供，那么将会按时开始验证；各个验证组别之间的依赖关系；如果是给客户做事情，Spec可能会变动；资源限制。
第四点，所需要验证功能的这一点可以分成几类：
1 优先级最高的功能，对芯片功能具有重大影响的功能。如果功能不好，那么芯片就废了。这样的功能一定要验证到。
2 第二优先级的性能，一般是在性能方面的作用，不会对芯片的主要功能造成影响，但是还是会影响性能。或者一些通过软件可以规避的问题，还有一些Corner。
3 通用的功能，比如reset和clk。
4 可能存在一些特定的场景，需要进行特别的配置，然后再进行验证；不同的数据类型；重要的参数类型；还比如一些错误的情况。
第五点，Verification的策略：
1 直接的验证的方法， 比如上述的第一优先级的功能，会经常一直用的，可以选择这种方式，写单独的case进行验证。还有一些Corner case，需要具体的去进行验证。
2 random策略。芯片复杂性越来越大，需要这种策略。
3 formal的策略，穷举法进行验证。
第六点，覆盖率的需求这点，每个项目都会有自己的coverage目标。
第七点，人力资源、计算资源。
第八点，时间表，执行计划。 对于一代产品来说，Schedule是至关重要的。这个可以结合上面的图片进行理解。

Design Verification Environment

这个模块是想详述一下整个一个SystemVerilog 的TestBench是什么作用。

如上图所示，是一个TestBench的简单示图。DUT（Design Under Test）是待测设计，而包围着产生激励和收集输出的则是TestBench。正就是一个概念上的验证环境。

一个好的TestBeach，可以产生非常好的效果。TestBench一代一代的发展，原动力就是为了提供有效的工作效率。Reusable是TestBench非常非常重要的属性，这对研发周期的缩短具有很大的作用。SystemVerilog是一种面向对象的编程语言。对于复用性会有很大的影响。层次化是TestBench 另一个重要属性之一。

一个详细的层次化的TestBench的例子


如上图所示，在一个DUT中，可以分为几个相对的层次:

1. 首先是最低的信号层，包含待测设计和把待测设计链接到TestBench的interface。
2. 第二个是命令层，比如待测设计的输入与驱动器链接，待测设计的输出与监控器链接，以及断言策略。
3. 第三层是功能层，功能层下面是命令层，这里的功能层将功能具体到一个一个的Transaction，驱动受理到上层的transaction然后再进行转换到详细的信号层的输入。这里包含
4. 第四层是场景层，对于一个独立的IP或者芯片，每一次的运用都算作一次场景，不同的场景对应的不同的命令层，不同的信号驱动，即generator。
5. 最上面的一层就是Test。即我们所熟知的TestCase。

小结：TestBench的层次化和可重用性是非常重要的两个属性。