基于UVM的PCI Express总线控制器验证平台

赵 赛，闫 华，丛红艳，张艳飞

（无锡中微亿芯有限公司，江苏无锡 214072）

1 引言

当今系统级芯片（System of Chip，SoC）的设计大多数为软硬件协同、数字模拟混合设计，让功能设计的复杂性日益增加。如果使用较高抽象层次的设计方法来优化和改进设计，会增加验证的复杂度，当前的验证策略仍然是基于仿真寄存器传输级的传统方法，验证无法跟上设计的步伐。对于验证的挑战是在电路原型期内，不牺牲功能覆盖率以提高验证流程的速度。集成是另外一个重要问题，对系统级进行功能划分然后同步运行，要保证芯片功能的仿真结果与设计意图完全相符，以满足系统可靠性需求[1]。

传统验证平台是由Verilog语言搭建，通过信号层端口与待测对象（Design Under Test，DUT）直接进行信号传输，对端口上的各个信号单独制定驱动逻辑产生输入激励。传统验证平台对每个功能验证点设计直接激励或完全随机激励，再通过运行脚本中不同的选项来输入不同的激励，验证人员通过观察波形文件和日志文件定位功能错误。高速外设部件互连（Peripheral Component Interconnect Express，PCIe）总线用于各种计算和通信平台的高性能、通用I/O互连设备，PCIe充分利用点对点互连、基于交换机技术以及分组协议上的最新进展，使得性能和功能达到一个新的高度。PCIe支持电源管理、服务质量（Quality of Service，QoS）、热插拔、数据完整性以及错误处理等功能[2-3]。PCIe设备包括4层：系统层、事务层、数据链路层、物理层。系统层接收从驱动层及以上发起的或者在系统层发起的命令，并管理所有配置寄存器和状态[2]。PCIe接口信号数目较多，内部模块的信号数量庞大，对错误行为直接观察检测定位可行性极低，验证人员需要花费很多的时间和精力完成验证目标；且验证平台按接口协议进行设计，由于不同协议接口的特殊性，验证平台很难被重用。

由于PCIe逻辑功能复杂，验证向量空间以指数级增加，为每个功能验证点设计直接激励不现实。但采用完全随机激励可能对功能验证点进行重复触发，遗漏某些功能验证点，随机出来的激励可能有一部分对DUT验证没有实际意义，导致验证效率和质量下降。例如PCIe状态机状态较多，为了全面验证PCIe功能的正确性，验证人员将每种可能的当前状态与进入条件的情况列举并进行验证，验证DUT是否达到正确的状态，这使得验证工作量急剧增加，导致传统验证平台无法完全匹配验证需求。而且传统验证平台缺少功能覆盖率模型，只能进行代码覆盖率统计，无法统计验证计划中已完成的验证功能点数量，不利于掌握验证工作整体进度[4-6]。

UVM是整个电子行业中实现高效开发和重用的验证环境和验证IP（VIP）的一种标准，UVM类库（Class Library）提供System Verilog语言编写的内建组件，可快速开发具有良好架构和可重用的验证组件和验证环境[7]。UVM验证平台为分层次的事务级验证平台，具有随机分布控制等特性，在较高的抽象层次上设计验证用例，减少验证人员设计不同验证用例的时间，从而提高验证效率，可创建坚实、可重用、互操作性高的验证IP和测试平台（testbench）组件[8]。

针对上述问题，本文提出了基于UVM验证方法学的PCIe总线控制器核验证平台，用于验证PCIe协议的所有功能[9]。

2 基于UVM的PCIe总线控制器功能验证平台

2.1 PCIe从设备接口控制器的验证计划

根据对PCIe总线设计规范和项目需求的分析，对PCIe从控制器的验证目标为PCIe控制器所有功能的正确性，一方面是事务层、数据链路层、物理层的模块功能正确性，另一方面是系统级功能正确性，如流量控制、仲裁机制、容错和重传机制、中断处理、低功耗管理等。

