基于UVM的远程控制FPGA一体化闭环仿真验证平台

于清华，高赛军

(上海航天电子通讯设备研究所，上海 201109)

0 引言

随着信息量的飞速爆炸，FPGA(Field Programmable Gate Array，现场可编程门阵列)作为提升电子产品速度性能的重要手段，其应用层面越来越广泛面，复杂程度日益提高，FPGA软件的质量和鲁棒性也越来越受到大家的重视，FPGA验证尤其是功能仿真变得尤为重要。特别是航空航天产品，基于FPGA 的应用系统在运行过程中因异常情况发生导致FPGA功能错误，使得下行到地面的数据错误或者丢失，甚至导致单次试验任务失败[1]，需要对系统重新上电复位。如果在地面测试或者仿真验证过程中[2]，针对各种正常和异常的测试场景进行全面测试，则会提前发现软件缺陷，从而降低故障的发生概率。

随着FPGA设计功能繁杂度增加，其门数和复杂度也日益增加，验证难度越来越大，验证充分性和验证效率的提升是验证的致命瓶颈，也是验证设计的主攻方向[3]。传统定向仿真验证方法由于存在抽象层次低、效率低、验证不充分、验证平台重用性差的缺点，难以满足验证的需求。面向对象的验证方法学的产生，能够很好解决传统验证方法的上述痛点，可解决大规模FPGA的验证平台重用性问题，有效的提升验证效率和验证完备性。

基于SV(System Verilog)的验证方法学从VMM发展到OVM，最后进阶到成为整个电子行业统一验证标准通用验证方法学[4]UVM(Universal Verification Methodology)[5]。该方法学由于采用了较佳的验证框架实现覆盖率驱动的验证，并配有受约束的随机验证方法，可有效实现可重用仿真验证环境，大大缩短了验证时间，提高验证效率。

本文以航天某卫星型号远程控制FPGA为验证对象，采用UVM验证方法学搭建一体化闭环仿真验证平台，采用动态数组方法实现了三级激励数据包的嵌套，验证远程控制FPGA功能的正确性。

1 UVM简介

1.1 UVM验证方法学概述

UVM有一套System Verilog的语法和语义定义的具备面向对象编程的类库[6]，使用者通过使用这些类库创建包括驱动器、监视器和记分板等可重用组件，从而提高验证效率和质量[7]。此外，这些类库还包括各种任务和函数，能够完成驱动器的驱动与被测件(DUT-Device Under Test)通信功能，以及实现监视器的监测DUT输入输出接口功能等。最后，UVM还可通过phase、factory等高级机制和寄存器模型等功能，实现了验证平台的高安全性和可重用性[7]。

1.2 UVM验证平台的组成

图1是一个典型的UVM验证平台结构示意图，由1个验证环境env组成，1个env包括2个代理器Agent:In_Agent和Out_Agent，参考模型(reference model)和记分板(Scoreboard)[8]。In_Agent负责驱动和监测总线，Out_Agent负责监测DUT的响应。在In_Agent中，Sequencer负责产生[9]随机测试队列传送给驱动器Driver。

图1 UVM验证平台结构示意图

图1中，in_Agent包含3个组件Sequencer、driver和[10]Monitor，其主要功能是在序列发生器Sequencer调度下产生根据传输协议生成的队列[11]，再由根据约定时序由驱动其Driver驱动到DUT输入端口上。同时，监视器Monitor将产生的队列发送至参考模型reference model[12]。参考模型通常根据需求模拟被测件的行为，产生期望结果并压到期望堆栈中。out_Agent的Monitor[13]用于监测DUT输出，并将实测结果发送至记分板Scoreboard。Scoreboard在收到实测结果后，自动提取来自参考模型的数据堆栈中的期望结果和实测数据进行比较，自动化比对结果。

1)序列产生器(Sequencer)：

主要自动产生受约束的[14]随机化激励数据。

2)驱动器(driver)：

主要负责向Sequencer请求队列，将队列根据特定的传输协议和接口时序转化为输入信号发送到DUT的输入端口。

3)监控器(Monitor)：

负责从驱动器driver输出采集数据，传送到参考模型并转换成期望队列发送给记分板(Scoreboard)，从而完成功能数据结果的比对和覆盖率信息的收集。

4)代理器(Agent)：

通常用于发送端，可封装序列产生器(Sequencer)、驱动器(Driver)、监视器(Monitor)。

