通用验证方法学环境搭建方法、芯片验证方法及验证系统与流程

1.本技术涉及功能验证技术领域，具体涉及一种通用验证方法学环境搭建方法、芯片验证方法及验证系统。


背景技术：

2.通常，高层级的待测设计（design under test，dut）（例如，系统级dut）会包含多个功能相同的低层级的第一dut（例如，模块级dut）。由于这些第一dut的功能相同，因此，在对这些第一dut进行功能验证时，使用的通用验证方法学（universal verification methodology，uvm）环境（又称“第一级uvm环境”）也是相同的，或者说，第一级uvm环境中包含的uvm组件是相同的。因此，为了提高uvm验证系统的搭建效率，在搭建高层级的uvm环境（又称“第二级uvm环境”）以对高层次级dut的进行功能验证时，往往会复用第一级uvm环境，以对上述功能相同的低层级dut进行功能验证。
3.在传统的uvm验证系统的搭建过程中，为了将高层级的dut与第二级uvm环境的连接，需要将第一级uvm环境中的uvm组件与第一dut进行绑定。首先，需要在第二级uvm环境的验证顶层中，将第一dut的实例接口与第一dut的接口连接，再将第一dut的实例接口对应的虚拟接口发送给第一级uvm环境中的各个uvm组件，以便各个uvm组件可以通过虚拟接口与第一dut通信。这种传统的第一dut与第一级uvm环境的连接方式较为繁琐，限制了uvm验证系统的验证效率。
4.尤其是在高层级的dut中包含多个第一dut情况下，在第二级uvm环境中复用第一级uvm环境，此时，如果依然利用上述高层级的dut与第二级uvm环境的连接方式，则需要重复执行第一dut与第一级uvm环境的绑定过程，直到多个第一dut中的每个第一dut绑定到对应的第一级uvm环境。并且在上述重复执行第一dut与第一级uvm环境的绑定过程中，需要将虚拟接口传递到多个第一级uvm环境中的每个uvm组件，这种多次重复性地向多个第一级uvm环境中的uvm组件发送虚拟接口的方式，导致第一dut与第一级uvm环境的连接过程较为繁琐，限制了uvm验证系统的验证效率。


技术实现要素：

