一种验证平台生成装置、方法、介质及电子设备

摘要

本申请提供一种验证平台生成装置、方法、介质及电子设备。验证平台生成装置包括交互式界面和处理器。交互式界面包括第一区域和第二区域，第二区域包括多种标准组件。处理器配置为：根据组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的第二模板生成至少一个第二验证平台，其中多种标准组件对应第一模板并且组件组合的可视化结构对应第一验证平台。第一模板和至少一个第二模板中的每一个之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。当DUT在第一验证平台上功能验证通过并且在至少一个第二验证平台上功能验证通过时交互式界面显示DUT功能验证通过。如此提升验证效率和缩短开发周期。

权利要求

1.一种验证平台生成装置，其特征在于，所述验证平台生成装置包括交互式界面和至少一个处理器，所述交互式界面包括第一区域和第二区域，所述第二区域包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件、用于表示环境的第二组件和用于表示连接关系的第三组件，所述多种标准组件可被拖拉到所述第一区域从而构建组件组合；

所述至少一个处理器配置为：根据所述组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，其中所述多种标准组件对应所述第一模板并且所述组件组合的可视化结构对应所述第一验证平台，所述第一模板和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求；当至少一个待测设计DUT在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证通过时，所述交互式界面显示所述至少一个DUT功能验证通过，其中，当所述至少一个待测设计在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证不通过时，所述交互式界面显示所述至少一个待测设计功能验证不通过，当所述至少一个待测设计在所述第一验证平台上功能验证不通过并且在所述至少一个第二验证平台上功能验证通过时，所述交互式界面显示所述至少一个待测设计功能验证不通过。

2.根据权利要求1所述的验证平台生成装置，其特征在于，所述交互式界面还包括模板选择组件用于用户选择所述一个或者多个第二模板。

3.根据权利要求1所述的验证平台生成装置，其特征在于，所述第一模板是默认模板，所述至少一个第二模板是可选模板。

4.根据权利要求1所述的验证平台生成装置，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：工程脚本、激励生成、数据类型、打印机制、环境集成和环境启动。

5.根据权利要求4所述的验证平台生成装置，其特征在于，所述第一验证方法学和所述第二验证方法学在激励生成上不同，其中所述第一验证方法学通过控制激励组合sequence实现控制激励生成，所述第二验证方法学通过调用宏调用作为激励发生器的激励类。

6.根据权利要求4所述的验证平台生成装置，其特征在于，所述第一验证方法学和所述第二验证方法学在打印机制上不同，其中所述第一验证方法学的打印继承uvm_report_server类，所述第二验证方法学的打印调用vmm_log类和与vmm_log类对应的宏实现组件和对象的打印。

7.根据权利要求4所述的验证平台生成装置，其特征在于，所述第一验证方法学通过宏声明实现工厂模式以及通过全局资源配置方式实现不同组件之间的数据传递，所述第二验证方法学通过外部声明定义进行数据传递。

8.根据权利要求4所述的验证平台生成装置，其特征在于，所述第一验证方法学和所述第二验证方法学还在验证环境层级划分上不同。

9.根据权利要求4所述的验证平台生成装置，其特征在于，所述第一验证方法学是UVM，所述第二验证方法学是VMM或者OVM。

10.根据权利要求1所述的验证平台生成装置，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：激励退出机制、激励发送机制、打印格式和名称检查规则。

11.根据权利要求10所述的验证平台生成装置，其特征在于，所述UVM第一版本和所述UVM第二版本在激励退出机制上不同，所述UVM第一版本通过调用raise_objection和drop_objection控制激励退出机制，所述UVM第二版本通过调用set_starting_phase和get_starting_phase控制激励退出机制。

12.根据权利要求10所述的验证平台生成装置，其特征在于，所述UVM第一版本和所述UVM第二版本在名称检查规则上不同，所述UVM第二版本通过resource_db对域段名称中元字符的使用进行检查并生成警告，所述UVM第一版本对域段名称中元字符的使用不进行检查或者对所述警告进行过滤。

13.根据权利要求10所述的验证平台生成装置，其特征在于，所述UVM第二版本与所述UVM第一版本的版本号不同。

14.根据权利要求13所述的验证平台生成装置，其特征在于，所述UVM第二版本是相对于所述UVM第一版本的更新版本。

15.根据权利要求1所述的验证平台生成装置，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。

16.根据权利要求15所述的验证平台生成装置，其特征在于，所述第一仿真工具用于适配VCS的编译方式和仿真选项调用，所述第二仿真工具用于适配xrun、irun或者modelsim的编译方式和仿真选项调用。

17.根据权利要求15所述的验证平台生成装置，其特征在于，所述第一仿真工具和所述第二仿真工具在编译方式上不同，所述第一仿真工具在编译时将虚拟接口视为错误，所述第二仿真工具在编译时不将虚拟接口视为错误。

18.根据权利要求15所述的验证平台生成装置，其特征在于，所述第一仿真工具和所述第二仿真工具采用不同的编译方式和仿真选项。

19.根据权利要求1所述的验证平台生成装置，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。

20.根据权利要求19所述的验证平台生成装置，其特征在于，所述第一场景需求和所述第二场景需求均与所述至少一个DUT的复杂度相关联。

21.根据权利要求20所述的验证平台生成装置，其特征在于，所述第一模板选择第一验证方法学、第一仿真工具以及第一版本，并且所述第一验证方法学、所述第一仿真工具以及所述第一版本的选择是基于所述第一场景需求和所述至少一个DUT的复杂度。

22.根据权利要求21所述的验证平台生成装置，其特征在于，当所述至少一个DUT是乘法器、异步FIFO、时钟生成器或者分频器时，所述第一场景需求中环境运行速度要求和验证效率的优先级高于环境层次化程度要求的优先级。

23.一种验证平台生成方法，其特征在于，所述验证平台生成方法包括：

提供交互式界面，其中所述交互式界面包括第一区域和第二区域，所述第二区域包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件、用于表示环境的第二组件和用于表示连接关系的第三组件；

通过拖拉所述多种标准组件到所述第一区域从而构建组件组合；

根据所述组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，其中所述多种标准组件对应所述第一模板并且所述组件组合的可视化结构对应所述第一验证平台，所述第一模板和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求；

当至少一个DUT在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证通过时，通过所述交互式界面显示所述至少一个DUT功能验证通过，其中，当所述至少一个待测设计在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证不通过时，所述交互式界面显示所述至少一个待测设计功能验证不通过，当所述至少一个待测设计在所述第一验证平台上功能验证不通过并且在所述至少一个第二验证平台上功能验证通过时，所述交互式界面显示所述至少一个待测设计功能验证不通过。

24.根据权利要求23所述的验证平台生成方法，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：工程脚本、激励生成、数据类型、打印机制、环境集成和环境启动。

25.根据权利要求23所述的验证平台生成方法，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：激励退出机制、激励发送机制、打印格式和名称检查规则。

26.根据权利要求23所述的验证平台生成方法，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。

27.根据权利要求23所述的验证平台生成方法，其特征在于，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。

28.一种非瞬时性计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，该计算机指令被处理器执行时实现根据权利要求23至27中任一项所述的方法。

29.一种电子设备，其特征在于，所述电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现根据权利要求23至27中任一项所述的方法。

说明书

一种验证平台生成装置、方法、介质及电子设备

技术领域

[0001] 本申请涉及计算机技术领域，尤其涉及一种验证平台生成装置、方法、介质及电子设备。

背景技术

