CN104166744A - 验证视频算法寄存器传输级实现的方法和系统 - Google Patents

Abstract

本发明公开了一种验证视频算法寄存器传输级实现的方法，包括：构建测试视频序列库；从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。本发明还公开了一种验证视频算法寄存器传输级实现的系统。本发明的具体实施方式通过生成测试序列自动选择程序，能够根据功能覆盖率自动挑选测试序列，并和算法参数一起组成测试向量，使算法功能覆盖率达到100%，因此提高了对视频算法寄存器传输级设计进行验证的效率和正确性。

Description

验证视频算法寄存器传输级实现的方法和系统

技术领域

本申请涉及芯片设计技术领域，尤其涉及一种验证视频算法寄存器传输级实现的方法和系统。

背景技术

随着嵌入式系统的高速发展，嵌入式系统芯片（SoC）视频芯片应用范围越来越广泛，然而在芯片规模变得越来越大、功能变得越来越复杂、SoC的IP复用等新情况的出现使功能验证这一工作变得更重要、更艰巨。在现代集成电路（IC）设计中，大约有50%～70%的设计周期被用在了功能验证上，而且随着SoC规模的不断扩大，其比例还会不断增加。如果在行为和功能调试时忽视这个过程，就很难在后面的物理设计阶段发现逻辑性错误，而只能在流片之后才会被测试出来，这就导致了设计的高成本以及会耽搁芯片的最终上市时间（Time-to-Market）。从成本和上市时间的角度来考虑，通过功能验证发现逻辑性错误，将会极大地降低整个设计的成本。

当芯片的规模和功能越来越复杂时，输入激励的可能空间是巨大的，而且对一个输入激励，完成同样的视频算法，硬件仿真的时间远比软件仿真所需的时间长，穷尽仿真所有的输入组合变得不可行。所以只能选取输入空间中选择部分有效的子集作为输入激励进行验证。

目前，在对视频算法的RTL硬件实现进行验证时，主要采用直接验证的方法，手动选取测试序列作为输入激励进行测试。这种直接验证的方法的效率严重依赖于验证者的经验，选取的测试序列可能包含了大量对功能覆盖率提高没有贡献的序列，花费了大量的测试运行时间，但却未得到高的覆盖率。

发明内容

本申请要解决的技术问题是针对现有技术的不足，提供一种基于功能覆盖率驱动验证视频算法寄存器传输级实现的方法。

本申请要解决的另一技术问题是提供一种基于上述方法的系统。

本申请要解决的技术问题通过以下技术方案加以解决：

一种验证视频算法寄存器传输级实现的方法，包括：

构建测试视频序列库；

从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；

根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；

对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

所述对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证包括：黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后，分别产生输出，若这些输出一致，则验证通过；若不一致，则验证失败。

若所述验证失败后，还包括：确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

所述黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

所述待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。

一种验证视频算法寄存器传输级实现的系统，包括测试视频序列库、测试向量生成器和文件比较器；

所述测试向量生成器用于从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；

所述文件比较器用于对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

所述文件比较器还用于对黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后所产生的输出进行比较，若这些输出一致，则验证通过；若不一致，则验证失败。

所述文件比较器还用于在所述验证失败后，确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

所述黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

所述待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。

由于采用了以上技术方案，使本申请具备的有益效果在于：

⑴在本申请的具体实施方式中，通过在Golden C Model上添加功能覆盖率检查代码，生成测试序列自动选择程序，能够根据功能覆盖率自动挑选测试序列，并和算法参数一起组成测试向量，使算法功能覆盖率达到100%，因此解决了采用直接验证的方法对视频算法的寄存器传输级设计进行验证时，需要花费大量测试时间，却不能得到高的功能覆盖率的问题，提高了对视频算法寄存器传输级设计进行验证的效率和正确性。

⑵在本发明的具体实施方式中，将待验证的功能点列表分为算法功能点和硬件功能点，在Golden C Model上进行算法功能点的测试场景构建；因为GoldenC Model的运行时间远比RTL仿真的时间快，所以能够快速找到测试序列和参数组合构成测试场景；构建好满足算法功能覆盖率目标的测试场景后，就可以并行运行多个RTL仿真，从而大大提高验证的效率。

附图说明