5.有鉴于此，本技术实施例致力于提供一种搭建通用验证方法学环境的方法和验证系统，以简化第一dut与第一级uvm环境的连接过程，有利于提高uvm验证系统的验证效率。
6.第一方面，提供了一种搭建通用验证方法学uvm环境的方法，所述uvm环境包括第一级uvm环境和第二级uvm环境，且所述第一级uvm环境的层级低于所述第二级uvm环境的层级，所述第一级uvm环境包含第一uvm容器，所述第一uvm容器中封装的uvm组件用于对第一待测设计进行功能验证，所述第二级uvm环境包括至少一个所述第一待测设计，所述方法包括：将所述第一uvm容器封装在第一检测器中，所述第一检测器的接口与所述第一待测设计的接口相同，且所述第一检测器的接口与所述uvm组件的虚拟接口相互连接；将所述第一检测器与所述第二级uvm环境中的所述第一待测设计绑定，使得所述第一检测器的接口与所
述第一待测设计的接口自动连接。
7.在本技术中，将第一检测器的接口配置为与第一dut相同的接口，并预先将第一检测器的接口与第一uvm容器中的uvm组件建立连接，这样，在利用第一检测器对第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现第一检测器的接口（或者说第一dut的接口）与第一uvm容器中uvm组件的接口之间的自动连接。避免了传统的第一dut与第一级uvm环境的绑定过程中，当第一dut的接口与第一dut的实例接口连接之后，再将第一dut的实例接口对应的虚拟接口发送到第一uvm容器中的各个uvm组件，有利于简化第一dut与第一级uvm环境的绑定过程，提高uvm验证系统的验证效率。
8.尤其是在第二级uvm环境中复用第一级uvm环境的场景中，第二级uvm环境中包含多个第一uvm容器，此时，利用本技术实施例的方法，可以预先将第一检测器的接口与多个第一uvm容器中的uvm组件的接口建立连接，这样，在利用第一检测器对多个第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现多个第一uvm容器中uvm组件的接口与多个第一dut之间的自动连接。避免了传统的高层级的dut与第二级uvm环境的连接方式中，需要多次重复性地向多个第一级uvm环境中的uvm组件发送虚拟接口，有利于简化第一dut与第一级uvm环境的连接过程，提高uvm验证系统的验证效率。
9.在一种可能的实现方式中，所述方法还包括：收集所述第一检测器在例化过程中的层次路径名；根据所述层次路径名，确定所述第一uvm容器在例化时的名称。
10.在本技术中，将第一检测器在例化过程中的层次路径名作为第一uvm容器在例化时的名称，有利于提高第一uvm容器命名的合理性，以便验证工程师在查阅验证结果的过程中，通过层次路径名快速定位到生成验证结果的第一uvm容器。
11.在一种可能的实现方式中，所述第一检测器中声明了第一变量和第一句柄，所述第一变量为字符串类型的变量，所述第一句柄为预先创建的用于存储所述层次路径名的字符串收集器的句柄；所述第一检测器封装了第二uvm容器，所述第二uvm容器中声明了第二句柄和第三句柄，所述第二句柄为所述字符串收集器的句柄，所述第三句柄为所述第一uvm容器的句柄；所述第一检测器中建立有第一初始块，所述第一初始块用于执行以下操作：将所述层次路径名赋值给所述第一变量；通过所述第一句柄将所述第一变量的值存储至所述字符串收集器中。
12.在本技术中，通过创建字符串收集器来存储层次路径名，并通过第一句柄和第二句柄之间的句柄传递将层次路径名传递到第二uvm容器中，以便将第二句柄中的层次路径名作为第二uvm容器中的第三句柄，以实现将层次路径名作为第一容器在例化时的名称。
13.在一种可能的实现方式中，所述层次路径名是基于层次路径名获取指令和格式调整函数获取的。
14.在本技术中，可以使用uvm验证系统提供的层次路径名获取指令和格式调整函数，来获取层次路径名，有利于提高本技术实施例的方法与uvm验证系统之间的兼容性。
15.在一种可能的实现方式中，所述第一检测器在例化过程中的层次路径名为所述第一检测器在被调用的过程中的所述层次路径名，或，所述第一uvm容器在例化时的名称为所述第一uvm容器在被调用时的名称。
16.在一种可能的实现方式中，在所述将所述第一uvm容器封装在所述第一检测器中之前，所述方法还包括：将所述第一uvm容器中的发送端代理的工作模式设置为uvm_
passive模式。
17.在本技术中，通过将发送端代理的工作模式设置为uvm_passive模式，有利于提高发送端代理的可重用性。
18.在一种可能的实现方式中，所述第一级uvm环境为模块级uvm环境，所述第二级uvm环境为系统级uvm环境。
19.第二方面，提供了一种基于uvm环境的验证系统，所述uvm环境包括第一级uvm环境和第二级uvm环境，且所述第一级uvm环境的层级低于所述第二级uvm环境的层级，，所述第一级uvm环境包含第一uvm容器，所述第一uvm容器中封装的uvm组件用于对第一待测设计进行功能验证，所述第二级uvm环境包括至少一个所述第一待测设计，所述验证系统包括：验证顶层，包括至少一个第一待测设计；至少一个第一检测器，分别与所述至少一个第一待测设计连接，所述第一检测器的接口与所述第一待测设计的接口相同，且所述第一检测器的接口与所述uvm组件的虚拟接口相互连接。
20.在本技术中，将第一检测器的接口配置为与第一dut相同的接口，并预先将第一检测器的接口与第一uvm容器中的uvm组件建立连接，这样，在利用第一检测器对第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现第一检测器的接口（或者说第一dut的接口）与第一uvm容器中uvm组件的接口之间的自动连接。避免了传统的第一dut与第一级uvm环境的绑定过程中，当第一dut的接口与第一dut的实例接口连接之后，再将第一dut的实例接口对应的虚拟接口发送到第一uvm容器中的各个uvm组件，有利于简化第一dut与第一级uvm环境的绑定过程，提高uvm验证系统的验证效率。
21.尤其是在第二级uvm环境中复用第一级uvm环境的场景中，第二级uvm环境中包含多个第一uvm容器，此时，利用本技术实施例的方法，可以预先将第一检测器的接口与多个第一uvm容器中的uvm组件的接口建立连接，这样，在利用第一检测器对多个第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现多个第一uvm容器中uvm组件的接口与多个第一dut之间的自动连接。避免了传统的高层级的dut与第二级uvm环境的连接方式中，需要多次重复性地向多个第一级uvm环境中的uvm组件发送虚拟接口，有利于简化第一dut与第一级uvm环境的连接过程，提高uvm验证系统的验证效率。
22.在一种可能的实现方式中，所述验证系统还包括：字符串收集器，用于收集所述第一检测器在例化过程中的层次路径名；所述第一检测器，用于根据所述字符串收集器收集的所述层次路径名，确定所述第一uvm容器在例化时的名称。
23.在本技术中，将第一检测器在例化过程中的层次路径名作为第一uvm容器在例化时的名称，有利于提高第一uvm容器命名的合理性，以便验证工程师在查阅验证结果的过程中，通过层次路径名快速定位到生成验证结果的第一uvm容器。
24.在一种可能的实现方式中，所述第一检测器中声明了第一变量和第一句柄，所述第一变量为字符串类型的变量，所述第一句柄为预先创建的用于存储所述层次路径名的字符串收集器的句柄；所述第一检测器封装了第二uvm容器，所述第二uvm容器中声明了第二句柄和第三句柄，所述第二句柄为所述字符串收集器的句柄，所述第三句柄为所述第一uvm容器的句柄；所述第一检测器中建立有第一初始块，所述第一初始块用于执行以下操作：将所述层次路径名赋值给所述第一变量；通过所述第一句柄将所述第一变量的值存储至所述字符串收集器中。
25.在本技术中，通过创建字符串收集器来存储层次路径名，并通过第一句柄和第二句柄之间的句柄传递将层次路径名传递到第二uvm容器中，以便将第二句柄中的层次路径名作为第二uvm容器中的第三句柄，以实现将层次路径名作为第一容器在例化时的名称。
26.在一种可能的实现方式中，所述层次路径名是基于层次路径名获取指令和格式调整函数获取的。
27.在本技术中，可以使用uvm验证系统提供的层次路径名获取指令和格式调整函数，来获取层次路径名，有利于提高本技术实施例的方法与uvm验证系统之间的兼容性。
28.在一种可能的实现方式中，所述第一检测器在例化过程中的层次路径名为所述第一检测器在被调用的过程中的所述层次路径名，或，所述第一uvm容器在例化时的名称为所述第一uvm容器在被调用时的名称。
29.在一种可能的实现方式中，所述第一uvm容器中的发送端代理的工作模式为uvm_passive模式。
30.在一种可能的实现方式中，所述第一级uvm环境为模块级uvm环境，所述第二级uvm环境为系统级uvm环境。
31.在本技术中，通过将发送端代理的工作模式设置为uvm_passive模式，有利于提高发送端代理的可重用性。
32.第三方面，提供了一种芯片的验证方法，所述方法应用于根据第一方面或第一方面中任一种可能的实现方式搭建的uvm环境，所述方法包括：利用所述uvm环境对所述芯片包括的至少一个所述第一待测设计进行功能验证。
33.第四方面，提供了一种芯片的验证系统，所述验证系统包括根据第一方面或第一方面中任一种可能的实现方式搭建的uvm环境，所述uvm环境用于对所述芯片包括的至少一个所述第一待测设计进行功能验证。
34.第五方面，提供了一种计算设备，所述计算设备具有实现上述第一方面的方法设计中的部分或全部的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。
35.第六方面，提供了一种计算设备，包括输入输出接口、处理器和存储器。该处理器用于控制输入输出接口输入或输出信息，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该计算设备执行上述第一方面中的方法。
36.第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
37.第八方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
附图说明
38.图1是功能验证方式的示意图。
39.图2是本技术实施例适用的uvm环境的示意图。
40.图3是本技术实施例适用的uvm树形结构的示意图。
41.图4是基于传统的uvm验证系统的搭建的uvm环境的示意图。
42.图5是传统的uvm验证系统的搭建方式的流程图。
43.图6是本技术实施例的uvm环境的示意图。
44.图7是本技术实施例的搭建uvm环境的流程图。
45.图8是本技术实施例的uvm环境的示意图。
46.图9是本技术实施例的芯片的示意图。
47.图10是本技术实施例的搭建检测器0的方法的流程图。
48.图11是本技术实施例的uvm环境的示意图。
49.图12是本技术实施例的基于uvm环境的验证系统的示意图。
50.图13是本技术实施例的计算设备的示意性框图。
具体实施方式
51.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。
52.功能验证用于对dut（其中dut例如可以是集成电路或者芯片）的功能进行功能验证。功能验证存在的意义在于不断地给dut的设计过程提供迭代的关键意见。例如，功能验证过程中发现的性能不满足、设计代码功能bug、集成错误等问题可以反馈到设计过程中，以提高设计过程的效率。
53.图1示例性介绍了功能验证方式。参见图1，在对dut110进行功能验证过程中，可以将激励信号120作为输入信号输入dut110，然后观察dut110对激励信号120的响应，即输出结果130。最终判断输出结果130是否与期望的输出结果相似。若输出结果130与期望的输出结果相似，则可以认为dut110的功能验证为通过。若输出结果130与期望的输出结果不相似，则可以认为dut110的功能验证结果为不通过。
54.随着功能验证技术的广泛应用，dut的种类越来越多，亟需一种通用的验证方法来实现对多种类型的dut进行功能验证。此时，基于uvm的功能验证系统应运而生。uvm旨在打造通用的验证系统（简称“uvm验证系统”），这样，验证工程师可以利用uvm验证系统来搭建uvm环境以对dut进行功能验证。为了保证uvm验证系统的通用性，uvm验证系统中将功能验证流程拆分成单独的子流程，不同的子流程可以通过不同的uvm组件实现。这样，验证工程师在搭建验证不同dut的uvm环境时，可以从uvm验证系统中选择合适的uvm组件即可。其中，常见的uvm组件可以包括驱动器（driver）、激励路由器（sequencer）、监测器（monitor）、代理（agent）、参考模型（referencemodel）、计分板（scoreboard）、uvm容器、验证顶层（testtop）等。
55.此外，uvm验证系统还提供了各种机制以简化验证工程师的开发过程。例如，reg机制就封装了在硬件开发中读写寄存器（register）的一些操作，验证工程师可以通过调用uvm函数，来迅速的开发读写寄存器的过程。又例如，为了提高uvm环境的封装和复用性，可以通过使用uvm_config_db配置机制在uvm环境中传递接口（virtual interface）。当然，uvm验证系统中的机制除了上述机制之外还包括factory机制、objection机制等。
56.为了便于理解，下文结合图2介绍uvm环境。图2是uvm环境的示意图。图2所示的uvm环境200包括验证顶层210，验证顶层 210用于封装uvm验证系统中对dut进行功能验证的uvm容器，其中，uvm容器220主要用于将uvm组件进行有关联的分层。另外，验证顶层 210中还可以封装例化后的dut，并且将dut接口与uvm容器的虚拟接口连接起来，以便uvm容器中
的uvm组件与dut进行交互，例如，数据传输等。
57.上述uvm容器220包含的 uvm组件有发送端代理（tx_agent）230、接收端代理（rx_agent）240、参考模型250和计分板260。其中，发送端代理230中可以封装有驱动器231和监测器232。接收端代理240中可以封装有监测器241。下文分别介绍各个uvm组件的功能。
58.发送端代理230和/或接收端代理240，用于对一些uvm组件进行分层和连接。
59.对于接收端代理240而言，接收端代理240可以封装监测器241。
60.对于发送端代理230而言，有两种工作模式：主动模式（又称“uvm_active”）和被动模式（又称“uvm_passive”）。对于处于主动模式的发送端代理230而言，可以封装有激励路由器、驱动器231以及监测器232。对于处于被动模式的发送端代理230而言，可以封装有监测器232，而并不封装驱动器231以及激励路由器。通常，对于不同的dut进行功能验证时，驱动到不同的dut上的激励信号通常是不同的，正是由于被动模式的发送端代理230中没有封装驱动器231以及激励路由器，因此，被动模式的发送端代理230的可重用性相对于主动模式的发送端代理230的可重用性较高。
61.驱动器231，用于向激励路由器申请激励信号，并将激励信号按照总线协议规定驱动到dut的端口上。在一些实现方式中，上述激励信号可以承载在数据包中。
62.监测器232，用于监测驱动在dut上的激励信号，并将监测到的激励信号发送给参考模型250。
63.参考模型250，用于模仿dut的功能，或者说，用于完成与dut相同的功能。
64.在一些实现方式中，dut可以是用verilog写成的时序电路，而参考模型250则可以直接使用sv（systemverilog）语言的构造，同时还可以通过dpi等接口调用其他语言来完成与dut相同的功能。
65.计分板260，用于检查dut的功能是不是符合预期。在一些实现方式中，计分板260可以比较参考模型250和监测器241分别发送来的数据，得到比较结果，并根据比较结果判断dut是否正确工作。
66.监测器241，用于监测dut针对激励信号产生的响应信号，并将响应信号发送给计分板260。
67.基于上文对uvm验证系统中各个uvm组件的封装方式可知，uvm组件被划分在不同的层次中，形成uvm树形结构。图3示出了本技术实施例适用的uvm树形结构的示意图。参见图3所示的uvm树形结构300，验证顶层210可以作为uvm树形结构的根，而其他uvm组件之间通过不同的封装方式，可以作为uvm树形结构中不同层次的节点。在这种uvm树形结构中，父节点（例如，验证顶层210）可以操作管理相连接的子节点（例如，uvm容器220），以实现有序地管理uvm组件，避免出现遗漏和错误。应理解，uvm组件之间的封装方式在上文中已详细介绍，为了简洁，下文不再赘述。
68.下文结合上文所示的uvm验证系统，以对dut1进行功能验证为例，介绍uvm验证系统的验证方式。
69.继续参见图2，在步骤s1中，驱动器231将激励信号驱动到dut1的接口上。
70.在步骤s2中，监测器232监测驱动到dut1上的激励信号，并将监测到的激励信号发送给参考模型250。
71.在步骤s3中，参考模型250对监测器232监测的激励信号产生响应信号1，并将产生
的响应信号1发送给计分板260。
72.在步骤s4中，监测器241监测dut1中针对激励信号产生的响应信号2，并将监测到的响应信号2发送给计分板260。
73.在步骤s5中，计分板260将响应信号1和响应信号2进行对比，以确定dut1是否正确地工作。
74.随着dut的设计规模与复杂度不断提高，可以按照dut的设计规模与复杂度划分为多个层级：模块级、部件级、子系统级和系统级，其中，模块级dut的设计规模和复杂度低于部件级dut的设计规模和复杂度，部件级dut的设计规模和复杂度低于子系统级dut的设计规模和复杂度，子系统级dut的设计规模和复杂度低于系统级dut的设计规模和复杂度。
75.通常，高层级的dut（例如，系统级dut）会包含多个功能相同的低层级的第一dut（例如，模块级dut）。由于这些第一dut的功能相同，因此，在对这些第一dut进行功能验证时，使用的uvm环境（又称“第一级uvm环境”）也是相同的，或者说，第一级uvm环境中包含的uvm组件是相同的。因此，为了提高uvm验证系统的搭建效率，在搭建高层级的uvm环境（又称“第二级uvm环境”）以对高层次级dut的进行功能验证时，往往会复用第一级uvm环境，以对上述功能相同的低层级dut进行功能验证。下文结合图4和图5，以对系统级dut进行功能验证的过程中复用模块级dut的uvm环境为例，介绍传统的uvm验证系统的搭建方式。
76.假设系统级dut中包含多个功能相同的模块级dut，并且对其中一个模块级dut验证所使用的第一级uvm环境可以封装为图2所示的uvm容器220。由于系统级dut中包含多个功能相同的模块级dut，因此在搭建图4所示的第二级uvm环境400时，第二级uvm环境会包含多个uvm容器220，以分别对多个模块级dut进行功能验证，其中，第二级uvm环境的搭建方法可以参见图5。图5所示的方法包括步骤s510至步骤s530。
77.在步骤s510中，搭建第一级uvm环境（即uvm容器）。
78.由于第二级uvm环境是对系统级dut整体进行功能验证，因此，激励信号是施加在系统级dut上的。也就是说，在第一级uvm环境中不需要单独地为每个模块级dut单独施加激励信号，因此，可以将第一级uvm环境中的发送端代理230配置为uvm_passive模式。
79.在步骤s520中，在第二级uvm环境的验证顶层410中，将模块级dut的实例接口与模块级dut相连接。
80.在步骤s530中，将模块级dut的实例接口对应的虚拟接口传送给第二级uvm环境中的uvm容器，使得各个uvm组件可以通过虚拟接口与对应的模块级dut通信。
81.如上文所述，系统级dut中会包含多个模块级dut，相应地，在第二级uvm环境中会包含多个uvm容器，因此，在执行步骤s530的过程中，需要将多个模块级dut的实例接口对应的多个虚拟接口分别传送给对应的uvm容器，以便将多个uvm容器中的uvm组件可以与对应的模块级dut通信，以验证模块级dut的功能。
82.基于图5所介绍的方法可知，在传统的uvm验证系统的搭建过程中，为了将高层级的dut与第二级uvm环境的连接，需要将第一级uvm环境中的uvm组件与第一dut进行绑定。首先，需要在第二级uvm环境的验证顶层中，将第一dut的实例接口与第一dut相连接，再将第一dut的实例接口对应的虚拟接口传送给第一级uvm环境中的各个uvm组件，使得各个uvm组件可以通过虚拟接口与第一dut通信。这种传统的第一dut与第一级uvm环境的连接方式较为繁琐，限制了uvm验证系统的验证效率。
83.尤其是在高层级的dut中包含多个第一dut情况下，第二级uvm环境中会复用第一级uvm环境（或者说，在第二级uvm环境中需要例化多个uvm容器），此时，如果依然利用上述连接方式，则需要重复执行第一dut与第一级uvm环境的绑定过程，直到多个第一dut中的每个第一dut绑定到对应的第一级uvm环境。并且在上述重复执行第一dut与第一级uvm环境的绑定过程中，需要将虚拟接口传递到多个第一级uvm环境中的每个uvm组件，这种多次重复性地向多个第一级uvm环境中的uvm组件发送虚拟接口的方式，导致高层级的dut与第二级uvm环境的连接过程较为繁琐，限制了搭建第二级uvm环境的效率。
84.因此，为了解决上述问题，本技术提供了一种搭建uvm环境（即第二级uvm环境）的方案，以简化第一dut与第一级uvm环境的连接过程，提高搭建第二级uvm环境的效率。下文结合图6所示的第二级uvm环境介绍本技术实施例的方案。在一些实现方式中，第二级uvm环境可以理解为被封装在对高层级dut进行功能验证的验证顶层610中。需要说明的是，第二级uvm环境600与第二uvm环境400中功能相同的uvm组件使用相同的编号，相关介绍请参见上文，为了简洁，下文不再赘述。
85.在第二级uvm环境600中包含一个或多个第一dut，并且还封装有第一级uvm环境，第一级uvm环境中封装有第一检测器（checker）620，第一检测器620中封装有第一uvm容器630，第一uvm容器630中封装的uvm组件用于对第一dut进行功能验证。在一些实现方式中，上述第一uvm容器630中封装的uvm组件可以参见uvm容器220中封装的uvm组件。当然，第一uvm容器630中还可以封装其他的uvm组件。本技术实施例对此不作具体限定。
86.如上文介绍，通常可以使用sv语言来搭建uvm验证环境，而在sv语言中的基本设计单元可以是模块（module），这些模块可以实现特定的功能并进行层次的嵌套，因此，在本技术实施例中可以利用模块来构建第一检测器610。
87.图7是本技术实施例的搭建uvm环境的流程图。图7所示的方法可以包括步骤s710和步骤s720。
88.在步骤s710中，将第一uvm容器封装在第一检测器610中。
89.上述第一检测器610的接口与第一dut的接口相同，且第一检测器的接口与uvm组件的虚拟接口相互连接。或者说，在第一检测器内，第一检测器的接口与uvm组件的虚拟接口之间的连接是预先连接好的。
90.在步骤s720中，将第一检测器610与第二级uvm环境中的第一dut绑定，使得第一检测器610的接口与第一dut的接口自动连接。
91.在一些实现方式中，在第二级uvm环境的顶层中，可以将第一dut的实例接口与第一检测器的接口相连，并将第一dut的实例接口对应的虚拟接口发送到第一检测器中的uvm组件，以使得第一检测器的uvm组件可以通过虚拟接口与第一dut通信。其中，可以利用assign语句连接第一检测器的接口与第一dut的实例接口。
92.目前，uvm验证系统中，提供bind命令可以实现将模块（module）或接口（interface）绑定到任意的设计模块或者其特定例化。因此，在本技术实施例中，可以利用bind命令将第一检测器610与第一dut绑定。
93.在本技术实施例中，将第一检测器的接口配置为与第一dut相同的接口，并预先将第一检测器的接口与第一uvm容器中的uvm组件建立连接，这样，在利用第一检测器对第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现第一检测器的接口（或
者说第一dut的接口）与第一uvm容器中uvm组件的接口之间的自动连接。避免了传统的第一dut与第一级uvm环境的绑定过程中，当第一dut的接口与第一dut的实例接口连接之后，再将第一dut的实例接口对应的虚拟接口发送到第一uvm容器中的各个uvm组件，有利于简化第一dut与第一级uvm环境的绑定过程，提高uvm验证系统的验证效率。
94.尤其是在第二级uvm环境中复用第一级uvm环境的场景中，第二级uvm环境中包含多个第一uvm容器，此时，利用本技术实施例的方法，可以预先将第一检测器的接口与多个第一uvm容器中的uvm组件的接口建立连接，这样，在利用第一检测器对多个第一dut进行功能验证时，仅需将第一检测器与第一dut绑定，便可以实现多个第一uvm容器中uvm组件的接口与多个第一dut之间的自动连接。避免了传统的高层级的dut与第二级uvm环境的连接方式中，需要多次重复性地向多个第一级uvm环境中的uvm组件发送虚拟接口，有利于简化第一dut与第一级uvm环境的连接过程，提高uvm验证系统的验证效率。
95.如上文介绍，在搭建第二级uvm环境的过程中，第二级uvm环境会复用第一uvm环境，这样，第二级uvm环境中也会包含多个第一uvm容器。通常，为了保证每个第一uvm容器的独立性，需要将不同的第一uvm容器例化为不同的名字，或者说，需要区分上述多个第一uvm容器的命名。在传统的uvm环境搭建过程中，主要依托于验证工程师手动为不同的第一uvm容器命名。然而，这种通过验证工程师手动命名的方式，导致uvm环境搭建的自动化程度较低。
96.因此，为了提高uvm环境搭建的自动化程度，本技术还提供一种搭建uvm环境的方案，在该方案中，可以将第一检测器在例化过程中的层次路径名自动作为第一uvm容器在例化时的名称。即本技术实施例的方法包括收集第一检测器在例化过程中的层次路径名；根据层次路径名，确定第一uvm容器在例化时的名称。
97.参见图3所，各个uvm组件可以构成uvm树形结构，或者说，各个uvm组件之间是具有层级关系的，每个uvm组件会有对应的层级路径名，层级路径名用于指示第一检测器在uvm树形结构中的位置。假设处理器作为系统级dut中包含三级高速缓存存储单元（l3 cache memory unit，lmu）1和lmu2，也就是说lmu1和lmu2为模块级dut。在使用本技术实施例的方法通过第一检查器1对lmu1进行功能验证时，第一检查器1中包含的第一uvm容器在例化时的名称可以为“lmu_uvm_checker1”。在使用本技术实施例的方法通过第一检查器2对lmu2进行功能验证时，第一检查器2中包含的第一uvm容器在例化时的名称可以为“lmu_uvm_checker2”。
98.目前，在利用uvm验证系统对第一dut进行验证后会得到验证结果，在验证结果中会显示对第一dut进行功能验证的第一uvm容器的名称。在本技术实施例中，将第一检测器在例化过程中的层次路径名作为第一uvm容器在例化时的名称，有利于提高第一uvm容器命名的合理性，以便验证工程师在查阅验证结果的过程中，通过层次路径名快速定位到生成验证结果的第一uvm容器。当然，如果不考虑第一uvm容器命名的合理性，在本技术实施例中，也可以以随机的方式对第一uvm命名，只要保证第一uvm容器可以例化为不同的名称即可保证例化后的第一uvm容器的独立性。
99.在一些实现方式中，上述层次路径名可以通过句柄传递的方式在第一检测器中传递。下文结合图8，以验证顶层610中包含的一个第一检查器620为例介绍句柄传递的过程。参见图8，在第一检测器620中声明了第一变量810和第一句柄820，第一变量810为字符串类
型的变量，第一句柄820为预先创建的用于存储层次路径名的字符串收集器的句柄；第一检测器封装了第二uvm容器830，第二uvm容器830中声明了第二句柄831和第三句柄832，第二句柄为字符串收集器的句柄，第三句柄为第一uvm容器的句柄；第一检测器中建立有第一初始块，第一初始块用于执行以下操作：将层次路径名赋值给第一变量；通过第一句柄将第一变量的值存储至字符串收集器中。
100.也就是说，在第一初始块中，可以通过第一句柄将层次路径名存储在字符串收集器中。由于第二uvm容器中声明的第二句柄为字符串收集器的句柄，这样，可以通过第一句柄与第二句柄之间句柄的传递，使得第二句柄指向收集到层次路径名的字符串收集器，此时，在第二uvm容器中可以通过第二句柄获取到字符串收集器中收集的层次路径名。在一些实现方式中，上述第一句柄和第二句柄之间的句柄传递可以通过uvm_config_db机制来实现。
101.另外，由于第二uvm容器中还声明有第一uvm容器的句柄，即第三句柄。因此，可以将第二句柄中的层次路径名作为第三句柄创建对象时的名称。
102.如上文所述，第一uvm容器可能经过多次例化，并且在每次例化时都需要执行将第二句柄指向的层次路径名称作为的第一uvm容器的名称。因此，可以使用循环语句来实现上述将第二句柄指向的层次路径名称作为的第一uvm容器的名称的相关操作。
103.如上文所述，在一些情况下，第一uvm容器会进行多次例化，并且每次例化使用的名称不同，也就是说，字符串收集器中需要存储多个层次路径名，而sv中提供的队列可以存储多个成员，因此，可以利用队列来存储多个层次路径名。在另一些情况下，还可以通过类来构建字符串收集器，即将上述队列封装在类中，或者说，在类中定义的一个成员是队列。
104.在一些实现方式中，上述层次路径名可以是基于层次路径名获取指令和格式调整函数获取的。其中，层次路径名获取指令可以为sv语言中的“%m”，格式调整函数可以为sv语言中的“$sformatf()函数”。当然，在另一些实现方式中，上述格式调整函数还可以为sv语言中的“$sformat()函数”，本技术实施例对此不作限定。
105.为了便于理解，下文结合图9和图10，以对芯片900进行验证为例介绍本技术实施例的方案。参见图9，芯片900包括信息中心网络（information-centric networking, icn）910、处理器核920以及多个lmu930，其中，多个lmu分别为lmu0 930、lmu1 930、lmu2 930以及lmu3 930。在对芯片900进行功能验证时，芯片900可以视为上文中的系统级dut，lmu 930可以视为上文中的模块级dut。相应地，用于对芯片900进行验证的uvm环境为高层级的uvm环境，即第二级uvm环境，用于对lmu 930进行验证的uvm环境为低层级的uvm环境，即第一级uvm环境。其中，处理器核920，用于执行各种指令操作。通常，处理器核920如果可以正常执行软件测试程序那么可以保证芯片900功能的正确性。icn 910用于将处理器核920发送的请求转发给不同的lmu 930。
106.假设可以采用图8所示的第一检测器620来对lmu930进行功能验证，那么在第二uvm环境中需要例化4个第一uvm容器630来对lmu0 930、lmu1 930、lmu2 930以及lmu3 930分别进行功能验证，即基于第一uvm容器0用于对lmu0 930进行功能验证，第一uvm容器1用于对lmu1 930进行功能验证，第一uvm容器2用于对lmu2 930进行功能验证，第一uvm容器3用于对lmu3 930进行功能验证。
107.图10是本技术实施例的搭建检测器的方法，图10所示的方法包括步骤s1010至步
骤s1040。需要说明的是，为了便于描述，下文结合步骤s1010至步骤s1030描述uvm组件的创建过程时，以uvm树结构中子节点到父节点的顺序介绍，也就是说，按照从第一uvm容器到第二uvm容器再到检测器的顺序介绍。
108.在步骤s1010中，创建第一uvm容器。
109.第一uvm容器中封装的uvm组件用于对lmu0进行功能验证。其中，每个uvm组件的功能可以参见上文结合图2的介绍，为了简洁，在此不再赘述。
110.在步骤s1020中，创建第二uvm容器。
111.在一些实现方式中，可以基于uvm验证系统中uvm_env的类来创建第二uvm容器，第二uvm容器的命名可以为multi_lmu_env。
112.如上文所述，可以通过句柄的传递来将字符串收集器中的层次路径名传递到第二uvm容器，因此，在创建第二uvm容器的过程中还需要声明句柄，以完成句柄的传递。即上述步骤s1020还包括步骤s1021和步骤s1022。另外，上述字符串收集器的创建过程可以参见步骤s1030。
113.在步骤s1021中，声明第二句柄和第三句柄。
114.第二句柄为字符串收集器的句柄，可以表示为句柄modc。第三句柄为第一uvm容器的句柄，可以表示为句柄lmu_env_mod。
115.在步骤s1022中，在第二uvm容器中获取字符串收集器中收集的层次路径名。
116.在一些实现方式中，在build_phase函数中利用uvm_config_db机制，将第一句柄指向的存储有层次路径名的字符串收集器传递给第二句柄，使得第二句柄指向字符串收集器。再将第二句柄指向的字符串收集器中的层次路径名作为第三句柄创建对象时的名称，由于第三句柄为第一uvm容器的句柄，因此，第一uvm容器的实例化名则是第二句柄指向的字符串收集器中的层次路径名。
117.需要说明的是，若第一uvm容器需要例化多次，并且字符串收集器中存储有多个层次路径名，可以利用循环语句实现将字符串收集器中收集的每个字符串元素值作为第三句柄lmu_env_mode创建对象时的名称，以作为第一uvm容器的实例化名。
118.在步骤s1030中，创建检测器。
119.在一些实现方式中，可以利用sv中的模块来对第二uvm容器multi_lmu_env进行封装，形成检测器。上述步骤s1030可以包括步骤s1031至步骤s1033。
120.在步骤s1031中，在检测器中创建字符串收集lmucollector、并声明第一变量以及第一句柄。
121.在一些实现方式中，利用类来创建字符串收集器（可以表示为lmucollector），并在字符串收集器中定义队列（表示为stcollector[$]）作为成员，来存储检测器在例化过程中的层次路径名，并在检测器中声明第一变量表示为mod_name，其中，第一变量mod_name可以为字符串类型的变量，以便后续过程中，可以通过将层次路径名赋值给第一变量mod_name，再将第一变量mod_name存储到字符串收集器lmucollector中的队列，来实现将层次路径名存储在字符串收集器中。
[0122]
上述第一句柄为用于存储层次路径名的字符串收集器的句柄，可以表示为mnc。
[0123]
在步骤s1032中，在检测器中建立初始（initial）块。
[0124]
在初始块中执行步骤s10321至步骤s10323。
[0125]
在步骤s10321中，将层次路径名赋值给第一变量mod_name；通过第一句柄将第一变量mod_name的值存储至字符串收集器lmucollector中。
[0126]
在一些实现方式中，可以利用层次路径名获取指令“%m”以及格式调整函数“$sformatf”，将层次路径名赋值给第一变量mod_name。
[0127]
在步骤s10322中，将第一句柄mnc指向的层次路径名传递给第二句柄modc。
[0128]
在一些实现方式中，利用uvm验证系统中的uvm_config_db机制将第一句柄mnc传递给第二句柄modc，使得第二句柄modc指向存储了层级路径名的字符串收集器。
[0129]
在步骤s10323中，将lmu930的实例接口对应的虚拟接口传递到检测器中的各个uvm组件。
[0130]
为了便于说明，下文结合图11介绍检测器中的接口连接过程。参见图11，在一些实现方式中，可以利用uvm_config_db机制将上述虚拟接口传递给各个uvm组件，以完成检测器和各个uvm组件之间的连接。
[0131]
在步骤s1033中，在检测器中声明lmu930实例接口，并将lmu930的实例接口与检测器的接口连接。
[0132]
在一些实现方式中，可以利用assign语句来连接lmu930的实例接口与检测器的接口。
[0133]
继续参见图11，在检测器中可以声明检测器的接口，并且检测器的接口与lmu的接口相同。再将检测器的接口与检测器的虚拟接口连接，以完成检测器的接口与各个uvm组件之间的连接。
[0134]
需要说明的是，由于检测器的接口与lmu的接口相同，当完成检测器的接口与各个uvm组件之间的连接时，也就完成了lmu的接口与各个uvm组件之间的连接，实现了在将lmu与检测器真正连接之前，预先将lmu的接口与各个uvm组件进行连接。
[0135]
经过以上步骤，可以理解为检测器的封装过程结束。下文结合步骤s1040介绍检测器和lmu的绑定过程。
[0136]
在步骤s1040中，将检测器与lmu绑定。
[0137]
在一些实现方式中，可以在系统级验证环境顶层（例如，验证顶层610）中使用bind语句将lmu0和检测器进行绑定，即完成了lmu和检测器中uvm组件之间的连接。这样，在验证顶层中会基于例化的lmu930的数量，来自动生成相同数量的检测器，也就是说，仅需要一次绑定操作，便可以将多个例化的lmu930与多个检测器相连接。
[0138]
参见图9，在芯片900中包含4个lmu，也即是说，lmu在例化时会例化成lmu0、lmu1、lmu2、 lmu3。在采用上述方法完成lmu和检测器之间的绑定后，并在运行上述uvm验证环境时，也会基于上文封装的检测器例化4个检测器，即，检测器0、检测器1、检测器2、检测器3，并自动完成检测器0与lmu0的接口之间的连接，检测器1与lmu1的接口之间的连接，检测器2与lmu2的接口之间的连接，检测器3与lmu3的接口之间的连接。
[0139]
相应地，采用上述方法还可以自动化生成第一uvm容器例化时的名称。即lmu0对应的第一uvm容器在例化时的命名为lmu_uvm_checker0，lmu1对应的第一uvm容器在例化时的命名为lmu_uvm_checker1，lmu2对应的第一uvm容器在例化时的命名为lmu_uvm_checker2，lmu3对应的第一uvm容器在例化时的命名为lmu_uvm_checker3。
[0140]
上文结合图1至图11，详细描述了本技术的方法实施例，下面详细描述本技术的装
置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
[0141]
图12是本技术实施例的基于uvm环境的验证系统的示意图。其中，uvm环境包括第一级uvm环境和第二级uvm环境，且第一级uvm环境的层级低于第二级uvm环境的层级，所述第一级uvm环境包含第一uvm容器，所述第一uvm容器中封装的uvm组件用于对第一dut进行功能验证，所述第二级uvm环境包括至少一个所述第一dut，所述验证系统1200包括：验证顶层1210、第一检测器1220。
[0142]
验证顶层1210，包括至少一个第一dut。
[0143]
至少一个第一检测器1220，分别与所述至少一个第一dut连接，所述第一检测器的接口与所述第一dut的接口相同，且所述第一检测器的接口与所述uvm组件的虚拟接口相互连接。
[0144]
在一种可能的实现方式中，所述验证系统1200还包括：字符串收集器，用于收集所述第一检测器在例化过程中的层次路径名；所述第一检测器1220，用于根据所述字符串收集器收集的所述层次路径名，确定所述第一uvm容器在例化时的名称。
[0145]
在一种可能的实现方式中，所述第一检测器1220中声明了第一变量和第一句柄，所述第一变量为字符串类型的变量，所述第一句柄为预先创建的用于存储所述层次路径名的字符串收集器的句柄；所述第一检测器封装了第二uvm容器，所述第二uvm容器中声明了第二句柄和第三句柄，所述第二句柄为所述字符串收集器的句柄，所述第三句柄为所述第一uvm容器的句柄；所述第一检测器中建立有第一初始块，所述第一初始块用于执行以下操作：将所述层次路径名赋值给所述第一变量；通过所述第一句柄将所述第一变量的值存储至所述字符串收集器中。
[0146]
在一种可能的实现方式中，所述层次路径名是基于层次路径名获取指令和格式调整函数获取的。
[0147]
在一种可能的实现方式中，所述第二级uvm环境包括多个所述第一dut。
[0148]
在一种可能的实现方式中，所述第一uvm容器中的发送端代理的工作模式为uvm_passive模式。
[0149]
在一种可能的实现方式中，所述第一级uvm环境为模块级uvm环境，所述第二级uvm环境为系统级uvm环境。
[0150]
在一种可能的实现方式中，所述第一检测器在例化过程中的层次路径名为所述第一检测器在被调用的过程中的所述层次路径名，或，所述第一uvm容器在例化时的名称为所述第一uvm容器在被调用时的名称。
[0151]
在可选的实施例中，上述验证系统1200可以运行在计算设备1300中，其中计算设备1300的结构可以参见图13。
[0152]
图13是本技术实施例的计算设备的示意性框图。图13所示的计算设备1300可以包括：存储器1310、处理器1320、输入/输出接口1330。其中，存储器1310、处理器1320和输入/输出接口1330通过内部连接通路相连。
[0153]
存储器1310用于存储指令和代码，在一些实现方式中，代码可以是用于实现本技术实施例的方法的代码。
[0154]
处理器1320用于执行该存储器1320存储的指令和代码，以控制输入/输出接口
1330接收输入的数据和信息，输出操作结果等数据（例如，验证结果）。在一些实现方式中，通过软件或者固件来实现本技术实施例的方案时，用于实现本技术实施例的方案的代码可以被保存在处理器1320中，并由处理器1320来执行。
[0155]
应理解，在本技术实施例中，该处理器1320可以采用通用的中央处理器（central processing unit，cpu），微处理器，应用专用集成电路（application specific integrated circuit，asic），或者一个或多个集成电路，用于执行相关程序，以实现本技术实施例所提供的技术方案。
[0156]
该存储器1310可以包括只读存储器和随机存取存储器，并向处理器1320提供指令和数据。处理器1320的一部分还可以包括非易失性随机存取存储器。例如，处理器1320还可以存储设备类型的信息。
[0157]
在实现过程中，上述方法的各步骤可以通过处理器1320 中的硬件的集成逻辑电路或者软件形式的指令完成。结合本技术实施例所公开的用于请求上行传输资源的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1310，处理器1320 读取存储器1310中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
[0158]
应理解，本技术实施例中，该处理器可以为中央处理单元（central processing unit，cpu），该处理器还可以是其他通用处理器、数字信号处理器（digital signal processor，dsp）、专用集成电路（application specific integrated circuit，asic）、现成可编程门阵列（field programmable gate array，fpga）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0159]
在一些实现方式中，计算设备1300除了包含上文介绍的硬件单元之外，还可以包括软件模块，其中，软件模块例如可以是操作系统、基本输入输出系统（basic input output system，bios）应用软件（application software）等。
[0160]
操作系统用于管理计算设备的硬件和/或软件资源，也定计算设备的内核和基石。操作系统需要处理如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。为了方便用户操作，大多数操作系统会提供一个让用户与系统交互的操作界面。
[0161]
bios用于在通电引导阶段运行硬件初始化，以及为操作系统和应用程序提供运行时服务。在一些实现方式中，bios还可以监测显示处理器温度以及执行调整温度保护策略等功能。
[0162]
应用软件又称应用程序（application program）可以理解为是针对用户的某种特殊应用目的所撰写的软件，作为计算机软件的主要分类之一。例如，应用软件可以是用于实现功率控制、温度管理等目的程序。
[0163]
本技术还提供一种芯片的验证方法，所述方法应用于根据上文结合图1至11介绍的任意一种方法搭建的uvm环境，所述方法包括：利用所述uvm环境对所述芯片包括的至少一个所述第一待测设计进行功能验证。
[0164]
在一些实现方式中，上述验证方法可以基于图13所示的装置执行。在另一些实现
方式中，上述验证方法所涉及的uvm环境可以是基于图13所示的装置搭建的。
[0165]
本技术还提供一种芯片的验证系统，所述验证系统包括上文结合图1至11介绍的任意一种方法搭建的uvm环境，所述uvm环境用于对所述芯片包括的至少一个所述第一待测设计进行功能验证。
[0166]
在一些实现方式中，上述uvm环境可以是基于图12或图13所示的装置搭建的。
[0167]
需要说明的是，在本技术中“例化的过程”可以理解为“被调用的过程”。例如，第一检测器在例化过程中可以理解为第一检测器在被调用的过程中。又例如，第一uvm容器在例化时可以理解为第一uvm容器在被调用时。
[0168]
应理解，根据a确定b并不意味着仅仅根据a确定b，还可以根据a和/或其它信息确定b。
[0169]
还应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
[0170]
应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0171]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0172]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0173]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0174]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，dsl））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用
光盘（digital video disc，dvd））或者半导体介质（例如，固态硬盘（solid state disk，ssd））等。
[0175]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。