《SystemVerilog验证-测试平台编写指南》学习 - 第1章 验证导论

• 《SystemVerilog验证-测试平台编写指南》学习 - 第1章 验证导论
  • 测试平台（testbench）的功能
  • 方法学基础
    • 1. 受约束的随机激励
    • 2. 功能覆盖率
    • 3. 分层的测试平台
  • 建立一个分层的测试平台
    • 1. 创建一个简单的驱动器
    • 2. 仿真环境阶段
    • 3. 最大限度代码重用
    • 4. 测试平台的性能

《SystemVerilog验证-测试平台编写指南》学习 - 第1章 验证导论

---

测试平台（testbench）的功能

1. 产生激励（Generate stimulus）；
2. 把激励输入到待测设计上（DUV，Design Under Verification）；
3. 产生预期（Generate Expectation）；
4. 捕捉响应（Capture response）；
5. 检验响应的正确性（Check the response for correctness）；
6. 根据验证目标评估验证进度（Measure the progress against the overall verification goals）；

验证四要素：

1. 灌激励：（产生输入信号）
2. 做预期：（产生预期结果）
3. 集响应：（收集输出信号）
4. 作比较：（比较响应和预期结果）

---

方法学基础

本书采用如下原则：

1. 受约束的随机激励；
2. 功能覆盖率；
3. 使用事务处理器的分层测试平台；
4. 对所有测试通用的测试平台；
5. 独立于测试平台之外的个性化测试代码；

  这些原则是相关联的。随机激励对测试复杂设计十分关键。

定向测试：找出设计中预期的漏洞；

随机测试：找出预料不到的漏洞；

  当使用随机激励时，需要用功能覆盖率来评估验证进度。一旦开始使用自动生成的激励，就需要一种能够自动预测结果的方式 -- 通常是计分板或参考模型。

1. 受约束的随机激励

为什么要约束？

答：

  虽然你希望仿真器能产生随机激励，但同时有不希望这些激励数值完全随机。

你的随机化对象是什么？

  需要广泛地考虑所有的设计输入，而不是仅仅是数据字段，如下所列：

1. 设备和环境配置；
   
     你应该对整个环境的配置进行随机化，包括仿真的时长、设备的数量，以及它们的配置方式。当然，你需要创建约束以确保配置的合法性。
2. 输入数据；
   
     你需要事先估计好所有的分层协议和错误注入，以及计分板的内容和功能覆盖率。
3. 协议异常、错误和违例；
   
     应该尽量尝试去仿真在实际的硬件中可能出现的错误，而且应该针对所有可能出现的错误。
4. 时延和同步；
   
     尝试协调各个驱动器使他们能够在不同的速率下进行通信。

2. 功能覆盖率

  你需要知道哪些部分已经被验证过，这样才能对验证计划中的项目进行核对。

功能覆盖率的测量和使用：

1. 添加代码用于监控进入设备中的激励，以及设备对激励的反应，并据此确定哪些功能已经被验证过；
2. 运行几次仿真，每次使用不同的种子，合并报告；
3. 分析结果，采用新的激励测试未被测试到的条件和逻辑；

  随机测试需要使用反馈。最初的测试会被运行很多次，使用不同的种子，创建很多互异的输入序列。但是到了最后，即时使用新的种子，所产生的激励也很可能无法在设计空间中探测到新区域。

  随着功能覆盖率逐渐接近极限，你需要改变测试，以期望能找出新的方法去达到那些尚未被覆盖的区域。这被称为“ 覆盖率驱动的验证 ”

  在受约束的随机激励中很少采用动态反馈。相反地，需要手工分析覆盖率报告，然后调整随机约束。

3. 分层的测试平台

  不分层的的测试平台或者低层次的Verilog测试就是初学Verilog时写的简单testbench那种形式。

  如下图所示是带着所有层次的完整测试平台：

1. 信号层：把待测设计和测试平台相连；
2. 命令层：驱动器驱动待测设计的输入和监视器检测待测设计的输出变化，并把这些变化按照命令分组。断言也穿过命令层和信号层，负责监视独立的信号以寻找穿越整个命令的信号变化；
3. 功能层：代理（在VMM中称为事务处理器）接收到来自上层的事务，例如DMA读或者写，把它们分解成独立的命令。这些命令也被送往用于预测事务结果的计分板。检测器则负责比较来自监视器和计分板的命令；
4. 场景层：功能层被位于场景层中的发生器所驱动。所谓的场景就是操作步骤，场景层就是负责组织协调这些步骤的；
5. 测试层和功能覆盖率：测试平台的最顶层 -- 测试层，就像一个指挥官，不演奏任何乐器却引领者其他人的表演。测试包含了用于创建激励的约束。功能覆盖率可以衡量所有测试在满足验证计划要求方面的进展。随着各项测量标准的完成，功能覆盖率代码在整个项目过程中会经常变化。由于代码经常被修改，所以它不作为测试环境的组成部分。

建立一个分层的测试平台

1. 创建一个简单的驱动器

  如之前所说，驱动器接收来自代理的命令。驱动器可能会注入错误或增加时延，然后再把命令分解成一些信号的变化，例如总线请求或者握手。这样的一个测试平台模块通常被称为“事务处理器（transactor）”，它的核心部分是一个循环：有关事务处理器的示范代码如下所示。

task run();
    done = 0;
    while (!done) begin
        // 获取下一个事务
        // 进行变换
        // 发送事务
    end
endtask

2. 仿真环境阶段

• 建立（build）

1. 生成配置：把待测设计的配置和周围的环境随机化；
2. 建立环境：基于配置来分配和连接测试平台构件；
3. 对待测设计进行复位；
4. 配置待测设计：基于第一步中生成的配置，载入待测设计的命令寄存器；

• 运行（run）

1. 启动环境：运行测试平台构件，例如各种BFM和激励发生器；
2. 运行测试：启动测试然后等待测试完成。定向测试很容易判断，但随机测试却比较困难。可以使用测试平台的层作为引导。从顶层启动，等待一个层接收完来自上一层的所有输入，接着等待当前层空闲下来，然后再等待下一层。应该同时使用超时检测保证待测设计或者测试平台不出现死锁；

• 收尾（wrap-up）

1. 清空：在最下层完成以后，你需要等待待测设计清空最后的事务；
2. 报告：一旦待测设计空闲下来，你就可以清空遗留在待测设计中的数据了。你可以根据这些信息创建最终报告，如果测试失败，务必把相应的功能覆盖率结果删除，因为他们可能是不正确的。

3. 最大限度代码重用

  为了验证一个带有数百个特性的复杂设备，必须编写数百个定向测试。如果使用受约束的随机激励，你需要编写的测试就会少很多。

  与定向测试相比，随机测试的主要工作是构建测试平台，使它包含所有较低的层：场景、功能、命令以及信号。这个测试平台代码要能够被所有的测试使用，所以它需要有很好的通用性。

4. 测试平台的性能

  创建受约束的随机测试需要几个步骤：

1. 建立分层的测试平台，包括自检的部分；
2. 按照验证计划中列举的目标创建激励，你可以使用随机约束，也可以采用注入错误或者协议违例等迂回的方式；
3. 功能覆盖率，这项任务的开始是创建一个强有力的验证计划，这个计划必须带有清晰而且便于测量的目标；
4. 收集数据，结果分析；