图1是本申请验证RTL硬件实现系统一个实施例的结构示意图；

图2是对应于图1所示实施例对视频算法的RTL硬件实现进行验证方法实施例的流程图；

图3为根据本申请实施例测试向量生成器生成测试向量的方法流程图；

图4为根据本申请实施例在测试向量生成器生成测试向量后对视频算法的RTL硬件实现进行验证的方法流程图。

具体实施方式

下面通过具体实施方式结合附图对本发明作进一步详细说明。

功能验证就是要确保硬件设计功能的正确性。本申请所涉及的硬件设计是寄存器传输级（Register Transfer Level，简称RTL）的硬件设计，所以仅涉及对于RTL硬件设计的验证。简而言之，就是核实经过人工翻译或工具翻译后的设计属性与翻译前的设计属性是否一致。它主要验证硬件的硬件描述语言（HDL）描述是否符合设计的功能描述。

通常，基于功能覆盖率驱动的对视频算法的RTL硬件实现进行验证方法流程为：构建测试场景，产生输入激励→RTL仿真→覆盖率分析，若覆盖率未达到目标，则要顺序重复上述步骤。当硬件规模越来越大时，RTL仿真需要花费大量时间，这样完成一次迭代需要大量时间，要达到覆盖率目标，需要多次迭代，所以总体验证时间巨大。

本申请针对视频算法的RTL硬件实现的特点，提出了一种基于功能覆盖率驱动的对视频算法的RTL硬件实现进行验证的系统及方法，该方法将待验证的功能点列表分为算法功能点和硬件功能点，其中算法功能点即视频算法应该满足的功能特性，RTL硬件实现后，必须检查视频算法应该满足的功能特性是否被正确实现；硬件功能点为硬件上的时序要求等；然后在Golden C Model上进行算法功能点的测试场景构建；因为Golden C Model的运行时间远比RTL仿真的时间快，所以能够快速找到测试序列和参数组合构成测试场景；构建好满足算法功能覆盖率目标的测试场景后，就可以并行运行多个RTL仿真，从而大大提高验证的效率。

实施例一：

本申请的验证视频算法寄存器传输级实现的系统，其一种实施方式，包括测试视频序列库、测试向量生成器和文件比较器；测试向量生成器用于从测试视频序列库根据预定功能覆盖率选取规则选取测试序列；根据选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；文件比较器用于对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

在一种实施方式中，文件比较器还用于对黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后所产生的输出进行比较，若这些输出一致，则验证通过；若不一致，则验证失败。

在一种实施方式中，文件比较器还用于在所述验证失败后，确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

在一种实施方式中，黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

在一种实施方式中，待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。

如图1所示，图1是依照本申请实施例基于功能覆盖率驱动的对视频算法的RTL硬件实现进行验证的系统的示意图，该系统包括测试视频序列库、测试向量生成器、Golden C Model、待验证的RTL硬件模型和文件比较器。

其中，测试视频序列库用于存储对视频算法的RTL硬件设计进行验证所需要的测试序列。测试向量生成器用于从测试视频序列库中根据算法功能覆盖率选取测试序列，并生成测试向量，再将该测试向量输出给Golden C Model和待验证的RTL硬件模型。Golden C Model是用C语言编写的实现一定视频处理功能的模块，待验证的RTL硬件模型是用硬件描述语言编写的，实现与Golden CModel相同的视频处理功能的模块，是功能验证的对象。Golden C Model和待验证的RTL硬件模型接收到测试向量后，会分别产生输出，并将各自的输出输出给文件比较器。文件比较器比较Golden C Model的输出与待验证的RTL硬件模型的输出是否一致，如果一致，则验证通过，如果不一致，则待验证的RTL硬件模型中存在Bug，需要对待验证的RTL硬件模型进行调试。

其中测试向量生成器包含有一个测试序列自动选择程序，该测试序列自动选择程序在Golden C Model上添加了功能覆盖检查和覆盖率评估代码，具有自动挑选测试序列的功能。

实施例二：

本申请的验证视频算法寄存器传输级实现的方法，其一种实施方式，包括以下步骤：

步骤A：构建测试视频序列库；

步骤B：从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；

步骤C：根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型。黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

步骤D：对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

对黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证包括：黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后，分别产生输出，若这些输出一致，则验证通过；若不一致，则验证失败。

