基于UVM和VIP的AXI总线互连矩阵验证平台设计

杜越 吴益然 郑杰良

（中国电子科技集团公司第五十四研究所 河北省石家庄市 050081）

1 引言

总线互连矩阵是系统芯片（System on Chip，SoC）中实现CPU、DMA、高速接口等模块之间交互所必不可少的组成部分，随着SoC集成度的提高，总线设备数量及吞吐率迅速增长，总线互连矩阵的复杂度显著提高，对总线互连矩阵的设计和验证已成为整个SoC开发的关键工作之一。AXI（Advanced eXtensible Interface）总线协议作为一款面向高带宽、低延时的片内总线协议标准，广泛应用于各类SoC中。研究基于AXI的总线互连矩阵的验证方法对SoC芯片的开发具有重要意义。

在SoC开发的早期，互连架构方案并不是完全确定的，总线矩阵的各项参数可能随项目的进展发生调整，这要求验证平台具有足够的灵活性与扩展性以快速适配待测设计的变化，同时，验证平台要具备充分的可靠性，这些要求对总线互连矩阵的验证提出了挑战。

UVM验证方法学因具备良好的扩展性和重用性，已成为被业界广泛采用的新一代验证方法学。与此同时，随着验证语言和验证方法学的的发展，VIP的概念逐渐形成。VIP作为一种可重复使用的验证组件，实现了对标准接口协议功能的封装。使用VIP有助于简化环境搭建工作，缩短验证时间。因此，结合使用UVM方法学和VIP技术是进行总线互连矩阵验证的合理选择。

本文在分析了总线互连矩阵的特点与验证需求的基础上，采用UVM验证方法学，使用成熟的商用AXI VIP搭建了总线互连矩阵验证平台，并完成了对待测总线互连矩阵的仿真验证。实践表明该平台具备良好的灵活性与扩展性，能够有效地提高验证效率,并且可有力保障总线互连矩阵的设计质量。

2 UVM验证方法学和VIP

UVM验证方法学以SystemVerilog类库的形式实现了验证环境的可重用机制，其提供了大量基类和方法将验证平台的结构、验证的实施过程标准化、层次化，具备良好的可重用性和规范性。

UVM验证平台的基本框架如图1所示，待测设计（Design Under Test，DUT）的端口信号被打包成接口并与验证环境进行连接。验证环境顶层ENV内部包含若干验证代理（agent），agent是实现特定协议功能的验证组件，其可对DUT施加激励或监视DUT的输出，reference model用于得到输出期望值，Scoreboard将reference model和monitor分别送来的数据进行比较，用来判断仿真是否通过。

图1：UVM验证平台基本框架

VIP是封装了特定的总线或接口协议的、可重用、可灵活配置的一组验证组件，这些组件是已被验证过的、严格遵循标准协议的行为模型。目前主流的EDA厂商已推出了各种协议的UVM VIP。利用VIP，验证人员无需对接口协议的实现细节充分了解，只需要在UVM验证平台中正确集成相应接口协议的VIP，就能够产生各种符合协议要求的激励，并自动对输入输出信号进行协议检查。例如，对于图1所示的UVM验证平台，如果DUT的输入接口遵循某种接口协议，则可使用相应协议的VIP替换图中in_agent的位置，从而避免了对in_agent进行建模与调试的繁琐过程，大大缩短验证环境搭建周期。同时，VIP具有良好的可移植性，基于VIP搭建的验证环境和用例可以方便的在不同层次乃至不同项目的验证环境之间移植。因此，结合使用UVM和VIP技术，可以较快捷地搭建出层次化、可重用并且功能完备的验证平台，减少环境准备和用例开发时间，从而显著提高验证工作的效率。

3 总线互连矩阵

总线互连矩阵作为SoC中各外设交互的桥梁，是数据流的必经通道，因此也是验证工作的重点。

总线互连矩阵一般由一个或多个总线桥组成。总线桥是构成总线互连的主要模块，其示意图如图2所示，其具备若干总线主机接口和总线从机接口，其中S0、S1……Sn为主机接口，M0、M1……Mn为从机接口。总线桥实现了特定数量总线主机和总线从机的点对点互连，不同的主机可以访问到的地址空间可能是不同的，也可能是重叠的。总线桥内部通常包含输入逻辑，地址译码，总线仲裁和输出逻辑几部分，可以完成数据流交换，地址分配，共享资源的优先级确定等功能。

图2：总线桥结构示意图

