基于UVM的AXI4总线自验证平台设计

隋金雪，张 霞，郁添林，

(1. 山东工商学院电子与信息工程学院，山东 烟台 264003；
2. 北京大学信息技术高等研究院，浙江 杭州 311215)

随着大规模集成电路技术的发展，实现复杂多样的功能，需要更多的知识产权模块(intellectual Property，IP)加入片上系统(System On Chip，Soc)。Soc总线作为实现IP之间高效通信的重要组件，影响整个片上系统的处理速度。实现IP间高效通信成为SOC性能的关键问题。因此验证设计的功能正确性对整个SOC系统的正常运行具有重要作用。

传统的验证方法要求设计者根据被测设计(Design under test，DUT)的信号接口手动编写测试向量，并通过检查相应的DUT来判断设计功能的正确性。这种类型的验证方法具有较低的抽象级别。对于复杂的设计，在功能点验证、不可重用、浪费大量开发时间等方面存在不足。本文采用通用验证方法UVM对AXI4总线模块进行验证。UVM结合了OVM和VMM两种验证方法的优点，得到Synopsys、Mentor和Cadence三大厂商的支持，已成为芯片验证行业通用的验证标准。UVM是一个以Systemverilog类库为主体的验证平台开发框架。通过它的可重用组件，构建一个具有标准化层次结构和接口的功能验证环境。UVM验证方法有效地结合了测试激励的随机生成、自检平台和随机化约束，大大提高了验证的工作效率。

AXI(Advanced eXtensible Interface)是一种面向高性能、高带宽、低时延的片内总线，分为读地址、读数据、写地址、写数据、写响应5个独立的信息通道。主要具有以下几个特点：

1)AXI协议以突发模式(burst)传输，主机只需给出突发传输首地址，从机可以突发传输宽度自动计算后续地址。为了防止突发传输访问两个从机的边界和限制从机所需支持的地址自增数，突发传输不能跨4KB边界。

2)共享地址多数据(Shared-Address Multiple-Data，SAMD)交叉体系结构，具有面向写入和读取数据通道的并行路径。AXI IP最多可接16个主器件和从器件。

3)AXI使用基于valid/ready的握手机制数据传输协议，传输源端使用valid表明地址/控制信号、数据是有效的，目的端使用ready表明能接收信息。具有字节选通机制，可实现非对齐的数据传输。

AXI4与AXI3的主要区别在于对burst长度进行了扩展；
去掉了WID信号，减小了设计复杂度，降低死锁的概率；
增加了用户自定义信号。AXI总线满足高性能内存映射需求，提高了多主多从系统互联的性能和利用率。

3.1 AXI总线功能模型

AXI BFM(bus function model)用于自定义的RTL设计流程验证AXI主机和从机的连接性和基本功能。图1显示了单个AXI BFM，测试平台也可以包含多个AXI BFMs实例。DUT和AXI BFMs在包含时钟和复位发生器的测试平台上进行实例化。然后，测试编写人员将测试平台实例化到测试模块中，并使用BFM API层创建一个测试程序。测试程序将使用fork和join顺序或并发地调用API任务。

用AXI BFM建立DUT的内存模型，从如图2所示的测试结构，将主从bfm直接互联。使用从通道级API的的存储器模型可以创建写数据路径，先等待写地址总线上的任何写地址请求，确保记录第一个检测到的有效写地址握手，并将详细信息传回；
再获取与写地址请求相对应的写数据突发，捕获具有指定id标记的整个写入数据突发；
然后从写数据突发中获取数据并将其放入存储器阵列；
最后确定传输是否互斥，并响应发送回具有与写入数据传输相同的ID标签的从站。或者等待读取地址总线上的任何读取地址请求，在找到读取地址通道传输后；
从存储阵列中获取请求的数据，并以读取突发的形式发送，实现创建读取数据路径的存储器模型。

图1 单总线功能模型测试平台

AXI BFM把底层的操作封装起来，调用这些task或function将其转化成底层信号的动作，将验证的抽象层次从底层信号提升到传输事物层。同时，AXI BFM能自动从错误中恢复，根据问题的严重程度做出停止仿真、打印错误报告或警告信息继续仿真的决策。AXI总线功能模型作为验证平台的独立模块，避免了验证同类型设计的重复开发。不断改进的重用总线功能模型，降低重新构建验证组件带来的风险，简化验证激励的编写，提高验证效率并增强可靠性。

图2 多测试用例平台结构

3.2 验证平台的组件功能

本文设计的AXI4总线功能验证平台如图3所示。顶层是environment，包含读写的request＿scoreboard、response＿scoreboard；
master＿agent、slave＿agent；
axi＿interface。其中读写request＿scoreboard用作记录读写请求是否选择到正确的slave端，并判断id、addr、len、size等信号是否一致。读写response＿scoreboard是判断master端获得的response数据流与slave端发送的一致性。

仿真开始后，运行run＿phase，在master＿agent类中，master＿driver从sequencer得到具体的transaction，判断读写请求方式，并驱动读或写的地址通道，当写请求时还需驱动写数据通道，等待数据传输完成后，清除通道信号，继续等待下一笔数据传输。