2.2 UVM验证环境

PCIe从接口控制器验证平台结构如图1所示，创建的针对PCIe的UVM验证环境平台采用System Verilog语言完成，主要包括9个组件：序列产生器、验证用例、PCIe参考模型、记分板、AXI（Advanced eXtensible Interface）驱动模块、PIPE（Physical Interface for PCI Express）驱动模块、AXI监测模块、PIPE监测模块、功能覆盖率模块。各个组件之间通过端口连接和通信[7,9]。

图1 PCIe从接口控制器验证平台结构

PCIe可以配置为两种模式：根复合体（Root Complex，RC）和终端（Endpoint，EP）。该验证平台为了适配PCIe不同的模式，同样也配置了以上两种模式。当PCIe设计作为EP时，PCIe验证模块作为RC；当PCIe设计作为RC时，PCIe验证模块作为EP。PCIe验证平台根据协议遍历各种通信情况来进行数据传输。PCIe设计一端与PIPE接口相连接，另一端与AXI总线接口相连。验证平台通过AXI总线接口对PCIe设计进行配置和控制。当配置好相应的寄存器之后，验证平台完成与待验证模块的初始化、复位、链路初始化以及各个层次事务包的数据通信。验证平台将PCIe设计上传到应用层的数据结果采集到记分板并与期望数据进行自动比较，自动判断功能是否正确，方便验证回归测试（Regression）[7,9-10]。

由于PCIe接口信号数量较多，该UVM验证平台使用虚接口对DUT接口信号和功能进行封装，使验证平台更加简练，更具有可重用性。

UVM验证平台使用受约束的随机为主、直接用例为辅的验证策略。平台中采用受约束的随机化方法增强随机验证的可控性，加快验证收敛速度。对于随机无法覆盖到的验证点，使用直接用例验证。激励随机包括事务层包（Transaction Layer Packet，TLP）的类型，各类型TLP的数据内容及其大小、终端设备地址、路由信息、缓存一致性属性、事务级别等，数据链路层包（Data Link Layer Packet，DLLP）的类型和数据内容以及物理层有序集的类型、数据包的插入错误字段位置。例如将PCIe目标设备的访问地址限制在PCIe存储和I/O空间范围内，并将存储空间和I/O空间分为几个区间段，每个区间的权重通过验证计划制定，减少随机重复或者无意义的存储空间地址和I/O空间地址，也可以对一些特殊的地址编写直接用例，快速覆盖PCIe存储空间和I/O空间地址[6,10-11]。

UVM验证平台使用事务级验证技术，序列产生器根据验证用例生成不同的事务序列，包括链路状态机的初始化以及链路训练，数据链路层的容错和重传机制，对存储器、配置空间以及I/O的读写访问等；再通过AXI/PCIe驱动模块将序列产生器生成的事务序列的每一个事务转化成物理接口信号激励，同样AXI/PCIe监视模块监视DUT实际输出信号，并将其转化成事务数据结构传输给记分板进行比对。相较于传统验证方法，UVM验证平台根据不同的抽象层次划分模块，如果对其他功能相似的接口模块进行验证，仅仅需要修改驱动模块满足接口协议，可大大提高验证平台的重复利用性；而且UVM验证平台提高了抽象层次，更便于对验证用例进行分析调试，也更有利于对事务类型及功能进行统计和管理，收集和分析功能覆盖率信息[11]。

该UVM验证平台添加功能覆盖率模块，根据PCIe控制器的系统规范、接口要求、功能要求、协议规范等明确功能验证点后，分析和编写功能覆盖率点和组。由于验证用例是无法穷尽的，在复杂的设计功能验证中有必要提取和量化验证功能点[8]。例如对于TLP包长的功能点，如果只收集代码覆盖率，完成验证目标需要把所有包长遍历，消耗大量验证时间。如果时间有限，可以将包长划分为最短包长（1 DW）、最长包长（1024 DW）、合法包长（2～1023 DW）、非法包长。根据以上分类编写功能覆盖点，提供了可测量的验证进展指标，根据功能覆盖率数据库中未覆盖功能点可以添加直接验证用例或增加回归次数，进一步优化验证平台。

