一种片上系统芯片验证的方法和装置.pdf

本发明涉及SoC芯片领域，特别涉及一种SoC芯片验证的方法和装置，用以解决现有技术中对同一个SoC芯片不同功能进行验证时，每次验证都需要重新编译，增加了随机向量产生和控制的难度的问题。本发明实施例的方法包括：设定SoC芯片的配置文件，配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件；根据收到的指令，确定需要验证的SoC芯片的功能所涉及的模块；根据基本信息、确定的模块的约束条件以及指令中的模块功能数据，生成随机测试向量；根据随机测试向量，对SoC芯片进行验证。本发明实施例能够减少构建验证系统的复杂度和维护难度，增强验证部件的重用性，降低验证难度，节省时间。

1、  一种片上系统SoC芯片验证的方法，其特征在于，设定SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件，该方法包括：
根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；
根据所述基本信息、确定的所述模块的所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；
根据所述随机测试向量，对所述SoC芯片进行验证。

2、  如权利要求1所述的方法，其特征在于，所述指令为自定义类汇编语言或类C语言指令文件，该方法还包括：
读取收到的指令文件，并将读取的数据进行转换，形成二进制指令文件。

3、  如权利要求2所述的方法，其特征在于，所述形成二进制指令文件后，该方法还包括：
读取所述二进制指令文件，对读取的指令进行译码。

4、  如权利要求3所述的方法，其特征在于，如果在处理过程中有中断信号产生，则记录程序指针，停止处理二进制指令文件，并跳转到中断服务程序进行处理，在处理结束后，返回记录的程序指针处继续对所述二进制指令文件进行处理。

5、  如权利要求3或4所述的方法，其特征在于，如果译码后的指令是内部处理指令，则根据内部处理指令进行处理，并在处理结束后，继续读取二进制指令文件。

6、  如权利要求1所述的方法，其特征在于，所述根据所述随机测试向量，对所述SoC芯片进行验证包括：
模拟需要验证的所述SoC芯片的功能所涉及的模块，根据所述随机测试向量，得到预估数据；
将所述随机测试向量发送给所述SoC芯片，得到实际数据；
将所述预估数据和所述实际数据转换成设定格式的数据，进行比较。

7、  如权利要求6所述的方法，其特征在于，所述配置文件还包括SoC芯片中的模块的寄存器映像数据，所述模拟需要验证的所述SoC芯片的功能所涉及的模块包括：
根据所述寄存器映像数据，模拟对应的模块。

8、  如权利要求1所述的方法，其特征在于，所述根据所述随机测试向量，对所述SoC芯片进行验证包括：
将所述随机测试向量发送给所述SoC芯片；
将所述随机测试向量和所述SoC芯片输出的数据转换成特定格式的数据，进行比较。

9、  一种SoC芯片验证的装置，其特征在于，该装置包括：
配置模块，用于保存SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件；
配置调度模块，用于根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块，将所述配置模块保存的所述基本信息以及确定的模块的约束条件发送给随机激励产生模块；
随机激励产生模块，用于根据所述基本信息、所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；
验证模块，用于根据所述随机测试向量，对所述SoC芯片进行验证。

10、  如权利要求9所述的装置，其特征在于，所述随机激励产生模块包括：
接收模块，用于接收所述配置调度模块发送的所述基本信息和所述约束条件；
生成模块，用于根据所述基本信息、所述约束条件以及所述指令中的模块功能数据，生成随机测试向量。

11、  如权利要求9所述的装置，其特征在于，所述指令为自定义类汇编语言或类C语言指令文件，所述装置还包括：
指令解释模块，用于读取收到的指令文件，并将读取的数据进行转换，形成二进制指令文件。

12、  如权利要求11所述的装置，其特征在于，所述随机激励产生模块包括：
第一处理模块，用于读取所述二进制指令文件，对读取的所述二进制指令文件进行译码。

13、  如权利要求12所述的装置，其特征在于，所述随机激励产生模块包括：
第一发送模块，用于将所述第一处理模块译码后的指令发送给所述配置调度模块；
则所述配置调度模块包括：
第一确定模块，用于根据收到的译码后的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；
第二发送模块，用于将所述配置模块保存的所述第一确定模块确定的模块的配置数据，发送给所述随机激励产生模块。

14、  如权利要求12所述的装置，其特征在于，所述配置调度模块包括：
译码模块，用于读取所述指令解释模块形成的所述二进制指令文件，对读取的所述二进制指令文件进行译码；
第二确定模块，用于根据所述译码模块译码后的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；
第三发送模块，用于将所述配置模块保存的所述第二确定模块确定的模块的配置数据，发送给所述随机激励产生模块。