master＿monitor派生自uvm＿monitor，对DUT接口进行实时采样，捕获其事务中的数据信息，做进一步分析。master＿monitor把读写请求方式发送至scoreboard，并存至相应的队列。在接收到读写响应后，进入队列检索id，判断一个读写请求是否完成。

图3 验证平台框架

slave＿agent类中的slave＿driver是根据读写请求方式驱动读或写的响应通道，等待数据传输完成的标志位有效后，表示一次传输完成。

slave＿monitor只需要对地址、写数据和读响应通道信号监测，将接收到的读写请求方式发送到request＿scoreboard，并在队列中检索id进行信息比对。在数据传输完成后，把读响应发送到response＿scoreboard，在读响应队列检索响应id对应的数据流。

当slave＿monitor接收到读写请求时，需要response＿handle模块进行处理。如图4所示，response＿handle模块的功能是将slave＿monitor中接收到的request信号，存入空的queue中，同时遍历整个queue，根据request＿id、request＿type、request＿len、request＿size等数据，随机生成相应的response信号，经sequencer发送至slave＿driver的response信号通道。

图4 response＿handle模块

为保证验证平台与DUT通信，需在最顶层的testbench中例化interface，并指向多个virtual interface，同时将config＿db机制用于UVM验证平台间传递参数。将agent类中须例化的driver、monitor和sequencer组件配置active模式，对应DUT接口需要激励驱动和监测的场景，而passive模式对应DUT接口已连接只需要监测的场景。

本文搭建的验证平台采用层次化设计，将自动化执行与调试的多语言脚本文件、rtl级代码、验证测试平台以及编译仿真产生的输出文件层级放置，提高验证平台的可重用性。

3.3 测试用例

验证过程中，需要根据AXI总线的猝发传输、乱序传输等特性来设计测试用例。针对DUT特性的验证需求，制定测试点。在测试用例中启动sequence，向sequencer传输transaction，驱动driver，以测试设计是否符合预期。本文的验证IP设计了多种验证方案，包括带约束随机激励测试，监测AXI4中的len，size，burst，ready、valid等信号，并自动打印信息(uvm＿info)汇总。本文验证IP设计了对于突发传输类型，读写随机传输方式的测试用例。

以FIXED、INCR和WRAP三种突发传输类型，分别对某固定地址进行数据更新；
数据以突发传输基地址为起始，递增量与突发传输尺寸有关；
在初始地址上递增至最高地址界限，回到初始地址继续递增，循环往复。

读写随机传输方式不同于对所有master port进行遍历，直接进行n次随机选择master port，每次随机到某个端口后，随机读写n次地址，地址范围不超过32′h0fffffff。对同一个端口，用不同的突发传输类型交叉，且请求信号必须等上一个请求信号完成后才能触发。

对每个sequence都会进行一系列的配置信息，包括打印信息等级、fsdb文件生成、仿真时间和总线仲裁方式，其部分代码如下：

tags=[′protection′，′dataflow′]，

args=[RANDOM＿SEED＿ARG]，

test＿seq＿name=′+test＿seq＿name=axi＿interconnect＿mixed＿fixed′，

test＿uvmverbosity=′+UVM＿VERBOSITY=UVM＿HIGH′，

test＿dump＿fsdb=′+test＿dump＿fsdb=YES′，

test＿run＿time=′+test＿run＿time=short′，

test＿arbiter＿type=′+test＿arbiter＿type=priority′

用python执行相同的随机数种子，可重复随机出现的实验结果。根据测试用例不同的需求，可调整以上参数选项，降低验证占用的硬件资源，缩短仿真时间。

验证平台搭建完成后用vcs和verdi进行联合仿真验证，根据输出的波形和日志分析工具，参照总线功能模型和dut的一致性，并查看覆盖率和测试用例的通过率，保证验证的完备性。

4.1 波形图分析

由图中看出，AXI总线工作在burst=0和burst=1的模式下，数据从高位开始发送，数据宽度为64位，波形图可以看出当处于INCR突发传输类型时size=2，且请求信号路由到对应的slave端，接收到正确的请求信号，读写响应信号已正确发回对应的master port，响应状态为0。图中还有握手信号，包括猝发读传输和写传输的信号，当ready和valid信号同时为高电平时，表示握手成功，数据有效。

图5 以INCR读写混合为例的各端口波形图

4.2 覆盖率分析

图左侧给出从平台顶层模块top＿tb对主从读写请求以及主从读写响应的覆盖率统计，图右侧是针对具体的覆盖点和断言的bins值。通过增加随机化次数、添加约束、自定义bins、调整hits次数分布，由于代码覆盖率最终覆盖率达到100%，满足验证需求。

图6 AXI4总线部分覆盖率报告

本文基于AXI4总线功能的验证需求，使用UVM搭建可重用的模块验证平台。该验证平台将总线功能模型、测试用例、仿真报告、可执行脚本文件及环境参数层次化构造，提高测试平台的可重用性和自动化水平。验证结果表明，该验证平台能够全面地对AXI4的功能进行验证，达到了预期效果，缩短了验证周期，对同类型总线验证平台的搭建具有一定的参考价值。