[0002] 集成电路（integrated circuit，IC）有时也称作芯片，芯片将数量巨大的晶体管、二极管、电阻、电容和电感等各种元件以及布线通过半导体工艺集成在晶圆片上成为具有特定功能的电路。例如超大规模集成电路（very large scale integration，VLSI）可以在微米尺寸的硅片上集成数百万个晶体管以及这些晶体管之间复杂的布线。因为需要一次性制作完成晶体管及其它元件和布线，所以芯片生产的工时和费用深受芯片设计的影响。其中，芯片设计流程一般从规格制定开始也就是对芯片的目的和效能以及需要满足的协定标准等作出设定，并进行功能分配和单元划分；接着用硬件描述语言（hardware description language，HDL）例如常见的Verilog HDL对电路系统的硬件行为、结构及数据流进行描述；然后通过电子设计自动化（electronic design automation，EDA）工具，将HDL代码转换成逻辑电路图，并进行仿真验证；最后通过EDA工具的自动综合功能将逻辑电路图转换到门级电路网表，进行电路布局和绕线从而得到具体电路布线结构。随着系统级芯片（system on chip，SOC）的广泛应用以及单个芯片上集成的硬件规模和复杂程度增加还有更先进的工艺制程的发展，芯片验证占据了整个芯片设计流程的大部分工作量。芯片验证效率的提升和芯片验证环境的改进直接影响到芯片项目的研发周期以及后续生产效率的保证。芯片集成开发中的前端功能验证。一般由验证工程师根据待测设计（design under test，DUT）制定验证方案，通过验证平台所提供的平台工具对环境框图进行绘制和配置并生成验证环境。
功能验证有助于在芯片生产之前验证芯片设计是否符合需求例如逻辑时序的正确性等，并且通过验证方法学来提供相应标准的规范、统一化验证平台的编码风格和环境架构等。常见的验证方法学包括通用验证方法学（universal verification methodology，UVM），其提供基于system verilog类库的验证平台开发框架。其它的验证方法学还包括验证方法学手册（verification methodology manual，VMM）和开放验证方法学（open verification methodology，OVM）。

[0003] 实践中存在各种EDA工具，包括相关的集成电路设计版图设计软件、电子电路设计软件等，这些EDA工具由各个EDA厂商或者专门从事EDA的软件公司提供，还存在新旧版本和用户定制或半定制版本，这些不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上有所不同。因此当需要切换EDA工具或版本时，例如从一个厂商提供的EDA工具切换到另一个厂商提供的EDA工具时，又例如在交付不同的客户时，需要重新修改由于工具切换、方法学切换引入的验证问题并再次回归验证用例，这样不利于验证效率的提升和缩短芯片开发周期。

[0004] 综上所述，目前需要解决的问题是如何提升验证效率和缩短芯片开发周期。

发明内容

[0005] 本申请实施例提供了一种验证平台生成装置、方法、介质及电子设备，用于解决现有技术中存在的问题也就是如何提升验证效率和缩短芯片开发周期。

[0006] 第一方面，本申请提供了一种验证平台生成装置。所述验证平台生成装置包括交互式界面和至少一个处理器。所述交互式界面包括第一区域和第二区域，所述第二区域包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件、用于表示环境的第二组件和用于表示连接关系的第三组件。所述多种标准组件可被拖拉到所述第一区域从而构建组件组合。

[0007] 所述至少一个处理器配置为：根据所述组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，其中所述多种标准组件对应所述第一模板并且所述组件组合的可视化结构对应所述第一验证平台，所述第一模板和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求；当至少一个待测设计DUT在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证通过时，所述交互式界面显示所述至少一个DUT功能验证通过。

[0008] 通过本申请的第一方面，考虑到了芯片的开发项目以及芯片验证环节可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）也考虑到了追求更好的综合性的优化效果和开发设计效果的需求，针对不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上存在差异性，根据组件组合以及基于第一模板生成第一验证平台和基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，从而有效应对宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响，并且多种标准组件对应第一模板和组件组合的可视化结构对应第一验证平台，从而使得可以通过交互式界面便利地搭建环境框图，有利于后续切换EDA工具或版本或者适配两种或者更多种EDA工具或者版本。

[0009] 在本申请的第一方面的一种可能的实现方式中，所述交互式界面还包括模板选择组件用于用户选择所述一个或者多个第二模板。

[0010] 在本申请的第一方面的一种可能的实现方式中，所述第一模板是默认模板，所述至少一个第二模板是可选模板。

[0011] 在本申请的第一方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：工程脚本、激励生成、数据类型、打印机制、环境集成和环境启动。

[0012] 在本申请的第一方面的一种可能的实现方式中，所述第一验证方法学和所述第二验证方法学在激励生成上不同，其中所述第一验证方法学通过控制激励组合sequence实现控制激励生成，所述第二验证方法学通过调用宏调用作为激励发生器的激励类。

[0013] 在本申请的第一方面的一种可能的实现方式中，所述第一验证方法学和所述第二验证方法学在打印机制上不同，其中所述第一验证方法学的打印继承uvm_report_server类，所述第二验证方法学的打印调用vmm_log类和与vmm_log类对应的宏实现组件和对象的打印。

[0014] 在本申请的第一方面的一种可能的实现方式中，所述第一验证方法学通过宏声明实现工厂模式以及通过全局资源配置方式实现不同组件之间的数据传递，所述第二验证方法学通过外部声明定义进行数据传递。

[0015] 在本申请的第一方面的一种可能的实现方式中，所述第一验证方法学和所述第二验证方法学还在验证环境层级划分上不同。

[0016] 在本申请的第一方面的一种可能的实现方式中，所述第一验证方法学是UVM，所述第二验证方法学是VMM或者OVM。

[0017] 在本申请的第一方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：激励退出机制、激励发送机制、打印格式和名称检查规则。

[0018] 在本申请的第一方面的一种可能的实现方式中，所述UVM第一版本和所述UVM第二版本在激励退出机制上不同，所述UVM第一版本通过调用raise_objection和drop_objection控制激励退出机制，所述UVM第二版本通过调用set_starting_phase和get_starting_phase控制激励退出机制。

[0019] 在本申请的第一方面的一种可能的实现方式中，所述UVM第一版本和所述UVM第二版本在名称检查规则上不同，所述UVM第二版本通过resource_db对域段名称中元字符的使用进行检查并生成警告，所述UVM第一版本对域段名称中元字符的使用不进行检查或者对所述警告进行过滤。

[0020] 在本申请的第一方面的一种可能的实现方式中，所述UVM第二版本与所述UVM第一版本的版本号不同。

[0021] 在本申请的第一方面的一种可能的实现方式中，所述UVM第二版本是相对于所述UVM第一版本的更新版本。

[0022] 在本申请的第一方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。

[0023] 在本申请的第一方面的一种可能的实现方式中，所述第一仿真工具用于适配VCS的编译方式和仿真选项调用，所述第二仿真工具用于适配xrun、irun或者modelsim的编译方式和仿真选项调用。

[0024] 在本申请的第一方面的一种可能的实现方式中，所述第一仿真工具和所述第二仿真工具在编译方式上不同，所述第一仿真工具在编译时将虚拟接口视为错误，所述第二仿真工具在编译时不将虚拟接口视为错误。

[0025] 在本申请的第一方面的一种可能的实现方式中，所述第一仿真工具和所述第二仿真工具采用不同的编译方式和仿真选项。

[0026] 在本申请的第一方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。

[0027] 在本申请的第一方面的一种可能的实现方式中，所述第一场景需求和所述第二场景需求均与所述至少一个DUT的复杂度相关联。

[0028] 在本申请的第一方面的一种可能的实现方式中，所述第一模板选择第一验证方法学、第一仿真工具以及第一版本，并且所述第一验证方法学、所述第一仿真工具以及所述第一版本的选择是基于所述第一场景需求和所述至少一个DUT的复杂度。

[0029] 在本申请的第一方面的一种可能的实现方式中，当所述至少一个DUT是乘法器、异步FIFO、时钟生成器或者分频器时，所述第一场景需求中环境运行速度要求和验证效率的优先级高于环境层次化程度要求的优先级。