5)参考模型(reference model)：

reference model用于完成和DUT相同的功能。reference model的输出发送给Scoreboard，用于和DUT的输出相比较。

6)记分板(Scoreboard)：

比较reference model和Monitor采集到的DUT输出信号，并给出比较结果。

7)验证环境(env)：

UVM验证环境，使用UVM机制将代理器(Agent)、参考模型(reference model)和记分板(Scoreboard)配置在一起。

8)测试用例(test case)：

test case用于例化env，不同的test case用于对DUT的不同功能进行验证。

1.3 UVM的各种机制

UVM是基于System Verilog语言开发的一套开源类库，包括了一系列标准类，如uvm_sequence、uvm_driver、uvm_monitor、uvm_sequencer、uvm_agent、uvm_env等，通过对这些基本类进行继承和重载，结合TLM标准接口和各种机制，可构造多层次可重用的高效验证平台。

1)factory机制：

factory机制是UVM非常重要的一个机制，采用UVM中的宏注册实现factory机制。当某个类经过注册并且实例化后，其main_phase会自动调用。使用factory机制可以在不改变原代码的基础上，调用UVM内部封装的大量功能，实现验证平台组件的重用，提高整个验证平台的重用性。

2)phase机制：

UVM通过phase机制实现了验证流程的细分，在不同的phase中实现相应的任务，或者在不同的phase之间进行跳转，可以更加容易地控制验证的进程，使得验证平台中各组件按照各自的需求自动阶段性执行。

按照是否需要消耗仿真时间，phase可以分成两大类：function phase和task phase，function phase包括build_phase、connect_phase等，不会消耗仿真时间；task phase包括run_phase和main_phase等，通过任务实现，需要消耗仿真时间。整个验证平台按照phase的执行顺序，执行完一个状态，自动跳转到下一个状态。build_phase完成UVM中各个类成员的实例化工作，connect_phase将UVM中各个功能组件实例化对象进行连接，run_phase则运行整个验证平台，按照事务生成器顺序驱动整个平台运行。

3)sequence机制：

sequence机制用来产生激励，包括sequence和sequencer。sequence不属于验证平台组件，但对于验证平台来说处于特殊位置，sequencer只有在sequence出现的情况下才有价值，sequence通过sequencer才能将它产生的sequence传送到驱动器。

sequence指定了DUT需要的transaction类型数据，每一个sequence类都有一个body函数，启动一个sequence时，body函数会自动执行。实际使用时经常使用以下4个宏`uvm_do、`uvm_do_with、`uvm_do_pri、`uvm_do_pri_with来创建transaction的实例，同时对transaction进行约束和随机，并把这些数据通过端口发送到sequencer。当sequencer同时检测到driver和sequence的请求时，将sequence产生的transaction发送给driver。实际程序中通过default_sequence方式启动sequence。

通常采用virtual sequence实现sequence之间的同步。使用virtual sequencer[15]来使用virtual sequence，virtual sequencer里面包含了指向其他sequencer的指针。

4)objection机制：

objection机制通过raise_objection和drop_objection对验证平台组件内部的phase进程进行控制，用于开启和关闭验证平台。

5)TLM机制：

TLM(transaction level model)即事务级建模，是System C的一种通信标准。transaction是把具有某一特定功能的一组信息封装在一起形成的一个类。UVM中内置了各种port，用于实现各组件之间transaction级别的通信。

6)config_db机制：

通过config_db机制，可以修改验证平台的参数，对接口和寄存器进行配置。UVM通过set和get函数实现这一过程。config_db机制可以在不同的层次对同一个参数进行配置。

7)field_automation机制：

field_automation机制是使用UVM中定义好的宏对transaction数据成员进行注册，transaction可以直接调用UVM中特有的内部函数，如比较、复制、打印等。

1.4 验证平台的工作流程

在设计好验证平台之后，当定义好一个test case后，通过在命令行中添加+UVM_TESTNAME指令要启动执行的test_case。仿真器首先进入顶层模块top，当执行到run_test后，启动UVM验证平台。验证平台首先根据+UVM_TESTNAME后的字符创建一个类的实例，然后自动执行该实例的build_phase，创建env，当build_phase执行完毕后，接下来自动执行env中的build_phase，创建env中的验证组件。如此循环，自上而下执行所有component中的build_phase，建立UVM树。执行完build_phase后，执行connect_phase，之后再执行main_phase等phase。当所有的phase执行完毕后，结束仿真。

