一种基于需求驱动验证的可编程逻辑器件验证方法及系统与流程

1.本发明涉及可编程逻辑器件验证技术领域，具体是一种基于需求驱动 验证的可编程逻辑器件验证方法及系统。


背景技术：

2.随着可编程逻辑器件的广泛应用以及用户对产品质量要求的提高，传 统的仿真验证已难以满足日益增长的可编程逻辑器件验证需求，由于其验 证抽象层次低、层次结构划分不清晰，使得可重用性不好。近年来，uvm、 ovm、vmm等一类新的验证方法学的有力发展，提升了验证效率。研究表明， 越是高层次化的验证则验证效率越高，而越是低层次化的验证则验证准确 性越高。新的方法学属于tlm级验证，相比于传统的rtl级验证，是一种 更高层次的验证方法。uvm主要是对结构相似的dut进行验证，实际工程中 dut对象往往呈现的是多重接口特性，针对多重验证环境，通常在uvm中需 要重新搭建验证环境，建立连接关系，设计层次化测试序列，使得验证的 复杂度和出错概率都急剧增加。
3.通用的uvm验证平台分为top层、test层、env层、interface层和 dut层5个层次，env层根据被测件的不同又做了进一步层次划分。整个测 试平台由sequence产生激励信号，在虚拟序列器virtual sequencer(虚 拟数据包)调度下，分别传递给driver，通过虚拟virtual interface接 口，驱动dut端口，scoreboard对接收来自各个monitor的监控信号进行 比较并输出结果。最终实现了测试指令与测试设计相分离，测试设计与被 测件相分离的设计思路，达到提高测试的效率和可重用性。
4.在通用的uvm验证平台中，一个driver只能接受一种sequence测试 序列格式；各个组件之间信息传递采用port通信技术实现，一个agant中 只能构造一个sequence的通信端口，端口连接关系具有严格对应要求，这 种方式降低了可重用性，增加了复杂性。一个顶层的testcase是一组具体 化的测试激励测试序列产生，测试序列产生层次化较低，当外部接口对测 试序列结构产生变化，有多重验证需求时，需要重新配置不同测试环境， 测试环境复杂度会急剧增加，这是一项非常难以忍受的设计。主要存在的 问题如下：
5.接口数据格式协议支持相似的单一验证环境中，无法满足uvm设计多 重验证环境，需要重新配置；
6.sequence被作为测试的最顶层，但却是处理的是底层具体的测试序列 设计，抽象级别低；
7.以agent配置的各种port传递信息，各种port建立连接关系需一一 对应，有两种操作模式，数据格式以8bit严格要求。复杂且重用性低；
8.采用了vif接口，但在连接处理中仍无法完全与dut隔离，有待提升。
9.尽管uvm验证方法学是业内一种主流的验证方法学，但是其中一些强 制的工厂工作模式设计理念，使人们在一开始就很难能够简单地使用和正 确理解，所有的验证环境组件在整合后才能使用，很难定位到错误来源， uvm在执行过程中还存在着难以处理的数据传递和同步化问题。


技术实现要素：

