基于UVM的AMBA总线接口通用验证平台①

2021-08-02马鹏,刘佩,张伟

计算机系统应用 2021年7期

马鹏,刘佩,张伟

(华东计算技术研究所,上海 201808)

SoC (System on Chip)产品研发一般采用正向设计方法,产品的开发流程包括:项目策划、系统说明以及行为描述、RTL 描述、前端仿真、后端设计、流片阶段、出样等[1].项目策划阶段会对市场需求进行调研,形成产品规格书.在系统说明及行为描述阶段,确定设计对象和目标,明确芯片功能、内外部性能要求等,从而定制RTL 代码.本文以一款工控CPU 芯片研制为例,芯片内部需要集成CPU 核以及大量的外设(如SPI、I2C、UART、CAN、SPI、PCIE、USB、DMA 等),在RTL 描述阶段将整体任务划分为各个子模块实现,根据任务书的需求分析,通用性IP 配置达不到目标需求.因此,这部分模块只能通过自研的方式实现.而自研代码相比较于成熟IP 而言可靠性不高,风险大,必须依靠前仿验证保证RTL 代码功能的完善完备性,前仿任务艰巨繁重.

传统的验证方法[2],需要验证人员具备丰富的经验,人的因素很大,进度不可控,难以满足复杂的SoC验证需求.目前,市场上流行的验证方式是UVM (Universal Verification Methodology)验证方法学.

UVM 验证方法学[2],由Accellera 于2011年2月推出,以SystemVerilog类库为主体的验证平台开发框架,继承了VMM和OVM的优点,构建的验证环境具备可重用组件构建标准化和层次化特性,并且得到了Synopsys、Mentor和Cadence 公司的支持,EDA 环境构建完善.它目前已经得到市场的验证,现在市面上很多IC 设计公司都已经在使用[1].UVM 方法学的特点是能够产生带约束的随机测试激励、通过refm 设定可以判定输出结果是否符合预期,能够进行大量的随机验证,平台本身具备可靠性,加入覆盖语句、断言语句,获取到代码覆盖率、功能覆盖率、断言覆盖率的百分比,通过分析能够量化的科学的判定验证的程度,验证进度可控.

AMBA (Advanced Microcontroller Bus Architecture)由ARM 公司研发推出,定义了一种嵌入式高性能微控制器的片上通信标准[3].目前,已被广泛地应用于大型复杂SoC 系统中[2].

本文以工控处理器SoC 芯片验证为背景,目标芯片内部采用AMBA 总线作为片上通信的总线架构,搭建基于UVM 验证方法学的AMBA 总线接口的验证平台,平台具备可靠性、可扩展性、通用性、高效性,能够减少验证准备工作的重复性,节约验证时间,可靠的高效完成整个芯片的验证工作,保障RTL 代码功能的正确性和完备性,提高芯片成功率.

1 基于UVM的AMBA 总线接口验证平台搭建

在AMBA 3.0 版本中,介绍了4 种接口类型,AMBA APB (Advanced Peripheral Bus)总线[3]、AMBA AHB(Advanced High-performance Bus)总线[4]、AMBA AXI(Advanced eXtensible Interface)总线[5]和AMBA ATB(Advanced Trace Bus)总线[6].

目标芯片系统结构图,如图1所示,片上总线采用AMBA 总线、内部集成大量低速外设包括多路UART控制器、I2C 控制器、Timer 控制器、Watchdog 控制器、PWM 控制器、GPIO 控制器等;高速设备,L2 Cache 控制器、DMA 控制器、PCIE 控制器、USB 控制器、EMMC 控制器、SMC 控制器等;基于系统性能设计考虑,目标芯片系统架构设计采用AMBA 协议中的3 种类型,AMBA[7]AXI、AMBA AHB[8]、AMBA APB 总线协议,选择高速总线AMBA AXI 总线作为处理器与外设相连的一级总线,选择AMBA AHB[9]总线作为片上本地总线,选择AMBA APB 总线,连接低速设备.如图1所示,AMBA-AXI 总线上挂接CPU 核以及高速缓存控制器AXI-L2Cache 控制器、AXI-SRAM控制器、AXI-PCIE 控制器等,这类子模块的验证工作需要平台包含AMBA AXI 总线驱动;通过AXI2AHB桥控制器,完成AMBA AXI 总线与AMBA AHB 总线桥接工作,AMBA AHB 作为本地高性能总线,挂接AHB-DMA 控制器、AHB-SPI 控制器等高速外设,这类子模块的验证工作需要平台包含AMBA AHB 总线驱动;通过AHB2APB桥控制器,完成AMBA AHB 总线与AMBA APB 总线桥接工作,AMBA APB 总线作为低速外设总线,挂接低速外设APB-UART、APBWDT 等模块,这类子模块的验证工作需要平台包含AMBA APB 总线驱动.