图2 UVM验证平台工作流程图

2 远程控制FPGA概述

远程控制产品是卫星的重要组成部分，主要完成卫星对地面上传数据的处理、直接指令执行和数据转发。远程控制FPGA是远程控制产品的核心，其主要功能框图如图3所示。首先对输入的远程控制上行数据进行BCH解码、解扰、CRC校验，CRC校验正确后将远程控制上行数据中包含的传送帧写入SRAM缓存，然后再从SRAM读出传送帧进行传送帧解析，当传送帧中数据域为重要指令时，将传送帧包含的内部指令数据指令码和PROM预先存储的指令码表进行比对，比对正确后译码输出相应的48条指令控制信号，传送给外部的BM2711器件进行指令驱动输出；当传送帧中数据域为远程数据包时，根据VCID值的不同，选择将传送帧中包含的远程数据包通过异步串行接口或者两线制通信接口进行转发。

图3 远程控制FPGA功能框图

输入远程控制上行数据帧格式示意图如图4所示，按照执行终端和处理途径分，可以分为遥控包和内部指令。

图4 远程控制FPGA输入远程控制上行数据帧格式图

远程控制FPGA是航天产品中的一种重要工作软件，安全关键等级高，需要测试大量的测试用例，采用传统的定向验证方法耗时耗力，无法进行随机指令组合，无法确保不同数据帧长均测试全面，故很[16]难保证测试的充分性。采用UVM高级验证方法学搭建验证平台，能随机产生符合帧协议的测试队列，并自动比对测试结果，提高测试效率和[17]测试质量，有助于保证航天型号试验任务的顺利完成。

3 仿真验证平台的设计与实现

3.1 验证策略

为了保证远程控制FPGA验证的完备性和高效性，在搭建验证平台前，需要制定验证策略和计划，确定平台应该具有的基本要求和功能。

1)提取验证功能点：

根据远程控制FPGA需求规格说明，需要测试远程控制48条指令执行功能和4种远程控制数据(直接指令、间接指令、直接注数和软件数据)转发功能。

2)设计验证平台架构：

根据远程控制FPGA需求规格说明，DUT需要接受2种格式的输入远程控制上行数据，对应2种数据协议，将验证环境ykzd_env划分为2个Agent：远程控制指令执行代理器Agent和远程控制数据转发代理器Agent。

本文设计的远程控制FPGA验证平台如图5所示。ykzd_env与DUT之间采用虚拟接口ykzd_if进行数据通信。采用自底向上创建代理中的各组件。

图5 远程控制FPGA的UVM验证平台

ykzd_env主要由远程控制数据包代理器主ykzd_master_agent和远程控制指令代理器ykzd_zl_agent组成。如图5所示，利用UVM机制，2个代理器分别封装了相应的序列生成器sequencer、驱动器driver和监控器monitor。验证平台各组件之间的通信以字节为单位，ykzd_if和DUT之间的引脚通信以bit为单位。

远程控制数据包代理器的driver用于随机不定时驱动远程控制数据帧发送给DUT，同时利用ykzd_master_monitor监控驱动队列数据根据队列数据的VCID将传输数据帧数据域提取出来，分别送各自的参考模型rs422_ref和lvds_ref生成期望动态数组堆栈传输给相应记分板rs422_scoreboard和lvds_scoreboard；远程控制指令代理器ykzd_zl_agent用于随机不定时驱动远程控制指令帧发送给DUT，同时利用ykzd_zl_monitor监控驱动队列数据将传输指令帧数据域提取出来，传输给参考模型cmd_ref根据指令匹配生成期望动态数组堆栈传输给相应记分板cmd_scoreboard。3个接收monitor分别监控DUT连接的接口模型产生的实测数据并分别送记分板进行比对，实现整个仿真验证平台的一体化闭环验证。

3)测试激励产生方案：

受约束的随机激励可以根据软件功能需求设置输入数据的约束范围，实现正常情况测试和故障情况测试，本验证平台设置远程控制数据包占空比为直接指令∶间接指令∶直接注数∶软件数据=10∶5∶2∶1，验证平台的ykzd_master_sequencer序列发生器会自动调用数据包transasction按照队列方式产生远程控制数据包。远程控制指令包数据值约束按照PROM与设置的48路指令数据和异常数据指令进行随机分配，验证平台的ykzd_zl_sequencer序列发生器会自动调用指令包transasction按照队列方式产生远程控制指令。