待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。

步骤E：若所述验证失败后，还包括：确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

图2是对应于图1所示系统对视频算法的RTL硬件实现进行验证的方法实施例的流程图，该方法包括以下步骤：

步骤201：测试向量生成器从测试视频序列库中根据算法功能覆盖率选取测试序列，生成测试向量，并将该测试向量输出给Golden C Model和待验证的RTL硬件模型；

步骤202：Golden C Model和待验证的RTL硬件模型接收到测试向量后，会分别产生输出，并将各自的输出均输出给文件比较器；

步骤203：文件比较器比较Golden C Model的输出与待验证的RTL硬件模型的输出是否一致，如果一致，则验证通过，如果不一致，则待验证的RTL硬件模型中存在Bug，需要对待验证的RTL硬件模型进行调试，返回执行步骤201。

基于图2所示的对视频算法的RTL硬件实现进行验证的方法流程图，图3示出了依照本申请实施例测试向量生成器生成测试向量的方法流程图，该流程包括以下步骤：

步骤1：在算法设计人员指导下确定待验证的算法功能点列表和测试视频序列库；

步骤2：在Golden C Model上加入功能覆盖检查点和功能覆盖检查代码，以及覆盖率评估代码，生成测试序列自动选择程序；

步骤3：在最佳联合覆盖率列表上，将所有算法功能点的属性设为“未覆盖”；

步骤4：设定算法参数，第一次运行时设为默认；

步骤5：运行测试序列自动选择程序，该自动选择程序的步骤是：

1）遍历测试视频序列库的所有测试序列，计算每个测试序列与已经选出的测试序列集合的联合覆盖率，挑选联合覆盖率最高的测试序列进入测试序列集合；

2）将最佳联合覆盖率列表更新为本次遍历联合覆盖率最高的测试序列所对应的联合覆盖率列表；

3）检查功能覆盖率，如果功能覆盖率超过门限或迭代次数超过门限，则退出，否则返回步骤2。运行一次步骤2到步骤4为一次迭代。

其中，计算每个测试序列与已经选出的测试序列集合的联合覆盖率，是在已产生的测试序列集合对应的最佳联合覆盖率列表基础上，将该测试序列新覆盖的功能点属性改为“已覆盖”，再计算覆盖率。

步骤6：检查算法功能覆盖率，如未达到100%，则分析功能覆盖率报告，根据不同情况采取如下措施：

1）重新返回步骤4，修改算法参数；

2）向测试视频序列库中添加新的测试序列，返回步骤5；

3）产生具有特定特征的测试序列，加入测试视频序列库，返回步骤5；

步骤7：将挑选出的测试序列集合以及对应的算法参数配置构成测试向量。

基于Golden C Model来产生测试向量的原因是，Golden C Model是RTL硬件设计的对比方，RTL硬件设计的目标就是实现Golden C Model的功能，而且因为Golden C Model是用C程序编写，所以其运行的速度远比硬件RTL仿真的速度快，基于Golden C Model能快速地找到合适的测试向量。

在算法设计人员指导下确定待验证的算法功能点列表和测试视频序列库，这一点具有特别重要的意义。因为通常情况下，视频算法开发和硬件实现的任务由不同的部门来担当。如果一个RTL设计人员不了解视频算法，仅以代码覆盖率为衡量目标进行验证，不仅效率不高，而且难以保证验证的质量。因为代码覆盖率只是表示对RTL源代码的执行情况，和源代码所描述的功能没有关系，因而具有很大的局限性。比如一个状态机的状态如果每个状态都覆盖到，可是并不能表示状态之间相互转换的过程也被遍历到。功能覆盖率是用户定义的在验证过程中某种功能的运行程度，经验表明，功能覆盖率与出错（bug）之间有紧密联系。但代码覆盖率可以作为功能覆盖率的补充，如果功能覆盖率高而代码覆盖率低，有可能已有的待验证的功能点还不完全，此时需添加新的功能点。通常，视频算法开发人员对算法有着比RTL设计人员更深入和更准确的理解，所以在算法设计人员指导下确定待验证的算法功能点列表和测试视频序列库有着事半功倍的效果。