对于复杂的SoC，由于其总线设备数量较多，不同类型的总线设备所需要访问的地址空间往往不尽相同，并且不同设备对总线吞吐率也有着不同的需求，因此总线互连矩阵一般采用图3所示的多个总线桥相拼接的互连拓扑方案，以在满足功能和性能要求的前提下，实现较优的面积与功耗。在这种互连拓扑中，不同的总线桥可能工作在不同的时钟频率下，不同时钟域的总线桥之间通过专门的跨时钟域模块进行连接。

图3：多级总线桥拼接的总线互连矩阵

在SoC设计与验证的早期阶段，其互连架构方案与具体代码往往是不稳定的，总线互连矩阵的工作频率、所支持的总线设备数量、总线接口信号位宽甚至总线互连的拓扑结构等都可能发生变化。这就要求总线互连的验证环境具备高度的灵活性，能够及时适配总线互连设计发生的变化，并产生符合要求的激励。根据第2章的分析，结合使用UVM和VIP技术，可满足对验证环境灵活性、扩展性的要求。

4 基于VIP的总线互连矩阵验证平台

本节以图3所示的互连矩阵为待测设计，对本文所提出的总线互连矩阵验证平台的搭建进行介绍。该验证平台基于UVM验证方法学，使用商用的AXI VIP来模拟互联矩阵所外接的各主机和从机的行为。

验证平台的框架如图4所示。UVM环境的顶层ENV中集成了virtual sequencer以及AXI VIP提供的验证组件AXI_VIP_ENV。在测试用例顶层中创建了AXI VIP的配置类的对象，并将其传递给AXI_VIP_ENV。AXI_VIP_ENV根据获得的配置信息，在build_phase创建一系列的master agent和slave agent。Master agent作为总线主机与总线互连矩阵的主机接口相连，在运行于其上的sequence的控制下发起各种总线读写操作；slave agent作为总线从机与互连矩阵的从机接口相连，在运行于其上的sequence的控制下对收到的总线读写操作进行响应。Virtual sequence运行于virtual sequencer上，负责调度各agent产生并发送测试激励，从而对总线互连矩阵各个数据通路进行验证。

图4：AXI总线互连矩阵验证平台框架

下面分别从AXI VIP的集成、层次化sequence结构的建立以及覆盖率驱动验证（Coverage Driven Verification，CDV）的实现三个方面对验证平台搭建的关键之处进行说明。

4.1 在平台中集成AXI VIP

AXI VIP在验证平台中的集成与配置流程如下所述。

（1）生成AXI VIP代码：验证人员运行VIP自带的脚本，根据验证需求，生成AXI VIP的相关组件的代码。

（2）在UVM环境中集成并配置AXI VIP：在UVM环境的顶层ENV中声明并创建VIP提供的验证组件AXI_VIP_ENV的对象实例。然后修改AXI_VIP_ENV的对象的配置类的代码，根据DUT的参数，对AXI_VIP_ENV内所包含的master agent和slave agent的个数、各agent的总线协议版本、数据位宽、ID信号位宽、地址位宽、outstanding能力等进行配置。对于slave agent，还需要配置其地址范围。

（3）在验证平台中将UVM环境与DUT相连：在验证平台的顶层代码中例化VIP提供的master接口和slave接口，将其逐个与DUT的各总线主机端口信号与从机端口信号相连，每个接口的时钟信号都应与其所连接的DUT的总线端口信号的时钟相同。然后，通过uvm_config_db机制将各接口传递到UVM环境中AXI VIP的的相应agent中，从而实现UVM环境与DUT的连接。

4.2 建立层次化的sequence结构

在UVM环境中，sequence被启动后会生成总线读写的transaction并将其送给sequencer，最终通过driver将信号级的激励施加给DUT。通过在UVM环境顶层启动不同的sequence，即可对DUT施加各种各样的激励。

本文利用UVM对sequence嵌套调用的支持，根据验证需求构建了层次化的sequence结构，构建方式如下：

（1）将环境中的sequence分为3层，分别为底层sequence、中间层sequence和顶层sequence。

（2）底层sequence运行于各master agent的sequencer上，完成对指定地址或随机地址的单笔读写操作和数据对比。

（3）中间层的sequence运行于AXI_VIP_ENV内的各master agent的sequencer上，可多次调用底层sequence，并对底层sequence传递地址、突发类型、数据位宽等参数，完成对一系列指定地址或随机地址的多笔读写测试。由于各个总线主机所能访问的地址范围不尽相同，所以对每一个master agent，理论上都需要有特定的第二层sequence与其对应，但如果存在多个master所能访问到的地址范围一致、且master数据位宽相同的情况，那这些master可以共用同一个中间层sequence。

