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

对于要验证的 DUT 的每个功能特性，所有可能的激励生成都是通过测试用例并在记分牌、模型、检查器和断言的帮助下开发的。

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

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

执行流量可追溯性

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

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

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

场景

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

在这种情况下，为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_《》方法中使用不同的索引进行采样。

代码示例