SystemVerilog 验证-测试平台编写指南学习笔记（0）：验证导论

---------- 0 引言 ---------- 1 创建SystemVerilog的原因？

• Verilog验证能力无法满足涉及规模的增长，催生了Accellera联盟。
• OpenVera语言的捐赠构成了SystemVerilog作为硬件验证语言（HVL）的基础。
• 2005.11 IEEE采纳SystemVerilog标准，标准号P1800-2005。

2 采用SystemVerilog的好处？

• 涉及和验证工具语法和语义上的统一减小验证和涉及工程师的分歧和沟通障碍。
• 设计、测试平台和断言结构集中一个语言使测试平台更容易访问环境中所有部分。

---------- 0 验证导论 ---------- 1 与HDL相比，SystemVerilog 硬件验证语言（Hardware Verification Language，HVL）的典型性质？

1. 受约束的随机激励生成。
2. 功能覆盖率。
3. 更高层次的结构，尤其是面向对象的编程。
4. 多线程及线程间的通信。
5. 支持HDL数据类型，例如Verilog的四状态数值。
6. 集成时间仿真器，便于对设计施加控制。

2 测试的层次？

• 代码块（block）层次上。代码块的功能
• 代码块的边界。
• 待测设计的最高层次上。测试整个系统。

3 测试平台的功能？

测试平台的用途在于确定待测设计的正确性，包含步骤：

1. 产生激励。
2. 把激励施加到DUT上。
3. 捕捉响应。
4. 检验正确性。
5. 对照整个验证目标测算进展情况。

4 定向测试 4.1 定向测试步骤？

1. 阅读硬件规范写下验证计划。
2. 根据验证计划编写针对待测设计具体特性的激励向量。
3. 使用激励向量对待测设计进行仿真。
4. 验证设计的行为与预期一致。

4.2 优点？

• 容易取得稳步进展。
• 激励向量的创建不需要基础设施，可以很快得到结果。
• 时间足够情况下可以实现整个验证计划100%覆盖率所需要的全部测试。

4.3 缺点？

• 消耗大量时间与人力。
• 定向测试可以找出设计中预期的漏洞，而随机测试才可以找出预料不到的漏洞。

5 随机测试

• 当使用随机激励时，需要用功能覆盖率来评估验证的进展情况。
• 使用自动生成的激励需要一种能够自动预测结果的方式-通常是记分板或者参考模型。
• 随机测试需要的前期准备工作比定向测试多得多，但受约束的随机测试平台找漏洞比很多定向测试快很多。

6 随机化对象是什么？

只用$random()对激励的数据字段进行随机化得到随机数据，只能找到数据路径上的漏洞。还需要找出逻辑控制上的漏洞。 广泛考虑以下所有的设计输入：

1. 设备配置。随着待测设计使用时间的增加，其配置会变得越来越随机。
2. 环境配置。实际英语中设备所在的环境会包含其他部件。环境配置包括仿真时长、设备数量、配置方式、测试长度、错误注入比率、时延模式等。
3. 输入数据。
4. 协议异常。
5. 错误和违例。
6. 时延。

7 功能覆盖率的测量和使用步骤？

需要知道哪些部分已经被验证过，这样才能对验证计划中的项目进行核对。 功能覆盖率的测量和使用步骤：

1. 监控进入设备的激励以及设备激励的反应，据此确定哪些功能被验证过。
2. 使用不同种子仿真几次，将仿真结果合并到一个报告中。
3. 分析结果，决定如何采用新的激励达到未测试的条件和逻辑。（从功能覆盖率到激励的反馈，覆盖率驱动的验证）。

8 测试平台的组成？

测试平台工作在一个很宽的抽象层次范围内，同时创建事务和激励序列并最终转换成bit向量。

测试平台模拟的就是实际应用中设备的连接，有很多总线功能模型（BFM），例如AMBA、USB、PCI和SPI总线。

测试平台建立了产生激励并检验响应的构件，这些构件不是可综合模型，而是遵循协议并且执行速度更快的高层次事务处理器。但是如果要把设计原型放在FPGA上实现或者硬件仿真，那么这些BFM就需要可综合。

8.1 分层的测试平台

好比我们FPGA开发写testbench，不分层是把所有激励卸载一个逻辑里面，而分层是将一些功能用task独立出来。可以提高工作效率减少出错。

8.1.1 信号与命令层

信号层：包含待测设计和连接待测设计与测试平台的信号。 命令层：

• 驱动器驱动待测设计的输入
• 监视器检验信号的变化并把变化按照命令分组
• 断言监视独立的信号以寻找穿越整个命令的信号变化。

8.1.2 功能层

功能层： - 代理（VMM中称为事务处理器）：接收来自上层的事务并分解成独立的命令。 - 记分板：用于预测事务结果。 - 检验器：比较来自监视器和记分板的命令。

8.1.3 场景层

什么是场景？ 待测设备完成预期任务中间的每个操作都称为一个场景。场景层负责组织与协调预期任务中的操作步骤。

随着项目的进展，测试平台环境可能会有一些变化，但是这些块对于每个独立的测试都是不应改变的。可以在代码中留下“钩子”来做到这一点。

8.1.4 测试的层次与功能覆盖率

测试层：测试平台的最顶层。 测试 包含了用于创建激励的约束。

功能覆盖率衡量所有测试在满足验证计划要求方面的进展。 随着各项测量标准的完成，功能覆盖率代码在整个项目过程中会经常变化。由于代码经常修改，所以它不能作为测试环境的组成部分。

测试平台是否需要所有层次？

测试平台所需的层次视待测设计而定，设计越复杂所需测试平台就要越完备。 测试层是必须的。如果需要也可以添加更多的层次。

9 仿真环境的阶段

1. 建立（build）
   1. 生成配置：把待测设计的配置和周围的环境随机化。
   2. 建立环境：基于配置来分配和连接测试平台构件。
   3. 对待测设计进行复位。
   4. 配置待测设计：基于第一步中生成的配置、载入待测设计的命令寄存器。
2. 运行（run）
   1. 启动环境：运行测试平台构件，如各种BFM和激励发生器。
   2. 运行测试：启动测试然后等待测试完成。
3. 收尾（wrap-up）
   1. 清空：在最下层完成后，等待待测设计清空最后的事务。
   2. 报告：创建报告。