处理器中的执行部件的验证方法及装置、设备、存储介质与流程

1.本技术涉及计算机领域，更为具体的，涉及一种处理器中的执行部件的验证方法及装置、设备、存储介质。


背景技术：

2.近年来，随着制造工艺的改进，处理器设计的复杂度越来越高，处理器功能验证已成为处理器设计流程中的瓶颈。处理器中的执行部件一般包括整数运算部件、浮点运算部件（vector and floating-point unit，vfu）和访存部件（load-store unit，lsu）等，这些部件通常只负责操作数准备完成后具体操作的执行，因此在验证处理器功能的过程中，需要验证环境完成操作数的准备工作，例如操作数的来源处理。


技术实现要素：

3.本技术提供一种处理器中的执行部件的验证方法及装置、设备、存储介质。下面对本技术实施例涉及的各个方面进行介绍。
4.第一方面，提供一种处理器中的执行部件的验证方法，该方法包括：构建所述执行部件的验证环境，所述验证环境中集成有指令队列，所述指令队列用于记录指令流中的各个指令以及所述各个指令对应的指令信息，所述各个指令对应的指令信息包含用于指示所述各个指令的相关性的信息；将所述指令流顺序提交至所述验证环境中的发射队列，使得所述执行部件乱序执行所述指令流；在执行所述指令流的过程中，根据所述指令流中的指令的相关性，确定所述指令流中的指令的操作数来源；在所述指令流中的指令顺序提交之后，根据所述指令流中的指令的执行结果，对所述执行部件进行验证。
5.作为一种可能的实现方式，所述根据所述指令流中的指令的相关性，确定所述指令流中的指令的操作数来源，包括：如果所述指令流中的当前指令与所述指令流中的其他指令不存在相关性，则确定所述当前指令的操作数来源为寄存器文件；和/或如果所述指令流中的当前指令与所述指令流中的其他指令存在相关性，且与所述当前指令相关的指令还未写回至所述寄存器文件，则所述当前指令的操作数来源为与所述执行部件具有旁路通道的其他执行部件。
6.作为一种可能的实现方式，所述指令流中的指令对应的指令信息还包括以下信息中的一种或多种：源操作数；目的操作数；重新分配的寄存器号；指令的执行周期；以及指令写回寄存器文件的时间。
7.作为一种可能的实现方式，所述指令队列包含一个或多个参变量，所述一个或多个参变量用于记录所述各个指令对应的部分或全部指令信息。
8.作为一种可能的实现方式，所述验证环境包括内部环境和外部环境，所述方法还包括：利用所述外部环境解析指令流，以获取所述各个指令对应的指令信息；利用所述内部环境解析所述各个指令对应的指令信息，以将所述指令流中的数据发送至所述执行部件。
9.作为一种可能的实现方式，所述验证环境中集成有指令的分派模块。
10.第二方面，提供一种处理器中的执行部件的验证装置，该装置包括：构建模块，用于构建所述执行部件的验证环境，所述验证环境中集成有指令队列，所述指令队列用于记录指令流中的各个指令以及所述各个指令对应的指令信息，所述各个指令对应的指令信息包含用于指示所述各个指令的相关性的信息；提交模块，用于将所述指令流顺序提交至所述验证环境中的发射队列，使得所述执行部件乱序执行所述指令流；确定模块，用于在执行所述指令流的过程中，根据所述指令流中的指令的相关性，确定所述指令流中的指令的操作数来源；验证模块，用于在所述指令流中的指令顺序提交之后，根据所述指令流中的指令的执行结果，对所述执行部件进行验证。
11.作为一种可能的实现方式，所述确定模块用于：如果所述指令流中的当前指令与所述指令流中的其他指令不存在相关性，则确定所述当前指令的操作数来源为寄存器文件；和/或如果所述指令流中的当前指令与所述指令流中的其他指令存在相关性，且与所述当前指令相关的指令还未写回至所述寄存器文件，则所述当前指令的操作数来源为与所述执行部件具有旁路通道的其他执行部件。
12.作为一种可能的实现方式，所述指令流中的指令对应的指令信息还包括以下信息中的一种或多种：源操作数；目的操作数；重新分配的寄存器号；指令的执行周期；以及指令写回寄存器文件的时间。
13.作为一种可能的实现方式，所述指令队列包含一个或多个参变量，所述一个或多个参变量用于记录所述各个指令对应的部分或全部指令信息。
14.作为一种可能的实现方式，所述验证环境包括内部环境和外部环境，所述装置还包括：第一解析模块，用于利用所述外部环境解析指令流，以获取所述各个指令对应的指令信息；第二解析模块，用于利用所述内部环境解析所述各个指令对应的指令信息，以将所述指令流中的数据发送至所述执行部件。
15.作为一种可能的实现方式，所述验证环境中集成有指令的分派模块。
16.第三方面，提供一种计算设备，该装置包括：存储器，用于存储代码；处理器，用于执行所述存储器中存储的代码，以执行如第一方面或第一方面中的任意一种可能的实现方式所述的方法。
17.第四方面，提供一种计算机可读存储介质，其上存储有用于执行如第一方面或第一方面中的任意一种可能的实现方式所述的方法的代码。
18.本技术实施例通过构建执行部件的验证环境，并基于验证环境中的指令相关性信息确定指令流中的指令的操作数来源，有助于提高验证环境的灵活性。
附图说明
19.图1为本技术实施例提供的一种处理器中的执行部件的验证方法的流程示意图。
20.图2为本技术实施例提供的一种物理寄存器重分配的方法的流程示意图。
21.图3为本技术实施例提供的一种确定操作数来源的方法的流程示意图。
22.图4为本技术实施例提供的一种处理器中的执行部件的验证装置的结构示意图。
23.图5为本技术实施例提供的一种计算设备的结构示意图。
具体实施方式
24.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。
25.近年来，随着制造工艺的改进，处理器设计的复杂度越来越高，处理器功能验证已成为处理器设计流程中的瓶颈。
26.处理器中的执行部件一般包括整数运算部件、浮点运算部件和访存部件等，这些部件通常只负责操作数准备完成后具体操作的执行，因此在验证处理器功能的过程中，需要验证环境，例如通用验证方法学（universal verification methodology，uvm）验证平台完成操作数的准备工作。操作数的准备工作例如可以包括操作数来源处理。
27.为了提高处理器的性能，通常会采用乱序执行、顺序提交的方法执行指令流，指令流可以为处理器待执行的指令序列，通常包括多个指令。也就是说，处理器可以不按照指令流中的指令序列的顺序执行指令，按照指令流中的指令序列的顺序提交指令的执行结果即可。
28.由于处理器的上述特性，在构建验证环境的过程中，面临如下几个需要解决的问题：如何解决指令之间的相关性，如何验证不同执行部件之间的交互旁路，如何充分的验证执行部件的功能等。
29.另外，对于指令的验证过程来说，每条指令在流水线上执行的周期（cycle）数不一样，指令之间的处理方式也不一样，同时还涉及到不同执行部件的交互，因此需要搭建更加灵活可控的验证环境，以适应各种需求。
30.为了解决上述问题，本技术实施例提供了一种处理器中的执行部件的验证方法，通过构建执行部件的验证环境，并基于验证环境中的指令相关性信息确定指令流中的指令的操作数来源，有助于提高验证环境的灵活性。
31.图1为本技术实施例提供的一种处理器中的执行部件的验证方法的流程示意图。在一些实施例中，该方法可以应用于执行部件的模块级验证，也可以应用于包括执行部件的子系统级验证。
32.参见图1，方法100包括步骤s110至步骤s140。
33.在步骤s110中，构建执行部件的验证环境。
34.如前文所述，验证环境可以用于为执行部件的验证完成准备工作。在实际使用中，通常通过指令的执行结果来验证执行部件的功能是否正确。因此，验证环境需要为执行部件提供待执行的指令。作为一种实现方式，验证环境可以为执行部件提供指令流。例如，验证环境中可以集成有指令队列，该指令队列可以用于记录指令流中的各个指令。其中，指令流可以从程序中获取，也可以根据执行部件的验证需求进行编写。如果根据验证需求编写指令流，可以通过aem工具生成该指令流对应的程序。
35.由于处理器中通常是基于指令流中各个指令的相关性，乱序执行指令流中的各个指令的，因此在对执行部件进行验证时，也可以采用指令流乱序执行的方式。为了实现乱序执行，需要知道指令流中各个指令对应的指令信息，例如相关性信息。
36.作为一种实现方式，验证环境中可以集成有指令队列，该指令队列可以用于记录指令流中的各个指令对应的指令信息，该指令信息包含用于指示各个指令的相关性的信息。例如，指令信息可以包括各个指令与之前的指令是否存在相关性，其中，之前的指令是
指按照指令流序列中指令的顺序，在当前指令之前的指令。如果当前指令与之前的指令存在相关性，当前指令的指令信息还可以包括该指令的数据的来源，例如，来源于之前某一条指令执行结束后写回的寄存器，又如，来源于该执行部件与其他部件之间的旁路，进一步地，指令信息还可以包括该旁路相关的信息。
37.验证环境中用于记录指令信息的指令队列和用于记录指令流中的各个指令的指令队列可以为同一个队列，也可以为不同的队列。
38.为了充分验证执行部件的功能，通常可以执行多个指令流。在这种情况下，验证环境中集成的指令队列可以为以指令流为索引的合并队列，其中队列的个数可以与指令流的个数相等。该队列中的每一项可以与指令流中的每个指令相对应，例如，每个指令号可以占用一项，而每个指令对应的指令信息可以以队列的形式存入该指令号的一项中。
39.在步骤s120中，将指令流顺序提交至验证环境中的发射队列。
40.验证环境中的发射队列可以用于存储待发射的指令，如待执行的指令流，其中指令流是按照顺序提交至发射队列的。
41.在一些实施例中，指令分派模块可以基于指令流的顺序以及指令流中各个指令对应的指令信息确定发射队列中指令的发射顺序，并将待执行指令分派至执行部件。例如，指令分派模块可以基于指令的类型、指令对应的指令信息（如相关性信息）确定指令的发射顺序以及发射时机，即实现前文提到的乱序发射。
42.作为一种实现方式，可以构建一个以指令流为索引的乱序发射的映射表，用于记录整个指令流与正在发射指令流之间的关系，以及发射的时间，执行cycle数，写回寄存器文件的时间等信息。
43.在步骤s130中，在执行指令流的过程中，根据指令流中的指令的相关性，确定指令流中的指令的操作数来源。
44.在执行指令流的过程中，验证环境还需要为待执行指令提供操作数。由于，指令流中的指令的操作数存在多种情况，因此需要先确定指令流中指令的操作数来源。
45.指令的操作数来源可以包括寄存器文件和/或当前执行部件与其他执行部件的旁路通道。如果指令流中的当前指令与指令流中的其他指令不存在相关性，则确定当前指令的操作数来源为寄存器文件；和/或如果指令流中的当前指令与指令流中的其他指令存在相关性，且与当前指令相关的指令还未写回至寄存器文件，则当前指令的操作数来源为与执行部件具有旁路通道的其他执行部件。
46.在步骤s140中，根据指令流中的指令的执行结果，对执行部件进行验证。
47.基于前文确定的执行指令以及指令相关的操作数，执行部件可以生成指令流中的指令执行结果。根据顺序提交的指令流中的指令执行结果可以验证执行部件的功能是否正确，例如在uvm验证平台中，可以通过对比参考模型的输出结果和执行部件的执行结果来判断执行部件的功能是否正确。如果执行结果与参考模型的输出结果一致，则执行部件的功能正确，反之亦然。
48.本技术实施例通过构建执行部件的验证环境，并基于验证环境中的指令相关性信息确定指令流中的指令的操作数来源，有助于为执行部件提供灵活可控的验证环境。
49.一条指令通常包括操作码、源操作数和目的操作数。指令流中指令存在相关性是指不同的指令之间存在数据冲突，也就是不同指令的操作数之间存在依赖关系，如使用同
一寄存器或存储器位置，因此指令必须等待相应的依赖关系得到解决后才能继续执行。
50.根据操作数依赖关系的不同，相关性可以分为假相关和真相关。对于假相关的情况，通过寄存器重分配，可以将相关指令解耦，例如可以同时执行。作为一个示例，对于操作数使用同一寄存器，但指令的执行不依赖相关指令的执行结果的相关指令，可以将操作数进行寄存器重分配。因此，指令流中的指令对应的指令信息还可以包括重新分配的寄存器号，以便验证环境能够为指令提供正确的操作数。
51.对于真相关的情况，一般需要等待相关指令执行结束后，才能执行当前指令。如果相关指令的执行部件和当前执行的执行部件存在旁路，当前指令可以在相关指令执行结束尚未写回寄存器时，通过旁路通道获取操作数。如果相关指令的执行部件和当前执行的执行部件不存在旁路，则可以在相关指令的执行结果写回寄存器以后，从寄存器文件中获取操作数。但是，每条指令的发射的时间、执行cycle数不同，写回寄存器文件的时间也不确定，因此，指令流中的指令对应的指令信息还可以包括指令的执行周期以及指令写回寄存器文件的时间，以便确定当前执行可以执行的时机。
52.作为一种实现方式，指令流中的指令对应的指令信息还包括以下信息中的一种或多种：源操作数；目的操作数；重新分配的寄存器号；指令的执行周期；以及指令写回寄存器文件的时间。
53.由于处理器中的物理寄存器数量有限，而执行部件的验证需要大量的指令，也就是需要大量的寄存器，因此在指令执行结束后需要及时回收寄存器号，以便后续指令使用。
54.作为一种实现方式，可以根据指令流构建队列，以源寄存器号为索引将指令流中的指令的源操作数存入队列，同时以目的寄存器号为索引将指令的执行结果写回队列中。源和目的寄存器可以通过python脚本解析获得。
55.当某条指令提交之后，可以根据该指令对应的指令信息获取寄存器号，同时回收寄存器队列中对应的寄存器号。
56.由于源和目的操作数也可能包括浮点数，因此可以根据指令流构建两个队列，一个以通用寄存器号为索引，一个以浮点寄存器为索引。
57.在一些其他实施例中，上述根据指令流构建的队列还可以作为参考模型。根据指令的操作码和源操作数，可以获取目的操作数，目的操作数可以作为参考模型的输出。当指令执行结束之后，可以将执行部件的执行结果与该队列中的目的操作数进行比较以验证执行部件的正确性。
58.针对不同的处理器，相关参数可能不同，为了提高验证环境的灵活性，指令队列可以包含一个或多个参变量，该一个或多个参变量用于记录所述各个指令对应的部分或全部指令信息。参变量独立于验证环境，既可以进行随机测试也可以对一些难以实现的测试点进行定向测试。例如，在当前指令与之前的指令存在相关性时，数据来源来自于哪条旁路，可以完全按照rtl规则进行设计，也可以通过参变量手动修改。作为一个示例，如果想要验证执行部件之间的某条旁路，可以将指令的数据来源修改为该条旁路。如此一来，如果该条指令的执行结果正确，那么可以认为该条旁路功能正确。
59.又如，参变量可以包括寄存器的数量，如果处理器的寄存器数量为128，则将该参变量设置为128，如果需要对寄存器数量为256的处理器中的执行部件进行验证，只需要将参变量从128改成256即可，非常方便灵活。
60.前文提到的本技术实施例构建的验证环境可以包括内部环境和外部环境。其中，利用外部环境可以解析指令流，以获取各个指令对应的指令信息，如通过外部环境的脚本可以解析出指令的寄存器号，数据信息，size大小等信息，这些信息可以以txt的格式存储。如果想要实现某些定向测试，也可以通过修改该文件中的内容实现。
61.利用内部环境可以解析各个指令对应的指令信息，以将指令流中的数据发送至执行部件。在一些实现方式中，根据设计文档对指令重新进行物理寄存器号（ptag）的分配，同时依据指令类型以及指令之间的相关性可以判断指令发射的时机以及指令执行多少cycle之后可以对比结果，最后回收ptag以及顺序提交指令流，这个时候可以得到一个完整的文件。其中，设计文档可以为前文提到的包括指令信息的txt文档。
62.内部环境通过提取这个完整文件对应的信息，并将数据发送给执行部件，并基于指令执行cycle的时间，确定指令执行结果对比时机。
63.通过脚本提取指令流的相关信息，可以使得这部分代码完全独立于验证环境，同时也会记录它与之前的指令是否存在相关性，通过对相关指令进行寄存器分配，可以在rtl中保存指令间的联系，以便测试不同执行部件的旁路通道。如果只想测试某一条通路是否正确或者测试指令计算结果是否正确，也可以手动切断指令之间的联系，有效提高了环境的灵活性。
64.需要说明的是，如果指令中出现flush机制，要保存flush之后的所有指令信息，以便重新发射。flush机制会按存储（save），更新（update），删除（delete）顺序执行，把缓存中的数据flush入数据库中的临时数据中，并清空缓存区，但是并未修改数据库数据。
65.由于执行部件的信号接口很多，逻辑组合过于复杂，不易控制，因此验证环境中可以集成指令的分派模块，使得顶层接口更加清晰。
66.前文提到的用于处理器中执行部件的验证方法，可以应用于新一代飞腾处理器核的vfu单元级验证环境中，也可以应用于arm架构下执行部件的验证。下文以应用于arm架构下执行部件的验证环境为例，对处理器中执行部件的验证方法进行详细地介绍。
67.该方法通过构造arm架构下不同的指令流，来验证执行部件内部旁路以及不同执行部件间的交互，它受指令流、指令在执行部件的cycle数以及rtl分派规则的影响。该方法包括步骤1至步骤6。
68.在步骤1中，指令流可以从程序中获取，也可以根据需要进行编写，并通过aem生成程序。根据指令流可以构造两个队列，一个以通用寄存器号为索引，另外一个以浮点寄存器为索引。通过python脚本，解析指令中每一个操作码（opcode）的源和目的寄存器，可以以源寄存器号为索引从队列中取得数据；根据指令的执行结果得到目的寄存器的数据，并以目的寄存器为索引将执行结果重新写回到队列中。通过上述方式可以得到指令流的源和目的数据，在一些情况下还可以获得地址和系统寄存器（spr）数据。
69.需要说明的是，由于寄存器中可以分为多个bank，某些指令只更改寄存器中的某个bank位，因此在取源操作数以及更新目的操作数时，只取或更新对应的bank位。
70.在步骤2中，构造一个以指令流为索引的一个合并队列，队列的个数与指令流的个数相等。队列中包括每个指令流中所有指令，每个指令号占用一项（每一个指令的id是唯一的），其中指令号对应的每一项都是一个队列，记录着指令的所有信息，如包括源、目的操作数，ptag号以及在执行部件执行的cycle数，什么时候写回寄存器文件。另外队列中也可以
记录指令与之前的指令是否存在相关性以及操作数来源来自于哪条旁路，旁路可以完全按照rtl规则进行设计，也可以手动修改。
71.在步骤3中，构建一个以指令流为索引的乱序发射的映射表，该表里面记录着整个指令流与正在发射指令流之间的关系，以及指令的相关信息。指令信息例如可以包括发射的时间，执行cycle数，写回寄存器文件的时间等。通过查询步骤2中构建的队列，可以确定指令的源数据来自哪里，也可以强制更改数据来源。
72.在步骤4中，当指令按照指令流的顺序进入到发射队列里面，在发射队列里面乱序发射出来的时候，根据指令号填回到步骤3中的映射表里面。如果通过查询步骤2中的队列发现，本条指令与之前指令不存在相关性，那么指令的数据来源来自于寄存器文件；如果存在相关性，查找相关指令执行到哪一步，是否已经写回到寄存器文件里面，如果没有写回到寄存器文里面，那么操作数来自于各个部件间的旁路。
73.在步骤5中，对于拆分指令，需要收集执行部件计算的中间值，来完善步骤1中的队列，确保拆分指令不会出错。
74.在步骤6中，同时执行结果的验证采用顺序提交对比的方式，以避免由于flush产生错误。
75.由于指令是顺序进入，乱序执行的，因此需要将发射单元和vfu结合起来作为rtl，另外在此过程中需要注意不同执行部件之间旁路信号的唤醒和取消（cancel）。为了提高验证效率，也可以强制修改旁路信息。
76.为满足不同执行部件的各种验证需求，模型中的队列可以使用参数化实现，并且独立于验证环境。如此一来，既可以对执行部件进行随机测试，也可以对于一些难以实现的测试点进行定向测试。
77.图2为本技术实施例提供的一种物理寄存器重分配的方法的流程示意图。方法200用于对指令的源和目的寄存器进行重分配，其中方法200包括步骤s210至步骤s252。
78.在步骤s210，判断源寄存器号是否分配过ptag。
79.如果源寄存器号分配过ptag，则跳转至步骤s211，如果源寄存器号未分配过ptag，则跳转至步骤s220。
80.在步骤s211，使用之前分配的ptag。
81.在步骤s220，判断是否还有空的寄存器号。
82.如果没有空的寄存器号则跳转至步骤s221，如果有空的寄存器号则跳转至步骤s230。
83.在步骤s221，等待寄存器号空出。
84.如果一条指令执行完并提交之后，且后续并没有相关指令，则可以回收该指令的寄存器号，以空出寄存器号供其他指令使用。
85.在步骤s230，从空的寄存器号中取一个寄存器号。
86.将该寄存器号分配给当前指令的源操作数，同时更新验证环境队列中的指令信息。
87.在步骤s240，判断是否还有空的寄存器号。
88.如果没有空的寄存器号则跳转至步骤s241，如果有空的寄存器号则跳转至步骤s250。
89.在步骤s241，等待寄存器号空出。
90.在步骤s250，判断目的寄存器是否分配过ptag。
91.如果目的寄存器号分配过ptag，则跳转至步骤s251，如果目的寄存器号未分配过ptag，则跳转至步骤s252。
92.在步骤s251，回收ptag并更新队列。
93.在步骤s252，更新队列。
94.图3为本技术实施例提供的一种确定操作数来源的方法的流程示意图。方法300包括步骤s310至步骤s350。
95.在步骤s310，判断是否存在当前指令的相关指令。
96.如果存在与当前指令相关的指令，则跳转至步骤s320；如果不存在与当前指令相关的指令，则跳转至步骤s311。
97.在步骤s311，数据来源于寄存器文件。
98.这里的数据是指该指令对应的操作数。
99.在步骤s320，判断当前指令是否与浮点运算单元（vfu）的指令相关。
100.如果当前指令与浮点运算单元的指令相关，则跳转至步骤s321；如果当前指令与浮点运算单元的指令不相关，则跳转至步骤s330。
101.在步骤s321，数据来源于发射单元（iss）与浮点运算单元之间的旁路。
102.在步骤s330，判断当前指令是否与整数运算单元（exu）的指令相关。
103.如果当前指令与整数运算单元的指令相关，则跳转至步骤s331；如果当前指令与整数运算单元的指令不相关，则跳转至步骤s340。
104.在步骤s331，数据来源于exu之间的旁路。
105.在步骤s340，判断当前指令是否与访存单元（lsu）的指令相关。
106.如果当前指令与lsu的指令相关，则跳转至步骤s350。
107.在步骤s350，数据来源于lsu旁路。
108.上文结合图1至图3，详细描述了本技术的方法实施例，下面结合图4至图5，详细描述本技术的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
109.图4为本技术实施例提供的一种处理器中的执行部件的验证装置的结构示意图。参见图4，验证装置400包括构建模块410、提交模块420、确定模块430以及验证模块440。
110.构建模块410，用于构建所述执行部件的验证环境，所述验证环境中集成有指令队列，所述指令队列用于记录指令流中的各个指令以及所述各个指令对应的指令信息，所述各个指令对应的指令信息包含用于指示所述各个指令的相关性的信息。
111.提交模块420，用于将所述指令流顺序提交至所述验证环境中的发射队列，使得所述执行部件乱序执行所述指令流。
112.确定模块430，用于在执行所述指令流的过程中，根据所述指令流中的指令的相关性，确定所述指令流中的指令的操作数来源。
113.验证模块440，用于在所述指令流中的指令顺序提交之后，根据所述指令流中的指令的执行结果，对所述执行部件进行验证。
114.可选的，所述确定模块用于：如果所述指令流中的当前指令与所述指令流中的其
他指令不存在相关性，则确定所述当前指令的操作数来源为寄存器文件；和/或如果所述指令流中的当前指令与所述指令流中的其他指令存在相关性，且与所述当前指令相关的指令还未写回至所述寄存器文件，则所述当前指令的操作数来源为与所述执行部件具有旁路通道的其他执行部件。
115.可选地，所述指令流中的指令对应的指令信息还包括以下信息中的一种或多种：源操作数；目的操作数；重新分配的寄存器号；指令的执行周期；以及指令写回寄存器文件的时间。
116.可选地，所述指令队列包含一个或多个参变量，所述一个或多个参变量用于记录所述各个指令对应的部分或全部指令信息。
117.可选地，所述验证环境包括内部环境和外部环境，所述装置还包括：第一解析模块，用于利用所述外部环境解析指令流，以获取所述各个指令对应的指令信息；第二解析模块，用于利用所述内部环境解析所述各个指令对应的指令信息，以将所述指令流中的数据发送至所述执行部件。
118.可选地，所述验证环境中集成有指令的分派模块。
119.图5为本技术实施例提供的一种计算设备的结构示意图。图5所示的计算设备500可以包括存储器510和处理器520。在一些实施例中，图5所示的计算设备500还可以包括输入/输出接口530以及收发机540。存储器510、处理器520、输入/输出接口530和收发机540通过内部连接通路相连，该存储器510用于存储指令，该处理器520用于执行该存储器510存储的指令，以执行前文任一实施例描述的验证方法。
120.应理解，在本技术实施例中，该处理器520可以采用通用的中央处理器（central processing unit，cpu），微处理器，应用专用集成电路（application specific integrated circuit，asic），或者一个或多个集成电路，用于执行相关程序，以实现本技术实施例所提供的技术方案。
121.还应理解，收发机540又称通信接口，使用例如但不限于收发器一类的收发装置，来实现计算设备500与其他设备或通信网络之间的通信。
122.该存储器510可以包括只读存储器和随机存取存储器，并向处理器520提供指令和数据。处理器520的一部分还可以包括非易失性随机存取存储器。例如，处理器520还可以存储设备类型的信息。
123.在实现过程中，上述方法的各步骤可以通过处理器520中的硬件的集成逻辑电路或者软件形式的指令完成。结合本技术实施例所公开的验证方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器510，处理器520读取存储器510中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
124.应理解，本技术实施例中，该处理器可以为中央处理单元（central processing unit，cpu），该处理器还可以是其他通用处理器、数字信号处理器（digital signal processor，dsp）、专用集成电路（application specific integrated circuit，asic）、现场可编程门阵列（field programmablegate array，fpga）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可
以是任何常规的处理器等。
125.应理解，在本技术实施例中，“与a相应的b”表示b与a相关联，根据a可以确定b。但还应理解，根据a确定b并不意味着仅仅根据a确定b，还可以根据a和/或其它信息确定b。
126.应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
127.应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
128.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
129.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
130.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
131.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，dsl））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，dvd））或者半导体介质（例如，固态硬盘（solid state disk，ssd））等。
132.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。