一种基于UVM的CAN控制器IP验证平台技术领域
本发明涉及芯片的功能验证，尤其是一种基于UVM的CAN控制器IP验证平台，用于
CAN控制器数据包的发送与接收功能，以及对所接收到数据包的正确性测试。
背景技术
近年来，随着芯片集成度的不断提高，芯片的功能复杂度也大大增加，芯片的设计
过程更加容易引入错误，验证工作变得更加艰巨。在集成电路设计中，验证工作占到整个设
计周期的一半以上。而验证的不充分导致的功能错误，是芯片首次投片成功率不高的主要
原因。传统的验证技术已经不能再满足日益增长的验证需求，验证成为集成电路设计中的
瓶颈。
传统验证方法一般采用verilog语言搭建验证平台，抽象层次低，结构缺乏层次化
设计，平台重用性差。由于verilog本身是用于描述硬件的一种语言，抽象层次低，如果设计
的某个改动需要修改验证平台，这种修改往往费时费力。其次，由于平台缺乏层次化设计，
不同项目间重用的可能性很低。另外，传统的验证方法一般采用定向测试，针对罗列的所有
功能点逐个构造测试用例，实现全覆盖，但这种人为的方法总会有所疏漏，不能实现最大程
度的功能覆盖，并且随着电路规模和功能的复杂，功能点的逐一覆盖使得工作量变得异常
巨大。传统验证方法的诸多缺陷已经不能满足当前的设计能力，高级验证方法学的出现正
是为了弥补设计和验证之间的这条鸿沟。
高级验证方法学引入了硬件验证语言SystemVerilog，verilog的一个扩展集，可
以完全兼容verilog。SystemVerilog是一种类似于C/C++的更高抽象层次的编程语言，扩展
性强。它具有面向对象语言的特性：函数、封装、继承和多态，同时还为验证提供了一些独有
的特性，如带约束的随机激励、功能覆盖率等。SystemVerilog是专门用于验证的语言，它使
得验证环境的搭建变得更加高效。但仅仅有硬件验证语言还不够，验证方法学是在硬件验
证语言基础上发展起来一套系统的验证方法。它具备一整套使用硬件验证语言为基础的类
库，这个库中提供的所有方法都可以使验证平台的搭建和测试用例的构造变得更加简单方
便。对于常用的一些方法，验证人员所要做的仅仅是简单的调用库中的函数或是基类，而不
是自己重新使用最底层的语言进行构造。
区别于传统定向测试验证方法，高级验证方法学还引入了随机测试方法，如图1所
示是对这两种测试方法的验证周期和功能覆盖率的比较。采用定向测试方法，使用的测试
时间和覆盖率成正比，随着定向测试用例的增加，功能覆盖率稳步上升。采用随机测试方
法，前期需要一段时间准备随机验证环境，这段时间覆盖率没有增加。当环境准备完毕，运
行随机测试用例会使覆盖率大幅增加，从整个验证周期来看，随机测试方法更具优势。
目前基于System Verilog的验证方法学主要有三种：VMM(Verification
Methodology Manual)是Synopsys在2006年推出的，VMM中集成了寄存器解决方案RAL
(Register Abstraction Layer)；OVM(Open Verification Methodology)是Candence和
Mentor在2008年推出的，OVM引进了功能强大的Factory机制；UVM(Universal
Verification Methodology)是2011年由Accellera推出的，得到了上述三大EDA厂商的共
同支持。UVM几乎完全继承了OVM，同时又采纳了VMM的寄存器解决方案RAL。可以说，UVM继承
了VMM和OVM的优点，同时克服了各自的缺点，代表了当前验证方法学的主流发展方向。
发明内容
本发明要解决的技术问题是克服现有的缺陷，提供一种基于UVM的CAN控制器IP验
证平台，验证的对象选择CAN控制器IP，提供的验证平台采用UVM能以较低的成本，较高的效
率，较为可靠的验证CAN控制器在不同工作模式下的数据收发。
为了解决上述技术问题，本发明提供了如下的技术方案：
本发明一种基于UVM的CAN控制器IP验证平台，该验证平台包括顶层TOP层，是验证
平台的最顶层，用于最顶层模块例化，主要包括：
待测设计DUT，在本例中使用CAN控制器作为DUT；
DUT接口模块interface，包含所有需要用到的待测设计DUT接口信号的定义，用于
验证平台和待测设计DUT的数据通信；
测试用例层test，用于创建不同的验证环境以及产生不同的测试激励。
进一步地，测试用例层test是根据仿真命令行选项+UVM_TESTNAME来例化相应的
测试用例testcase；每个测试用例testcase的test层都继承自base_test类，根据不同测试
用例testcase的实际需求配置不同的验证环境层env和从sequence lib中选择不同的
virtual sequence配置到虚拟激励产生器virtual sequencer，形成不同的测试用例
testcase。
进一步地，验证环境层env，用于根据test层输入的配置参数例化具体的不同验证
组件，包括寄存器访问代理bus_agent、发送端功能验证代理tx_agent或者接收端功能验证
代理rx_agent和结果比对模块scoreboard。
进一步地，寄存器访问代理bus_agent、接收端激励收发代理rx_agent或者发送端
激励收发代理tx_agent都属于代agent模块，其结构类似，包括：
一个激励产生模块sequencer，负责产生符合约束的随机激励，并发送给该agent
中的driver；
一个激励发送模块driver，负责将交易级的传输转换为对应的输入信号并发送到
待测设计DUT的输入端；
一个接口监控模块monitor，负责监控待测设计DUT的输入、输出信号，统计功能覆
盖率；
激励产生模块sequencer和激励发送模块driver之间使用TLM交易级通信方式进
行数据交互，使用阻塞的PORT和EXPORT接口；
激励发送模块driver和接口监控模块monitor之间使用virtual interface指向
顶层TOP层的DUT接口模块interface来访问待测设计DUT的信号；
激励发送模块driver和接口监控模块monitor之间使用TLM交易级通信方式与结
果比对模块scoreboard进行数据交互，使用阻塞的PORT和IMP接口。
进一步地，待测设计DUT的寄存器访问接口采用寄存器模型register model提供；
寄存器模型register model是uvm_reg_block类型的变量，对应待测设计DUT的寄存器，其
内部包含待测设计DUT所有寄存器的列表，其中的单个寄存器是uvm_reg类型的变量，单个
寄存器的某个域是uvm_reg_field类型的变量。
进一步地，寄存器模型register model中的每个uvm_reg_block内部都有一个
uvm_reg_map，用来存储每个寄存器加入寄存器模型register model时的偏移地址，这个地
址一般是偏移地址，当寄存器模型register model进行读/写操作时，uvm_reg_map会将偏
移地址转换成绝对地址来访问；寄存器模型register model的访问最终都将由uvm_reg_
map完成，因此在connect_phase中，需要将转换器adapter和bus_sequencer通过set_
sequencer函数告知reg_model的default_map，并将default_map设置为自动预测状态；
uvm_reg的new函数比较特殊，有三个参数，第一个是name，第二个是寄存器的位
宽，第三个是选择是否加入覆盖率的支持；uvm_reg的build函数中要实例化所有的uvm_
reg_field，并调用configure函数配置field；
寄存器模型register model根据读/写接口的命令生成一个uvm_reg_bus_op类型
的transaction变量，该变量经过转换器adapter转换成uvm_sequence_item扩展类型的变
量并发送给寄存器访问代理bus_agent；转换器adapter有两个重要的函数，一是reg2bus，
其作用是将寄存器模型register model通过sequencer发出的uvm_reg_bus_op类型的变量
转换成bus_component能够接受的形式，二是bus2reg，其作用是当监测到总线上有操作时，
将收集到的transaction转换成寄存器模型register model能够接受的形式，以便寄存器
模型register model能够更新相应寄存器的值；
例化reg_model时需要做四件事：第一是调用configure函数，第二是调用build函
数，将所有的寄存器例化，第三是调用lock_model函数，禁止再加入新的寄存器，第四是调
用reset函数，将所有寄存器的值设置为初始值。
进一步地，虚拟激励产生器virtual seqencer，用以集中管理验证平台内所有
sequencer和virtual sequence模块，其内部没有真正的激励产生器sequencer，而是指向
实际sequencer的指针，内部还包括指向寄存器模型register model的指针，作为平台其他
组件调用寄存器模型register model读/写接口时的句柄。
进一步地，虚拟激励产生器virtual seqencer的好处是可以在同一个函数体内先
后执行不同的virtual sequence，从而避免了复杂用例带来的多个virtual sequence执行
顺序的混乱，方便验证人员管理不同virtual sequence之间的先后顺序；构造测试用例的
时候可以把所有virtual sequence放置在虚拟激励产生器virtual sequencer的不同
phase中执行，比如对于CAN控制器的配置virtual sequence可以放在config_phase，而产
生收发包激励的virtual sequence可以放在main_phase，这些virtual sequence可以按照
不同场景或者分类事先准备好并归总在sequence lib中，由不同的测试用例来选用。
进一步地，结果比对模块scoreboard，负责预期数据和实际数据的比对，并输出比
对结果。
进一步地，结果比对模块scoreboard接收来自激励发送模块driver的预期数据，
并存放在FIFO中；接收来自接口监控模块monitor的实际数据，并从FIFO中取出对应的预期
数据进行比对；比对通过则继续下一个比对，比对失败则打印比对结果以及预期和实际数
据。
本发明使用UVM验证方法学和System Verilog为原理搭建仿真验证平台，相对于
采用verilog语言的传统验证方法，其优势主要分为以下几个方面：
1.整体验证平台是基于事务级建模，验证平台和待测设计DUT之间的通信是通过
DUT接口模块interface，事务级建模的层次相对较高，效率也明显高于verilog，同时方便
覆盖率的统计。
2.UVM验证方法学提供了大量现成的方法库，结合System Verilog可以更加方便
的实现平台的可重用化，同时有更加便于使用的激励随机化和结果比对机制。
3.UVM验证平台的层次化较好，组件的可重用行很高，便于不同项目间的继承的交
叉使用。
附图说明
图1为高级验证方法学引入的随机测试方法与传统定向测试方法的比较图；
图2为本发明验证平台的架构图；
图3为本发明中待测设计CAN控制器的功能示意框图；
图4为本发明中仿真验证流程图；
图5为本发明中待测设计CAN控制器支持的数据帧和远程帧结构；
图6为本发明中UVM平台运行阶段的所有phase列表。
具体实施方式
下面将结合附图和具体实施例对本发明作进一步阐述。
本发明验证平台的架构如图2所示，验证平台包括顶层TOP层，待测设计DUT，DUT接
口模块interface，测试用例层test，验证环境层env，寄存器模型register model，虚拟激
励产生器virtual seqencer，寄存器访问代理bus_agent，发送端激励收发代理tx_agent，
接收端激励收发代理rx_agent，激励产生器sequencer，激励发送模块driver，接口监控模
块monitor，结果比对模块scoreboard。
TOP层是验证平台的最顶层，对CAN控制器DUT、UVM的测试用例层test以及用于连
接DUT和testbench的接口interface进行例化。interface中包含所有需要用到的DUT接口
信号的定义，用于验证平台和DUT的数据通信。
test层是测试用例层，UVM会根据仿真命令行选项+UVM_TESTNAME来例化相应的测
试用例。每个测试用例的test层都继承自base_test类，根据实际需求例化不同的验证环境
env以及virtual sequence，形成不同的testcase。env一般都是可配置的，不同的test会配
置不同的参数给env，而virtual sequence则是从sequence lib中选择出来的适合当前用
例的sequence，简单的两步就能构造出不同的测试用例。
env是验证环境层，用于例化具体的验证组件，包括Bus_agent、Tx_agent/Rx_
agent、scoreboard。Bus_agent、Tx_agent/Rx_agent一般包含一个激励产生模块
sequencer，一个激励发送模块driver和一个接口监控模块monitor。sequencer负责产生符
合约束的随机激励，并发送给该agent中的driver。driver负责将交易级的传输转换为对应
的输入信号并发送到DUT的输入端。monitor负责监控这些信号线，统计功能覆盖率。
register model是寄存器模型，bus_agent中的driver和monitor负责与DUT的信
号交互，adapter是一个转换模块，负责将register model生成的transaction转换成
driver可以识别的transaction。上述组件在环境生成的时候例化生成，验证平台的其他组
件，例如driver想要访问寄存器时可以直接通过寄存器模型的接口来访问DUT内部的寄存
器，验证平台在后台会自动完成其余的事情，大大方便了测试用例的构造。
virtual sequencer是用来集中管理平台内所有sequencer和virtual sequence
的模块，它内部没有真正的激励产生器sequencer，而是指向实际sequencer的指针。比如图
2中的virtual sequencer是指向Tx_agent和Rx_agent的激励产生器sequencer的指针。集
中管理的好处是可以在同一个函数体内先后执行不同的virtual sequence，从而避免了复
杂用例带来的多个virtual sequence执行顺序的混乱，方便验证人员管理不同virtual
sequence之间的先后顺序。
phase机制是UVM控制验证平台运行的手段，什么时候启动、什么时候结束都由不
同的phase来决定。平台的每个组件都会定义很多个不同的phase，这些phase中实现不同的
功能代码，比如例化的代码就放在build_phase，连线的代码就放在connect_phase，任务执
行的代码就放在main_phase等等。UVM的后台phase机制会自动让所有component的build_
phase一起执行，connect_phase一起执行，main_phase一起执行。UVM运行过程中的所有
phase如图6所示。
由于平台使用了virtual sequencer，构造测试用例的时候可以把所有virtual
sequence放置在virtual sequencer的不同phase中执行。比如对于CAN控制器的配置
virtual sequence可以放在config_phase，而产生收发包激励的virtual sequence可以放
在main_phase，这些virtual sequence可以按照不同场景或者分类事先准备好并归总在
sequence库(lib)中，由不同的测试用例来选用。如图2所示，测试用例还需要根据自己的需
求配置合适的env，如果当前想测试CAN发送端的功能，就配置env中的其中一个agent为Tx_
agent，如果想测试CAN接收端的功能，就配置为Rx_agent。
本发明的待测设计(DUT)是一款CAN总线控制器1，它一般用于移动目标和工业环
境中的区域网络控制，有BasicCAN、PeliCAN两种工作模式以及Intel、Motorola两种CPU异
步读写接口，支持CAN 2.0B协议，如图3所示。
接口管理逻辑11负责处理上游微控制器2对CAN的寄存器读写命令。内核模块12负
责CAN协议的处理，按照协议接收和发送数据。发送缓冲器13实际上是若干个寄存器，存储
一个完整的待发信息，该信息由微控制器2通过写寄存器配置。内核模块12读取这部分内容
并按照CAN协议转换为串行数据发送到TX输出端，然后由外部的信号传输单元3发送到CAN
总线(BUS)上。当接收数据时，内核模块12按照CAN协议从RX输入端恢复出实际有用的数据
并将其写入接收缓冲器14。接收缓冲器14也是寄存器，微控制器2通过读寄存器的方式从接
收缓冲器14读取有效数据。
根据CAN2.0B协议，CAN控制器可以发送和接收如图5所示的数据帧以及远程帧，远
程帧不包含数据域，其余部分与数据帧格式相同。帧与帧之间由高电平的帧间隔填充，CAN
接收到第一个低电平信号作为帧起始，仲裁域包含帧ID，用于不同数据帧之间的优先级仲
裁，控制域包含帧类型和数据长度等信息，数据域包含最大8个字节的净荷数据，CRC域包含
CRC序列和界定符，ACK域应答间隙和应答界定符，用于接收方向总线发送应答信号，帧尾由
7个连续的高电平组成。
对于该IP的功能验证主要分为发送端和接收端两部分。发送端由验证平台通过
CPU读写接口对CAN进行配置，使其产生数据帧的发送，然后由验证平台在TX端检查发送的
串行数据是否正确，并且符合CAN协议。接收端则由验证平台产生符合协议的串行数据并发
送到RX端，然后平台通过CPU读写接口取检查CAN是否正确地接收到所发数据。
仿真验证流程如图4所示。验证平台复位后，首先例化TOP层DUT和DUT接口模块
interface，然后根据命令行选项+UVM_TESTNAME的选择例化相应的测试用例testcase。不
同的testcase会从sequence lib中选择不同的virtual sequence并配置到virtual
sequencer。不同的testcase同时会对env层进行不同的配置，主要分为发送端tx_agent和
接收端rx_agent两种。随后testcase开始运行，在virtual sequencer的config_phase启动
sequence lib中相应的config sequence对CAN控制器进行初始化配置。在virtual
sequencer的main_phase中平台的sequencer开始产生随机激励，driver发送激励给DUT，
monitor收集DUT的输出。最后scoreboard比对结果，仿真结束。
发送端：由tx_agent的sequencer随机产生包含一个数据帧信息的transaction并
发送给driver，driver通过寄存器模型register model的接口将数据帧配置到CAN控制器
的发送缓冲器中，然后配置发送命令让CAN控制器的tx端发送数据帧，driver同时将原始
transaction发送给scoreboard。Monitor监控tx端信号，收集到tx发出的完整数据帧并重
新组包形成一个新的transaction。最后monitor将实际的transaction发送给scoreboard，
scoreboard对比driver发送过来的原始transaction和monitor发送过来的实际
transaction，如果结果一致则认为当前验证场景的功能正确。
接收端：由rx_agent的sequencer随机产生一个包含数据帧信息的transaction并
发送给driver，driver按照CAN协议将该数据帧转化为串行序列发送到CAN控制器的rx端，
同时driver将原始transaction发送给scoreboard。Monitor监控rx端信号，当到达帧尾时
monitor通过寄存器模型的接口从CAN控制器的接收缓冲器中读取接收到的数据并重新组
包，将实际的transaction发送给scoreboard。Scoreboard比对两个transaction并输出结
果。
整个验证流程分为从CAN控制器功能特性和CAN总线协议的熟悉，分解功能测试
点，到制定验证策略和验证计划，实现验证平台代码，再到构造验证用例，执行仿真并随着
RTL版本发布回归测试用例，最后得到仿真结果。
本发明基于UVM验证方法学搭建验证平台，克服了采用verilog语言搭建验证平台
的传统验证方法抽象层次低，结构缺乏层次化设计，平台重用性差的缺点。使用专门用于验
证的硬件验证语言System Verilog，抽象层次较高，扩展性强，具有面向对象语言的特性。
平台搭建采用UVM组件化设计方法，平台结构性更好，重用性强，同时还使用了UVM提供的用
于环境搭建的方法类库，大大提高了验证效率。验证过程采用随机测试方法取代传统的定
向测试，用完全随机化的激励实现功能点的全覆盖。
本发明所列举的实施例，只是用于帮助理解本发明，不应理解为对本发明保护范
围的限定，对于本技术领域的普通技术人员来说，在不脱离本发明思想的前提下，还可以对
本发明进行改进和修饰，这些改进和修饰也落入本发明权利要求保护的范围内。