[0030] 第二方面，本申请提供了一种验证平台生成方法。所述验证平台生成方法包括：提供交互式界面，其中所述交互式界面包括第一区域和第二区域，所述第二区域包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件、用于表示环境的第二组件和用于表示连接关系的第三组件；通过拖拉所述多种标准组件到所述第一区域从而构建组件组合；根据所述组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，其中所述多种标准组件对应所述第一模板并且所述组件组合的可视化结构对应所述第一验证平台，所述第一模板和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求；当至少一个DUT在所述第一验证平台上功能验证通过并且在所述至少一个第二验证平台上功能验证通过时，通过所述交互式界面显示所述至少一个DUT功能验证通过。

[0031] 通过本申请的第二方面，考虑到了芯片的开发项目以及芯片验证环节可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）也考虑到了追求更好的综合性的优化效果和开发设计效果的需求，针对不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上存在差异性，根据组件组合以及基于第一模板生成第一验证平台和基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，从而有效应对宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响，并且多种标准组件对应第一模板和组件组合的可视化结构对应第一验证平台，从而使得可以通过交互式界面便利地搭建环境框图，有利于后续切换EDA工具或版本或者适配两种或者更多种EDA工具或者版本。

[0032] 在本申请的第二方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：工程脚本、激励生成、数据类型、打印机制、环境集成和环境启动。

[0033] 在本申请的第二方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：激励退出机制、激励发送机制、打印格式和名称检查规则。

[0034] 在本申请的第二方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。

[0035] 在本申请的第二方面的一种可能的实现方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。

[0036] 第三方面，本申请实施例还提供了一种计算机设备，所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据上述任一方面的任一种实现方式的方法。

[0037] 第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。

[0038] 第五方面，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括存储在计算机可读存储介质上的指令，当所述指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。

附图说明

[0039] 为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0040] 图1为本申请实施例提供的一种验证平台生成装置的示意图；

[0041] 图2为本申请实施例提供的第一模板和多个第二模板的示意图；

[0042] 图3为本申请实施例提供的一种验证平台生成方法的流程示意图；

[0043] 图4为本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

[0044] 下面将结合附图对本申请实施例作进一步地详细描述。

[0045] 本申请实施例提供了一种验证平台生成装置、方法、介质及电子设备，用于解决现有技术中存在的问题也就是如何提升验证效率和缩短芯片开发周期。其中，本申请实施例提供的方法和设备是基于同一发明构思的，由于方法及设备解决问题的原理相似，因此方法与设备的实施例、实施方式、示例或实现方式可以相互参见，其中重复之处不再赘述。

[0046] 应当理解的是，在本申请的描述中，“至少一个”指一个或一个以上，“多个”指两个或两个以上。另外，“第一”、“第二”等词汇，除非另有说明，否则仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

[0047] 应当理解的是，本申请实施例提供的验证平台生成装置、方法、介质及电子设备，用于芯片设计流程、芯片集成开发过程中的DUT也就是待测设计的功能验证，例如芯片前端功能验证。本申请实施例所提及的芯片的内涵及定义，应理解为涵盖通常意义上的集成电路、IC或者芯片以及相关的各种子类、子领域等。本申请实施例提供的验证平台生成装置、方法、介质及电子设备，适用于通常意义下的芯片的功能验证，包括适用于对通用芯片、定制芯片、针对处理信号定义的芯片、针对应用领域定义的芯片还有其他任意合适的基于对芯片设计理念、芯片类型、芯片架构等进行区分的方式而定义的芯片的功能验证。本申请实施例提供的验证平台生成装置、方法、介质及电子设备适用于通用芯片的功能验证，包括与其相关的设计和集成开发过程中的DUT的功能验证，通用芯片的示例性且非限制性的示例包括中央处理器（central processing unit，CPU）、精简指令集计算（reduced instruction set computing，RISC）、无指令集计算（no instruction set computing，NISC）以及其它任意合适的基于指令集体系的通用芯片，还包括图形处理器（graphic processing unit，GPU）、数字信号处理器（digital signal processor，DSP）等。本申请实施例提供的验证平台生成装置、方法、介质及电子设备适用于定制芯片（包括全定制芯片和半定制芯片）的功能验证，包括与其相关的设计和集成开发过程中的DUT的功能验证，定制芯片的示例性且非限制性的示例包括专用集成电路（application‑specific integrated circuit，ASIC）、现场可编程逻辑门阵列（field programmable gate array，FPGA）、粗颗粒可重构架构（coarse‑grained reconfigurable architecture，CGRA）以及其它任意合适的定制芯片如软件定义芯片等。本申请实施例提供的验证平台生成装置、方法、介质及电子设备适用于针对处理信号定义的芯片的功能验证，包括与其相关的设计和集成开发过程中的DUT的功能验证，针对处理信号定义的芯片的示例性且非限制性的示例包括用于数字处理信号的芯片、用于模拟处理信号的芯片以及混合芯片等。本申请实施例提供的验证平台生成装置、方法、介质及电子设备适用于针对应用领域定义的芯片的功能验证，包括与其相关的设计和集成开发过程中的DUT的功能验证，针对应用领域定义的芯片的示例性且非限制性的示例包括用于通用计算机的处理器芯片、传感器芯片、电源芯片、通讯芯片、接口芯片、用于人工智能算法加速的芯片等。

[0048] 参见图1，图1为本申请实施例提供的一种验证平台生成装置的示意图。所述验证平台生成装置包括交互式界面102和至少一个处理器104。所述交互式界面102包括第一区域110和第二区域112。所述第二区域112包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件122、用于表示环境的第二组件124和用于表示连接关系的第三组件126。所述多种标准组件可被拖拉到所述第一区域110从而构建组件组合130。所述至少一个处理器104配置为：根据所述组件组合130，基于第一模板142生成第一验证平台152以及基于至少一个第二模板（未示出）中由用户选择的一个或者多个第二模板（图1中用第二模板
144示例性示出由用户选择的一个或者多个第二模板）生成至少一个第二验证平台154。其中所述多种标准组件对应所述第一模板142并且所述组件组合130的可视化结构对应所述第一验证平台152。所述第一模板142和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。当至少一个待测设计DUT在所述第一验证平台152上功能验证通过并且在所述至少一个第二验证平台154上功能验证通过时，所述交互式界面102显示所述至少一个DUT功能验证通过。