（4）最顶层的virtual sequence运行于UVM顶层ENV的virtual sequencer上，其根据测试需求，通过多次调用中间层sequence，调度多个master agent并行或串行地发起总线读写。

采用上述sequence实现方案，使得各层sequence分工明确，耦合度低，对某一层的修改不影响其他层，且每个sequence的代码量控制在了较少的水平，易于维护和修改。

4.3 覆盖率驱动验证的实现

覆盖率驱动的验证CDV是保证验证工作完备性的重要手段，覆盖组（covergroup）和随机测试用例是实现CDV的基础。本文提出的集成了AXI VIP的UVM验证平台对CDV有着很好的支持。

4.3.1 覆盖组的创建

覆盖组的创建通常需要验证人员细致地识别出DUT的各项功能点，然后针对这些功能点进行覆盖组的代码编写，这个过程往往消耗了验证人员相当多的工作量。在本验证平台中集成了商用的AXI VIP，VIP本身提供了丰富的覆盖组，如图5所示，这些覆盖组对AXI协议的各项功能点进行了细致的划分，包括各接口信号的取值、各信号取值的交叉覆盖、outstanding个数等。只需要在VIP的配置中使能覆盖率统计功能，在仿真运行时，仿真工具就会对VIP提供的各项功能覆盖率进行实时的收集，从而大大减轻了验证人员的搭建环境的工作量。

图5：AXI VIP提供的部分覆盖组

4.3.2 随机用例的开发

随机测试用例开发的关键在于对底层sequence产生的transaction施加合理的约束。在本环境中，利用UVM方法学良好的扩展性，可以方便地对transaction施加各种约束以满足不同用例的需求。

在本验证平台中，总线transaction的基类为bus_trans，为了实现对transaction的约束，可以从该基类中派生出类cust_bus_trans，并且在cust_bus_trans中针对各成员变量定义约束，然后使用UVM的重载机制将环境中的bus_trans类型的对象整体替换为cust_bus_trans类型，即可实现对总线transaction的约束。图6为在cust_bus_trans类中定义约束的部分代码，可见验证人员能够对突发类型和长度、数据位宽、所访问地址范围等参数进行约束，从而实现对随机激励的灵活控制。

图6：总线transaction约束定义代码

本文提出的总线互连矩阵验证平台具有良好的灵活性与扩展性，表1中列出了验证平台支持的部分配置参数，在开展验证工作时，只需提取出DUT的各项参数，并对验证平台进行相应配置，即可获得适配DUT特征的验证环境与测试激励。

表1：验证平台的主要配置参数

5 仿真与结果分析

使用第4章中搭建的总线互连矩阵验证环境，对图3所示的互连矩阵进行了仿真验证。仿真采用直接测试与带约束的随机测试相结合的方式进行。

表2中列出了总线互连矩阵的某主机（下文用master0指代）接口相关的测试用例，其他总线接口相关的用例也与此类似。在仿真时，通过直接用例测试典型场景和一些边界情况，通过更改随机种子，反复运行随机用例来覆盖其他的情况，对总是覆盖不到的测试点，针对性地构建直接用例来命中，最终实现覆盖率的收敛。

表2：master0接口相关测试用例

验证环境对DUT的master0接口发起总线读写的波形如图7所示。可见图中总线主机发出了一系列AXI写操作和AXI读操作，并收到了相应的总线响应。这说明总线互连矩阵成功完成了对AXI读写请求的转发，同时也表明验证平台的master agent能够对DUT发起符合AXI协议的读写操作，slave agent也能够正确地响应来自DUT的读写请求。

图7：master0接口总线读写波形

图8和图9为覆盖率报告。覆盖率报告说明，经过直接测试和覆盖率驱动的随机测试，功能覆盖率和接口信号的翻转覆盖率达到了100%，总线互连矩阵的功能得到了充分的验证。

图8：接口信号翻转覆盖率报告

图9：功能覆盖率报告

6 结语

本文针对使用AXI协议的总线互连矩阵搭建了相应的验证平台，并完成了仿真验证。验证环境采用UVM验证方法学，并且使用了AXI VIP作为验证环境中的总线主机和从机模型组件，这使得环境在具备良好的可重用性与灵活性的同时，大大提高了可靠性，并降低了环境的搭建难度。仿真结果表明，该验证环境可有效完成 AXI总线互连矩阵的验证工作，为SoC的开发提供有力支撑。