该UVM验证平台完成PCIe接口模块中的物理层、数据链路层和事务层的全面验证，包括各种错误情况的处理、PCIe接口模块的完备及系统级验证，对PCIe接口模块兼容性方面也有一定的验证。

3 验证结果

在使用UVM验证平台验证PCIe模块时，AXI驱动模块的测试项完成PCIe模块相关寄存器的初始化操作测试。PIPE驱动模块的测试项完成链路状态机的初始化以及链路训练、数据链路层的容错和重传机制以及对存储器、I/O和配置空间的读写访问功能测试。

3.1 PCIe链路训练过程

PCIe IP核的链路训练如图2所示，链路训练及初始 化 过 程 经 历 了DETECT.quiet、DETECT.active、Polling.Active、Polling.Configuration、Configuration.Linkwidth.Start、Configuration.Linkwidth.Accept、Configuration.Lanenum.Wait、Configuration.Lanenum.Accept、Configuration.Complete、Configuration.Idle、Recovery. RcvrLock、Recovery. RcvrCfg、Recovery.Speed、Recovery.Equalization、Recovery.Idle、L0状态，说明PCIe IP核的链路训练成功，且速度从2.5 GT/s成功切换到8 GT/s。

图2 PCIe IP核的链路训练

3.2 数据链路层确认机制

数据链路层的ACK/NAK确认机制仿真结果如图3所示，PCIe核的数据链路层接收到多个DLLP，分析类型为ACK包，序列号为6，表明小于等于该序列号的TLP数据包都已经被对端成功接收，则将存储在重发缓冲区里小于等于该序列号的TLP数据包清除。

图3 数据链路层确认机制

3.3 访问PCIe核寄存器和存储空间

对PCIe寄存器空间和存储空间进行读写操作的仿真结果如图4所示。对PCIe寄存器多个地址空间（0X00D0/0X0000/0X00C4）进行读写操作，验证PCIe寄存器读写功能正确性。对IO空间和存储空间的多个地址空间（0X0010/0X0014/0X0018/0X001C/0X0020/0X0024/0X0030）进行读写操作，验证PCIe存储器空间操作、I/O空间操作功能正确性。从图4可以看出对存储空间地址0X10写入0X01020304，从存储空间地址0X10读出0X01020304，表明存储空间的写入值与读出值一致，可以得出验证PCIe配置空间操作、存储器空间操作、I/O空间操作功能正确。

图4 访问PCIe核寄存器和存储空间

3.4 覆盖率分析

经过多次回归测试和添加直接用例，代码覆盖率信息如图5所示，功能覆盖率信息如图6所示。验证平台得到的代码行覆盖率达到97.29%，功能覆盖率达到100%，代码覆盖率和功能覆盖率均达到要求，提高了验证的完备性，并且检测到设计的错误，及时反馈设计人员修改，确保验证工作按时完成。

图5 代码覆盖率

图6 功能覆盖率

4 结论

本文研究了PCIe总线控制器核的功能验证，针对传统验证方法中存在可重用性低、缺乏代码组织性、极难维护、验证效率低等问题，提出使用一种基于UVM的PCIe总线控制器核的验证平台，针对PCIe总线的协议规范分析和量化功能验证点搭建该平台，实现自动化比对和功能覆盖率收集。该UVM验证平台增加了功能验证的稳健性，可继承性高，可用于类似协议或PCIe下一代协议验证。与传统Verilog验证平台对比表明，验证周期从预估的12个月缩短到9个月，缩短了交付周期；由于UVM验证平台代码可以通过重用得以实现，验证代码减少至传统Verilog验证平台的60%，验证效率得到大幅提升。另外功能覆盖率模块的结果分析可以更加全面、快速地完成PCIe控制器核的功能验证工作。