4)结果检查：

通过仿BM2711模块用1 ms时钟频率分别对48路通道输出的指令脉冲信号进行计数，并将通道号和计数器值组成结构作为实测结果传输给cmd_scoreboard，cmd_scoreboard会自动查询期望动态数组，验证指令通道是否匹配，根据计数值检查是否满足80 ms±10 ms指令脉冲宽度要求，并给出日志文件，从而验证远程控制指令执行功能的正确性。

通过rs422_monitor监控仿RS422_rec模块产生的数据，形成实测动态数组发送给rs422_scoreboard进行和期望动态数组进行比对，并打印日志文件，从而验证远程控制数据转发功能中通过异步串行接口转发远程控制数据功能的正确性；通过lvds_monitor监控仿LVDS_rec模块产生的数据，形成实测动态数组发送给lvds_scoreboard进行和期望动态数组进行比对，并打印日志文件，从而验证远程控制数据转发功能中通过两线制通信接口转发远程控制数据功能的正确性。

5)覆盖率分析：

仿真验证覆盖率包括代码覆盖率和功能覆盖率。代码覆盖率统计的是仿真过程中程序代码语句、分支和状态机的执行情况，但是不能从功能点的角度考核设计功能的测试覆盖情况。功能覆盖率是针对功能点的通过比率进行覆盖率统计。本验证平台不仅验证代码覆盖率，还可以通过收集VCID、数据包长度确定远程控制数据转发功能覆盖率100%，通过收集通道指令号确定48路指令和异常指令覆盖和击中情况，从而确定远程控制指令执行功能覆盖率100%。

3.2 验证平台的设计流程

1)设计ykzd_if：

设计虚拟接口模块ykzd_if三线制输入接口KP_CLK1、LOCK_A、KP_DATA1，用于实现验证平台与DUT之间的数据通信。

2)设计队列：

由于要接受2种格式的远程控制上行数据，为了避免相互干扰，方便设计，本文设计了2种队列：ykzd_队列_zl和ykzd_队列。ykzd_队列_zl为远程控制指令执行Agent中的事务级数据包，ykzd_队列为远程控制数据转发Agent中的事务级数据包。

根据功能需求，对2种队列的数据成员变量采用constraint进行约束设置。采用field 机制对2种队列进行宏注册，设计BCH编码函数、加扰函数和CRC校验函数。

3)创建Sequencer：

按照UVM机制创建的sequencer命名为ykzd_zl_master_sequencer和ykzd_master_sequencer。

4)创建驱动器driver：

继承自uvm_driver，将ykzd_transaction_zl转换为信号级，并按照三线制接口时序驱动到DUT输入接口上。创建的driver命名为ykzd_zl_master_driver和ykzd_master_driver。通过虚拟接口ykzd_if连接DUT

5)创建监测器monitor：

发送端monitor用于通过虚拟接口ykzd_if收集DUT端口数据，并把端口数据转换为事务级数据。创建的发送端monitor命名为ykzd_zl_master_monitor(收集指令号)和ykzd_master_monitor(收集数据帧长度和VCID)。创建的接收端monitor命名为RS422_monitor(根据串口协议接收转发串口数据)、LVDS_monitor(在时钟上升沿接收数据，找到帧头并打包成数组)、BW2711_monitor(对各通道脉冲宽度用1 ms时钟进行计数)。

6)创建代理器agent：

为了区分调用不同的transaction，不同的agent代表不同的协议。创建的agent命名为ykzd_zl_master_ agent和ykzd_master_ agent。

7)创建参考模型reference model：

M_rs422_ref参考模型对ykzd_master_monitor监控产生的需要转发的直接指令和间接指令进行参考模型设计用产生给期望结果；M_lvds_ref参考模型对ykzd_master_monitor监控产生的需要转发的直接注数和软件数据进行参考模型设计用产生期望结果；Zl_cmd_ref参考模型对ykzd_zl_monitor监控产生的重要指令进行参考模型设计得到期望的通道号序列。

8)创建记分板scoreboard：

RS422_scoreboard记分板对期望产生的直接指令和间接指令结果与实测结果进行一致性比对，正确打印correct，错误打印error、期望正确数据和实测错误数据；LVDS_ scoreboard记分板期望产生的直接注数和软件数据与实测结果进行一致性比对，同理会自动打印正确和错误结果；cmd_ scoreboard记分板对期望产生指令序列号和实测指令序列号进行比对，匹配一致则打印正确，否则给出丢失的指令号，同时当脉冲指令宽度不满足80 ms±10 ms时报错。