15、  如权利要求12所述的装置，其特征在于，所述随机激励产生模块还包括：
中断模块，用于如果在所述第一处理模块处理过程中有中断信号产生，则通知所述第一处理模块停止处理所述二进制指令文件，并跳转到中断服务程序进行处理，在处理结束后，通知所述第一处理模块继续处理所述二进制指令文件；
则所述第一处理模块包括：
第一指针模块，用于在收到停止处理所述二进制指令文件的通知后，记录程序指针，停止处理所述二进制指令文件；
第二指针模块，用于在收到继续处理所述二进制指令文件的通知后，返回记录的程序指针处继续对所述二进制指令文件进行处理。

16、  如权利要求12-15中任一权利要求所述的装置，其特征在于，所述随机激励产生模块还包括：
第二处理模块，用于如果所述第一处理模块译码后的数据包括内部处理指令，则根据内部处理指令进行处理，并在处理结束后，通知所述第一处理模块继续读取二进制指令文件。

17、  如权利要求9所述的装置，其特征在于，所述验证模块包括：
第一参考模块，用于模拟需要验证的所述SoC芯片的功能所涉及的模块，根据所述随机测试向量，得到预估数据，将所述预估数据转换成特定格式的数据，发送给第一比较模块；
第一总线驱动模块，用于根据所述SoC芯片遵循的协议，将所述随机测试向量进行转换后发送给所述SoC芯片；
第一监视模块，用于抓取所述SoC芯片生成的实际数据，将所述实际数据转换成设定格式的数据，发送给第一比较模块；
第一比较模块，用于对转换后的预估数据和实际数据进行比较。

18、  如权利要求17所述的装置，其特征在于，所述配置文件还包括SoC芯片中的模块的寄存器映像数据，所述参考模块包括：
第一模块，用于从所述配置模块中查找需要模拟的模块对应的寄存器映像数据；
第二模块，用于根据所述第一模块查找到的所述寄存器映像数据，模拟对应的模块。

19、  如权利要求9所述的装置，其特征在于，所述验证模块包括：
第二参考模块，用于将所述随机测试向量转换成特定格式的数据，发送给第二比较模块；
第二总线驱动模块，用于根据所述SoC芯片所遵循的协议，将所述随机测试向量进行转换后发送给所述SoC芯片；
第二监视模块，用于抓取所述SoC芯片生成的实际数据，将所述实际数据转换成设定格式的数据，发送给第二比较模块；
第二比较模块，用于对所述第二参考模块和所述第二监视模块发送的转换后的数据，进行比较。