在Golden C Model上加入功能覆盖检查点和功能覆盖检查代码，以及覆盖率评估代码，可以生成测试序列自动选择程序。关于如何实现测试序列自动选择程序可以用典型的视频处理算法运动估计来举例。假设待验证运动估计的功能点有：

Case1:当输入视频发生场景切换时，运动估计的相应的处理是否和GoldenC Model一致；

Case2:当输入视频中含有大量纹理区域时，运动估计相应的处理是否和Golden C Model一致；

Case4:当输入视频中含有透明菜单时，运动估计相应的处理是否和GoldenC Model一致；

Case5:当输入视频中含有超过运动搜索范围的运动时，运动估计相应的处理是否和Golden C Model一致；

那么，在Golden C Model中添加数据结构TestCaseList

数据结构TestCaseList的元素和其代表的意义为：

isSeneChangeCovered：场景切换被覆盖了吗？

isPatternCovered：周期性纹理区被覆盖了吗？

isOSDCovered：透明菜单的场景被覆盖了吗?

isBigMotionCovered：大运动的场景被覆盖了吗？

Coverage:覆盖率

TestCaseList所有元素的初始值为FALSE，即“未覆盖”。然后在C Model上相应的位置添加覆盖检查的代码。比如在运动估计中的代码中有周期性纹理区检测的标志，isPattern.

则可以通过该标志来检查是否被周期性纹理区这个场景是否被覆盖。如下所示

If(isPattern=TRUE)then

isPatternCoved=TRUE;

在一个序列运行结束后，可以检查数据结构TestCaseList各元素的属性并得出覆盖率并将该覆盖率付给元素Coverage。遍历一次测试序列库，即运行测试序列库中的所有序列，能从中找出覆盖率最高的序列，并将此序列放入测试序列集合。然后将本次遍历中得到的覆盖率及覆盖列表作为初始值，进行第二次的测试序列库的遍历，第二次遍历挑选出的序列并非自身覆盖率最高的序列，以第一次遍历中得到的最佳覆盖列表为初始值，在上面进行覆盖率计算，能计算出和已经挑选出的序列组成的联合覆盖率最高的序列。第二次遍历后再进行第三次遍历，直至联合覆盖率的大小超出设定的门限或者遍历的次数超出设定的门限为止。

如果联合覆盖率未达到100%，则分析功能覆盖率报告，则可根据不同情况采取如下措施

1）修改算法参数，重新再进行测试序列的选择；

2）向测试序列库中添加新的视频测试序列；

3）产生具有特定特征的视频测试序列，加入测试序列库；

如果仅使用一套算法参数运行测试序列库，很难使功能覆盖率达到100%。比如对于运动估计的功能点列表中isBigMotionCovered这个特征，采用如下方法进行覆盖判断

If(mvx>SEARCHRANGE_H)and(mvy>SEARCHRANGE_V)then

isBigMotionCovered=TRUE;

end.

Mvx为运动向量的水平分量。Mvy为运动向量的垂直分量。SEARCHRANGE_H为水平搜索范围参数，SEARCHRANGE_V为垂直搜索范围参数，如果水平搜索范围参数和垂直搜索范围参数过大，则该条件不容易被满足。如果将这两个参数设定比较小的值，则很多测试序列都可以满足这个要求。

如果修改算法参数也无法使功能覆盖率达到100%，则应分析覆盖率报告，添加新的视频测试序列或者用随机生成和指定特征生成的方法产生新的测试序列加入测试序列库。

这样，可以将测试序列和算法参数组成测试向量。

在测试向量生成器生成测试向量后，运行RTL验证，图4为依照本发明实施例在测试向量生成器生成测试向量后对视频算法的RTL硬件实现进行验证的方法流程图，该方法包括以下步骤：

步骤10：将测试向量生成器生成的测试向量输出给Golden C Model和待验证的RTL硬件模型，运行Golden C Model仿真和RTL硬件模型仿真；Golden CModel和待验证的RTL硬件模型接收到测试向量后，分别产生输出，并将各自的输出均输出给文件比较器；

步骤20：文件比较器比较Golden C Model的输出与待验证的RTL硬件模型的输出是否一致，如不一致，则待验证的RTL硬件模型中存在Bug，需要修改代码，返回步骤10，进行功能调试；