[0049] 交互式界面102可以理解为展示给用户且便于用户进行操作的图形化操作界面并且通过交互式控件让用户可以输入相应指令或者执行相应操作。交互式界面102是以可视化的方式展示给用户。其中可视化方式可以是图形、图表、图标或者任意合适的形式，在此不做具体限定。多种标准组件可被拖拉到第一区域110从而构建组件组合130，这里，标准组件被拖拉的具体方式可以是用户操作可精确定位的装置例如鼠标、触摸笔或者任意合适的定位装置来实行拖拉操作，也可以是用户通过输入代码等方式从而由系统等效地完成拖拉操作。第一区域110中的组件组合130可以理解为用户通过标准组件在可视化界面上搭建的标准组件的组合也就是在可视化界面上绘制的图形，这样用户利用交互式界面102所提供的平台工具如标准组件对环境框图进行绘制和配置，进而用于后续生成验证环境。组件组合130包括将一个标准组件与另一个标准组件连接等，可以是从空白的环境框图开始绘制，也可以从现有模板或者过去保存的草稿开始绘制，在此不做具体限定。图1所示的验证平台生成装置用于芯片开发前端的功能验证。具体地，芯片的功能可以拆解成一个或者多个待测设计（design under test，以下简称为DUT）。在一种可能的实施方式中，芯片功能验证包括为每个DUT设计对应的验证环境，通过比较该DUT和参考模型（reference model，RM）对相同的输入或者说激励信号分别做出的输出，可以判断该DUT是否通过相应的验证环境下的功能验证。在构建验证环境时，为了简化用户操作，提供了多种标准组件，用于基于可视化界面生成验证环境。其中，多种标准组件可以包括多个层级的标准组件，例如图1所示的用于激励生成的第一组件122、用于表示环境的第二组件124和用于表示连接关系的第三组件126。应当理解的是，第二区域112可以提供的多种标准组件，可以是根据任意合适的验证方法学、平台架构或者分类方法来提供不同层级、不同类型的标准组件。在一些实施例中，第二区域112提供的多种标准组件包括最顶层的环境组件（ENV）、代理组件（AGENT）、计分板组件（SCOREBOARD）以及其它组件。通过这些标准组件，在可视化界面上（如交互式界面102的第一区域110）绘制可视化界面上的图形，也就是搭建标准组件的组合如组件组合130。用户可以通过拖拉组件的拖拉操作以及其他合适的定位操作来将一个标准组件与另一个标准组件连接以及绘制出代表了多个组件之间的连接关系和逻辑时序的图形也即组件组合
130。然后通过内置系统，例如图1的处理器104，基于在第一区域110上绘制好的环境框图如组件组合130，自动生成可以执行的代码文件，该代码文件可用于DUT的功能验证。在根据标准组件的组合自动生成代码文件的过程中，系统如处理器104会根据标准组件的组合里各个组件的属性（类名、例化名、文件路径、工作模式等）、组件之间的连接关系（通过用户拖拉组件、鼠标操作或者直接输入）来自动化生成如事务级建模（transaction level modeling，TLM）的连接、输入、输出等，以及生成接口类如port、interface等。此外，用户可以构造激励信号，也就是构造用于功能验证的输入激励，例如在组件组合130中包括代表输入激励的组件如用于激励生成的第一组件122，并完成对DUT的功能验证。应当理解的是，图
1所示的交互式界面102可以用于对单个DUT的功能验证，也可以用于对多个DUT的功能验证，例如将系统级芯片也叫SOC拆解成多个DUT并对多个DUT一起进行功能验证。在一些实施例中，可以通过多个最顶层的环境组件分别对应不同的DUT，再将多个环境组件整合成整体。

[0050] 图1的验证平台生成装置，用于芯片集成开发中的前端功能验证，根据至少一个DUT制定验证方案，通过验证平台生成装置所提供的工具如第二区域112的标准组件对环境框图进行绘制和配置并生成验证环境或者说验证平台。在根据绘制好的环境框图如组件组合130来生成验证环境或者说验证平台时，涉及到如何将在第一区域110的组件组合130的可视化结构（交互式界面102上呈现的多个组件的排布、组合等）转化为组件之间的连接关系、参数配置、信号传输等，并且可能涉及到如何生成相应的连接、输入、输出以及各种接口类、宏、类库、发送机制、退出机制等，还可能涉及到具体检查规则和警告机制例如识别不恰当的名称、字符的使用等。一方面，存在各种EDA工具，包括相关的集成电路设计版图设计软件、电子电路设计软件等，这些EDA工具由各个EDA厂商或者专门从事EDA的软件公司提供，还存在新旧版本和用户定制或半定制版本，这些不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上有所不同，也因此在面对同一个组件组合130的可视化结构时可能生成不一样的验证环境或者验证平台，包括可能在具体的生成过程中采用不一样的代码验证、检查规则、警告策略等。另一方面，用户有时候需要切换EDA工具或版本时或者说进行功能验证的芯片可能需要适配两种或者更多种EDA工具或者版本。例如，在旧版本下功能验证通过的芯片现在可能因为版本迭代而需要适配新版本或者定制版本；再例如，有些情况下因为失去了新版本的授权或者合法使用渠道而需要让在新版本下进行开发及功能验证的芯片或者芯片中部分设计适配旧版本；再例如，在前一个厂商提供的EDA工具下进行开发及功能验证的芯片现在需要适配另一个厂商提供的EDA工具。在一些特定情况下，芯片开发项目没有完成例如进行到一半时面临需要切换EDA工具或版本的问题，这可能是因为芯片开发项目失去了原来使用的EDA工具或者特定版本的授权或者合法使用权限或者其他可能原因。考虑到不同的EDA工具或版本在生成验证环境或者验证平台的过程中，采用的具体工具和平台架构，对连接关系、输入输出配置及参数配置的处理方式，还有对接口、类库、机制、检测规则和风险控制等的处理方式，在这些方面中的一项或者多项上存在差异性，这些差异性所带来的影响是难以预先估计的并且也难以预先判断不同EDA工具或者版本之间的差异的范围，这样就使得切换EDA工具或版本时面临难以适配甚至需要重新进行功能验证乃至更改设计的困难。进一步地，随着软件定义芯片成为行业发展的其中一个大趋势，芯片开发也需要考虑具体应用场景进行优化，例如根据不同客户的实际需要进行优化，如结合数据中心的应用场景或者数据处理需求特性（语音通讯、短连接等）进行优化。而为了达到综合性的更好优化效果，可能需要结合不同的EDA工具或者版本各自的优点或长处，例如一种EDA工具或版本适合针对一种应用场景下的芯片的开发项目而另一种EDA工具或版本适合针对另一种应用场景下的芯片的开发项目。此外，芯片的开发项目的时间和经济成本也可能影响具体的EDA工具或版本的选择，例如有时候适合选择经济成本较低的或者开发时间较短的EDA工具或版本。芯片验证占据了整个芯片设计流程的大部分工作量。因此用于芯片集成开发和功能验证的EDA工具或版本的选择，影响芯片验证效率和芯片验证环境还影响开发时间和经济成本。为了能更好地规划芯片的开发项目以及芯片验证环节以应对未来可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）以及为了追求更好的综合性的优化效果和开发设计效果，在芯片验证如芯片前端功能验证环节，需要考虑到切换EDA工具或版本时或者适配两种或者更多种EDA工具或者版本的情况，也因此需要考虑到不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上有所不同。下面结合图1进一步详细说明本申请实施例的验证平台生成装置及方法，例如图1的验证平台生成装置，如何满足上述要求。

[0051] 继续参见图1，所述至少一个处理器104配置为：根据所述组件组合130，基于第一模板142生成第一验证平台152以及基于至少一个第二模板（未示出）中由用户选择的一个或者多个第二模板（图1中用第二模板144示例性示出由用户选择的一个或者多个第二模板）生成至少一个第二验证平台154。这里，第一模板142和至少一个第二模板（包括其中由用户选择的第二模板144）体现了宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响。

[0052] 宏观因素的变化可能是因为验证环境的平台架构的搭建和激励信号的构造是基于过去的经验总结得到的特定验证方法学，例如通用验证方法学（universal verification methodology，UVM ）、验证方法学手册（verification methodology manual，VMM）和开放验证方法学（open verification methodology，OVM）等，这些验证方法学在软件仿真的仿真效率、稳定性等方面有不同的表现。另外，宏观因素的变化还可能是因为版本迭代和版本定制，例如新的行业标准或者工业规范可能定义了新的版本，并且即使同一个验证方法学下的新旧版本之间也可能存在较大的差异性。另外，宏观因素的变化还可能是因为所采用的EDA工具，例如来自不同的EDA工具的供应商，而不同的EDA工具的底层验证逻辑以及功能验证的基准可能不同（例如对system verilog标准中语法语义理解以及线程调度实现细节不同），这也就可能导致不同的仿真工具对于同一个验证环境编译和仿真结果有所不同。为此，通过提供第一模板142和至少一个第二模板（包括其中由用户选择的第二模板144），反映了上述各种宏观层面因素的变化，包括体现了来自于相应的仿真工具、验证方法学以及验证方法学的版本所带来的变化。其中，第一模板142和第二模板144分别对应地提供了标准化组件的有关细节，例如包括类、基类、TLM通信机制、以及AGENT和SCOREBOARD等。此外，第一模板142和第二模板144还分别提供了用标准化组件构建验证环境或验证平台时，后台如何通过自动化运行的方式验证其可行性以及如何自动化地根据绘制好的环境框图（例如图1的组件组合130）来生成TLM的连接、输入、输出等所遵守的规则（也包括约束条件、优化策略等）。例如，不同的验证方法学决定了激励信号的构造方式不同，如UVM方法学使用sequence方式而VMM方法学使用generator机制，因此取决于所依据的验证方法学，第一模板142和第二模板144可能采用不同的激励信号的构造方式。

