基于功能覆盖率的MAC的UVM验证*

徐梓文 郭桂良

（1.中国科学院大学 北京 100049）（2.中国科学院微电子研究所 北京 100029）

1 引言

随着集成电路制造技术的不断进步，以片上系统（SOC）为代表的数字集成电路发生了跨越式的发展，设计的复杂程度和规模大幅增加，这给验证工作提出了全新的要求与挑战。相关研究表示，验证已经占据了整个数字前端流程70%～80%的工作时间［1～3］，传统的验证手段已经难以满足新的要求。在这种背景下，如何找到快速高效的验证手段，成为了一项很有价值的研究工作。

近年来，各大EDA厂商都在努力推出自己的验证解决方案，诸如VMM等等。每种解决方案都有各自的优势，但是始终没能做到兼容所有的应用场景。2011年，UVM验证方法学横空出世，凭借其良好的性能得到了绝大多数先进IC公司的青睐。如今，UVM验证方法学已经正式成为了IEEE 1800.2-2017标准［4］。

媒体访问控制器（MAC）实现了上层数据和物理层比特流的封装和解封、流量的控制、检验检测和载波侦听多路访问的信道存取等功能，保障了以太网数据的高带宽、低延时传输。

2 UVM验证方法学和以太网控制器

2.1 基于CVD的通用验证方法学

通用验证方法学UVM是由三大EDA厂商Syn⁃opsys、Cadence、Mentor协力打造，由Accellera组织负责发布的一种标准化的验证方法学［5～6］。UVM本质上是一种基于SystemVerilog语言的一个库，它将验证中需要使用到的各项功能进行划分和标准化，使得验证工程师可以采用类似堆积木的方式来搭建自己的验证平台。由于UVM引入了大量的标准化模块，这使得基于UVM的验证平台具有了极强的可复用性。当待测设计（DUT）发生改变时，只需要改变与DUT相关的功能模块即可实现测试平台的复用。

基于覆盖率驱动（CVD）的UVM验证平台是指在验证平台运行时，除了在scoreboard（计分板）中对DUT反馈的数据做判断外，还会在各个monitor（监视器）中增加大量的CoverGroup（覆盖组）来对采集到的数据加以分析。只有当收集到的数据覆盖到所有CoverGroup中的全部CoverPoint（覆盖点）时，即功能覆盖率达到100%时，我们才可以认为该DUT的所有功能均已被测试［7］。

2.2 媒体访问控制器

在ISO组织制定的国际标准中，引入了OSI（开放式系统互联通信参考）模型，该模型定义了计算机之间的互联通信标准，共分为7层。OSI模型从下到上依次是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层，其中的数据链路层又分为三个部分，分别是：逻辑链路控制（LLC）子层、媒体访问控制（MAC）子层［8～9］。MAC子层的作用是屏蔽不同的物理层带来的差异性，使得上层网络可以操作不用的PHY（物理层）芯片［10］。

本文研究的MAC控制器便是采用MAC协议进行数据收发的IP，采用XGMII（10Gb独立于媒体的接口）进行通信。

3 本研究的验证平台

本文的验证平台的结构如图1所示，这是在标准UVM验证环境的基础上进行搭建的验证平台。

图1 UVM验证平台架构

由于DUT主要分为与片内通信的帧传输接口、寄存器控制接口、xgmii传输接口，本文构建了packet_in、packet_out、reg_access、xgmii_tx、xgmii_rx五组interface和agent。

Agent是根据数据包的功能进行划分的［11］，由于一组功能相关的数据接口都是同时使能或者屏蔽，几乎不会出现单独使用一组功能接口中某一个单独信号的情况［12］。因此，本文在设计env的时候，引入了名为is_agent_active的参数，且五组agent对应五个不用的is_agent_active参数。当is_agent_active置高，即参数有效时，表明该组数据接口需要被验证环境驱动，对应的agent才会被实例化到env中；相应的，当is_agent_active为低时，表明该组数据接口在本次测试用例中，不需要接受验证环境的驱动，该参数对应的agent就不会被实例化到env中。本文中的5个agent对应5个参数，这些参数通过uvm_config机制，从test_case这一层级，即用户接触到的层级中进行配置，用户只需要编写好testcase即可自动完成。这样做便可以根据testcase的实际需求不同，来快速实现不同的验证环境，用最精简的验证环境来完成需要实现的任务，以节约仿真所需的内存开销，减小仿真需要的总时长。

