具体实施方式
本发明实施例将待验证的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芯片系统的结构化程度,利于系统开发和维护。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。