[0053] 继续参见图1，多种标准组件对应第一模板142并且组件组合130的可视化结构对应第一验证平台152。第一模板142和至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。如此，通过第一模板142和至少一个第二模板可以覆盖各种宏观层面因素的变化及其影响，也就是说，通过提供第一模板142和至少一个第二模板（包括其中由用户选择的第二模板144），反映了上述各种宏观层面因素的变化，包括体现了来自于相应的仿真工具、验证方法学以及验证方法学的版本所带来的变化。进一步地，多种标准组件对应第一模板142，由多种标准组件构建而来的组件组合130的可视化结构，例如组件组合130中组件的排布、组合等，对应第一验证平台152，这意味着第一模板142决定了在生成第一验证平台152时的有关细节，包括如何将在第一区域110的组件组合130的可视化结构（交互式界面102上呈现的多个组件的排布、组合等）转化为组件之间的连接关系、参数配置、信号传输等，以及如何生成相应的连接、输入、输出以及各种接口类、宏、类库、发送机制、退出机制等，还有可能包括具体检查规则和警告机制例如识别不恰当的名称、字符的使用等。此外，多种标准组件对应第一模板142，第二区域112上提供的多种标准组件是用于用户便利地构建在第一区域110的组件组合130的可视化结构或者说用于用户便利地以可视化方式绘制环境框图，因此第一模板142可以对应用户的默认模板或者经常使用的模板。换句话说，在操作可视化界面例如图1的交互式界面102来绘制环境框图时，呈现给用户的是与绘制好的环境框图对应的组件组合130也就是对应第一模板
142的多种标准组件，而处理器104则基于第一模板142来将组件组合130转化为第一验证平台152（可能包括与一个DUT对应的单个验证环境和/或与多个DUT对应的多个验证环境）。而没有呈现给用户的，或者说对用户而言是不可视的，则是至少一个第二模板（包括其中由用户选择的第二模板144）所带来的对最终生成的可执行的代码文件的影响。换句话说，第一模板142，例如用户默认模板或者常用模板，用于配合用户绘制交互式界面102的第一区域
110中的组件组合130的可视化结构或者说绘制环境框图，并且第一模板142还用于生成与组件组合130对应的第一验证平台152；而第二模板则用于生成与组件组合130对应的第二验证平台154，但是第二模板并不对应第二区域112所提供的标准组件也因此不用于配合用户绘制环境框图的操作，而且第二模板所对应的标准化组件、所采用的验证方法学以及其它方面上可能不同于第一模板142。进一步地，当至少一个待测设计也即DUT在所述第一验证平台152上功能验证通过并且在所述至少一个第二验证平台154上功能验证通过时，所述交互式界面102显示所述至少一个DUT功能验证通过。因此，用户绘制的环境框图也即组件组合130的可视化结构用于以可视化的方式呈现当前验证逻辑，而该验证逻辑还需要结合具体的模板来生成对应于特定仿真工具、特定验证方法学及特定验证方法学版本的可执行代码也就是验证环境或者验证平台。对于用户而言，用户从交互式界面102上看到的是对应第一模板142的第二区域112的标准组件以及由这些标准组件构建的第一区域110的组件组合130，因此交互式界面102对外呈现的是基于第一模板142的可视化结构，但是后续进行功能验证时要求同时满足基于第一模板142的第一验证平台152的验证通过和基于由用户选择的第二模板144的第二验证平台154的验证通过才能使得交互式界面102显示所述至少一个DUT功能验证通过。如此，通过基于第一模板142来提供用户绘制环境框图的各种图形控件和可视化工具如对应第一模板142的第二区域112的标准组件，使得用户可以利用熟悉的开发工具和习惯来完成绘制，然后通过第一验证平台152和第二验证平台154的双重功能验证来确保该至少一个DUT的功能验证通过结果，考虑到了上述各种宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响，也有利于后续应对切换EDA工具或版本时或者适配两种或者更多种EDA工具或者版本的情况。

[0054] 第二模板144是由用户选择并且是从至少一个第二模板中选择的一个或者多个第二模板，而所述第一模板142和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。在一些实施例中，用户可以预先录入个人需要或者个人偏好，用来确定第一模板142，例如用户可以预先选择常用的或者偏好的仿真工具、验证方法学以及验证方法学的版本等。例如，设默认的或者用户熟悉的仿真工具和验证方法学版本是Cadence仿真工具和UVM 1.1，在用户绘制好图形或者环境框图后，调用与用户所熟悉的工具和版本对应的第一模板142来生成与该已绘制图形或环境框图以及该第一模板142对应的代码文件，从而生成第一验证平台152。并且，由用户选择第二模板144，第二模板144的选择可能是基于上述的各种可能的宏观因素的变化，例如可能考虑到切换EDA工具或版本时或者适配两种或者更多种EDA工具或者版本的情况，再例如可能考虑到不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上有所不同。通过第一验证平台152和第二验证平台154的双重功能验证来确保该至少一个DUT的功能验证通过结果，这样意味着在基于用户的默认模板也即第一模板142生成的第一验证平台152下对DUT进行功能验证（还适用于后续的自动化纠错、自动化优化）的同时，也完成了基于其它模板如第二模板144生成的第二验证平台154下的功能验证、纠错及优化等。也就是说，用户可以通过熟悉的或者常用的仿真工具和验证方法学版本来通过可视化界面快速搭建验证平台框架，而最终得到的验证过程和验证结果则能适用于其它仿真工具、其它验证方法学、其它版本等。并且用户可以根据特定策略选择第二模板144以及基于第二模板144生成的第二验证平台154从而结合上述的各种考量因素，这样的考量因素覆盖了需要切换EDA工具或版本时或者说进行功能验证的芯片可能需要适配两种或者更多种EDA工具或者版本等特定情况。示例性的考量因素或者特定情况包括但是不限于，在旧版本下功能验证通过的芯片现在可能因为版本迭代而需要适配新版本或者定制版本；失去了新版本的授权或者合法使用渠道而需要让在新版本下进行开发及功能验证的芯片或者芯片中部分设计适配旧版本；在前一个厂商提供的EDA工具下进行开发及功能验证的芯片现在需要适配另一个厂商提供的EDA工具；芯片开发项目未完成如进行到一半时面临需要切换EDA工具或版本的难题；芯片开发项目失去了原来使用的EDA工具或者特定版本的授权或者合法使用途径；根据不同客户的实际需要进行优化，如结合数据中心的应用场景或者数据处理需求特性（语音通讯、短连接等）进行优化；为了达到综合性的更好优化效果需要结合不同的EDA工具或者版本各自的优点或长处，例如一种EDA工具或版本适合针对一种应用场景下的芯片的开发项目而另一种EDA工具或版本适合针对另一种应用场景下的芯片的开发项目；需要选择经济成本较低的或者开发时间较短的EDA工具或版本。总之，为了能更好地规划芯片的开发项目以及芯片验证环节以应对未来可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）以及为了追求更好的综合性的优化效果和开发设计效果，在芯片验证如芯片前端功能验证环节，需要考虑到切换EDA工具或版本时或者适配两种或者更多种EDA工具或者版本的情况，也因此需要考虑到不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上有所不同。而这些不同来源、不同版本的EDA工具之间的差异性，通过上述的基于第一模板142来提供用户绘制环境框图的各种图形控件和可视化工具如对应第一模板142的第二区域112的标准组件以及通过第一验证平台152和第二验证平台154的双重功能验证来确保该至少一个DUT的功能验证通过结果，在给用户操作提供便利同时也实现了有效应对未来可能的干扰及更好的综合优化效果。

