验证符合AXI/ACE标准的互连的策略：第一部分

用于片上系统 （SoC） 中功能块连接和管理的 AMBA 4 规范现在具有支持多核计算的高级可扩展接口 （AXI） 一致性扩展 （ACE）。ACE 规范支持跨多核处理器群集的系统级缓存一致性。对这种系统的核查提出了重大挑战。在规划这样一个系统的功能验证时，我们需要有一个有效的测试策略，以确保不仅测试协议的所有方面，而且确保以最少的努力捕获错误。换句话说，我们需要有一个分层测试策略，从简单的序列发展到更复杂的序列。目的是用更简单的序列捕获尽可能多的问题，这样当我们移动到问题空间更大的更复杂的序列时，我们需要处理的错误就会减少。在本系列中，我们将提出这样的分层验证策略。本系列中的每篇文章都将描述：

正在测试的高级功能以及用于测试这些功能的序列

在此测试级别中，DUT 面临的常见问题

ACE 的分层测试 从 ACE

的角度来看，我们应该在每个层次结构级别测试什么？这些可能是：

集成/连接测试

系统是否正确连接？

每个主站能否正确访问系统中的每个从站？

互连路由事务是否正确？

互连是否正确写入/读取数据？

基本一致性事务测试

ACE 协议使用许多不同类型的事务。这些事务中的每一个都可以由具有许多不同状态的相应缓存行（以下称为初始缓存行状态）的主服务器启动。对于这些州中的每一个，都有允许的法律回应。随着最终缓存行状态（事务结束后）由各种配置选项确定，问题空间变得更加复杂。我们需要确保测试每个初始缓存行状态的所有响应类型。在此级别的测试中，我们确保系统针对每种交易类型正确且一致地工作。

涉及访问重叠地址的测试

该规范给出了当两个主站访问相同/重叠地址时互连要遵守的几条规则。在此级别的测试中，我们执行序列以确保对重叠地址的所有访问都遵循这些规则

DVM 和屏障交易测试

全面的随机测试（包括对重叠地址的访问）

在这篇文章中，我们将详细说明分层验证的第一个方面。

集成和连接测试

前面已经提到了集成和连接测试的关键验证要求。验证 IP 通常提供用于生成相关流量的现成序列。VIP附带的一组此类序列或序列库可以用作满足用户要求的起点。这使用户能够在适当的仿真阶段方便地使用它们，并修改与其DUT相关的所需参数。因此，即使对于集成测试，用户也可以利用VIP附带的一些基本序列。让我们看一下可用于此目的的序列类型。鉴于我们想要查看所有有效路径，我们应该有一组序列，这些序列将从 ACE/ACE_LITE 主站启动 WriteNoSnoop 和 ReadNoSnoop 事务，该主站使用属性指定，例如port_id，可以是随机端口或用户配置的特定端口。“port_id”是一个属性，可以配置为控制要从中启动事务的端口。然后，应在系统中的所有主服务器上运行这些序列。

下面是一个示例。以下代码片段显示了如何配置 port_id 属性：

uvm_config_db#（int unsigned）：：set（this， “env.axi_system_env.sequencer.svt_axi_ace_master_readnosnoop_sequence”， “port_id”， 1）;

此属性的默认值可以根据系统中的主节点数量随机化为有效值。

我们还需要确保主站访问系统中允许它访问的所有从站，以便测试所有路径。为此，我们需要根据系统地址映射来约束地址，以便我们可以确保覆盖所有路径。这可以通过定义自定义约束来完成。

这就是我们如何在从主端启动的事务上创建自定义约束：

类cust_svt_axi_master_transaction扩展svt_axi_master_transaction;
兰德整数 slave_port_id = 0;
约束 valid_slave_port_id {
slave_port_id 在 {[0：'SVT_AXI_MAX_NUM_SLAVES-1]};
//' SVT_AXI_MAX_NUM_SLAVES 定义系统环境中
从属服务器的最大数量 }
约束cust_addr_ranges_constraint { // 从主服务器 0 访问： if （port_cfg.port_id == 0） { /

/ 访问从属服务器 0

if （slave_port_id == 0） {
addr inside {[0：32'hff]}
}
else if （slave_port_id == 1） {
addr inside {[32'h10000：32'h100ff]};
}
Accesses from master 1 }
else if （port_cfg.port_id == 1） { }
}
endclass

集成测试中的关键验证点和潜在问题

系统连接

SoC 有数百个信号需要连接，而其中一些信号通常连接不正确。如果未连接，VIP 将在这些信号上观察到“X”，并报告指示相同的错误。例如，此错误可能表示互连的主端口和从机[2] VIP之间未连接ARCACHE信号：

ace_system_env.slave[2].monitor [register_fail] 检查 [效果=错误]：执行和失败 – 启用 AMBA 检查：signal_valid_arsnoop_when_arvalid_high_check（ACE_LITE/版本 2.0），描述：当 ARVALID 为高时，监视器检查 ARCACHE 上的 X 或 Z

事务路由

互连必须根据系统地址映射正确路由事务。应该有适当的方法来指定 VIP 的系统地址映射。如果互连路由事务不正确，系统监视器可以标记相应的“事务路由检查”。

数据完整性

此级别测试的一个关键方面是确保数据完整性。写入事务中的数据必须正确写入从站。同样，从从站获取的数据必须正确返回给主站。系统监视器应通过在事务完成后（在启动事务的主服务器上）比较内存中的数据和事务来执行这些检查。系统监视器应具有跨不同数据宽度的端口执行这些检查所需的基础结构。为了使数据完整性检查正常工作，在从属VIP上运行的序列必须更新相应代理中的从属内存实例。如果从属VIP配置为被动模式，则系统监视器应维护内存镜像并根据总线上的活动对其进行更新。如果数据未正确写入/读取，系统监视器应标记数据完整性检查。

在这篇文章中，我们描述了测试策略以及集成和连接测试的关键方面。在下一篇文章中，我们将讨论连贯事务测试，我们将进入有趣且具有挑战性的缓存一致性世界。

审核编辑：郭婷