步骤30：检查所有的测试向量是否都已经过测试，如否，返回步骤10，继续进行功能调试；当所有的测试向量都已运行并且得到与Golden C Model相同的输出，则算法功能验证结束；

步骤40：制定待验证的硬件功能点列表；

硬件功能点为除算法功能点之外的待验证的功能点。一般和时序有关。比如对于运动估计这个视频算法的RTL硬件实现，可以制定如下的硬件功能点：

Case1：不同帧率下运动估计是否正确；

Case2：相同帧率下时序信号发生变化时运动估计的结果是否正确；

步骤50：构建硬件功能点测试场景；

针对硬件功能点Case1，修改运动估计RTL硬件设计内部的时序产生器参数，产生不同帧率的时序；

针对硬件功能点Case2，修改运动估计RTL硬件设计内部的时序产生器参数，产生相同帧率，但不同的行列消隐区长度，来产生不同的时序信号；

步骤60：运行RTL仿真；

对于硬件功能点Case1，构建的测试场景为：修改运动估计RTL硬件设计内部的时序产生器参数，产生不同帧率的时序；所以修改时序产生器参数后，运行修改参数后的RTL仿真，就能得到该测试场景下的输出；

步骤70：检查功能覆盖率，如硬件功能点未被覆盖，返回步骤30，添加硬件功能测试场景，进行RTL硬件模型验证；如果硬件功能点被覆盖，则验证结束。

上述验证方法能提高视频算法RTL硬件实现的验证效率和正确性。因为RTL验证的功能点分为算法功能点和硬件功能点。算法功能的验证通常占了整个验证的大部分时间。通过本发明的测试向量生成器可以生成使功能覆盖率达到100%的测试向量。在RTL仿真中，一次RTL仿真需要大量的时间，仿真后发现Bug，修改再进行仿真。要达到零Bug和100%功能覆盖率，需要多次迭代。一个具有高功能覆盖率的测试向量，能够在一次仿真中发现尽可能多的Bug，从而大大减少迭代次数。

除了算法功能点之外，RTL验证还需要对硬件时序等硬件功能点进行验证，对于此类功能点，采用直接验证的方法，即构建测试场景，进行RTL仿真，检查功能点覆盖率，如覆盖率未达到要求，则构建新的测试场景，重复上述步骤，直至功能点被完全覆盖为止。

以上内容是结合具体的实施方式对本申请所作的进一步详细说明，不能认定本申请的具体实施只局限于这些说明。对于本申请所属技术领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干简单推演或替换。

Claims (10)

1.一种验证视频算法寄存器传输级实现的方法，其特征在于，包括：

构建测试视频序列库；

从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；

根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；

对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

2.如权利要求1所述的方法，其特征在于，所述对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证包括：

黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后，分别产生输出，若这些输出一致，则验证通过；若不一致，则验证失败。

3.如权利要求2所述的方法，其特征在于，若所述验证失败后，还包括：

确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

4.如权利要求1所述的方法，其特征在于，所述黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

5.如权利要求1所述的方法，其特征在于，所述待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。

6.一种验证视频算法寄存器传输级实现的系统，其特征在于，包括测试视频序列库、测试向量生成器和文件比较器；

所述测试向量生成器用于从所述测试视频序列库根据预定功能覆盖率选取规则选取测试序列；根据所述选取的测试序列生成测试向量，并输出给黄金C语言模型和待验证寄存器传输级硬件模型；

所述文件比较器用于对所述黄金C语言模型和待验证寄存器传输级硬件模型进行输出验证。

7.如权利要求6所述的系统，其特征在于，所述文件比较器还用于对黄金C语言模型和待验证寄存器传输级硬件模型接收到测试向量后所产生的输出进行比较，若这些输出一致，则验证通过；若不一致，则验证失败。

8.如权利要求7所述的系统，其特征在于，所述文件比较器还用于在所述验证失败后，确定待验证寄存器传输级硬件模型中存在的缺陷，对待验证的寄存器传输级硬件模型进行调试。

9.如权利要求6所述的系统，其特征在于，所述黄金C语言模型是用C语言编写的实现一定视频处理功能的模块。

10.如权利要求6所述的系统，其特征在于，所述待验证寄存器传输级硬件模型是用硬件描述语言编写的，实现与所述黄金C语言模型相同的视频处理功能的模块，是功能验证的对象。