[0055] 应当注意的是，所述第一模板142和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。由用户选择的第二模板144是从该至少一个第二模板中选择，因此第一模板142和第二模板144也至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。如上所述，通过第一模板142和至少一个第二模板（包括其中由用户选择的第二模板144）反映了上述各种宏观层面因素的变化，包括体现了来自于相应的仿真工具、验证方法学以及验证方法学的版本所带来的变化。下面结合图2详细说明这一点。图2为本申请实施例提供的第一模板和多个第二模板的示意图。如图2所示，第一模板242和三个第二模板（分别为第二模板244、第二模板246和第二模板248）。其中，第一模板242对应验证方法学252、仿真工具262、版本272以及场景需求282；
第二模板244对应验证方法学252、仿真工具262、版本272以及场景需求284；第二模板246对应验证方法学252、仿真工具262、版本274以及场景需求282；第二模板248对应验证方法学
254、仿真工具264、版本276以及场景需求282。通过比较第一模板242和第二模板244可以看出，两者采用相同的验证方法学、相同的仿真工具、相同的版本但是不同的场景需求，因此当DUT在分别基于第一模板242和第二模板244生成的验证平台上验证通过，这意味着该DUT同时适配第一场景需求282和第二场景需求284，也就意味着包括该DUT的芯片有更好的综合优化效果。类似地，通过比较第一模板242和第二模板246可以看出，两者采用相同的验证方法学、相同的仿真工具但是不同的版本，也适配相同的场景需求，其中第二模板246对应的版本274可能是相对于第一模板242对应的版本272而言的旧版本，这样当DUT在分别基于第一模板242和第二模板246生成的验证平台上验证通过，这意味着该DUT可以同时适配相对较新的版本272和相对较旧的版本274，也就意味着当芯片开发者遇到无法使用相对较新的版本272的情况时（例如可能是失去授权或者合法使用渠道），芯片开发者可以继续在相对较旧的版本274下进行开发和芯片验证也就是继续使用基于第二模板246的验证平台来完成后续芯片开发工作。类似地，通过比较第一模板242和第二模板248可以看出，第二模板
248采用了不同于第一模板242的验证方法学，也采用了不同的仿真工具和不同的版本，但是适配同一个场景需求282。这可能是因为第一模板242对应的是某个给定EDA工具供应商所提供的开发工具而第二模板248对应的是不同于该给定EDA工具供应商的另一个EDA工具供应商所提供的开发工具。来自不同的EDA工具供应商的EDA工具，一般是基于各自的长期积累下来的经验总结来设计各自的验证环境的平台架构和构造激励信号等，也就是说一般采用不同的验证方法学（或者至少在局部细节上保持差异性），而且来自不同的EDA工具供应商的EDA工具一般在底层验证逻辑以及功能验证的基准上也存在差异性（例如对system verilog标准中语法语义理解以及线程调度实现细节不同）。这些差异性体现在上述的第二模板248采用了不同于第一模板242的验证方法学、仿真工具和版本。因此，当DUT在分别基于第一模板242和第二模板248生成的验证平台上验证通过，这意味着该DUT可以同时适配第一模板242对应的EDA工具和第二模板248对应的另一EDA工具，也就意味着当芯片开发者遇到无法使用第一模板242对应的EDA工具的情况时（例如可能是失去授权或者合法使用渠道），芯片开发者可以继续在第二模板248对应的另一EDA工具下进行开发和芯片验证也就是继续使用基于第二模板248的验证平台来完成后续芯片开发工作。

[0056] 参见图1和图2，本申请实施例提供的验证平台生成装置，考虑到了芯片的开发项目以及芯片验证环节可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）也考虑到了追求更好的综合性的优化效果和开发设计效果的需求，针对不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上存在差异性，根据组件组合以及基于第一模板生成第一验证平台和基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，从而有效应对宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响，并且多种标准组件对应第一模板和组件组合的可视化结构对应第一验证平台，从而使得可以通过交互式界面便利地搭建环境框图，有利于后续切换EDA工具或版本或者适配两种或者更多种EDA工具或者版本。

[0057] 继续参见图1，在一些实施例中，上述的基于不同模板的验证平台的功能验证，例如模拟仿真过程，均可以进行全流程的存证，包括对代码覆盖率、功能覆盖率、仿真效率、稳定性等方面进行整体的评价，这样有利于用户比较不同模板下的功能验证表现。此外，通过全流程存证，还可以进行局部的比较。例如用户构建的验证平台框架包括对多个DUT分别验证的多个ENV，如对系统级芯片SOC进行功能验证的多个ENV。可以针对某一个DUT，比较不同模板下的验证平台或者验证环境的表现，例如比较UVM 1.1和UVM 1.2各自的表现。当采用不同的验证方法学时，例如UVM验证方法学和OVM验证方法学，往往涉及到不同的标准化组件，包括其定义和封装细节，例如采用不同的名称、编译语言、基类模板等。而用户绘制的环境框图可用于表征验证逻辑（通过对应第一模板的标准组件来构建），因此可将其所表征的验证逻辑用于其他模板如第二模板。通过比较单个DUT在不同模板下的验证环境的表现，可以提供更丰富的参考信息。以对单个DUT进行功能验证为示例，该DUT的验证环境或者验证平台是基于UVM验证方法学构建，包括参考模型和DUT。对参考模型和DUT施加相同的激励（单个输入信号或者同一个输入代理组件如INPUT AGENT），然后根据两者的输出判断两者是否一致，也就是将各自的输出导入同一个计分板组件如SCOREBOARD。而绘制好的环境框图，例如图1所示的交互式界面102的第一区域110中的组件组合130的可视化结构，经过相应模板转化为可执行的代码文件，例如经第一模板142转化为第一验证平台152以及经第二模板144转化为第二验证平台154。在根据具体模板转化绘制好的环境框图为可执行的代码文件的过程中，将封装好的标准化组件根据各自的组件属性（类名、例化名、文件路径、工作模式）转化为相应的代码，并根据绘制好的环境框图上的组件之间的连接关系提供合适的通信机制，提供激励类型等。也就是说，根据具体采用的模板，例如第一模板142或者第二模板144，确定如何将在第一区域110的组件组合130的可视化结构（交互式界面102上呈现的多个组件的排布、组合等）转化为组件之间的连接关系、参数配置、信号传输等，以及确定如何生成相应的连接、输入、输出以及各种接口类、宏、类库、发送机制、退出机制等，还有确定具体检查规则和警告机制例如识别不恰当的名称、字符的使用等。

[0058] 在一种可能的实施方式中，所述交互式界面还包括模板选择组件（未示出）用于用户选择所述一个或者多个第二模板。

[0059] 在一种可能的实施方式中，所述第一模板是默认模板，所述至少一个第二模板是可选模板。例如，用户可以根据偏好和个人需求设定默认模板。