图1 目标芯片系统结构图

本验证平台采用Agent 以及TLM 通信机制设计,实现平台可扩展性,支持外设接口类型为AMBA APB、AMBA AHB、AMBA AXI 单一接口或者组合接口多样性的验证工作,具备通用性,可操作类型:

1)AMBA APB 接口:支持外设地址位宽配置、支持32 位数据读写操作,符合AMBA APB 3.0 协议规范.

2)AMBA AHB 接口:支持外设地址位宽配置,支持8 位、16 位、32 位、64 位 SINGLE 读写操作,支持BURST INCR 类型读写操作(len 覆盖1～16),符合AMBA AHB 协议规范.

3)AMBA AXI 接口:支持外设地址位宽可配置,支持8 位、16 位、32 位、64 位SINGLE 读写操作,支持BURST INCR、BURST WRAP、BURST FIXED 类型读写操作(len 覆盖1～16),符合AMBA AXI 协议规范.

因此,验证平台能够满足系统内集成的所有子模块的验证工作,所包含的总线驱动,覆盖目标芯片验证所需的全部AMBA 接口驱动类型,具备通用性,能够通过平台结构扩展性满足子模块验证需要的接口类型以及数目的多样性,例如AHB-DMA 控制器,通过AMBA AXI 接口进行数据传输、AMBA AHB 接口进行控制器寄存器配置,需要在同一环境集成AXI 总线驱动以及AHB 总线驱动才能完成验证工作,验证平台具备的可扩展性能够满足验证需求.

1.1 AMBA APB 总线接口驱动实现

APB是高级外围总线,定义了APB 总线协议,本平台设计的APB 总线接口,支持待测模块地址位宽可配置,数据接口位宽可配置,驱动设计符合AMBA APB 3.0 协议规范.

根据AMBA APB 协议,定义sequence itemmonitor transfer,如表1和表2所示,根据`define APB_ADDR_WIDTH 配置支持地址位宽16 位或者32 位接口类型,根据`define APB_DATA_WIDTH 配置支持数据位宽16 位或者32 位接口类型;APB 接口驱动设计流程如图2所示,在VIF.clk 上升沿将激励值赋给对应接口,在时钟的下一个上升沿,将VIF.penable 拉高,之后,在每个时钟的上升沿判断VIF.pready 信号是否拉高,本节拍等待VIF.pready=1’b1 成功将VIF.prdata 值赋值给item.pdata,下节拍上升沿,将控制信号以及接口地址信号清零,APB 写驱动效果图,如图3所示.APB 接口监控设计,在VIF.clk 下降沿,判断读数据是否有效(psel==1’b1 &penable==1’b1 &pready==1’b1),满足条件当拍将VIF.prdata 赋值给mtr.prdata,流程如图2所示.APB 读驱动效果图,如图4所示.

图2 APB Driver 及Monitor 设计流程图

图3 APB 写效果图

图4 APB 读效果图

表1 APB sequence item

表2 APB monitor transfer

1.2 AMBA AHB 总线接口驱动实现

AHB是高级高性能总线,定义了AHB 总线协议,本平台设计的AHB总线接口,支持待测模块地址位宽8 位、16 位或者32 位接口类型,支持数据8 位、16 位、32 位、64 位SINGLE 以及BURST INCR 访问,符合AMBA AHB协议规范.

