《SystemVerilog验证-测试平台编写指南》学习 - 第1章 验证导论
---- # 《SystemVerilog验证-测试平台编写指南》学习 - 第1章 验证导论 ----
测试平台（testbench）的功能
- 产生激励（Generate stimulus）；
- 把激励输入到待测设计上（DUV，Design Under Verification）；
- 产生预期（Generate Expectation）；
- 捕捉响应（Capture response）；
- 检验响应的正确性（Check the response for correctness）；
- 根据验证目标评估验证进度（Measure the progress against the overall verification goals）；
验证四要素：
- 灌激励：（产生输入信号）
- 做预期：（产生预期结果）
- 集响应：（收集输出信号）
- 作比较：（比较响应和预期结果）
方法学基础
本书采用如下原则：
- 受约束的随机激励；
- 功能覆盖率；
- 使用事务处理器的分层测试平台；
- 对所有测试通用的测试平台；
- 独立于测试平台之外的个性化测试代码；
这些原则是相关联的。随机激励对测试复杂设计十分关键。
定向测试：找出设计中预期的漏洞；
随机测试：找出预料不到的漏洞；
当使用随机激励时，需要用功能覆盖率来评估验证进度。一旦开始使用自动生成的激励，就需要一种能够自动预测结果的方式 -- 通常是计分板或参考模型。
1. 受约束的随机激励
为什么要约束？
答：
虽然你希望仿真器能产生随机激励，但同时有不希望这些激励数值完全随机。
你的随机化对象是什么？
需要广泛地考虑所有的设计输入，而不是仅仅是数据字段，如下所列：
- 设备和环境配置；
你应该对整个环境的配置进行随机化，包括仿真的时长、设备的数量，以及它们的配置方式。当然，你需要创建约束以确保配置的合法性。- 输入数据；
你需要事先估计好所有的分层协议和错误注入，以及计分板的内容和功能覆盖率。- 协议异常、错误和违例；
应该尽量尝试去仿真在实际的硬件中可能出现的错误，而且应该针对所有可能出现的错误。- 时延和同步；
尝试协调各个驱动器使他们能够在不同的速率下进行通信。
2. 功能覆盖率
你需要知道哪些部分已经被验证过，这样才能对验证计划中的项目进行核对。
功能覆盖率的测量和使用：
- 添加代码用于监控进入设备中的激励，以及设备对激励的反应，并据此确定哪些功能已经被验证过；
- 运行几次仿真，每次使用不同的种子，合并报告；
- 分析结果，采用新的激励测试未被测试到的条件和逻辑；
随机测试需要使用反馈。最初的测试会被运行很多次，使用不同的种子，创建很多互异的输入序列。但是到了最后，即时使用新的种子，所产生的激励也很可能无法在设计空间中探测到新区域。
随着功能覆盖率逐渐接近极限，你需要改变测试，以期望能找出新的方法去达到那些尚未被覆盖的区域。这被称为“ 覆盖率驱动的验证 ”
在受约束的随机激励中很少采用动态反馈。相反地，需要手工分析覆盖率报告，然后调整随机约束。
3. 分层的测试平台
不分层的的测试平台或者低层次的Verilog测试就是初学Verilog时写的简单testbench那种形式。
如下图所示是带着所有层次的完整测试平台：
- 信号层：把待测设计和测试平台相连；
- 命令层：驱动器驱动待测设计的输入和监视器检测待测设计的输出变化，并把这些变化按照命令分组。断言也穿过命令层和信号层，负责监视独立的信号以寻找穿越整个命令的信号变化；
- 功能层：代理（在VMM中称为事务处理器）接收到来自上层的事务，例如DMA读或者写，把它们分解成独立的命令。这些命令也被送往用于预测事务结果的计分板。检测器则负责比较来自监视器和计分板的命令；
- 场景层：功能层被位于场景层中的发生器所驱动。所谓的场景就是操作步骤，场景层就是负责组织协调这些步骤的；
- 测试层和功能覆盖率：测试平台的最顶层 -- 测试层，就像一个指挥官，不演奏任何乐器却引领者其他人的表演。测试包含了用于创建激励的约束。功能覆盖率可以衡量所有测试在满足验证计划要求方面的进展。随着各项测量标准的完成，功能覆盖率代码在整个项目过程中会经常变化。由于代码经常被修改，所以它不作为测试环境的组成部分。
建立一个分层的测试平台
1. 创建一个简单的驱动器
如之前所说，驱动器接收来自代理的命令。驱动器可能会注入错误或增加时延，然后再把命令分解成一些信号的变化，例如总线请求或者握手。这样的一个测试平台模块通常被称为“事务处理器（transactor）”，它的核心部分是一个循环：有关事务处理器的示范代码如下所示。
task run();
done = 0;
while (!done) begin
// 获取下一个事务
// 进行变换
// 发送事务
end
endtask
2. 仿真环境阶段
- 建立（build）
- 生成配置：把待测设计的配置和周围的环境随机化；
- 建立环境：基于配置来分配和连接测试平台构件；
- 对待测设计进行复位；
- 配置待测设计：基于第一步中生成的配置，载入待测设计的命令寄存器；
- 运行（run）
- 启动环境：运行测试平台构件，例如各种BFM和激励发生器；
- 运行测试：启动测试然后等待测试完成。定向测试很容易判断，但随机测试却比较困难。可以使用测试平台的层作为引导。从顶层启动，等待一个层接收完来自上一层的所有输入，接着等待当前层空闲下来，然后再等待下一层。应该同时使用超时检测保证待测设计或者测试平台不出现死锁；
- 收尾（wrap-up）
- 清空：在最下层完成以后，你需要等待待测设计清空最后的事务；
- 报告：一旦待测设计空闲下来，你就可以清空遗留在待测设计中的数据了。你可以根据这些信息创建最终报告，如果测试失败，务必把相应的功能覆盖率结果删除，因为他们可能是不正确的。
3. 最大限度代码重用
为了验证一个带有数百个特性的复杂设备，必须编写数百个定向测试。如果使用受约束的随机激励，你需要编写的测试就会少很多。
与定向测试相比，随机测试的主要工作是构建测试平台，使它包含所有较低的层：场景、功能、命令以及信号。这个测试平台代码要能够被所有的测试使用，所以它需要有很好的通用性。
4. 测试平台的性能
创建受约束的随机测试需要几个步骤：
- 建立分层的测试平台，包括自检的部分；
- 按照验证计划中列举的目标创建激励，你可以使用随机约束，也可以采用注入错误或者协议违例等迂回的方式；
- 功能覆盖率，这项任务的开始是创建一个强有力的验证计划，这个计划必须带有清晰而且便于测量的目标；
- 收集数据，结果分析；