一种片上系统芯片验证的方法和装置
技术领域
本发明涉及片上系统(System on a Chip：SoC)芯片领域，特别涉及一种SoC芯片验证的方法和装置。
背景技术
随着SoC芯片设计日趋复杂，验证成为SoC芯片设计过程中关键的环节。一个设计被综合前，首先要进行逻辑功能验证，以确保模块或芯片的功能正确性。通常的功能验证主要采用自底向上的验证策略，可分为模块级验证和系统级验证两个阶段。
传统验证方法大多是在信号级的接口上直接与待验证SoC芯片进行通信，即用激励直接驱动SoC芯片的引脚，通过检查接口信号的值和变化来达到验证设计功能的目的。这种方法的抽象层次较低，验证平台的开发与SoC芯片的接口协议紧密相关，使得验证平台的重用性较差。
参考验证方法(Reference Verification Methodology，RVM)/验证方法手册(Verification Methodology Manual，VMM)的出现提高了SoC芯片验证平台的重用性。
RVM/VMM将SoC芯片验证平台的抽象层次提高到事务级，而且构建层次化的结构，层与层之间具有一定的独立性，改变底层并不会影响上层，从而做到一个验证平台可以验证多个不同的SoC芯片。
所谓事务(Transaction)是指设计对象与事务处理器(Transactor)之间通过接口所做的一次数据传输。从硬件的角度来看，事务可看成作用在一个特定接口上的一组信号的集合单元。事务具有3个要素：起始时间、终止时间，以及所有与这个事务相关的信息。
RVM/VMM能够让用户除了可以在信号/引脚级上进行验证，还可以在事务级上进行验证，从而提高了设计生产率。
RVM/VMM能把验证的步骤分层进行，将验证工作提高到更高的抽象层次，即事务层。层次化的验证方法使得用户只需关心SoC芯片的输入/输出接口，而不必关心SoC芯片内部的具体实现。用户可以搭建出具有随机测试、自动检错核对、功能覆盖等功能的层次化验证平台。这类验证平台包含很多参考模块，每个模型可完成不同的功能。
如图1所示，现有技术SoC芯片验证系统的结构示意图中，基于RVM/VMM的验证平台分成5层，每层完成独立的功能，层与层通过接口互相连接。
信号层提供验证平台与SoC芯片的信号级连接。验证平台通过信号层将上层产生的激励驱动到SoC芯片中。具体实现时，需要定义验证平台与SoC芯片连接的虚端口，当SoC芯片的接口改变时，只需要修改验证平台虚端口中的信号，上层模块不需要修改，方便整个验证平台的重用。
命令层将信号层的信号抽象为事务，给高层提供SoC芯片的接口与事务的转换。命令层主要包括驱动器和监视器，与上层模块通过事务级通道连接，与下层模块通过虚端口连接。驱动器完成对SoC芯片激励的驱动。监视器检测SoC芯片的输出，将输出反馈给上层模块。
功能层模拟SoC芯片的基本行为，将SoC芯片的行为抽象为更高一级的事务。功能层中包括两个事务处理器和自动比较模块。其中一个事务处理器根据SoC芯片所遵循的协议将上层产生的事务进行处理，经过事务处理器处理的事务通过事务级通道传给下层。另一个事务处理器将SoC芯片处理之后的数据传输给自动比较模块。自动比较模块用于对比事务经过SoC芯片处理之后是否符合协议的要求，通常用于检查SoC芯片传输数据的正确性。
激励产生层用于产生对SoC芯片的激励事务。这一层包括产生器，用于产生一系列的事务对象，通过事务级通道传输给下层。RVM/VMM支持两种产生器：原子(Atomic)产生器，用于产生一组相似的事务对象；情景(Scenario)产生器，用于产生顺序可控制的事务对象。
测试层用于对SoC芯片的逻辑功能进行验证。这一层主要是用户为了验证SoC芯片的逻辑功能而编写的不同测试例，在测试例中可以对各个模块的限制条件进行修改。通过对不同测试例运行结果的统计，可以查看SoC芯片的功能覆盖率，只有功能覆盖率达到一定要求，才能够认为该SoC芯片通过验证。
由于目前的SoC芯片内部十分复杂，并且可以完成多种功能，所以在进行检测时，只能选择一部分功能进行验证。验证结束后，选择另一部分功能进行验证。
由于进行验证时，将整个验证系统进行整体编写，如果想要对该SoC芯片的其他功能进行验证，必须根据需要验证的功能重新编写测试例，并对验证系统内每一层的模块进行重新编译，而每次编译都需要花费大量时间。
综上所述，现有技术中对同一个SoC芯片不同功能进行验证时，测试系统构建复杂，需要较长时间，重用性较差，维护困难，并且每次验证都需要重新编译，增加了验证的难度。
发明内容
本发明实施例提供一种SoC芯片验证的方法和装置，用以解决现有技术中存在的对同一个SoC芯片不同功能进行验证时，每次验证都需要重新编译，增加了随机向量产生和控制的难度的问题。
本发明实施例提供一种SoC芯片验证的方法和装置，还进一步解决了测试系统构建复杂，构建时间长，重用性较差，维护困难的问题。
本发明实施例提供的一种片上系统SoC芯片验证的方法，设定SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件，该方法包括：
根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；
根据所述基本信息、确定的所述模块的所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；
根据所述随机测试向量，对所述SoC芯片进行验证。
本发明实施例提供的一种SoC芯片验证的装置包括：
配置模块，用于保存SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件；
配置调度模块，用于根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块，将所述配置模块保存的所述基本信息以及确定的模块的约束条件发送给随机激励产生模块；
随机激励产生模块，用于根据所述基本信息、所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；
验证模块，用于根据所述随机测试向量，对所述SoC芯片进行验证。
本发明实施例设定SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件；根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；根据所述基本信息、确定的所述模块的所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；根据所述随机测试向量，对所述SoC芯片进行验证，从而减少构建验证系统的复杂度和维护难度，增强验证部件的重用性，降低验证难度，节省时间。
附图说明
图1为现有技术SoC芯片验证系统的结构示意图；
图2为本发明实施例SoC芯片验证的方法流程示意图；
图3A为本发明实施例SoC芯片验证的第一种装置结构示意图；
图3B为本发明实施例SoC芯片验证的第二种装置结构示意图；
图4为本发明实施例随机激励产生模块的功能流程示意图；
图5A为本发明实施例对多个芯片进行验证时的第一比较模块的结构示意图；
图5B为本发明实施例对单个芯片进行验证时的第一比较模块的结构示意图；
图6A为本发明实施例SoC芯片验证的第三种装置结构示意图；
图6B为本发明实施例SoC芯片验证的第四种装置结构示意图；
图7为本发明实施例串行外部设备接口(serial peripheral interface：SPI)芯片验证的结构示意图。
具体实施方式
本发明实施例将待验证的SoC芯片按照模块进行划分，设定SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件，在指令中加入需要验证的SoC芯片的功能所涉及的模块的模块功能数据，根据基本信息、约束条件以及模块功能数据，生成随机测试向量，对SoC芯片进行验证，在下一次测试该芯片的其他功能时，只需要在指令中加入需要验证的SoC芯片的功能所涉及的模块的模块功能数据即可，不需要对整个测试系统进行重新编译，从而减小验证SoC芯片的复杂度和验证的难度，节省了验证SoC芯片的时间。
其中，SoC芯片的基本信息包括但不限于下列信息中的一种或几种：
地址空间分配，模块名称，寄存器数量及读写特性等等。
模块的约束条件是对模块随机化过程提供约束，使得随机产生的结果在合法且感兴趣的范围内。对于有多个模式的SoC芯片来说，子模式之间互相约束，它们的组合必须合法，约束条件把模式组合约束在合法的范围内，这样可以使用简单指令来产生复杂但合法的模式组合。
比如：模块1有100种组合：sub1_0，sub1_1，sub1_2，sub1_3，...sub1_99；
模块2有50种组合：sub2_0，sub2_1，sub2_2，sub2_3，...sub2_49；
这样一共有100×50＝5000种可能的组合，但并不是所有组合都是有效的.
约束条件：当模块2处于sub2_1模式时，模块1只能处于sub1_2或sub1_3。
这种约束是固定的，每次随机化时都需要满足约束条件，因为设定了约束条件，所以编写的指令中可以不必考虑这种约束，使得编写过程得到简化。
下面结合说明书附图对本发明实施例作进一步详细描述。
如图2所示，本发明实施例SoC芯片验证的方法包括下列步骤：
步骤200、设定SoC芯片的配置文件。
其中，该配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件。
在具体实施过程中，可以设定SoC芯片中每个模块的约束条件，也可以根据需要设定部分模块的约束条件。
步骤201、根据收到的指令，确定需要验证的该SoC芯片的功能所涉及的模块。
其中，如果收到的指令为自定义类汇编语言或类C语言指令文件，比如：命令(command，CMD)文件，则步骤201之前还可以进一步包括：
步骤a201、读取收到的指令文件，并将读取的数据进行转换，形成二进制指令文件。
由于指令文件可以通过多种编程语言编写，所以需要对指令文件进行转换，将不同的编程语言转换成统一的格式。
其中，步骤a201之后，步骤201之前还可以进一步包括：
读取所述二进制指令文件，对读取的指令进行译码。
进一步的，如果在处理过程中有中断信号产生，则记录程序指针，停止处理二进制指令文件，并跳转到中断服务程序进行处理，在处理结束后，返回记录的程序指针处继续对所述二进制指令文件进行处理。
如果译码后的数据包括内部处理指令，则根据内部处理指令进行处理，并在处理结束后，继续读取二进制指令文件。
内部处理指令包括但不限于下列指令中的一种或几种：
空闲指令、记录指令、计算指令、跳转指令、I/O操作指令，延时控制等等。
如果译码后的数据包括验证指令(即随机配置指令和随机传输指令)，则执行步骤202。
步骤202、根据设定的SoC芯片的基本信息、确定的模块对应的约束条件以及指令中的模块功能数据，生成随机测试向量。
步骤203、根据生成的随机测试向量，对该SoC芯片进行验证。
其中，如果需要验证的SoC芯片的功能涉及的数据需要根据算法进行运算转换，则步骤203还可以进一步包括：
模拟需要验证的SoC芯片的功能所涉及的模块，根据生成的随机测试向量，得到预估数据。
将生成的随机测试向量发送给SoC芯片，得到实际数据。
将预估数据和实际数据转换成设定格式的数据，进行比较，如果比较结果相同，则验证通过；否则，验证失败。
进一步的，配置文件还包括SoC芯片中的模块的寄存器映像数据，则根据该寄存器映像数据，模拟对应的模块。
由于需要根据实际的SoC芯片中的模块的寄存器映像数据模拟对应的模块，现有技术中需要直接从SoC芯片中获得模块的寄存器映像数据，也就是说每次模拟时，都需要与SoC芯片进行交互。而与SoC芯片是通过系统总线进行传输，这样无疑就增加了系统总线的压力，所以在配置文件中加入模块的寄存器映像数据，可以减小与SoC芯片交互的次数，减轻系统总线的压力。
其中，如果需要验证的SoC芯片的功能涉及的数据不需要根据算法进行运算转换，则步骤203还可以进一步包括：
将随机测试向量发送给SoC芯片；
将该随机测试向量和该SoC芯片输出的数据转换成特定格式的数据，进行比较，如果比较结果相同，则验证通过；否则，验证失败。
本实施例还可以对多个SoC芯片进行顺序验证，验证的方法与单个SoC芯片验证的方法类似，不再赘述。
如图3A所示，本发明实施例SoC芯片验证的第一种装置包括：配置模块10、配置调度模块20、随机激励产生模块30和验证模块40。
配置模块10，与配置调度模块20连接，用于保存SoC芯片的配置文件。
其中，该配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件。
配置调度模块20，与配置模块10和随机激励产生模块30连接，用于根据收到的指令，确定需要验证的SoC芯片的功能所涉及的模块，将配置模块10保存的基本信息以及确定的模块的约束条件发送给随机激励产生模块30。
随机激励产生模块30，与配置调度模块20和验证模块40连接，用于根据指令中的模块功能数据、来自配置调度模块20的基本信息以及约束条件，生成随机测试向量。
其中，随机激励产生模块30还可以进一步包括：接收模块300和生成模块310。
接收模块300，用于接收配置调度模块20发送的基本信息和约束条件。
生成模块310，用于根据指令中的模块功能数据、接收模块300收到来自配置调度模块20的基本信息以及约束条件，生成随机测试向量。
验证模块40，与随机激励产生模块30连接，用于根据随机激励产生模块30生成的随机测试向量，对SoC芯片进行验证。
其中，如果收到的指令为自定义类汇编语言或类C语言指令文件，则本发明实施例SoC芯片验证的第一种装置还可以进一步包括：指令解释模块50。
指令解释模块50，用于读取收到的指令文件，并将读取的数据进行转换，形成二进制指令文件。
在具体实现过程中，如果有其他内容需要添加，可以编写出另一个指令文件发送给指令解释模块50，也可以在上一个指令文件的最后进行添加，而指令解释模块50可以实时的读取指令文件，或周期读取指令文件，或给指令解释模块50一个中断信号，提示读取指令文件。
由于指令文件可以通过多种编程语言编写，所以需要对指令文件进行转换，将不同的编程语言转换成统一的格式。
则随机激励产生模块30还可以进一步包括：第一处理模块320。
第一处理模块320，用于读取指令解释模块50生成的二进制指令文件，对读取的二进制指令文件进行译码。
在具体实施过程中，配置调度模块20可以从随机激励产生模块30获取译码后的二进制指令文件，也可以从指令解释模块50中获得二进制指令文件，并进行译码。
具体的，如果配置调度模块20从随机激励产生模块30获取译码后的二进制指令文件，则随机激励产生模块30还可以进一步包括：第一发送模块330。
第一发送模块330，用于将第一处理模块320译码后的指令发送给配置调度模块20。
则配置调度模块20还可以进一步包括：确定模块200和第一发送模块210。
第一确定模块200，用于根据译码后的二进制指令文件，确定需要验证的SoC芯片的功能所涉及的模块。
第二发送模块210，用于将配置模块10保存的第一确定模块200确定的模块的配置数据，发送给随机激励产生模块30。
如果配置调度模块20从指令解释模块50中获得二进制指令文件，并进行译码，则具体参见图3B。
其中，随机激励产生模块30还可以进一步包括：中断模块340。
中断模块340，用于如果在第一处理模块320处理过程中有中断信号产生，则通知第一处理模块320停止处理二进制指令文件，并跳转到中断服务程序进行处理，在处理结束后，通知第一处理模块320继续处理二进制指令文件。
则第一处理模块320还可以进一步包括：第一指针模块3200和第二指针模块3210。
第一指针模块3200，用于在收到来自中断模块340的停止处理二进制指令文件的通知后，记录当前的程序指针，停止处理二进制指令文件。
第二指针模块3210，用于在收到来自中断模块340的继续处理二进制指令文件的通知后，返回第一指针模块3200记录的程序指针处继续对二进制指令文件进行处理。
在具体实施过程中，随机激励产生模块30根据译码后的数据包括验证指令(即随机配置指令和随机传输指令)，生成生成随机测试向量，根据需要还可以先发送内部处理指令，则随机激励产生模块30还包括：第二处理模块350。
第二处理模块350，用于如果第一处理模块320译码后的数据包括内部处理指令，则根据内部处理指令进行处理，并在处理结束后，通知第一处理模块320继续读取二进制指令文件。
内部处理指令包括但不限于下列指令中的一种或几种：
空闲指令、记录指令、计算指令、跳转指令、I/O操作指令，延时控制等等。
其中，如果需要验证的SoC芯片的功能涉及的数据需要根据算法进行运算转换，则验证模块40还可以进一步包括：第一参考模块400、第一总线驱动模块410、第一监视模块420和第一比较模块430。
第一参考模块400，用于模拟需要验证的SoC芯片的功能所涉及的模块，根据随机激励产生模块30生成的随机测试向量，得到预估数据，将该预估数据转换成设定格式的数据，发送给第一比较模块430。
第一总线驱动模块410，用于根据SoC芯片遵循的协议，将随机激励产生模块30生成的随机测试向量进行转换后发送给SoC芯片。
第一监视模块420，用于抓取SoC芯片生成的实际数据，将实际数据转换成设定格式的数据，发送给第一比较模块。
在本实施例中，如果待验证的SoC芯片的数据只能从系统总线(比如AHB)接口输出，则第一监视模块420为总线监视模块，通过系统总线与SoC芯片连接，具体功能与第一监视模块420相同，不再赘述。
如果验证一个SoC芯片，一般会有一个第一监视模块420，一个总线监视模块。
第一比较模块430，用于对转换后的预估数据和实际数据进行比较，如果比较结果相同，则验证通过；否则，验证失败。
比如：从第一参考模块400来的数据：id＝0，op＝READ，data＝0x12345678；
从第一监视模块420来的数据：id＝0，op＝READ，data＝0x12345679；由于两个数据不同，从而判断验证的SoC芯片异常。
进一步的，配置文件还包括SoC芯片中的模块的寄存器映像数据，则第一参考模块400还可以进一步包括：第一模块4000和第二模块4010。
第一模块4000，用于从配置模块10中查找需要模拟的模块对应的寄存器映像数据。
第二模块4010，用于根据第一模块4000查找到的寄存器映像数据，模拟对应的模块。
由于需要根据实际的SoC芯片中的模块的寄存器映像数据模拟对应的模块，现有技术中需要参考模块400直接从SoC芯片中获得模块的寄存器映像数据，也就是说每次模拟时，参考模块400都需要与SoC芯片进行交互。而参考模块400与SoC芯片是通过系统总线进行传输，这样无疑就增加了系统总线的压力。
保存寄存器映像数据，使得参考模块400可以不必再通过系统总线进行读取.可以减小参考模块400与SoC芯片交互的次数，减轻系统总线的压力，在寄存器的数据发生变化时还可以发出告知信息，以便参考模块400作出相应修改。
其中，如果需要验证的SoC芯片的功能涉及的数据不需要根据算法进行运算转换，则验证模块40还可以进一步包括：第二参考模块440、第二总线驱动模块450、第二监视模块460和第二比较模块470。
第二参考模块440，用于将随机激励产生模块30产生的随机测试向量转换成特定格式的数据，发送给第二比较模块470。
第二总线驱动模块450，用于根据SoC芯片所遵循的协议，将随机测试向量转进行转换后发送给该SoC芯片。
第二监视模块460，用于抓取SoC芯片生成的实际数据，将实际数据转换成设定格式的数据，发送给第二比较模块460。
在本实施例中，如果待验证的SoC芯片的数据只能从系统总线接口输出，则第二监视模块460为总线监视模块，通过系统总线与SoC芯片连接，具体功能与第二监视模块460相同，不再赘述。
如果验证一个SoC芯片，一般会有一个第二监视模块460，一个总线监视模块。
第二比较模块470，用于对第二参考模块440和第二监视模块460发送的转换后的数据，进行比较，如果比较结果相同，则验证通过；否则，验证失败。
本实施例还可以对多个SoC芯片进行顺序验证，验证的方法与单个SoC芯片验证的方法类似，不再赘述。
图3B与图3A的区别在于配置调度模块20不是从随机激励产生模块30获取译码后的二进制指令文件，而是从指令解释模块50中获得二进制指令文件进行译码，则配置调度模块20还可以进一步包括：译码模块220、第二确定模块230和第三发送模块240。
译码模块220，用于读取指令解释模块50形成的二进制指令文件，对读取的二进制指令文件进行译码。
第二确定模块230，用于根据译码模块220译码后的指令，确定需要验证的SoC芯片的功能所涉及的模块。
第三发送模块240，用于将配置模块10保存的第二确定模块230确定的模块的配置数据，发送给随机激励产生模块30。
如图4所示，本发明实施例随机激励产生模块的功能流程示意图包括：
步骤400、随机激励产生模块读取指令解释模块转换后的二进制指令文件。
步骤401、随机激励产生模块对读取的指令文件进行译码，查看译码后的数据是否有结束指令，如果有，则结束数据处理，跳出本流程；否则，执行步骤402。
步骤402、随机激励产生模块查看译码后的数据是否有内部处理指令，如果有，则执行步骤403；否则执行步骤404。
步骤403、随机激励产生模块根据内部处理指令进行处理，并在处理结束后，返回步骤400。
步骤404、随机激励产生模块将译码后的指令文件发送给配置调度模块，并接收来自配置调度模块的基本信息以及约束条件。
步骤405、随机激励产生模块根据译码后的模块功能数据、来自配置调度模块的基本信息以及约束条件，生成随机测试向量，将该随机测试向量分别发送给总线驱动模块和参考模块，并返回步骤400。
其中，如果步骤401～步骤404之间有中断信号产生，则随机激励产生模块记录程序指针，停止当前正在处理的数据，并跳转到中断服务程序进行处理，在处理结束后，返回记录的程序指针处继续处理对应的数据。
如图5A所示，本发明实施例对多个芯片进行验证时的第一比较模块的结构示意图中，第一比较模块有两个输入端口：从参考模块来的数据输入给比较模块输入1(主设备)端口和从第一监视模块来的数据输入给比较模块输入2(从设备)端口。
在具体实施过程中，也可以交换输入的端口。
如果需要验证多个SoC芯片，则第一比较模块中分别为每一个SoC芯片对应一个比较器。由于数据存放在不同的比较器，在SoC芯片存在错误的情况下，很容易进行定位，而呈现给外界的界面都是统一的，而且一个模块的比较器由于比较数据格式统一，只需要多次例化同一个基类或者从对应的基类扩展即可，只需要极少代码。
这两组输入的数据通过查看地址或器件分配表确定对应的芯片比较器。
分配表根据保存的配置文件自动产生，使用时只需要把配置文件写好并存放入对应的比较器中即可。
需要说明的是，本发明实施例同样适用采用其他比较方式对数据进行比较。
如图5B所示，本发明实施例对单个芯片进行验证时的第一比较模块的结构示意图中，发送给第一比较模块的数据可以分为三类：前缀(包括地址，所属模块名称，数据序号，数据方向等)，信息(包括比较方式，比较公差，数据生成时间等)，比较项(要比较的数据)。当两个数据类的前缀相同时认为两个数据类相匹配，将这两个数据类按信息提供的比较方式进行比较。
如果第一比较模块收到主设备发送的数据，没有收到从设备发送的数据，则主设备发送的数据要暂存到写暂存队列(master-device)中；当第一比较模块收到从设备发送的数据时，可以直接触发一个比较任务，在写暂存队列中查找匹配的项进行比较；
如果没有找到匹配的项，则将从设备发送的数据暂存到写未完成队列(device)中，每次收到主设备发送数据时都会从写未完成队列中查找一次；
如果找到匹配的项，根据比较结果增加成功/失败计数器的值，同时将匹配的数据从队列中删除。
如果第一比较模块收到从设备发送的数据，没有收到主设备发送的数据，则将从设备发送的数据暂存到读暂存队列(device-master)中；当第一比较模块收到主设备发送的数据时，可以直接触发一个比较任务，在读暂存队列中查找匹配的项进行比较；
如果没有找到匹配的项，则将主设备发送的数据暂存到读未完成队列(master)中，每次收到从设备发送的数据都会从读未完成队列中查找一次；
如果找到匹配的项，根据比较结果增加成功/失败计数器的值，同时将匹配的数据从队列中删除。
当主设备或从设备存在故障时，未完成队列中的数据将不能从暂存队列中找到匹配项。通过监视未完成队列中的数据生存时间可以检测到这种情况，从而可以采取对应的操作，如发出错误警告，停止模拟等等。
在具体实现过程中，第一参考模块400和第二参考模块440可以组合成一个参考模块；第一总线驱动模块410和第二总线驱动模块450可以组合成一个总线驱动器；第一监视模块420和第二监视模块460可以合成一个芯片监视器；第一比较模块430和第二比较模块470可以合成一个自动比较器。如图6A所示，本发明实施例SoC芯片验证的第三种装置结构包括：指令解释器S1、随机激励产生器S2、配置调度器S3、配置模块S4、总线驱动器S5、参考模块S6、芯片监视器S7、总线监视器S8和自动比较器S9。
其中，指令解释器S1，用于读取收到的指令文件，并将读取的数据进行转换，形成二进制指令文件。
随机激励产生器S2，用于将指令解释器S1生成的二进制指令文件进行译码，并发送给配置调度器S3，根据二进制指令文件中的模块功能数据、来自配置调度器S3的基本信息以及约束条件，生成随机测试向量，将该随机测试向量分别发送给总线驱动器S5和参考模块S6。
配置调度器S3，用于根据来自随机激励产生器S2的指令文件，确定需要验证的SoC芯片的功能所涉及的模块，将配置模块10中保存的基本信息以及确定的模块的约束条件发送给随机激励产生器S2。
在具体实施过程中，随机激励产生器S2还可以不将译码后二进制指令文件发送给配置调度器S3，由配置调度器S3从指令解释器S1中获取二进制指令文件进行译码。
配置模块S4，用于保存SoC芯片的配置文件。
其中，配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件，以及SoC芯片中的模块的寄存器映像数据。
总线驱动器S5，用于根据SoC芯片遵循的协议，将来自随机激励产生器30的随机测试向量进行转换后，通过系统总线发送给SoC芯片。
参考模块S6，用于根据配置模块S4中的寄存器映像数据，模拟需要验证的SoC芯片的功能所涉及的模块，判断模拟的模块是否需要对涉及的数据根据算法进行运算，如果是，则算法对来自随机激励产生器S2的随机测试向量进行运算，将运算后的数据转换成设定格式的数据发送到自动比较器S9；否则，直接将随机测试向量转换成设定格式的数据发送到自动比较器S9。
芯片监视器S7，用于抓取SoC芯片生成的实际数据，将实际数据转换成设定格式的数据，发送给自动比较器S9。
总线监视器S8，用于在芯片监视器S7不能抓取SoC芯片生成的实际数据时，通过系统总线抓取SoC芯片生成的实际数据，将实际数据转换成设定格式的数据，发送给自动比较器S9。
自动比较器S9，用于将收到的来自参考模块S6的转换后的数据和，收到的来自芯片监视器S7或总线监视器S8的转换后的数据进行比较，如果比较结果相同，则验证通过；否则，验证失败。
如果需要对多个SoC芯片进行顺序验证，则需要预先设定将每个SoC芯片的配置文件。如图6B所示，本发明实施例SoC芯片验证的第四种装置结构示意图中，
由于需要验证多个SoC芯片，所以在配置模块中需要分别存储每个SoC芯片的配置文件，并为每个配置文件分配标识，在指令文件中也有相应的标识，配置调度器根据对应的标识确定当前需要验证哪个SoC芯片；
随机激励产生器生成的随机测试向量中包括指令文件中的标识；
总线驱动器根据标识，将随机测试向量通过系统总线发送给对应的SoC芯片。
下面以SPI芯片为例，对本发明进行说明。
如图7所示，本发明实施例SPI芯片验证的结构示意图中，整个测试环境包括DUT(待验证SoC芯片)和验证平台(testbench，TB)两部分。
DUT包含有AHB bus的一部分，如arbiter，APB bridge。
环境中大部分部件都是可重用的，在加入新模块时，仅需要从基类中扩展并加入少量代码，修改对应的配置文件，参考模块和自动比较器。其他部分则是TB的系统骨架，加入新模块并不需要修改。
验证平台中每个模块都有专用的配置文件，每个模块根据自身的配置文件就可以完成对应的功能。
在本实施例中，验证平台被封装到一个结构体内，该结构体的顶层例化了验证环境的env。
具体的指令文件是支持少数高级语言特性的汇编文件，使用一个简单的编译器编译成ASCII码的指令文件。
配置模块的文件是一个用systemverilog语言编写的模块配置类，包括了模块寄存映像，模块配置约束，以及一些告知事件；
如果一个验证的功能涉及一个模块，则这个传输受这个模块配置约束；
如果一个验证的功能涉及多个模块，则判断一个验证的功能属于哪个模块有两种方法：
通过命名事件，如果一个功能有名字，且名字与其中一个模块的device_name相同，则这个传输属于这个模块；
通过地址范围，如果一个功能的地址落在一个模块的地址范围内。则这个传输属于这个模块。
随机激励产生器的文件是一个用systemverilog语言编写的类，相当于一个CPU的地址产生器，并具有部分指令解释功能；
随机激励产生器通过调用sys_cfg::get_cmd(int function_id，int pc)取得指令并执行以下动作：
计算下一个pc值；
计算寄存器的值；
把寄存器值回写到模块寄存器；
驱动AHB driver等；
等待特定时间(由指令决定)；
查询是否有中断发生，如果有中断发生，则把当前的随机激励产生器的状态推入堆栈，然后进入中断服务程序。直到中断服务程序执行完毕执行出栈，继续原来的程序。
随机激励产生器有三个通道：第一条通道out_chan连接到AHB driver(总线驱动模块)的input channel，用于驱动AHB bus；第二条通道in_chan则连接到AHB driver的output channel，从中取回读取的数据；第三条通道则是可选通道，用于把数据送到参考模块。
配置调度器的文件是一个用systemverilog语言编写的类，从文件中读取指令并进行初步解释，在需要的情况下调度配置文件中受约束的随机数据。指令和数据送到随机激励产生器进行进一步解释，根据情况还可以进行回写。
从上述实施里中可以看出：本发明实施例设定SoC芯片的配置文件，所述配置文件包括SoC芯片的基本信息和SoC芯片中模块的约束条件；根据收到的指令，确定需要验证的所述SoC芯片的功能所涉及的模块；根据所述基本信息、确定的所述模块的所述约束条件以及所述指令中的模块功能数据，生成随机测试向量；根据所述随机测试向量，对所述SoC芯片进行验证，从而减少构建验证系统的复杂度和维护难度，增强验证部件的重用性，降低验证难度，节省时间，并且减少了读写系统总线的次数，提高了验证SoC芯片系统的结构化程度，利于系统开发和维护。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。