根据AMBA AHB 协议规范,定义sequence item,如表3所示.根据define AHB_ADDR_WIDTH 配置地址位宽16,32,64 位接口类型;AHB 接口驱动设计,根据协议规范,在时钟上升沿等待hready 拉高,通过trans_len 判断是否为SINGLE 操作,设置VIF.Hburst 参数值(AHB_BURST_SINGLEAHB_BURST_INCR),并将sequence item 赋值给对应的接口信号;通过item.hwrite 判断当前操作类型,若值为WR,如图5所示,写操作,在下一节拍上升沿且hready为高电平,当前操作为SINGLE,VIF.htrans 赋值AHB_TRANS_IDLE,若当前操作为BURST 操作,VIF.htrans 赋值AHB_TRANS_SEQ;根据数据单元大小8 bit16 bit32 bit64 bit 操作,对地址在item.trans_len个clk 节拍上升沿,分别进行VIF.haddr 加1 或者item.hsize*2 操作,同时,根据hsize 类型,进行hwdata 与VIF.hwdata 赋值操作,例如,若AHB 发起字节操作,hwdata 低8 位值赋给VIF.hwdata[31:0],且hwdata 右移8 位,等待下个节拍操作,直到trans_len 设定的数据传输完成,在最后一个节拍VIF.htrans=AHB_TRANS_IDLE,写操作完成.AHB 写驱动效果图,如图6所示.

图5 AHB 驱动设计流程图

图6 AHB 写效果图

表3 AHB sequence item

若值为RD,如图5所示,读操作,通过trans_len 判断当前操作,若是SINGLE 操作,在时钟上升沿,将VIF.hrdata 值赋值给item.hrdata,VIF.htrans 赋值AHB_TRANS_IDLE,若BURST 操作,在时钟上升沿,VIF.htrans 赋值AHB_TRANS_SEQ,地址按照数据单元值进行叠加VIF.haddr=item.haddr + trans_len*item.hsize*2,根据trans_len的值,进行循环操作,在最后节拍,VIF.trans=AHB_TRANS_IDLE.AHB 读驱动效果图,如图7所示.

图7 AHB 读效果图

1.3 AMBA AXI 接口驱动实现

AXI是高级可扩展接口,定义了AXI 总线协议,具有5个独立的传输通路(读地址通道、读数据通道、写地址通道、写数据通道、写应答通道),支持乱序传输,以点对点的方式进行握手交互,传输具有高效性,一般应用于处理器与高速设备之间的连接.本平台设计的AXI 接口驱动,支持待测模块地址为位宽32 位或者64 位接口了类型,支持数据8 位、16 位、32 位、64 位single 操作,支持BURST 类型FIXED、INCR、WRAP 三种类型、支持Burst len 覆盖0～16,支持读写乱序发送,符合AMBA AXI 协议规范.

根据AMBA AXI 协议规范,定义sequence item,如表4所示.根据define AXI_ADDR_WIDTH 配置地址位宽32,64 位接口类型;AXI 接口驱动设计,按照操作类型分成 AXI_WR 及AXI_RD 操作.

表4 AXI sequence item

AXI_WR 写操作,如图8所示,首先,等待VIF.awready 拉高,完成写地址通道握手操作;在下一拍时钟上升拉高VIF.wvalid 及VIF.bready,通过trans_len !=0,判断当前操作是否SINGLE 操作,若为SINGLE,在下一节拍VIF.wvalid 拉低;若为BURST 操作,VIF.wvalid 值不变,根据burst 类型(AXI_BURST_FIXED、AXI_BURST_INCR、AXI_BURST_WRAP),选择进入各自逻辑,根据trans_len 设置循环操作,通过tran_len==item.trans_len–1,判断是否为最后一次传输,满足条件,当前节拍拉高VIF.wlast,在下节拍对控制信号进行清零,等待slave 应答VIF.bvalid 拉高,满足条件,当前节拍VIF.bready=1’b0,完成写操作,AXI 写驱动效果图,如图9所示.其中,AXI 涉及的3 种驱动逻辑.

图8 AXI_WR Driver 流程图

图9 AXI_WR 效果图

1)AXI_BURST_FIXED 类型:操作访问地址不变,驱动设计关键在数据选通信号设计,根据item.trans_size(8 bit16 bit32 bit64 bit),若为8 bit,VIF.wstrb=(8’h1<

图10 AXI_BURST_FIXED 流程图

2)AXI_BURST_INCR 类型:操作地址以数据单元大小进行累加,在fixed 类型基础上增加地址设计逻辑,若为8 bit:item.axi_addr=item.axi_addr + 32’h1;若为16 bit,item.axi_addr=item.axi_addr + 32’h2;若为32 bit,item.axi_addr=item.axi_addr + 32’h4;若为64 bit,item.axi_addr=item.axi_addr + 32’h8,如图11所示.

