|
|
本教程首发于VX小石头的芯语芯愿
<hr/>SystemVerilog 测试激励文件
我们需要采用称为测试激励文件的环境，用于在设计上运行任何种类的仿真。
单击此处回顾仿真的基本概念 测试激励文件的目的是什么？
测试激励文件允许我们通过仿真来验证设计的功能。它是一个容器，在其中通过不同的输入激励来布局和驱动设计。
- 生成不同类型的输入激励
- 利用生成的激励来驱动设计输入
- 允许设计处理输入并提供输出
- 检查输出中是否存在意外行为，以便查找功能缺陷
- 如果发现功能缺陷，则更改设计以修复缺陷
- 执行上述步骤直至修复所有功能缺陷
测试激励文件的组件
鉴于简介中的示例中受测设计 (DUT) 的连接方式和信号驱动方式，它并不是模块化、可扩展、灵活或可复用的示例。我们来看一个简单的测试激励文件，认识一下有助于往来 DUT 进行数据传输的各种组件。
| 组件 | 描述 | | 生成器 | 生成要驱动到 DUT 的不同输入激励 | | 接口 | 包含可驱动或可监控的设计信号 | | 驱动程序 | 将生成的激励驱动到设计 | | 监控器 | 监控设计的输入输出端口以便捕获设计活动 | | 计分卡 | 检查设计输出的行为是否与期望相符 | | 环境 | 包含上述所有验证组件 | | 测试 | 包含可通过不同配置设置来加以调整的环境 |
simple-testbench.png
何谓 DUT？
DUT 表示 Design Under Test（受测设计），它是以 Verilog 或 VHDL 编写的硬件设计。DUT 是完成芯片制造后，硅片确认后常用的一个术语。在确认前，也将其称为“Design Under Verification”（待验证设计），简称 DUV。
// All verification components are placed in this top testbench module
module tb_top;
// Declare variables that need to be connected to the design instance
// These variables are assigned some values that in turn gets transferred to
// the design as inputs because they are connected with the ports in the design
reg clk;
wire en;
wire wr;
wire data;
// Instantiate the design module and connect the variables declared above
// with the ports in the design
design myDsn ( .clk (clk),
.en (en),
.wr (wr),
. ...
.rdata);
// Develop rest of the testbench and write stimulus that can be driven to the design
endmodule单击此处获取完整的 SystemVerilog 测试激励文件示例！ 什么是接口？
如果设计包含数百个端口信号，那么连接、维护和复用这些信号是十分繁琐的。我们改为将所有设计输入输出端口都布局到一个容器内，此容器就会成为与 DUT 对接的一个接口。随后，即可通过此接口以各种值来驱动设计。
什么是驱动程序？
驱动程序是通过接口中定义的 task（任务）来对 DUT 的管脚进行调整的验证组件。如果驱动程序必须将部分输入值驱动到设计，它只需在接口中调用此预定义任务，而无需实际知晓这些信号之间的时序关系。时序信息是在接口所提供的 task 中定义的。这是提升测试激励文件的灵活性和可扩展性所必需的抽象层次。未来如果更改此接口，那么新的驱动程序就可以调用相同任务并以不同方式来驱动信号。
驱动程序如何知晓要驱动的对象？
生成器是一个验证组件，它可以创建有效的数据传输事务，并将其发送给驱动程序。随后，驱动程序只需通过接口来驱动由生成器提供给自己的数据即可。数据传输事务是作为类对象来实现的，如上图中的蓝色方框所示。驱动程序负责获取数据对象，并将其转换为 DUT 可理解的信息。
为什么需要监控器？
之前已探讨过将数据驱动到 DUT 的方式了。但这只是一半，因为主要目标是验证设计。DUT 会处理输入数据，并将结果发送到输出管脚。监控器会提取处理后的数据、将其转换为数据对象，并将其发送到计分卡。
计分卡的目的是什么？
计分卡可包含参考模型，其行为方式与 DUT 相同。此模型会反映 DUT 期望的行为。发送到 DUT 的输入也会一并发送给该参考模型。因此，如果 DUT 存在功能问题，那么 DUT 的输出将与来自参考模型的输出不匹配。因此，通过比较来自设计的输出与来自参考模型的输出，即可得知设计中是否存在缺陷。此操作通常是在计分卡中完成的。
为什么需要环境？
环境能够提升验证的灵活性和可扩展性，因为可将更多组件插入相同环境以供未来工程使用。
测试是做什么的？
确实。测试将例化环境的对象，并按测试期望的方式来对其进行配置。还请牢记，我们很可能有数千个测试要做，为每个测试直接更改环境是不可行的。故而我们改为寄希望于对环境中的某些小部分或某些参数进行调整以供每个测试使用。这样测试就能对激励生成具有更高的掌控度，并且将变得更有效。
这里我们展示了一个简单的测试激励文件是什么样子的。在实际工程中，将会在更高的抽象层次插入大量此类组件来执行各种任务。如果要对一个简单的数字计数器进行验证，而其中只有 50 行 RTL 代码，那么这就足够了。但如果复杂性进一步增加，就需要处理更多的抽象对象。
什么是抽象层次？
在序言中，您已经了解了我们使用各信号来调整设计的方式。
#5 resetn <= 0;
#20 resetn <= 1;如果您改为把这两个信号置于某个任务中，将其称为“apply_reset”任务，那么您就创建了一个组件，这个组件不仅可复用，而且其中隐藏了用于断言该组件有效的信号和时间间隔的详细信息。这就是我们开发测试激励文件时想要的功能，即隐藏详细信息，这样编测试编写者不需要考量使用这些任务的方式，而是改为专注于思考使用这些任务的时机和原因即可。测试编写者最终即可使用任务、配置环境并编写代码来测试设计。
module tb_top;
bit resetn;
task apply_reset ();
#5 resetn <= 0;
#20 resetn <= 1;
endtask
initial begin
apply_reset();
end
endmodule单击此处获取另一个完整的 SystemVerilog 测试激励文件示例 |
|
发表于 2023-3-12 22:22:10