使用功能覆盖执行端到端流量可追溯性-电子发烧友网

大多数时候，定义功能覆盖目标是在测试计划准备过程中完成的。对于要验证的被测设备（DUT）的每个功能特性，所有可能的激励生成都是通过测试用例并在记分板、模型、检查器和断言的帮助下开发的。我们通过检查该刺激的响应来确认 DUT 的正确性。为了确保我们创建了足够多的输入场景和 DUT 响应组合，根据覆盖组、覆盖点和断言覆盖为每个特征定义了覆盖目标，这让我们对验证特定特征的彻底程度充满信心。

DUT 的 RTL 块进入从覆盖类别分数定义的变量中，并在具有不同值命中的交叉覆盖组中使用这些变量将确认输入事务是否遵循指定的设计输出路径。出于几个原因，这非常重要。首先，功能验证记分板确实进行端到端事务检查，但它不确认 DUT 流量路径激励已遵循。其次，单个覆盖组或 UVM RAL Regmodel 功能覆盖或断言覆盖将有助于单个刺激覆盖，但组合使用将确保功能路径的正确性。让我们详细看看我们如何使用功能覆盖来确认从输入到输出端口的流量穿过所需的数据和控制路径。

执行流量追溯

很多时候，仅仅涵盖单个特征和交叉特征是不够的。通过遍历不同数据块、各种控制逻辑和不同 DUT 配置的所有可能组合来检查输入接口的流量是否已到达另一端的输出接口，这是一个基本要求。

在控制块接口上具有用于 DUT 输入、输出接口的单独覆盖组，regmodel 自动生成的功能覆盖可能无法保证基于寄存器配置。输入事务、数据包或命令已通过所需的数据块和控制路径，或已绕过典型的控制块。

使用交叉覆盖，在覆盖类之外定义并用于存储来自各种写入方法的事务的变量上，可以确保这些变量的不同值被命中并跟踪设计的 DUT 路径。覆盖组也将在覆盖类之外定义。

设想

让我们考虑一个场景，如图 1 所示。在一个高度配置的 DUT 中，一个输入……一个数据包可以通过选择的数据路径和控制路径块以及通过基于寄存器配置的选择的数据包路由器端口路由到输出端口。带有字段 RT=2‘b01 的寄存器 CTRNL_RUT 使用 Cntrl_plan1、交换机 1（图中未显示）决定从输入端口 1 到 DataPath_blk1 并到路由器端口 1 并最终到输出端口 1 的数据包路径。但是，寄存器 CTRNL_RUT.RT= 2’b10 将使用 Cntrl_plan2 和路由器端口 2 通过 DataPath_blk2 更改新传入数据包的路由。

在这种情况下，为 datapath_block1、控制路径（即 Cntrl_plane1）和寄存器字段 RT 定义的覆盖组将分别覆盖激励值。但是，如果变量定义在覆盖类范围之外，保存来自这些接口的信号值，并且如果在具有有趣值的交叉覆盖中使用，则可以确认数据包已通过正确的路径并实现数据包可追溯性。

图 1 ：在每个点获取信息的交通跟踪

覆盖实施

在测试平台中，环境类通常具有在其中实例化的所有接口代理、功能覆盖和记分板。IO 和控制接口监视器的分析端口连接到功能覆盖类的出口，以获取接口数据包和事务。所需资源，如 regmodel，将使用 uvm_condig_db 构造将不同的配置对象设置为覆盖类。覆盖实现方面，定义变量、覆盖类之外的数据包存储元素，并使用它们复制重要接口信号、控制信号和数据包字段的值。这些在覆盖类之外定义的变量将用于交叉覆盖。

如上图 1 所示，覆盖类之外定义的变量将用于保存数据包 ID 等信息，对 DataPath_blk1 有效。对于控制平面，保存准备就绪、状态、目标 ID、路由通道号等信息。可以将 CTRNL_RUT.RT 值等字段的寄存器值与这些变量交叉，以确保如果 RT 的字段值为 01，则 Datapath_blk1 字段和控制计划信号具有感兴趣的值。使用上述方法实现功能覆盖将很有帮助，尤其是在块和集群级别验证的情况下。覆盖类的独立实现探索了具有类似 DUT 接口的项目之间的可重用性选项。

寄存器配置信息也可以通过接口接收，但又需要解码地址和字段，所以使用regmodel会很有意义。Regmodel 带有丰富的 API 和默认序列集，可以使用它们的属性来运行所有寄存器和字段。基于 Regmodel 的自动生成功能覆盖可以单独处理。

嵌入式覆盖组存在一个已知限制。我们不能使用相同覆盖组的多个实例作为数据类型，因此在功能覆盖类之外定义覆盖组将有助于定义覆盖组数组，特别是如果大多数接口属于相同类型，通常会有所帮助网络域 DUT 的情况。具有多个实例的单个覆盖组可以在覆盖类的每个write_《》方法中使用不同的索引进行采样。

代码示例