SystemVerilog验证教程(一)--Test Plan and Design Verification Environment

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_31019565/article/details/86585683

转载请标明出处:
原文发布于:浅尝辄止,未尝不可的博客
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的层次化和可重用性是非常重要的两个属性。

展开阅读全文

没有更多推荐了,返回首页