10.为克服现有技术的不足，本发明提供了一种基于需求驱动验证的可编 程逻辑器件验证方法及系统，解决现有技术存在的组件复杂、层次关系复 杂、测试环境复杂度高、可重用性低等问题。
11.本发明解决上述问题所采用的技术方案是：
12.一种基于需求驱动验证的可编程逻辑器件验证方法，包括以下步骤：
13.s1，构建基于需求驱动的验证平台，并依据需求说明提取需求功能点， 所述验证平台包括依次通信相连的命令层、功能层和信号层；
14.s2，命令层根据需求功能点下发不同测试指令；
15.s3，功能层提取任务和函数，执行测试指令并输出测试结果；
16.s4，信号层提供被测件接口信号。
17.根据权利要求1所述的一种基于需求驱动验证的可编程逻辑器件验证 方法，其特征在于，步骤s2包括以下步骤：
18.s21，命令层先做被测对象和功能点识别；
19.s22，再根据识别结果提取测试任务和函数，执行测试；
20.s23，最后判决功能覆盖率是否满足条件，不满足则返回步骤s21，满 足则结束测试并输出测试结果。
21.作为一种优选的技术方案，步骤s22中，执行测试包括：端口例化、 定义工作时钟、设定测试循环次数、枚举待测件和/或待测功能点。
22.作为一种优选的技术方案，步骤s1中，构建的验证平台的功能层包括 参考库、激励处理器；步骤s3中，功能层从参考库中提取任务和函数。
23.作为一种优选的技术方案，步骤s1中，构建的参考库包括激励器库、 驱动器库、检测器库；步骤s3中，功能层从激励器库、驱动器库和/或检 测器库中提取任务和函数。
24.作为一种优选的技术方案，激励器库用以实现激励产生，识别不同测 试任务，产生测试序列的集合体。
25.作为一种优选的技术方案，驱动器库用以通过需求引导所有驱动生成， 使得驱动与测试序列之间可以直接通信。
26.作为一种优选的技术方案，检测器库用以实现检测结果产生，产生检 测结果的集合体。
27.作为一种优选的技术方案，激励处理器用以对所有测试序列进行创建、 例化、随机化以及重组处理。
28.一种基于需求驱动验证的可编程逻辑器件验证系统，其特征在于，应 用于所述的一种基于需求驱动验证的可编程逻辑器件验证方法，包括基于 需求驱动的验证平台，所述验证平台包括依次通信相连的命令层、功能层 和信号层；命令层用以根据需求功能点下发不同测试指令；功能层用以提 取任务和函数，执行测试指令并输出测试结果；用以信号层提供被测件接 口信号。
29.本发明相比于现有技术，具有以下有益效果：
30.(1)本发明创建了一种可集成化基础组件的参考库模型，实现激励 100％隔离，建立广泛使用激励的方式。方法的特点组件独立、层次关系少、 环境简洁、可重用性好，能满
足不同需求和验证环境需要，经测试结果分 析比较，新方法可快速应用于fpga软件功能验证，有效提升工作效率；
31.(2)本发明搭建环境的测试代码量、文件数据数量、测试层数，以及 单个功能点测试花费的时间、总的测试时间进行分析对比，通过对比，测 试代码量有效减小60％，设计文件数量减少61.5％，测试层数复杂度减少40％， 测试时间缩短66.7％，测试效率提升40％以上。可以看出，新方法不论在设 计还是测试中都比uvm简单、高效，测试效果提升显著。在大型复杂多变 的测试环境中，仿真速度、可重用性的提升效果都将会更加明显；
32.(3)本发明能从更宏观的角度去考察验证问题，可以最大程度地减少 人工工作量，改变产品的测试方式。对于目前越来越复杂的验证需求，使 用uvm等验证方法很大一部分时间放在了验证环境搭建中，而采用此方法， 验证操作简单，能够根据需求定制出不同的参考库模型，且相互之间不会 影响，不仅能减少很多繁琐的工作，还能为测试人员带来新思路，建立可 持续集成的验证平台，通过参考库参数不断迭代累加和优化，为进一步打 造智能化验证平台奠定基础；
33.(4)本发明利用需求之间存在的很多共性特点，提取了多重验证环境 下的验证基础设施组件，创建出一种可集成化验证基础组件的参考库模型， 利用需求驱动所有测试组件，做到了需求、激励、驱动、检测、被测件之 间的100％隔离，创建出具有广泛使用的验证模式。新方法与uvm验证方法 学相比，可重用性提升效果显著，具有组件独立、层次关系少、使用方便 等特点，可满足不同需求和验证环境需要。举例对参考库的可重用性进行 了有效性证明，最后对测试结果分析比较，表明新方法可以快速应用于多 重环境的软件功能验证，提升工作效率。
附图说明
34.图1为现有技术基于uvm的验证平台的结构示意图；
35.图2为本发明基于需求驱动的验证平台的结构示意图；
36.图3为本发明命令层相关性映射例化示意图；
37.图4为本发明测试执行流程示意图；
38.图5为本发明功能层组件架构图；
39.图6为本发明sequence的映射示意图；
40.图7为本发明driv_lib处理架构图；
41.图8为本发明resu_lib处理架构图；
42.图9为本发明需求驱动组件间的消息传递示意图。
具体实施方式
43.下面结合实施例及附图，对本发明作进一步的详细说明，但本发明的 实施方式不限于此。
44.实施例1
45.如图1至图9所示，为了解决背景技术所述的技术问题，本发明的目 的是提供一种能够有效减少验证时间，提升验证效率，组件独立、层次关 系少、环境简洁、可重用性好的验证方法。
46.为满足多重验证环境需要，一基于需求驱动的验证平台如图2所示。
47.基于需求驱动的验证平台包含命令层、功能层和信号层共3个层次， 首先依据需求说明提取需求功能点，命令层根据需求功能点下发不同测试 指令(testcase)；然后功能层从参考库(ref_lib)中的激励器库(seq_lib， 测试序列库)、驱动器库(driv_lib)和检测器库(resu_lib)里提取任 务和函数，执行测试指令并输出测试结果，信号层提供被测件(dut)接口 信号；最后根据功能覆盖率检验充分性，遍历所有功能点，完成需求的所 有功能测试。
48.一个好的验证平台是要以需求为导向，需求改变验证平台，验证平台 丰富需求，是需求与验证相结合的验证平台。
49.参考库(ref_lib)是根据外部需求(requirement specification) 提取输入与输出变量，根据测试说明(test specification)例化识别对 象以及用例特征的表征参数，将多重验证环境的基础设施抽象出来，建立 一种具有可重复性使用的通用性数据库。
50.命令层设计：
51.在需求说明中，一个功能点可以分解为标识、属性、行为和实体四个 部分，功能点就是待测设计在特定的场景下所表现出来的行为及属性，不 论什么样的功能点，通过分散的应用场景和通信场景能够聚合成一个完整 的功能模型。通过分析每一个功能点的属性，明晰每个功能点需要在什么 样的场景下能表现出预期需要的行为，就可以形成一个功能模型。首先按 照需求对功能点进行列表化，然后通过枚举方法，将列表后的协议映射为 代码标识，最后再根据功能点的具体操作内容，将功能点转换为命令层的 具体可执行代码模型，如图3所示。
52.例化中使用typedef enum枚举方法列举出不同功能点test_task的例 化名，枚举命名根据测试需要设计，`define是确定执行哪个功能点，当 `define test_case flash_erase时，表示对判断是否进行flash接口插除 测试。测试命令是测试执行主要阶段，放在顶层完成，使用programautomatic定义测试执行过程自动进行，测试执行流程示意如图4所示。
53.命令层作为顶层设计，主要包含端口例化、定义工作时钟、设定测试 循环次数、枚举待测件和待测功能点等，先做被测对象和功能点识别，再 根据识别结果从ref_lib中提取测试任务和函数，执行测试，最后判决功 能覆盖率是否满足，不满足则迭代进行，满足则结束测试。设计过程中使 用initial fork
…
join_none可完成多个时钟产生。对于复杂功能点的测 试设计，可多次调用ref_lib库里的任务完成。工程师主要花费时间是按 需求中的功能点构造出功能模型，其他基础组件的激励、驱动和检测结果 直接从参考库中调用即可，从这点看，比uvm有很强的通用性和便捷性。
54.功能层设计：
55.功能层由参考库(ref_lib)和激励处理器(seq_base)组成，分别提 供验证平台所需的激励、驱动和检测三种基本功能。参考库的设计是将测 试环境的基础设施抽象出来，定义为具有一定可复用的通用性库文件，包 含了不同dut需求的通用性提取，将seq_lib、driv_lib、resu_lib三者 集合而成，如图5所示。
56.该层次建模组件基本实现功能包括：
57.1)seq_lib：基本功能是实现激励产生，能识别不同test_task，产生 各种
sequence(测试序列)的集合体，sequence之间相互独立。
58.2)driv_lib：基本功能是实现驱动产生，所有driv_lib需先建立一 个任务：seq_lib调用，通过seq_base从seq_lib从提取sequence，能识 别不同test_task，产生各种drive的集合体，drive之间相互独立，能根 据test_task将sequence添加到不同的drive上。
59.3)resu_lib：基本功能是实现检测结果产生，能识别不同test_task， 产生各种result的集合体，result之间相互独立。
60.4)seq_base：基本功能是对所有的seq_lib进行封装、激励重组处理 等活动，并将激励传递给drive和result等组件。
61.seq_base设计：
62.采用一个公共的seq_base组件完成对所有sequence进行创建、例化、 随机化以及重组处理，以class类的形式完成，如图6所示。首先是对 sequence的类进行例化，如将seq1类例化成ra1，然后使用build进行创 建，例化过程中将sequence的长度传递给动态数组，以便确定其具体长度， 使用new()实例化ra1，assert(seq.randomize())对ra1进行随机化处理。 crc_chk()是对ra1进行数组重组，使用covergroup开展覆盖率收集。
63.在设计sequence时，有时候会存在对输出的一组或多组sequence有 其他额外要求，如对每次输出的一组sequence需进行crc校验，并将校验 数据合并到sequence发送给被测件。对应这类需求，可以在seq_base组 件中完成，在build创建结束时使用task对sequence重新配置，产生客 户需要的新的激励。
64.seq_lib库设计：
65.假设一个dut，需求中有m个功能点，每个功能点需要一组测试序列， 每组测试序列包含l个采样点：则所有的测试序列可表征为：
66.seq＝{(zi,yi)|zi∈rm,yi∈{1,0},i＝1,...,l},
67.zi＝{fi1,...,fim},zi表示dut的m个特性其中的一个功能点。yi 表示第i个功能特性是否含有bugs，当yi＝1表示至少有1个bugs，当yi＝0 表示没有任何bugs。最终，dut的所有功能点特性都以测试序列数来建立 表征关系，其结果用来预测一个新dut。
68.若是一个bug存在一条路径中，所有的路径节点可以看作是测试序列 数据的一些元素构成，比如可以是由一个数据包存在多个激励点，可以是 不同顺序的数据、数据中某数据位、数据长度等影响，也可以是多个p的 组合而成。如情况1：bug存在路径：p21，则p1-p2-p21的路径就是该bug 存在路径，测试就是通过测试序列寻找出这些点，将这条路径上的点激活 就能发现该bug。以此，设计测试序列就是将需求中激活路径的点采用列表 形成数据帧格式，再将列表的数据帧转换成class类的sequence形式，最 后通过多次随机遍历的方式寻找出sequence中存在的bug。
69.测试的可重用性包含了继承性的可重用性和组合性的可重用性，继承 性的可重用性是指对已有的测试序列的属性和方法继承，在此基础上，增 加或改变约束条件而产生一个新的测试序列；组合性的可重用性则是同一 个测试序列，在不做改变的情况下，直接用在不同的被测件上。考虑多个 设计dut，每个dut需求可能存在不同要求，就需要每个dut都产生一个 seq_lib。
70.sequence的可重用性放在seq_base组件中完成，含2个dut接口测试， 通过识别不
同dut，调用不同的seq_lib，并对seq_lib进行实例化、随机 化、测试序列重组化处理以及参数传递等封装。
71.从两个方面进行库的可重用性证明：情况1)被测件u1的emif总线写 操作时，需要使用被测件u1的emif_write激励；情况2)被测件u1的emif 总线写操作时，需要使用被测件u2的emif_write激励。
72.两种情况的测试结果，从以上可以看出，不同待测dut，只需要指定测 试对象是u1还是u2，只需发送一句测试指令，就可以从参考库中提取不同 的sequence直接供其他组件使用，从而也证明激励是具有可重用性。
73.driv_lib库设计：
74.通过需求引导所有drive生成，使得drive与sequence之间可以直接 通信，driv_lib库设计使用模块(module)封装，采用task封装drive任 务，主要包含sequence调用、各种接口驱动产生等任务。
75.如图6为driv_lib处理架构，包含了emif总线写、uart等接口驱动， dut内的所有驱动器采用task第1次封装；使用program automatic程序 将所有dut的驱动器成员第2次封装，支持所有任务、函数和模块参数传 递具有自动存储功能；在program automatic程序之外对sequence使用task 调用封装，最后使用模块(module)总体第3封装，支持时序驱动，建立 与dut连接关系。
76.driv_lib设计原则：库内的每个驱动器使用task任务例化封装接口， 接口的参数传递必须以ref形式定义，库内的接口信号命名不能重名，否 则产生竞争现象；库的对外接口列举所需的时钟等外部关键信号。若是考 虑验证多个设计dut，考虑到所有可能情况以及可重用性，针对每个dut使 用模块(module)封装，形成一个文件，可以定义为dut1的驱动器库driv1。 若是有多个{dut1,dut2,
…
}，则形成多个{driv1,driv2,
…
}，而 {driv1,driv2,
…
}集合则定义为新的驱动器库。
77.resu_lib库设计：
78.resu_lib实现方法如图8所示。期望结果通过seq_lib提取，seq_lib 是一种静态数据，提取不受时间约束，可直接进行提取，实测结果通过dut 提取，dut是一种时序电路，是一种动态数据，提取受时间约束，不能直接 进行提取，
79.采用always@*作为在整个测试时序过程中提取参数，提取时根据不同 test_task需求提取不同的接口参数，如使能信号、实测数据等，提取放在 整个测试过程进行，即覆盖了期望结果也满足实测结果提取要求，通过判 断`test_type，至少需要提取采样时钟、期望结果和实测结果3类参数。 打印结果输出放在整个测试过程中进行，对结果提取放在program程序外 进行，实施连续监控和打印，通过采样时钟分别提取期望结果和实测结果， 根据评估准则，比较期望结果和实测结果，打印测试结果，最后可通过查 看打印文件确认测试结果是否通过。
80.组件解耦与覆盖性分析：
81.通过命令层和功能层设计，完成对参考库模型，最后再通过top顶层 执行测试工作，其组件解耦与覆盖率特性如图9所示。组件解耦主要表现 在先是将需求分解为测试项和测试用例，top中识别测试项，通过seq_base 组件调用gen_sequence，即提取seq_lib库中的测试序列，测试序列通过 识别标识创建测试序列，表明测试是需求驱动，测试序列与
测试平台、被 测件之间被seq_base组件隔离，测试序列设计与时序、测试环境和被测件 无关，仅是依据需求分解出的测试用例相关。因此，可以确认测试序列与 测试平台、被测件之间被seq_base组件之间做到了100％隔离。同时测试执 行过程中，测试的驱动器、检测器调用driv_lib库和resu_lib库中函数， 对函数接口采用可重用的形式定义接口信号，也做到了驱动器、检测器与 测试环境、被测件之间有效隔离。
82.测试功能覆盖性提升是通过两个方面实现，一方面是测试项覆盖率收 集，另一方面是测试用例覆盖率收集。从图中可以看出，需求分解成测试 项，在top中识别调用测试序列执行测试，通过seq_base完成收集测试项 的覆盖率结果。需求分解成测试用例，在设计测试序列时采用动态数组， 添加不同的随机化约束，覆盖所有测试用例，最后在seq_base中完成对测 试序列中的所有测试点覆盖结果收集。
83.本发明的优点和积极效果在于：
84.搭建环境的测试代码量、文件数据数量、测试层数，以及单个功能点 测试花费的时间、总的测试时间进行分析对比，通过对比，测试代码量有 效减小60％，设计文件数量减少61.5％，测试层数复杂度减少40％，测试时 间缩短66.7％，测试效率提升40％以上。可以看出，新方法不论在设计还是 测试中都比uvm简单、高效，测试效果提升显著。在大型复杂多变的测试 环境中，仿真速度、可重用性的提升效果都将会更加明显。
85.基于需求驱动的功能验证方法，能从更宏观的角度去考察验证问题， 可以最大程度地减少人工工作量，改变产品的测试方式。对于目前越来越 复杂的验证需求，使用uvm等验证方法很大一部分时间放在了验证环境搭 建中，而采用此方法，验证操作简单，能够根据需求定制出不同的参考库 模型，且相互之间不会影响，不仅能减少很多繁琐的工作，还能为测试人 员带来新思路，建立可持续集成的验证平台，通过参考库参数不断迭代累 加和优化，为进一步打造智能化验证平台奠定基础。
86.命令层相当于将uvm的测试层，作为顶层使用，通过枚举和查询的方 式，下发各种testcase，主要测试指令包括被测对象(test_dut)、功能 点(test_task)，以及功能点对应的激励(sequence)、驱动(drive) 和检测结果(result)调用等指令。
87.功能层相当于将uvm的场景层、功能层和命令层三合为一，是代理接 收来自命令层的事务。在识别test_dut后，首先下发test_task指令，然 后根据不同的test_task，从ref_lib中选择性启动seq_lib的激励产生指 令sequence、driv_lib驱动指令drive、resu_lib提取结果指令result， 输出测试结果。同时过程中可能会增加时延、多轮测试次数等参数。
88.ref_lib集合了seq_lib、driv_lib和result_lib三类库，采用sv 验证语言搭建，将验证平台所需的基础设施独立出来，参数化表达，使用 激励处理器(seq_base)对seq_lib中的激励sequence进行创建、例化、 随机化及重组等封装，最终ref_lib形成一个公共的参考库，其目的是不 需要经常性的修改，便能在所有测试项目中通用。
89.基于需求驱动的验证平台包含命令层、功能层和信号层共3个层次， 首先依据需求说明提取需求功能点，命令层根据需求功能点下发不同测试 指令(testcase)；然后功能层从参考库(ref_lib)中的激励器库(seq_lib， 测试序列库)、驱动器库(driv_lib)和检测器库(resu_lib)里提取任 务和函数，执行测试指令并输出测试结果，信号层提供被测件(dut)接口 信号；最后根据功能覆盖率检验充分性，遍历所有功能点，完成需求的所 有功
能测试。
90.综上，本发明采用需求驱动验证功能方法:
91.以需求为导向，按照需求对功能点进行列表化，然后通过枚举方法， 将列表后的协议映射为代码标识，最后再根据功能点的具体操作内容，将 功能点转换为命令层的具体可执行代码模型。
92.采用seq_lib库实现激励产生，能识别不同test_task，产生各种 sequence的集合体，sequence之间相互独立。
93.采用driv_lib库实现驱动产生，所有driv_lib需先建立一个任务： seq_lib调用，通过seq_base从seq_lib从提取sequence，能识别不同 test_task，产生各种drive的集合体，drive之间相互独立，能根据test_task将sequence添加到不同的drive上。
94.采用resu_lib库实现检测结果产生，能识别不同test_task，产生各 种result的集合体，result之间相互独立。
95.采用seq_bas模块所有的seq_lib进行封装、激励重组处理等活动， 并将激励传递给drive和result等组件。需求分解成测试项，在top中识 别调用测试序列执行测试，通过seq_base完成收集测试项的覆盖率结果。 需求分解成测试用例，在设计测试序列时采用动态数组，添加不同的随机 化约束，覆盖所有测试用例，最后在seq_base中完成对测试序列中的所有 测试点覆盖结果收集。
96.将需求分解为测试项和测试用例，top中识别测试项，通过seq_base 组件调用gen_sequence，即提取seq_lib库中的测试序列，测试序列通过 识别标识创建测试序列，表明测试是需求驱动，测试序列与测试平台、被 测件之间被seq_base组件隔离，测试序列设计与时序、测试环境和被测件 无关，仅是依据需求分解出的测试用例相关。因此，可以确认测试序列与 测试平台、被测件之间被seq_base组件之间做到了100％隔离。同时测试执 行过程中，测试的驱动器、检测器调用driv_lib库和resu_lib库中函数， 对函数接口采用可重用的形式定义接口信号，也做到了驱动器、检测器与 测试环境、被测件之间有效隔离。
97.本发明公开的一种采用需求驱动验证功能的方法，通过分析业内芯片 验证的主流通用验证方法学(uvm)的不足之处，提出了一种基于需求驱动 的功能验证方法，创建了一种可集成化基础组件的参考库模型，实现激励 100％隔离，建立广泛使用激励的方式。方法的特点组件独立、层次关系少、 环境简洁、可重用性好，能满足不同需求和验证环境需要，经测试结果分 析比较，新方法可快速应用于fpga软件功能验证，有效提升工作效率。
98.实施例2
99.如图1至图9所示，作为实施例1的进一步优化，本实施例包含了实 施例1的全部技术特征，除此之外，本实施例还包括以下技术特征：
100.一个完整的uvm验证平台包含测试层、场景层、功能层、命令层和信 号层共5个层次划分，执行顺序又按phases机制细分为12个阶段，其验 证平台架构如图1所示。
101.uvm平台包含了代理组件(agent)和环境组件(env)两大基本类，每 个代理组件中封装了测试序列器，驱动器和监视器。环境组件封装了测试 序列发生器、代理组件、参考模型、记分器，若是在多重环境时，则需要 创建多个代理组件、多个环境组件。uvm不仅层次关系复杂，执行阶段较多， 且在多重环境时，还需要花费大量的时间设计代理组件和环境组件。
102.这对于一个越来越复杂的设计环境来说是难以接受，随着电子设计复 杂度的持续增长，需要有一种新颖、简洁且系统化的方法来创建验证平台。 一个好的验证平台是以需求为导向，需求改变验证平台，验证平台丰富需 求，是需求与验证相结合的平台。基于需求驱动的验证平台实现框图如图2 所示。
103.基于需求驱动的验证平台包含命令层、功能层和信号层共3个层次， 首先依据需求说明提取需求功能点，命令层根据需求功能点下发不同测试 指令(testcase)；然后功能层从参考库(ref_lib)中的激励器库(seq_lib， 测试序列库)、驱动器库(driv_lib)和检测器库(resu_lib)里提取任 务和函数，执行测试指令并输出测试结果，信号层提供被测件(dut)接口 信号；最后根据功能覆盖率检验充分性，遍历所有功能点，完成需求的所 有功能测试。
104.命令层相当于将uvm的测试层，作为顶层使用，通过枚举和查询的方 式，下发各种testcase，主要测试指令包括被测对象(test_dut)、功能 点(test_task)，以及功能点对应的激励(sequence)、驱动(drive) 和检测结果(result)调用等指令。
105.功能层相当于将uvm的场景层、功能层和命令层三合为一，是代理接 收来自命令层的事务。在识别test_dut后，首先下发test_task指令，然 后根据不同的test_task，从ref_lib中选择性启动seq_lib的激励产生指 令sequence、driv_lib驱动指令drive、resu_lib提取结果指令result， 输出测试结果。同时过程中可能会增加时延、多轮测试次数等参数。
106.参考库(ref_lib)是根据外部需求(requirement specification) 提取输入与输出变量，根据测试说明(test specification)例化识别对 象以及用例特征的表征参数，将多重验证环境的基础设施抽象出来，建立 一种具有可重复性使用的通用性数据库。
107.ref_lib集合了seq_lib、driv_lib和result_lib三类库，采用sv 验证语言搭建，将验证平台所需的基础设施独立出来，参数化表达，使用 激励处理器(seq_base)对seq_lib中的激励sequence进行创建、例化、 随机化及重组等封装；最终ref_lib形成一个公共的参考库，其目的是不 需要经常性的修改，便能在所有测试项目中通用。
108.相比与uvm，新平台基于需求驱动，层次关系少，可重用性好，激励随 机约束，测试设计难度降低，建立平台建立所需时间大为减少，减轻了工 作负担。
109.命令层设计：
110.在需求说明中，一个功能点可以分解为标识、属性、行为和实体四个 部分，功能点就是待测设计在特定的场景下所表现出来的行为及属性，不 论什么样的功能点，通过分散的应用场景和通信场景能够聚合成一个完整 的功能模型[13]。通过分析每一个功能点的属性，明晰每个功能点需要在 什么样的场景下能表现出预期需要的行为，就可以形成一个功能模型。首 先按照需求对功能点进行列表化，然后通过枚举方法，将列表后的协议映 射为代码标识，最后再根据功能点的具体操作内容，将功能点转换为命令 层的具体可执行代码模型，如图3所示。
[0111]
例化中使用typedef enum枚举方法列举出不同功能点test_task的例 化名，枚举命名根据测试需要设计，`define是确定执行哪个功能点，当 `define test_case flash_erase时，表示对判断是否进行flash接口插除 测试。测试命令是测试执行主要阶段，放在顶层完成，使用programautomatic定义测试执行过程自动进行，测试执行流程示意图见下
图4所示。
[0112]
命令层作为顶层设计，主要包含端口例化、定义工作时钟、设定测试 循环次数、枚举待测件和待测功能点等，先做被测对象和功能点识别，再 根据识别结果从ref_lib中提取测试任务和函数，执行测试，最后判决功 能覆盖率是否满足，不满足则迭代进行，满足则结束测试。设计过程中使 用initial fork
…
join_none可完成多个时钟产生。对于复杂功能点的测 试设计，可多次调用ref_lib库里的任务完成。工程师主要花费时间是按 需求中的功能点构造出功能模型，其他基础组件的激励、驱动和检测结果 直接从参考库中调用即可，从这点看，比uvm有很强的通用性和便捷性。
[0113]
功能层设计：
[0114]
功能层由参考库(ref_lib)和激励处理器(seq_base)组成，分别提 供验证平台所需的激励、驱动和检测三种基本功能。参考库的设计是将测 试环境的基础设施抽象出来，定义为具有一定可复用的通用性库文件，包 含了不同dut需求的通用性提取，将seq_lib、driv_lib、resu_lib三者 集合而成，如图5所示。
[0115]
该层次建模组件基本实现功能包括：
[0116]
1)seq_lib：基本功能是实现激励产生，能识别不同test_task，产生 各种sequence的集合体，sequence之间相互独立。
[0117]
2)seq_base：基本功能是对所有的seq_lib进行封装、激励重组处理 等活动，并将激励传递给drive和result等组件。
[0118]
3)driv_lib：基本功能是实现驱动产生，所有driv_lib需先建立一 个任务：seq_lib调用，通过seq_base从seq_lib从提取sequence，能识 别不同test_task，产生各种drive的集合体，drive之间相互独立，能根 据test_task将sequence添加到不同的drive上。
[0119]
4)resu_lib：基本功能是实现检测结果产生，能识别不同test_task， 产生各种result的集合体，result之间相互独立。
[0120]
seq_lib库设计：
[0121]
假设一个dut，需求中有m个功能点，每个功能点需要一组测试序列， 每组测试序列包含l个采样点：则所有的测试序列可表征为：
[0122]
seq＝{(zi,yi)|zi∈rm,yi∈{1,0},i＝1,...,l}
ꢀꢀ
(1)
[0123]
zi＝{fi1,...,fim},zi表示dut的m个特性其中的一个功能点。yi 表示第i个功能特性是否含有bugs，当yi＝1表示至少有1个bugs，当yi＝0 表示没有任何bugs。最终，dut的所有功能点特性都以测试序列数来建立 表征关系，其结果用来预测一个新dut。
[0124]
若是一个bug存在一条路径中，所有的路径节点可以看作是测试序列 数据的一些元素构成，比如可以是由一个数据包存在多个激励点，可以是 不同顺序的数据、数据中某数据位、数据长度等影响，也可以是多个p的 组合而成。如情况1：bug存在路径：p21，则p1-p2-p21的路径就是该bug 存在路径，测试就是通过测试序列寻找出这些点，将这条路径上的点激活 就能发现该bug。以此，设计测试序列就是将需求中激活路径的点采用列表 形成数据帧格式，再将列表的数据帧转换成class类的sequence形式，最 后通过多次随机遍历的方式寻找出sequence中存在的bug。
[0125]
test_type用来识别功能点标识(由test_task产生对应的标识)，根 据识别出的
功能点不同，选取不同的sequence。使用no.sequence表示测 试序列号，如当测试test_type＝＝dsp_write时，产生的是dsp总线写 sequence，当test_type＝＝flash_erase时，产生的是对flash进行擦除 操作sequence。测试序列的产生只根据功能点来生成，不再与测试环境、 被测件有关联。利用动态数组约束关联测试序列。图中采用16bit设计总 线，设计的第1包数据内容：帧头、消息体、帧尾、地址等信息。动态数 组在随机约束过程中，使用-》或if{
…
}else{
…
}条件判决，约束中不 识别begin
…
end语句，必须使用{
…
}指定一段的完整数组约束加以区分， 若是不使用，则数组约束过多时会产生数组混乱现象。
[0126]
equence的可重用性：
[0127]
测试的可重用性包含了继承性的可重用性和组合性的可重用性[14]， 继承性的可重用性是指对已有的测试序列的属性和方法继承，在此基础上， 增加或改变约束条件而产生一个新的测试序列；组合性的可重用性则是同 一个测试序列，在不做改变的情况下，直接用在不同的被测件上。考虑多 个设计dut，每个dut需求可能存在不同要求，就需要每个dut都产生一个 seq_lib，sequence可重用性如图8所示。sequence的可重用性放在 seq_base组件中完成，如上图所示，含2个dut接口测试，通过识别不同 dut，调用不同的seq_lib，并对seq_lib进行实例化、随机化、测试序列 重组化处理以及参数传递等封装。
[0128]
从两个方面进行库的可重用性证明：情况1)被测件u1的emif总线写 操作时，需要使用被测件u1的emif_write激励；情况2)被测件u1的emif 总线写操作时，需要使用被测件u2的emif_write激励。
[0129]
不同待测dut，只需要指定测试对象是u1还是u2，只需发送一句测试 指令，就可以从参考库中提取不同的sequence直接供其他组件使用，从而 也证明激励是具有可重用性。设计中以驱动不同测试激励测试序列建立， 巧妙利用seq_base组件实现测试激励与其他组件完全隔离，激励设计需求 定制化，可重用性好等特点，可以应用于不同的需求。
[0130]
seq_base组件设计：
[0131]
seq_base组件主要是完成对所有的sequence的创建、例化、随机化、 重组处理，以及功能覆盖率收集。
[0132]
采用一个公共的seq_base组件完成对所有sequence进行创建、例化、 随机化以及重组处理，以class类的形式完成。首先是对sequence的类进 行例化，如将seq1类例化成ra1，然后使用build进行创建，例化过程中 将sequence的长度传递给动态数组，以便确定其具体长度，使用new()实 例化ra1，assert(seq.randomize())对ra1进行随机化处理。crc_chk() 是对ra1进行数组重组，使用covergroup开展覆盖率收集。
[0133]
在设计sequence时，有时候会存在对输出的一组或多组sequence有 其他额外要求，如对每次输出的一组sequence需进行crc校验，并将校验 数据合并到sequence发送给被测件。对应这类需求，可以在seq_base组 件中完成，在build创建结束时使用task对sequence重新配置，根据不 同的测试项标识，产生客户需要的新的激励。可以看出，激励仅通过 seq_base类与外界联系，因此，激励实现了与被测件、测试环境之间的100％ 隔离。
[0134]
driv_lib库设计：
[0135]
通过需求引导所有drive生成，使得drive与sequence之间可以直接 通信，driv_lib库设计使用模块(module)封装，采用task封装drive任 务，主要包含sequence调用、各种接口驱动产生等任务。上图为driv_lib 处理架构，包含了emif总线写、uart等接口驱动，
dut内的所有驱动器采 用task第1次封装；使用program automatic程序将所有dut的驱动器成 员第2次封装，支持所有任务、函数和模块参数传递具有自动存储功能； 在program automatic程序之外对sequence使用task调用封装，最后使 用模块(module)总体第3封装，支持时序驱动，建立与dut连接关系。
[0136]
driv_lib设计原则：库内的每个驱动器使用task任务例化封装接口， 接口的参数传递必须以ref形式定义，库内的接口信号命名不能重名，否 则产生竞争现象；库的对外接口列举所需的时钟等外部关键信号。若是考 虑验证多个设计dut，考虑到所有可能情况以及可重用性，针对每个dut使 用模块(module)封装，形成一个文件，可以定义为dut1的驱动器库driv1。 若是有多个{dut1,dut2,
…
}，则形成多个{driv1,driv2,
…
}，而{driv1,driv2,
…
}集合则定义为新的驱动器库。
[0137]
drive的可重用性：对于多个待测dut，每个dut含有不同的drive要 求，就需要每个dut都产生一个driv_lib库，driv_lib库的可重用性举例 证明：同一个驱动器在被测件u1的emif总线对特定地址写4个随机数， 在被测件u2的emif总线对特定地址写3个随机数。
[0138]
经测试，平台对u1的emif总线对特定地址'h601010写了4个随机数， 对u2的emif总线对特定地址'h602020写了3个随机数，调用同一个 emif_write驱动器命，发送两组不同的指令，便实现对不同dut的emif总 线写测试，从而证明了驱动器库的同一个驱动器能够在不同的dut中可重 复使用。
[0139]
resu_lib实现方法如图8所示。
[0140]
期望结果通过seq_lib提取，seq_lib是一种静态数据，提取不受时间 约束，可直接进行提取。
[0141]
实测结果通过dut提取，dut是一种时序电路，是一种动态数据，提取 受时间约束，不能直接进行提取。
[0142]
采用always@*作为在整个测试时序过程中提取参数，提取时根据不同 test_task需求提取不同的接口参数，如使能信号、实测数据等，提取放在 整个测试过程进行，即覆盖了期望结果也满足实测结果提取要求，通过判 断`test_type，至少需要提取采样时钟、期望结果和实测结果3类参数。 打印结果输出放在整个测试过程中进行，对结果提取放在program程序外 进行，实施连续监控和打印，通过采样时钟分别提取期望结果和实测结果， 根据评估准则，比较期望结果和实测结果，打印测试结果，最后可通过查 看打印文件确认测试结果是否通过。
[0143]
result的可重用性：与uvm相比，无需分开处理以及同步化处理等问 题，处理方法简单，result_lib的可重用性举例证明：与drive的可重用 性相似。
[0144]
对被测件dut1和dut2的emif总线写功能测试同时做了2轮不同的测 试序列测试，并打印出8次对比后的测试结果，其打印指令可满足一定的 复用性。
[0145]
组件解耦与测试覆盖性分析：
[0146]
通过命令层和功能层设计，完成参考库建立，最后再通过需求驱动top 层执行测试工作。其组件间的消息传递如图9所示。
[0147]
先是需求被分解成测试项，如test_uart,......等，top层中识别出 测试项，当发现测试项为test_uart时，分别调取参考库中激励器、驱动 器和检测器。driv.gen_sequence(“uart_seq01”,17,cyc)表示提取测试 项为test_uart下的uart_seq01测试激励
测试序列，17为测试序列长度， cyc为测试序列的重复数，测试激励测试序列通过识别标识uart_seq01产 生随机测试序列，激励与测试环境、被测件、需求之间被seq_base组件隔 离开来，使得测试激励测试序列设计不需要时序、测试环境和被测试等参 数参与，仅依据需求分解出的测试用例来设计测试序列。同时，过程中调 用驱动任务采用可重用的形式定义任务接口信号，uart_send(1,rx_in)表 示串口发送函数，1代表奇偶特性，rx_in代表发送端口，激励与驱动、检 测、被测件间做到了100％隔离。而uvm组件间信息传递是有严格的端口要 求，因此解耦性比uvm会更好。
[0148]
测试功能覆盖性实现是通过seq_base组件的covport.sample()分别 收集需求的测试项{_uart,......}和测试用例 {uart_seq01,uart_seq02.....}完成，由于seq_base组件实现了对所有测 试序列的管理，因此覆盖率收集只需要对测试项、测试用例标识和测试序 列特定值三个参数收集即可。1个测试序列中可以包含1个或多个测试用例， 如串口的测试用例{uart_seq01,uart_seq02.....}，同时，1个测试用例如 uart_seq01采用的是动态数组设计，添加不同的随机化约束，也可以在进 一步再将1个测试用例细分成更多个子测试用例{uart_seq01_1,uart_seq01_2.....}，做到充分覆盖所有需求点。
[0149]
uvm仅涉及测试用例，其测试用例覆盖需求功能人为因素影响较多，因 此，新方法实现比uvm功能覆盖率更充分。
[0150]
实验与结果：
[0151]
为了便于分析对比，选取文献[15]uvm验证方法，与本方法对同一个项 目进行验证，选取fpga软件代码规模3千行左右，需求功能点26个，测 试完成后对结果数据进行对比分析，测试及分析结果如表1所示。
[0152]
表1测试性能参数比较
[0153][0154]
分别从搭建环境的测试代码量、文件数据数量、测试层数，以及单个 功能点测试花费的时间、总的测试时间进行分析对比，与uvm相比，测试 代码量的大大减小，设计一个uvm验证平台，一般需要设计3000～4000行 代码，采用新方法，仅需要设计400～500行代码，在相同功能下设计代码 量大为减小；设计文件数量减少61.5％，uvm设计文件数量一般至少是在13 个以上，在多重验证环境中甚至翻倍，而新的方法设计文件数量一般只需5 个，利用需求之间存在很多的共性关系，在多重验证环境中，新增代码减 少效果明显，仅需要较小的修改就可重用；测试层数复杂度减少40％，测试 时间缩短66.7％，测试效率提升
40％以上。
[0155]
功能覆盖率uvm只收集测试序列特定值1个对象，且存在人为因素影 响；新的方法收集测试项、测试用例、测试序列特定值3个对象，收集方 式完全追踪需求功能点，人为因素影响较小，覆盖对象更全面。
[0156]
继承性的可重用性应用中，组件重用占比提升15.6％，在组合性的可重 用性应用中，组件重用占比提升37.8％，在组合性中提升效果会更好。
[0157]
可以看出，新方法不论在设计还是测试中都比uvm简单、高效，测试 效果提升显著。在大型复杂多变的测试环境中，仿真速度、可重用性的提 升效果都将会更加明显。
[0158]
综上，基于需求驱动的功能验证方法，能从更宏观的角度去考察验证 问题，可以最大程度地减少人工工作量，改变产品的测试方式。对于目前 越来越复杂的验证需求，使用uvm等验证方法很大一部分时间放在了验证 环境搭建中，而采用此方法，验证操作简单，能够根据需求定制出不同的 参考库模型，且相互之间不会影响，不仅能减少很多繁琐的工作，还能为 测试人员带来新思路，建立可持续集成的验证平台，通过参考库参数不断 迭代累加和优化，为进一步打造智能化验证平台奠定基础。
[0159]
本发明提出了一种基于需求驱动的功能验证方法，利用需求之间存在 的很多共性特点，提取了多重验证环境下的验证基础设施组件，创建出一 种可集成化验证基础组件的参考库模型，利用需求驱动所有测试组件，做 到了需求、激励、驱动、检测、被测件之间的100％隔离，创建出具有广泛 使用的验证模式。新方法与uvm验证方法学相比，可重用性提升效果显著， 具有组件独立、层次关系少、使用方便等特点，可满足不同需求和验证环 境需要。举例对参考库的可重用性进行了有效性证明，最后对测试结果分 析比较，表明新方法可以快速应用于多重环境的软件功能验证，提升工作 效率。
[0160]
如上所述，可较好地实现本发明。
[0161]
本说明书中所有实施例公开的所有特征，或隐含公开的所有方法或过 程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合 和/或扩展、替换。
[0162]
以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式 上的限制，依据本发明的技术实质，在本发明的精神和原则之内，对以上 实施例所作的任何简单的修改、等同替换与改进等，均仍属于本发明技术 方案的保护范围之内。