[0060] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：激励生成、数据类型、打印机制、环境集成和环境启动。这里，验证方法学代表了长期积累下来的经验总结来设计验证环境的平台架构和构造激励信号等，并且不同的验证方法学一般在底层验证逻辑以及功能验证的基准上也存在差异性。例如，不同的验证方法学可能采用不同的激励的构造方式，如UVM方法学使用sequence方式而VMM方法学使用generator机制。此外，不同的验证方法学对于system verilog标准中语法语义理解以及线程调度实现细节不同。因此，第一验证方法学与第二验证方法学的差异性体现在激励生成、数据类型、打印机制、环境集成和环境启动。在一些实施例中，所述第一验证方法学和所述第二验证方法学在激励生成上不同，其中所述第一验证方法学通过控制激励组合sequence实现控制激励生成，所述第二验证方法学通过调用宏调用作为激励发生器的激励类。例如，UVM对应的验证方法学在激励处理上定义了sequence作为一系列激励的组合，激励产生控制通过控制不同的sequence实现。而VMM对应的验证方法学，则通过代用宏，例如使用宏vmm_automic_gen或者vmm_scenario_gen来产生激励发生器的类。激励发生器与其他组件进行TLM通信并将产生的激励传递给其他组件。在一些实施例中，所述第一验证方法学和所述第二验证方法学在打印机制上不同，其中所述第一验证方法学的打印继承uvm_report_server类，所述第二验证方法学的打印调用vmm_log类和与vmm_log类对应的宏实现组件和对象的打印。例如，对于组件运行，UVM对应的验证方法学采用特有的机制来控制多线程有序运转和结束，其中打印继承uvm_report_server类。而VMM对应的验证方法学通过命令行方式实现打印级别的修改，打印调用vmm_log类和与vmm_log类对应的宏实现组件和对象的打印。在一些实施例中，所述第一验证方法学通过宏声明实现工厂模式以及通过全局资源配置方式实现不同组件之间的数据传递，所述第二验证方法学通过外部声明定义进行数据传递。例如，UVM对应的验证方法学采用uvm_config_db方式，其把验证环境的一些资源配置为类似全局变量一样，使得它对于整个验证环境来说是可见的，也就是说通过全局资源配置方式实现不同组件的数据传递。而VMM对应的验证方法学可以靠new函数中的参数或者外部声明定义方式进行传递。在一些实施例中，所述第一验证方法学和所述第二验证方法学还在验证环境层级划分上不同。例如，VMM对应的验证方法学中在验证环境层级划分上区分开vmm_subenv和vmm_env两个概念，而UVM对应的验证方法学在验证环境层级划分上没有subenv的概念。在一些实施例中，所述第一验证方法学是UVM，所述第二验证方法学是VMM或者OVM。

[0061] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：工程脚本、激励退出机制、激励发送机制、打印格式和名称检查规则。同一种验证方法学存在版本迭代以及定制版本等，并且可能因为工业标准和行业规范的变化而定义新的版本。一般来说，两个不同的版本之间的差异性体现在工程脚本、激励退出机制、激励发送机制、打印格式和名称检查规则。在一些实施例中，所述UVM第一版本和所述UVM第二版本在激励退出机制上不同，所述UVM第一版本通过调用raise_objection和drop_objection控制激励退出机制（例如UVM 1.1版本），所述UVM第二版本通过调用set_starting_phase和get_starting_phase控制激励退出机制（例如UVM 1.2版本）。在一些实施例中，所述UVM第一版本和所述UVM第二版本在名称检查规则上不同，所述UVM第二版本通过resource_db对域段名称中元字符的使用进行检查并生成警告，所述UVM第一版本对域段名称中元字符的使用不进行检查或者对所述警告进行过滤。因此，不同版本之间在名称检查规则上采用不同的规定或者局部性细节的差异，可能影响回归用例结果的判断，也因此需要对警告进行针对性过滤或者处理。在一些实施例中，所述UVM第二版本是相对于所述UVM第一版本的更新版本。例如，所述UVM第一版本是UVM 1.1版本，所述UVM第二版本是更新版本如UVM 1.2版本。另外，两个EDA工具可能分别采用不同的工程脚本，因此在一些实施例中，所述UVM第一版本和所述UVM第二版本之间的差异性还可以体现在工程脚本上。在一些实施例中，所述UVM第二版本与所述UVM第一版本的版本号不同。