4 测试点以及测试用例

根据待测设计的功能，本文对以下几个功能进行验证。

表1 待测电路功能点划分

4.1 时钟的验证

控制各时钟的使能信号，观测对应的时钟输出频率是否满足要求。验证时钟树上不同时钟之间的相位差关系以及同源时钟的分频关系，故将时钟信息纳入功能验证覆盖点。

4.2 复位的验证

在正常的工作状态下，随机产生一个等候时间，在此时间之后产生复位信号，并观测各寄存器是否复位成功。复位之后释放复位信号，重新使能，观测系统能否正常工作。

4.3 数据帧传输的验证

时钟使能之后，通过总线agent配置相应的寄存器使DUT进入工作状态。即配置TX与RX的使能寄存，使DUT可以进行数据的收发。此时需要调用UVM_INFO机制，将每次的收发信息进行打印对比，并将其纳入测试覆盖点。根据每次运行的testcase的不同，观察系统是否能正常工作或者给出中断信号等错误响应。

发送入栈引擎接受数据包，并将他们存入发送FIFO（先进先出存储队列）；发送FIFO的每一个入口均指向一个［71：0］的存储空间，其中低64比特存储该帧的数据，高8比特存储该帧的帧信息，具体存储格式如图2所示；发送出擎分为两个状态机，分别控制帧数据的封装、CRC校验逻辑计算延时等待和帧数据发送过程的错误处理。

图2 FIFO中数据存储的格式

接受入栈引擎通过gemii接口接受帧数据，它也包含两个状态机，分别控制帧数据接受过程的错误处理和帧数据的解封、CRC校验逻辑计算延时的等待，如果校验通过则会将剩下的数据写入接收FIFO［13］；接收FIFO的存储格式和发送FIFO相一致；接收出栈引擎则将接收FIFO的信息反馈给上层逻辑，使得其他用户可以得到接收到的数据信息。

图3 发送出栈引擎的工作流程

通过对MAC处理器工作逻辑的分析，本文将发送接口和接收接口相连接，将发送的数据和接收到的数据进行对比，将FIFO中的各个状态加入测试点。如果所有功能测试点都能100%覆盖，则说明验证充分全面［14～16］。

5 实验结果与分析

5.1 一个完整的数据收发周期

一个完整数据发送周期的波形如图4所示，首先是CPU对寄存器进行了配置，设置了发送模式使能，打开了各项中断位。发送数据帧经过解码存入了发送FIFO，并且随即从发送FIFO中取出。接下来CRC校验逻辑对该帧的数据进行了CRC值的计算，根据mac协议完成了数据包的封装，进入发送阶段。在发送出栈状态机的控制下，由于没有侦测到PHY接口上有远程错误信息，该数据帧的各个数据段按照MAC协议依次经xgmii接口进行了发送。

图4 数据发送过程的波形

为了加快验证，本文在testbench中将xgmii的发送口与接收口连接到了一起，即mac控制器会接收到自己发送出去的数据。从波形图上可以看出，接受到的数据和发送数据完全一致，CRC校验通过，接收到的数据帧符合mac协议。通过testbench的对比，发送的数据字段和接受的数据字段一致，该mac控制器可以正常工作。

5.2 功能覆盖率的结果与分析

图5 是经过回归测试之后的覆盖率统计结果。回归测试是在大规模随机测试之后，针对没有覆盖到的区域编写定向测试用例，功能覆盖率达到100%。

图5 功能覆盖率的实验结果

在随机测试用例中，大部分的功能点都已经被覆盖，只有不足10%的bins没有被完全覆盖掉。针对这种情况，本研究编写了定向测试用例，即对DUT施加确定的激励，使随机测试用例中没有被覆盖到的功能也能通过仿真来实现。理论上，只要仿真时间不加以限制，随机测试用例足够多，总能实现100%的完成功能覆盖，但是这样做会耗费大量的时间与计算资源，延长了项目的开发周期，变相地降低了产品的竞争力。

6 结语

UVM作为目前最通行的数字芯片验证手段，虽然其前期平台搭建和测试用例的编写会耗费大量时间，但是其高度的可重用性和清晰的结构也给验证人员带来了无可比拟的便利性。本研究提出了一种基于UVM的以太网控制器IP的验证环境，并且成功达到了功能覆盖率100%的验证目标，在实际的芯片开发流程中具有相当重要的应用价值。