9)创建验证环境env：

根据UVM机制env是验证平台组件的顶层，包含了验证平台的所有验证组件。本验证平台创建的env命名为ykzd_ env，包含了代理器(ykzd_zl_master_ agent、ykzd_master_ agent)、参考模型(M_rs422_ref、M_lvds_ref、Zl_cmd_ref)、监视器(RS422_monitor、LVDS_monitor、BW2711_monitor)、记分板(RS422_scoreboard、LVDS_ scoreboard、cmd_ scoreboard)。

10)创建虚拟激励产生器virtual sequencer：

创建了virtual sequencer，命名为my_vsqr0， my_vsqr0包含了指向ykzd_zl_master_sequencer和ykzd_master_sequencer的指针。在基本类ykzd_base_case中，实例化my_vsqr0，将相应的sequencer赋值给my_vsqr0中各sequencer的指针。

11)仿SRAM模型：

模拟SRAM根据输入的sram_addr[18:0]、sram_data[7:0]、sram_cs、sram_we和sram_oe按照SRAM芯片手册的时序要求，将数据sram_data[7:0]存储在存储区中或者将sram_data[7:0]反馈输出给DUT，同时根据DUT设计SRAM控制时序进行时序参数自动检测。

12)仿PROM模型：

模拟PROM存储指令码表，根据输入的sram_addr[11:0]、rom_ce、rom_oe按照PROM芯片手册的时序要求，输出 sram_data[7:0] 给DUT，同时根据DUT设计PROM控制时序进行时序参数自动检测。

13)创建测试用例test case：

测试用例命名为ykzd_case，继承于基本类ykzd_base_case，而ykzd_base_case继承于uvm_test，包含了虚拟激励产生器my_vsqr0。

14)顶层设计：

顶层为top_tb，定义了虚拟接口ykzd_if，连接DUT和验证平台；例化了DUT和SRAM、PROM、RS422_rev、LVDS_rev、BW2711模型，提供系统输入时钟和上电复位信号。

3.3 验证结果

该平台设计了多个sequence，组成sequence的集合sequence_lib，设计了多个测试用例ykzd_case，每个测试用例ykzd_case对应1个sequence，分别单独测试远程控制指令执行功能、远程控制数据转发功能以及帧头错误、帧尾错误、CRC校验错误、BCH编码错误等异常情况。

将多个sequence用virtual sequence进行统一管理，将virtual sequence作为某个测试用例ykzd_case的default_sequence，对远程控制指令执行功能、远程控制数据转发功能的正常情况、异常情况进行组合测试。通过RS422_rev模型和LVDS_rev模型接收数据，并通过监控模块和参考模型输出在对应记分板中进行对比，检查远程控制数据转发功能的正确性；通过BM2711模型接收指令，除了通过观察波形检查远程控制指令执行情况，更通过BM2711模型检测脉冲宽度，通过监控模型和参考模型通道号序列在记分板中进行对比，检查远程控制指令执行功能的正确性和脉冲宽度的正确性，实现闭环的一体化仿真验证平台。

文中设计的仿真验证平台可通用于Modelsim、Rivera、VCS和NC-sim等主流支持UVM的仿真工具，图6是用VCS仿真器进行仿真的DUT接口仿真波形结果图。从仿真波形图看出，验证平台产生的激励数据如远程控制转发数据、远程控制指令数据通过DUT的三线制输入接口KP_CLK1、LOCK_A、KP_DATA1先后输入给DUT，在输出端口上可看到相应的输出波形如两线制转发的LVDS远程控制数据和48路指令控制信号输出，说明功能正常执行。

图6 远程控制FPGA组合测试仿真波形图

4 结束语

UVM验证方法学吸收了当前许多[15]验证方法学的优点，本文搭建了基于UVM的远程控制FPGA验证平台，实现了验证平台的各个组件。该验证平台结构层次分明、便于扩展和管理，具有受约束的随机验证和输出结果自动检查功能，有效的提高了验证的效率，确保了验证功能的正确性和鲁棒性。该验证平台具有验证效率高、完备性好、自动化程度高、通用性强、可扩展性强的优点，可以被其他验证项目所重用。