[0062] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。不同的仿真工具，一般来源于不同的供应商例如不同的EDA工具的供应商。不同的仿真工具之间的差异一般体现在：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。具体地，不同的仿真工具可以是来自Synopsis的VCS软件和来自Cadence的xrun软件，或者来自Mentor Graphics的modelsim软件。此外，在一些实施例中，第一仿真工具是Synopsys所提供的仿真工具，第二仿真工具是Cadence所提供的仿真工具或者还可以是华大九天等其他EDA开发工具的供应商或者专注于EDA软件的软件厂商。在一些实施例中，所述第一仿真工具和所述第二仿真工具在编译方式上不同，所述第一仿真工具在编译时将虚拟接口视为错误，所述第二仿真工具在编译时不将虚拟接口视为错误。例如，来自Synopsis的VCS软件对于定义为虚拟接口的接口不会报告编译错误，但是来自Cadence的xrun软件对于定义为虚拟接口的接口报告编译错误。在一些实施例中，所述第一仿真工具和所述第二仿真工具采用不同的编译方式和仿真选项。例如，第一仿真工具和第二仿真工具可能对于TCL脚本的调用方式、对于特定写法（例如a dist {[0:'1]}）、对于参数类型（例如try_get）、对于特定动作（例如get动作）、对于特定语法（例如disable lable语法）等有不同的处理方式或者判断标准等。在一些实施例中，所述第一仿真工具用于适配VCS的编译方式和仿真选项调用，所述第二仿真工具用于适配xrun、irun或者modelsim的编译方式和仿真选项调用。

[0063] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。随着软件定义芯片的趋势发展以及细化场景需求和下沉应用的推广，需要考虑不同场景需求来设计芯片及芯片验证，不同的场景需求之间的差异性体现在客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。在一些实施例中，所述第一场景需求和所述第二场景需求均与所述至少一个DUT的复杂度相关联。例如，DUT的复杂度较低的情况下，可能功能比较单一，也对应了相应的场景需求。在一些实施例中，所述第一模板选择第一验证方法学、第一仿真工具以及第一版本，并且所述第一验证方法学、所述第一仿真工具以及所述第一版本的选择是基于所述第一场景需求和所述至少一个DUT的复杂度。如此，针对DUT的复杂度较低、功能比较单一而且第一场景需求也强调时效性和经济性的情况下，可以选择更匹配的第一模板来缩短开发周期。在一些实施例中，当所述至少一个DUT是乘法器、异步FIFO、时钟生成器或者分频器时，所述第一场景需求中环境运行速度要求和验证效率的优先级高于环境层次化程度要求的优先级。这里，乘法器、异步FIFO、时钟生成器或者分频器等功能比较单一、复杂度较低，适合优先考虑环境运行速度要求和验证效率。例如，可以不采用如UVM验证方法学等，而是利用system verilog甚至verilog语言搭建简易的验证平台来进行功能测试，这样具有相对较低的环境层次化程度但同时具有环境运行速度快和验证效率高的优点。

[0064] 参见图3，图3为本申请实施例提供的一种验证平台生成方法的流程示意图。如图3所示，验证平台生成方法包括以下步骤。

[0065] 步骤S310：提供交互式界面。

[0066] 在步骤S310中，所述交互式界面包括第一区域和第二区域，所述第二区域包括多种标准组件，所述多种标准组件至少包括用于激励生成的第一组件、用于表示环境的第二组件和用于表示连接关系的第三组件。

[0067] 步骤S320：通过拖拉多种标准组件到第一区域从而构建组件组合。

[0068] 步骤S330：根据组件组合，基于第一模板生成第一验证平台以及基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台。

[0069] 在步骤S330中，所述多种标准组件对应所述第一模板并且所述组件组合的可视化结构对应所述第一验证平台。所述第一模板和所述至少一个第二模板中的每一个第二模板之间至少在以下一项上不同：验证方法学、仿真工具、版本和场景需求。

[0070] 步骤S340：判断至少一个DUT是否在第一验证平台上功能验证通过并且在至少一个第二验证平台上功能验证通过，如果通过执行步骤S350，如果不通过执行步骤S360。

[0071] 步骤S350：交互式界面显示至少一个DUT功能验证通过。

[0072] 步骤S360：交互式界面显示至少一个DUT功能验证未通过。

[0073] 图3所示的验证平台生成方法，考虑到了芯片的开发项目以及芯片验证环节可能受到的干扰（如失去对当前EDA工具或版本的授权或合法使用渠道）也考虑到了追求更好的综合性的优化效果和开发设计效果的需求，针对不同来源、不同版本的EDA工具之间可能在验证方法学、验证工具以及具体的技术细节上存在差异性，根据组件组合以及基于第一模板生成第一验证平台和基于至少一个第二模板中由用户选择的一个或者多个第二模板生成至少一个第二验证平台，从而有效应对宏观因素的变化所带来的对芯片功能验证过程及验证结果的影响，并且多种标准组件对应第一模板和组件组合的可视化结构对应第一验证平台，从而使得可以通过交互式界面便利地搭建环境框图，有利于后续切换EDA工具或版本或者适配两种或者更多种EDA工具或者版本。

[0074] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一验证方法学，所述一个或者多个第二模板采用第二验证方法学，所述第一验证方法学不同于所述第二验证方法学并且所述第一验证方法学和所述第二验证方法学至少在以下一项上不同：工程脚本、激励生成、数据类型、打印机制、环境集成和环境启动。

[0075] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用UVM第一版本，所述一个或者多个第二模板采用UVM第二版本，所述UVM第一版本和所述UVM第二版本至少在以下一项上不同：激励退出机制、激励发送机制、打印格式和名称检查规则。

[0076] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板采用第一仿真工具，所述一个或者多个第二模板采用第二仿真工具，所述第一仿真工具和所述第二仿真工具至少在以下一项上不同：硬件描述语言的语义理解、线程调度、编译方式和仿真选项调用。

[0077] 在一种可能的实施方式中，所述一个或者多个第二模板与所述至少一个第二验证平台一一对应，所述第一模板对应第一场景需求，所述一个或者多个第二模板对应第二场景需求，所述第一场景需求和所述第二场景需求至少在以下一项上不同：客户偏好、环境运行速度要求、验证效率、环境层次化程度要求。

[0078] 参见图4，图4是本申请实施例提供的一种计算设备的结构示意图，该计算设备400包括：一个或者多个处理器410、通信接口420以及存储器430。所述处理器410、通信接口420以及存储器430通过总线440相互连接。可选地，该计算设备400还可以包括输入/输出接口450，输入/输出接口450连接有输入/输出设备，用于接收用户设置的参数等。该计算设备
400能够用于实现上述的本申请实施例中设备实施例或者系统实施例的部分或者全部功能；处理器410还能够用于实现上述的本申请实施例中方法实施例的部分或者全部操作步骤。例如，该计算设备400执行各种操作的具体实现可参照上述实施例中的具体细节，如处理器410用于执行上述方法实施例中部分或者全部步骤或者上述方法实施例中的部分或者全部操作。再例如，本申请实施例中，计算设备400可用于实现上述装置实施例中一个或者多个部件的部分或者全部功能，此外通信接口420具体可用于为了实现这些装置、部件的功能所必须的通讯功能等，以及处理器410具体可用于为了实现这些装置、部件的功能所必须的处理功能等。

[0079] 应当理解的是，图4的计算设备400可以包括一个或者多个处理器410，并且多个处理器410可以按照并行化连接方式、串行化连接方式、串并行连接方式或者任意连接方式来协同提供处理能力，或者多个处理器410可以构成处理器序列或者处理器阵列，或者多个处理器410之间可以分成主处理器和辅助处理器，或者多个处理器410之间可以具有不同的架构如采用异构计算架构。另外，图4所示的计算设备400，相关的结构性描述及功能性描述是示例性且非限制性的。在一些示例性实施例中，计算设备400可以包括比图4所示的更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者具有不同的部件布置。处理器410可以有多种具体实现形式，例如处理器410可以包括中央处理器（central processing unit，CPU）、图形处理器（graphic processing unit，GPU）、神经网络处理器（neural‑network processing unit，NPU）、张量处理器（tensor processing unit，TPU）或数据处理器（data processing unit，DPU）等一种或多种的组合，本申请实施例不做具体限定。处理器410还可以是单核处理器或多核处理器。处理器410可以由CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路（application‑specific integrated circuit，ASIC），可编程逻辑器件（programmable logic device，PLD）或其组合。上述PLD可以是复杂可编程逻辑器件（complex programmable logic device，CPLD），现场可编程逻辑门阵列（field‑programmable gate array，FPGA），通用阵列逻辑（generic array logic，GAL）或其任意组合。处理器410也可以单独采用内置处理逻辑的逻辑器件来实现，例如FPGA或数字信号处理器（digital signal processor，DSP）等。通信接口420可以为有线接口或无线接口，用于与其他模块或设备进行通信，有线接口可以是以太接口、局域互联网络（local interconnect network，LIN）等，无线接口可以是蜂窝网络接口或使用无线局域网接口等。

[0080] 存储器430可以是非易失性存储器，例如，只读存储器（read‑only memory，ROM）、可编程只读存储器（programmable ROM，PROM）、可擦除可编程只读存储器（erasable PROM，EPROM）、电可擦除可编程只读存储器（electrically EPROM，EEPROM）或闪存。存储器430也可以是易失性存储器，易失性存储器可以是随机存取存储器（random access memory，RAM），其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器（static RAM，SRAM）、动态随机存取存储器（dynamic RAM，DRAM）、同步动态随机存取存储器（synchronous DRAM，SDRAM）、双倍数据速率同步动态随机存取存储器（double data rate SDRAM，DDR SDRAM）、增强型同步动态随机存取存储器（enhanced SDRAM，ESDRAM）、同步连接动态随机存取存储器（synchlink DRAM，SLDRAM）和直接内存总线随机存取存储器（direct rambus RAM，DR RAM）。存储器430也可用于存储程序代码和数据，以便于处理器410调用存储器430中存储的程序代码执行上述方法实施例中的部分或者全部操作步骤，或者执行上述设备实施例中的相应功能。此外，计算设备400可能包含相比于图4展示的更多或者更少的组件，或者有不同的组件配置方式。总线440可以是快捷外围部件互连标准（peripheral component interconnect express，PCIe)总线，或扩展工业标准结构（extended industry standard architecture，EISA）总线、统一总线（unified bus，Ubus或UB）、计算机快速链接（compute express link，CXL）、缓存一致互联协议（cache coherent interconnect for accelerators，CCIX）等。总线440可以分为地址总线、数据总线、控制总线等。总线440除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

[0081] 本申请实施例还提供一种系统，该系统包括多个计算设备，每个计算设备的结构可以参照上述图4所描述的计算设备的结构。该系统可实现的功能或者操作可以参照上述方法实施例中的具体实现步骤和/或上述装置实施例中所描述的具体功能，在此不再赘述。本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，当所述计算机指令在计算机设备（如一个或者多个处理器）上运行时可以实现上述方法实施例中的方法步骤。所述计算机可读存储介质的处理器在执行上述方法步骤的具体实现可参照上述方法实施例中所描述的具体操作和/或上述装置实施例中所描述的具体功能，在此不再赘述。

[0082] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。本申请实施例可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线）或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。可用介质可以是磁性介质（如软盘、硬盘、磁带）、光介质、或者半导体介质。半导体介质可以是固态硬盘，也可以是随机存取存储器，闪存，只读存储器，可擦可编程只读存储器，电可擦可编程只读存储器，寄存器或任何其他形式的合适存储介质。

[0083] 本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和/或方框图来描述。可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

[0084] 在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并或删减；本申请实施例系统中的模块可以根据实际需要进行划分、合并或删减。如果本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。