基于UVM的AXI4-Stream可重用验证平台设计
2021-01-05徐春琳宋宇鲲
徐春琳, 倪 伟, 宋宇鲲
(1.合肥工业大学 微电子设计研究所,安徽 合肥 230601; 2.教育部IC网上合作研究中心,安徽 合肥 230601)
0 引 言
随着片上系统(system on chip,SoC)芯片复杂度日益提高,验证环节用时逐渐增加,目前约占整个芯片设计周期的70%～80%,其进度将直接影响整个项目进度。传统验证方法耗时长,且对规模较大的设计难以保证覆盖所有的功能点。2011年,Accellera标准组织推出新型通用验证方法学(universal verification methodology,UVM),并于2017年被正式纳入IEEE 1800.2-2017标准[1]。UVM集成了验证方法学手册(verification methodology manual,VMM)和开放验证方法学(open verification methdology,OVM)的优点并克服了各自的缺点,提供了寄存器抽象层(register abstraction layer,RAL)验证解决方案,并引入了面向对象设计模式中的工厂(factory)机制,因此,利用UVM搭建的验证平台具有良好的可重用性,得到了业界的广泛认同,越来越多的新项目开始选择基于UVM的验证方案。
当今异构SoC设计中通常需要高速和大数据量的数据流传输。2010年,ARM公司推出了面向高速流数据传输的AXI4-Stream协议,主要用于模块之间进行高速流数据传输。AXI4-Stream是一种单通道单向的传输方式,去除了地址的概念,是一种点对点或1点对多点的数据流通信协议,支持多种流传输及多种字节方式,允许无限制的数据突发传输规模[2],适合访问诸如先进先出(first input first output,FIFO)队列这样没有地址概念的存储介质。AXI4-Stream已被广泛应用于众多SoC设计,如无线通信基站芯片。部分业内领先的电子设计自动化(electronic design automation,EDA)公司也相继开发了支持AXI4-Stream的Video Combiner、Noise Filter等商业IP核和基于UVM的AXI4-Stream验证IP[3]。
目前,国内有少数科研机构大规模开展了UVM的验证技术研究,如合肥工业大学开发了基于UVM的通用异步收发传输器(universal asynchronous receiver/transmitter,UART)、集成电路内置音频总线(inter-IC Sound,I2S)及高级可拓展接口(advanced extensible interface,AXI)等验证IP[4-6],西安电子科技大学研究了控制器局域网(controller area network,CAN)和高速外设部件互连(peripheral component interconnect express,PCI Express)等UVM验证平台[7-8],其中,对于AXI验证IP的研究虽然考虑了可配置性与可重用性,但是在多主机(Master)-多从机(Slave)验证场景中,只考虑了路由功能,未考虑到仲裁功能,验证具有局限性,且对于CAN总线验证平台的研究未考虑可配置性。随着集成电路的发展和对高速数据传输的依赖,高速接口AXI4-Stream的应用也越来越广泛,而目前国内对AXI4-Stream验证平台的相关研究很少。本文研究设计了基于UVM的AXI4-Stream验证平台。
该验证平台采用UVM技术,在设计过程中考虑了验证平台的可配置性、可重用性及自动化。本文特别研究了AXI4-Stream互联(Interconnect)结构中多Master与多Slave之间信息交互的路由和仲裁算法,解决它们之间的竞争行为;构建了可自动收集功能覆盖率的覆盖率模型,大大提升了验证平台的自动化程度;通过配置类实现了验证平台的可配置性,因此具有良好的可重用性,显著提高了验证效率。
1 AXI4-Stream验证平台设计
1.1 AXI4-Stream验证平台
本文设计的AXI4-Stream验证平台整体结构如图1所示。Top封装了环境类Env,Env封装了Master-agent、Slave-agent以及负责监测事务(transaction)传输是否符合协议的检验器Checker。Master-agent包含Master-sequencer、Master-driver、Master-monitor组件,Slave-agent包含Slave-sequencer、Slave-driver、Slave-monitor组件。图1中的Master-seq和Slave-seq为验证平台提供测试激励,虚拟接口(virtual interface,VI)用于连接验证平台和待测设备,系统配置类Sys-config和端口配置类Port-config为验证平台提供配置信息,功能覆盖率模型Coverage-model收集功能覆盖率。
图1 验证平台整体结构
Master-agent内的Master-seq负责产生测试激励;Master-sequencer一方面检验是否有Master-seq需要发送transaction,另一方面检测Master-driver是否向自身申请transaction,且Master-seq产生的transaction只有经过Master-sequencer才可以发送至Master-driver;Master-driver将接收到的transaction从事务级转化为信号级,并驱动至VI上;Master-monitor采集VI上的信号并将其转化为事务级的transaction,接着将transaction分别发送至Checker和Coverage-model。
Slave-agent内各个组件功能与Master-agent内的类似。
多Master-多Slave验证平台的结构如图2所示。
图2 多Master多Slave验证平台的结构
当待验证场景为单Master-单Slave情形时,可直接采用图1所示的结构。自验证时,Master-seq产生的transaction通过Master-sequencer发送给Master-driver。Master-driver将transaction从事务级转化为信号级并通过相应的任务驱动到VI上。Slave-monitor不断采样VI上的有效信号并将其转化为事务级transaction,存储在一个内部邮箱中。Slave-seq调用Slave-sequencer内部端口的peek任务从内部邮箱中获取transaction,根据不同的测试需求做相应的处理后通过Slave-sequencer发送给Slave-driver。Slave-driver将transaction从事务级转化为信号级后驱动至VI上,完成Master-agent和Slave-agent的握手过程,一次数据传输完成。
待验证场景为多Master-多Slave情形时,采用图2所示的结构。图2中,Intcon-env代表互联结构,用于多Master与多Slave之间信息的交互,解决多Master与多Slave之间的路由以及仲裁问题。Sys-monitor负责采集互联结构内部从机Intcon-slave-agent和主机Intcon-master-agent的transaction并传送至Sys-checker,Sys-checker比较两者的输出,从而判断Intcon-env是否工作正常。
1.2 AXI4-Stream Interconnect结构
1.2.1 Intcon-env路由设计
互联Intcon-env整体结构如图3所示, Intcon-slave-fifo和Intcon-master-fifo是一组uvm-tlm-fifo组件,既保证了互联结构内部各个组件之间的通信,又解决了多路数据做不同处理问题。Intcon-master-agent和Intcon-slave-agent分别为互联内部的主机和从机,功能与1.1节所述相同。Intcon-driver负责将transaction从互联内部的从机驱动至内部的主机。
图3 Intcon-env结构
自验证时,主机按照单Master-单Slave发送transaction的方式将transaction转化为信号级并驱动至VI上,Intcon-slave-monitor不断采样VI上的有效信号,并将其转化为事务级存入一个内部邮箱中。Intcon-slave-sequencer调用内部端口peek任务从此邮箱中获取transaction,经Intcon-slave-sequence处理后发送给Intcon-slave-sequencer。Intcon-slave-sequencer调用内部端口put任务将transaction存入Intcon-slave-fifo,并将transaction发送给Intcon-slave-driver,后者将其转化为信号级后驱动至VI上,实现Master-agent与Intcon-slave-agent的握手。Intcon-driver调用内部端口get任务从Intcon-slave-fifo中获取transaction并将其推入一个内部队列中,接着以轮询方式访问队列中的每个transaction,获取每个transaction的路由端口,并按照所获取的端口信息将不同transaction发送给不同Intcon-master-fifo。Intcon-master-sequence调用内部get任务从Intcon-master-fifo中获取transaction发送给Intcon-master-driver。Intcon-master-driver将transaction转化后驱动至VI上。
从机的transaction接收方式与单Master-单Slave情况相同。
验证平台的Intcon-driver的功能总结如下:① 从Intcon-slave-fifo中获取transaction并将其推入一个内部队列;② 按照轮询的方式处理内部队列中的每个transaction;③ 获取内部队列中每个transaction即将路由的端口;④ 将处理后的transaction按照各自的路由端口发送至对应的Intcon-master-fifo。
1.2.2 Intcon-env仲裁设计
为解决多Master发送transaction时可能出现的竞争,设计了2种仲裁方式,即轮询仲裁和固定优先权仲裁,并将2种仲裁方式加入Port-cfg中,用户可根据需求配置。TVALID信号和TREADY信号是AXI4-Stream协议中的一对握手信号,当两者均拉高时,完成一次传输。仲裁时,将主机侧的TVALID信号视为请求信号,TVALID信号拉高代表主机有请求;将Intcon-env输出的TREADY信号视为授权信号,TREADY信号拉高代表授予总线控制权,完成握手过程。
轮询仲裁首先设置一个默认的主机curr-master并授予其总线控制权。Intcon-slave-monitor采样所有主机接口上的TVALID信号,利用轮询算法得到下一轮可能获得总线控制权的主机next-master,并判断next-master对Intcon-env是否有请求。若有请求,next-master即为下一个轮询主机,Intcon-slave-driver将next-master的TREADY信号拉高,Intcon-slave-monitor不断采样VI上的TREADY信号,当采样到TREADY信号被拉高后,更新curr-master的值从而进行下一轮的轮询判断;若无请求,继续循环直至找到有请求的next-master。若所有主机均无请求,则在预设时钟周期内继续轮询判断,若在预设时间内仍无主机发出请求,则停止轮询仲裁。算法伪代码如下:
Setting curr-master as the default master
Granting curr-master bus control
Sampling tvalid signal of all masters
for (i=0; i < num-masters; i++) do
next-master=(curr-master+i+1)% num-master
if (next-master.tvalid) then
identified-master=1
if (identified-master) then
drive tready of next-master to high
break;
end if
end if
end for
if (identified-master) then
sampling tready signal of next-master
while (curr-tready!=1) do
wait a clock
end while
if (curr-tready==1) then
prev-master=curr-master
curr-master=next-master
end if
else
continue to identify next-master in expected clock
if (identified-master !=1) then
stop
end if
end if
固定优先权仲裁由Master权重值决定Intcon-env响应顺序,可通过Port-cfg设置每个Master的权重值,权重值越大,优先权越高。首先用户为每个主机分配一个权重值,并按照权重值大小进行排序,排序后的主机索引值存入mstr-index数组中。Intcon-slave-monitor采样所有主机接口的TVALID信号,按顺序遍历mstr-index数组从而获取next-master,并判断next-master对Intcon-env是否有请求。若有请求,Intcon-slave-driver将next-master的TREADY信号拉高并驱动至VI上, Intcon-slave-monitor不断采样VI上的TREADY信号,当采样到TREADY信号拉高后,更新curr-master的值从而进行下一轮判断;若无请求,处理方法与轮询仲裁相同,不再赘述。算法伪代码如下:
Sorting the master by weightage
Storing the master index value in an array
Sampling tvalid signal of all masters
for (i=0; i < num-masters; i++) do
next-master=mstr-index[i];
if (next-master.tvalid) then
identified-master=1
curr-master=next-master
if (identified-master) then
drive tready of next-master to high
break;
end if
end if
end for
if (identified-master) then
sampling tready signal of next-master
while (curr-tready!=1) do
wait a clock
end while
if (curr-tready==1) then
prev-master=curr-master
curr-master=next-master
end if
else
continue to identify next-master in expected clock
if (identified-master !=1) then
stop
end if
end if
1.3 自动化功能覆盖率模型
为评估验证结果是否满足预期要求,设计了一个可以自动统计功能覆盖率的模型Coverage-model,通过覆盖组实现覆盖率的统计模型。根据协议的规范,提取要验证的功能点,如主从设备的握手情况、transaction的各种属性等特性,定义不同的覆盖组,采样数据流类型的覆盖组代码如下:
covergroup cg-xact-type@(stream-event)
STREAM-XACT-TYPE:coverpoint cov-xact-type{
bins byte-stream={axis-transaction::BYTE-STREAM};
bins sparse-stream={axis-transaction::SPARSE-STREAM};
……
bins user-stream={axis-transaction::USER-STREAM};}
endgroup
覆盖组cg-xact-type的采样事件stream-event在Master-monitor和Slave-monitor中触发,当事件触发后便开始收集覆盖率。所有的功能覆盖率均是自动收集,验证平台的自动化程度大大提升。
1.4 验证平台的可配置性与可重用性分析
所设计的系统配置类Sys-config与端口配置类Port-config为验证平台提供了灵活的可配置性,如利用Sys-config可设置总线最大延时时间、仲裁类型等,利用Port-config可设置TDATA数据宽度、TREADY默认值等。用户可根据需求利用Sys-config和Port-config对验证平台参数进行修改。
验证平台的可重用研究项目包括可重用的验证组件、可重用的序列sequence、可重用的测试用例以及可重用的验证平台4种。验证组件的重用主要是在基类中定义组件的公共函数或方法,在派生类中实现自身特定的功能,如在设计的验证平台中定义了一个父类Slave-agent,Intcon-env里直接从Slave-agent派生出子类Intcon-slave-agent,增加仲裁机制即可,其余函数和方法直接重用父类。
sequence的重用主要是继承重用,继承重用指从已构建的父类sequence中直接派生一个子类sequence进行重用,或者通过修改或添加新的控制属性生成新的子类sequence进行重用[9],如定义一个父类Master-sequence,在Master-sequence中的pre-body()任务中执行raise-objection,在post-body()中执行drop-objection,其他的sequence均可从Master-sequence派生,根据不同的功能添加不同的控制属性即可。
每个测试用例都包含sequence,因此测试用例的可重用性反映在sequence的重用中。
验证平台的可重用性如图4所示,DUT为待测设计(design under test)。
当进行模块级AXI4-Stream接口验证时,所设计的验证平台可直接重用;当进行子系统级或系统级AXI4-Stream接口验证时,只需更改接口模块即可重用整个验证平台,如图4中灰色区域的验证。
图4 可重用验证平台原理图
2 验证结果与分析
2.1 测试用例
验证的输入为测试激励,需要根据AXI4-Stream协议设计大量不同的测试用例,以满足预定的功能验证需求。验证时需要根据AXI4-Stream的outstanding传输、间插操作等特性设计各种测试用例。所设计的验证平台共包含3种测试用例类型,即约束随机测试、基础测试及直接测试。在约束随机测试中,transaction通过自身定义约束使得验证朝向合理的状态空间[10];在约束随机测试基础上,根据AXI4-Stream协议的各个功能点,如传输类型、transaction的各种属性等,继续向transaction添加额外的约束从而形成基础测试;对于约束随机测试和基础测试未覆盖到的功能点,根据覆盖率报告修改约束形成新的直接测试用例,继续测试直至功能覆盖率达100%。以发送数据零延时说明default-sequence的具体结构,核心代码如下:
`uvm-do-on-with (req,master-sequencer,
{for each (tvalid-delay)
tvalid-delay[i]==0;
})
2.2 验证结果与分析
验证阶段的输出为仿真报告,包括仿真日志和覆盖率报告,仿真日志用于记录仿真过程中是否有异常情况,覆盖率报告记录了设计功能的遍历情况。为保证所设计验证平台的正确性,将验证平台配置为图1所示的单Master-单Slave自测试结构。为保证所设计Intcon-env的正确性,将Intcon-env作为DUT,验证平台配置为图2所示的多Master-多Slave自测试结构,例化出5个主机和5个从机进行验证。为进一步测试所设计的验证平台可用于验证任何带有AXI4-Stream接口的验证平台,验证了一个实际的商用IP——Fifo-generator,连接方式如图5所示。图5中,灰色区域代表DUT。
3次验证覆盖率报告如图6～图8所示,统计的覆盖率结果见表1、表2所列。
由图6～图8可知,单Master-单Slave自测试共包含49个覆盖组;多Master-多Slave增加了轮询仲裁、固定优先权仲裁等功能,覆盖组增加到53个;Fifo-generator支持5种流数据传输及outstanding传输,但不支持间插传输,共包含47个覆盖组。
由表1可知,3次验证3种测试总功能覆盖率均达到100%。由表2可知,在约束随机测试和基础测试2种测试后,覆盖率未达到100%,还存在一部分覆盖点未覆盖到,如表2中的cg-cross-type-tid,查看覆盖率报告发现,type为continuous-unaligned-stream类型、tid为32～47的范围未覆盖到,因此修改transaction的约束,重新控制type和tid形成直接测试用例继续测试,直至覆盖率均达到100%。
图5 Fifo-generator验证结构
图6 单Master-单Slave自测试部分覆盖率报告
图7 多Master-多Slave自测试部分覆盖率报告
图8 Fifo-generator验证部分覆盖率报告
表1 3种测试用例覆盖率结果 %
表2 约束随机测试和基础测试的部分覆盖率报告
3 结 论
本文基于UVM开发了一个可自动统计功能覆盖率的AXI4-Stream验证平台,通过约束随机测试、基础测试及直接测试使其功能覆盖率达100%,仿真结果表明该验证平台功能正确,可用于验证任何带有AXI4-Stream接口的设计或包含该接口的SoC系统。所设计的验证平台具有很强的可配置性与可重用性,灵活性较强,当投入新一轮验证工作时,大量代码可以重用,大大减少了验证人员开发验证平台的周期,具有一定的工程意义和实用价值。
