SystemVerilog验证测试平台编写指南第一章验证导论

74 阅读 0 评论 49 点赞

我是靠谱客的博主香蕉大碗，最近开发中收集的这篇文章主要介绍SystemVerilog验证测试平台编写指南第一章验证导论，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

作为一名验证工程师，你应该尽可能细致深入地去检验设计，并提取出所有可能的漏洞。在流片之前每发现一个漏洞就意味着最终到顾客手里就会少一个漏洞。
System Verilog硬件验证语言（Hardware Verification Language，HVL），相比于硬件描述语言（Hardware Description Language，HDL），HVL具有以下典型的性质：
（1）受约束的随机激励生成（CRT）。
（2）功能覆盖率。
（3）更高层次的结构，尤其是面向对象的编程（OOP）。
（4）多线程及线程之间的通信。
（5）支持HDL数据类型。
（6）集成了事件仿真器，便于对设计加以控制。
1.1 验证流程
什么是验证呢？作为一名验证工程师，你的目的就是确保该设备能够成功地完成预定的任务，也就是说，该设计是对规范的一种准确表达。
验证的流程并行于设计流程。一名验证工程师，你必须阅读硬件规范并拟定验证计划，创建测试来检查RTL代码是否准确地实现了所有的特性。
1.1.1 不同层次上的测试
设计上的漏洞会在不同层次上产生漏洞，下面从底层开始对设计中的漏洞进行下面几种分类。
代码块层次，在module创建的代码块。
代码块的边界，不同的设计者会对同一个规范有不同的理解，这样会造成硬件逻辑上的争议。
为了仿真一个代码块，你需要创建测试集来模拟周围代码块产生激励，这样低层次的仿真运行起来会很快，但是产生激励的方式会很繁琐。将多个代码块集成到一起，在待测设计的最高层次上，整个系统都会被测试，代码块之间相互激励，运行起来速度会更慢一些，但是仿真过程就会简单很多。你的测试应该尽可能让所有的代码块并发活动。所有的输入输出端口都被激活，处理器正在处理数据，而高速缓存也在载入数据。这样的话，数据分配和时序上的漏洞肯定会出现。
错误注入和处理，一旦验证了待测设计能够执行所有预期的功能以后，你还需要看一下当出现错误时，待测设计会怎样操作。
我们永远也无法证明没有任何漏洞留下，所以需要不停地尝试新的验证策略。
1.1.2 验证计划
验证计划主要包括以下几种方法：定向测试、随机测试、断言、软硬件协同验证、硬件仿真、形式验证，以及对验证IP的使用等等。
1.3 基本测试平台的功能
测试平台的用途在于确定待测设计的正确性。包含下列步骤：
(1) 产生激励。
(2) 把激励施加到DUT上。
(3) 捕捉响应。
(4) 检验正确性。
(5) 对照整个验证目标测算进展情况。
1.4 定向测试
定向测试就是针对待测设计制订具体的激励向量，然后使用这些向量对待测设计进行仿真。仿真结束后，手工查看一下结果文件和波形确保设计的行为和预期一致。如果测试结果正确，你就可以继续下一个测试。如果给予你足够的时间和人力，定向测试可以完成验证计划百分之百覆盖率所需要的全部测试。
1.5 方法学基础
方法学的原则如下：
(1)受约束的随机激励。
定向测试可以找出设计中预期的漏洞，随机激励能够找出预料不到的漏洞。在复杂的设计中，随机激励十分关键。
(2)功能覆盖率。
当使用随机激励时，需要用功能覆盖率来评估验证的进展情况。使用自动生成的激励，就需要一种能够自动预测结果的方式—通常是记分板或参考模型。建立包括自预测在内的测试平台基础设施是一件工作量很大的事情。
(3)使用事务处理器的分层测试平台。
分层的测试平台能够把问题分解为容易处理的小块，这样有助于控制复杂度。
(4)对所有测试通用的测试平台。
建立一个测试平台所需要的基础设施，它们能在所有测试中通用并且不需要经常性修改。你只需要在某些地方放置“钩子”，以便测试能够在这些地方执行调整激励或注入错误这样特定的操作。
(5)独立于测试平台之外的个性化测试代码。
针对单一测试的个性化代码必须与测试平台分开，这样可以避免增加基础设施的复杂度。
总之，建立这种风格的测试平台所需的时间要比传统的定向测试平台多得多—尤其是自检部分。结果是可能需要很长的准备时间才能进行第一次可运行的测试。每个随机测试都可以公用测试平台。受约束的随机测试平台找起来漏洞会比很多定向测试快很多。
随着漏洞出现率的下降，你应该创建新的随机约束去探索新的区域。最后的几个漏洞可能只能通过定向测试来发现，但是绝大部分的漏洞都应该会在随机测试中出现。
1.6 受约束的随机激励
我们希望仿真器能够产生随机激励，但同时又不希望激励时完全随机的。SystemVerilog语言可以描述激励的格式，然后让仿真器产生满足约束的数值。这些数值会被发送到设计中去，同时也会被发送到一个负责预测仿真结果的高层模块中去。设计的实际输出最终需要和预测输出做对比。
1.7 随机化对象
以一个初入验证领域的人来讲，所谓的随机化就是数据字段，这种激励最容易创建—只需要调用$random()函数即可。但是这种随机数据在找漏洞方面的回报是很小的。使用这种随机数据找到的漏洞一般都是在数据路径上，很可能还都是比特级的错误。其实我们更加需要找到一些控制逻辑上的漏洞。比如下面几种类型：
（1）设备和环境配置
很多测试只使用了仅仅经过复位的设计或者施加固定的初始向量集把设计引向一个已知的状态。在一个实际的应用环境中，随着待测设计使用时间的增加，其配置会变得越来越随机。你应该对整个环境的配置进行随机化，包括仿真的时长、设备的数量，以及它们的配置方式。
（2）输入数据
当看到随机激励时，可能会想到选取一个总线写入的事务或ATM信元，然后把随机数值填充到其中的数据字段里。
（3）协议异常、错误和违例
设备死机的最有可能的原因就是产品内部的一部分逻辑一旦遇到错误以后无法恢复过来，因此设备不能正常工作。我们就想尽量去尝试仿真在实际的硬件中可能出现的错误，要对这些情况一一尝试，然后确保设备还能继续正常运作。
尝试使用不当的命令去激励硬件的同时注意捕捉出现的问题。
（4）时延和同步
一个代码块对于来自同一接口的所有可能激励也许都能正常工作，但同时面对多个输入，隐蔽的漏洞可能就会出现。
（5）并行的随机测试
随机测试包含了测试平台代码和随机种子。如果你想对同一个测试运行50次，每次都采用不同的种子，那么你将会得到50个不同的激励集合。使用多个种子运行同一个测试可以加大覆盖率，同时也能减少你的工作量。
1.8 功能覆盖率
前面我们讲述了如何创建激励并使用这些激励遍历整个可能的输入空间。使用这种方法，你的测试平台会频繁访问部分区域，但是需要花费很长时间来达到所有可能的状态。即使对仿真时间不加限制，无法达到的状态还是永远也不会被访问到。这个时候我们就需要知道哪些部分已经被验证过，这样才能对验证计划中的项目进行核对。
对功能覆盖率的测量和使用包括下面几个步骤：
（1）在测试平台中加入代码，用于监控进入设备中的激励，以及设备对激励的反应，并据此确定哪些功能已经被验证过。
（2）运行几次仿真，每次使用不同的种子。
（3）把这些仿真的结果合并到一个报告中。
（4）对结果进行分析，最后决定如何采用新的激励来达到那些尚未被测试到的条件和逻辑。