图11 AXI_BURST_INCR 流程图

3)AXI_BURST_WRAP 类型,操作地址具有回卷特点,以item.size*item.len为wrap boundary,地址循环操作;以item.trans_size=8 bit为例,首先确认回卷地址访问以及起始地址wrap_axi_addr[log2(item.trans_len)–1:0]=item.axi_addr[log2(item.trans_len)–1:0],设计数据选通信号VIF.wstrb=(8’h1<

图12 AXI_BURST_WRAP 流程图

AXI 读驱动效果图,如图13所示.AXI_RD 读操作,配置读地址通道,VIF.arvalid=1,配置传输地址,等待valid 与ready handshake,在时钟上升沿等待VIF.arready=1,若成立,拉低VIF.arvalid,读地址通道配置完成,开始读数据通道配置操作,拉高VIF.rready,给入传输id 配置,通过VIF.rdata 读回数据,如图14所示.

图13 AXI_RD 效果图

图14 AXI_RD DRIVER 流程图

1.4 验证平台实现

本验证平台采用UVM 验证方法[10]学集成了上述前3 种接口类型.经典的验证平台结构包含,如图15所示,需要实现激励功能的driver 组件,预判DUT 输出的reference model 组件,DUT 输出信息收集的monitor组件,以及给出验证结果的scoreboard 组件.

图15 经典验证平台结构

为了满足目标芯片的验证工作,减少验证的前期准备工作,通常待测模块需要的接口数量是不定,例如测试AXI[11]转AHB 接口的桥模块,需要驱动多路AXI总线接口以及观测多路AHB 总线接口,基于可扩展性考虑,验证平台定义一个通用的Agent 模板.

Agent[12]是容器化概念,本平台设计的通用Agent 模板内部集成了monitor、driver、sequencer、以及driver 与reference model 通信队列传输通道、DUT 与scoreboard 通信队列传输通道、reference model 与scoreboard 通信队列传输通道,Agent 定义了各个组件应该存放的位置以及之间如何进行通信[13],如图16所示.对于不同总线驱动设计,整体Agent[14]框架不变,新创建文件夹,改变关键字以及driver_item_dut内容既可.对于相同总线接口的扩展,例如原AMBA_UVM[15]平台内部,只定义了一路AXI_MASTER,验证PCIE 需要两路AXI_MASTER,此时只需要对uvm/axi_uvc 进行复制,uvm/axi1_uvc,更改axi1_uvc 关键字即可,这样能便于灵活扩展,实现验证环境集成两路AXI_MASTER 接口驱动可以同时使用,满足验证需求.

图16 平台整体结构图

通信队列传输通道利用TLM 事务级端口设计,将组件之间的通信细节(信息交换细节)与通信架构的细节分离开来,事务请求在调用通信队列时发生.本平台利用通用的uvm_tlm_analysis_fifo 组件,明确了数据传输方向,数据通过get_ap 获取,通过put_ap传送出去,实现各个组件之间的通信.在顶层tb 例化uvm_tlm_analysis_fifo 事务,与通用agent 模板内预先设计通路配合使用,实现各个模块之间的通信,如图17所示.

图17 平台通信队列

uvm_tlm_analysis_fifo(xx_monitor_sequencer_item)dut2scb_mtr_fifo;

Uvm_tlm_analysis_fifo(xx_monitor_sequencer_item)rm2scb_mtr_fifo;

Uvm_tlm_analysis_fifo(xx_sequence_item) drv2rm_item_fifo;

平台可扩展性实现还需要定制激励发送形式,这个过程由sequencer 实现.可以将sequencer 看作是个瞄准器,sequence item 就是要发射的物件.为了便于扩展,本验证平台建立一个通用的dut_virtual_ sequencer,内部对各个接口sequencer 进行例化.可以实现通过一个通道发送不同的sequence item 目的,如图16所示.当平台接口数目需要扩展时,可以通过在dut_virtual_seuqncer 进行例化.

class dut_virtual_sequencer extends uvm_sequencer;

`uvm_component_utils(dut_virtual_sequencer)

dut_apb_sequencer apb_seqr;

dut_ahb_sequencer ahb_seqr;

dut_axi_sequencer axi_seqr;

…

endclass

class dut_tb extends uvm_env;

`uvm_component_utils(dut_tb)

dut_virtual_sequencer vsqr;

…

function void connect_phase(uvm_phase phase);

$display("connect_phase ");

vsqr.apb_seqr=apb.common_agent.sequencer;

vsqr.ahb_seqr=ahb.common_agent.sequencer;

vsqr.axi_seqr=axi.common_agent.sequencer;

…

Endclass

本平台是基于UVM 验证方法学[16–19]结合Agnet以及TLM 通信机制进行设计的验证平台,平台的架构本身具备稳定性,能够确保验证工作的展开;而本平台在driver 以及monitor 设计中预留了probe 用于覆盖率数据收集,能够在验证工作完成之后,通过EDA工具对数据进行分析,形成代码、功能、断言覆盖率,用于总结子模块的验证工作是否完备,若未达到验证需求,根据覆盖率能够快速准确地找到未覆盖的点,创造场景激励,实现全面覆盖,最终保障验证的完备性.

2 AXI-SRAM 控制器验证

目标芯片系统内部按照需求集成了1 MB的片上存储设备,作为boot ram 使用.以自研模块AXI2SRAM控制器为例进行验证平台使用说明.

对待测子模块接口进行分析,有两种接口类型,一路AXI 接口[20]用于与系统内部CPU 或者其它master设备进行数据传输,一路slave sram 接口用于挂接存储设备.因此,根据待测子模块的功能特性将挂接local_mem的axi2sram 控制器整体作为被测试目标,验证平台搭建如图18所示.

本平台具备验证所需的AXI 接口驱动,在平台tb中例化连接axi_if 接口驱动和axi2sram 控制器,控制器外接local_mem,如图18所示,完成验证环境构造.根据dut 特点,编写reference model,验证覆盖,axi 8 bit、16 bit、32 bit、64 bit single 操作,axi burst fixed、incr、wrap 操作,burst_len 覆盖1～16;基于UVM 平台特点[21,22],产生大量的带约束的随机操作,例如,以axi_test_64bit_wrap 测试场景为例,如图19所示为激励构造思路,激励axi_bit64_wrap_randomize 能够实现数据随机、传输长度随机、地址随机,交叉组合;平台定义的通用dut_virtual_sequencer 机制利用p_sequencer.axi_seqr 能够准确的将测试激励赋值给指定axi_if 接口,最终完成随机测试.

图18 axi2sram 验证平台结构

图19 axi_test_64bit_wrap

实验结果,如图20所示,本验证平台定义了一个通用的记分板,用于收集DUT 接口以及reference model分别发送回Scoreboard的数据,并对数据进行分析,最终打印出比较结果.基于待测模块结构特点,平台仅应用AMBA AXI[23]驱动,因此,记分板对比结果仅axi 接口具有有效数据,dut_mtr为待测模传输给scb的反馈结果,rm_mtr为参考模型[24]传输给scb的期望结果,mch_mtr为成功对比的数目,nmch_mtr为不符合预期结果的数目;通过结果可分析,产生随机次数为150028 次,其中待测目标发送给记分板的数据数目是150028 次,参考模型发送给记分板的数据数目是150 028 次,其中,按照数值产生的先后数据进行对比,对比失败的数据数目为0,因此,认为本次随机场景测试结果有效.运行波形如图21.

图20 axi_test_64bit_wrap 实验结果

图21 axi_test_64bit_wrap 运行波形

根据验证大纲,对所列验证点进行递归运行,在运行脚本中加入define COV_WORK,开启验证平台的probe 功能,运行脚本cov.sh 收集覆盖率数据;运行merge.sh 最终通过Cadence 工具得到覆盖率报告,如图22所示,代码覆盖率100%,如图23所示,功能覆盖率100%;能够得到结论,AXI2SRAM 控制器通过验证过后硬件代码具备功能完备且可靠,达到验证目标,完成验证工作.