CN114692539A - 一种soc芯片验证架构并行验证的实现方法 - Google Patents

Abstract

本发明公开了一种SOC芯片验证架构并行验证的实现方法，首先配置验证环境参数，之后选择后仿真、门仿真、FPGA仿真和RTL仿真其中一种仿真类型，脚本文件会自动生成独立命令的运行执行程序和一些独立命名的中间文件，最后脚本会调用独命名的执行程序进行仿真。优点是：该方法支持生成独立命名的CASE仿真输出文件夹以及编译生成独立运行的编译执行文件，各个独立命名的文件在运行时并不会产生冲突，从而达到RTL仿真、门仿真、后仿真、FPGA仿真并行仿真验证目的，加快了仿真时间同时节省了资源。

Description

一种SOC芯片验证架构并行验证的实现方法

技术领域

本发明涉及芯片验证技术领域，尤其涉及一种SOC芯片验证架构并行验证的实现方法。

背景技术

在SOC验证过程中,通常有大量的CASE需要验证及调试分析。通常SOC验证环境只能进行单一测试CASE的仿真，如果进行并行仿真的话，需要完全手动拷贝一份仿真环境，然后再运行仿真。在同一份仿真环境进行二次仿真操作后，前一次仿真的相关的log以及波形文档被覆盖。有些仿真环境能自动实现一些并行验证,但不充分，生成的相关log以及文件保存的不够充分，在多个CASE同时进行仿真时，很容易造成冲突,并不利于多个CASE同时仿真，产生的log文件和文档有前后覆盖的情况,不利于调试前后对比分析。

发明内容

本发明的目的在于提供一种SOC芯片验证架构并行验证的实现方法，从而解决现有技术中存在的前述问题。

为了实现上述目的，本发明采用的技术方案如下：

一种SOC芯片验证架构并行验证的实现方法，包括如下步骤，

S1、配置验证环境参数，包括case名字及仿真类型参数；

S2、判断仿真类型参数选择的是否为后仿真，若是，则生成独立命名的后仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的后仿真执行程序进行仿真；否则，进入步骤S3；

S3、判断仿真类型参数选择的是否为门防真，若是，则生成独立命名的门仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的门仿真执行程序进行防真；否则，进入步骤S4；

S4、判断仿真类型参数选择的是否为FPGA仿真，若是，则生成独立命名的FPGA仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的FPGA仿真执行程序进行防真；否则，进入步骤S5；

S5、判断仿真类型参数选择的是否为RTL仿真，若是，则生成独立命名的RTL仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的RTL仿真执行程序进行防真；否则，配置其他仿真类型参数，流程结束。

优选的，所述验证结构文件包括，

veri子文件夹；包含tb文件夹以及仿真运行目录simdir；

所述tb文件夹中包含case测试例以及common environment；

所述仿真运行目录simdir包括用于存放脚本文件的公共的脚本文件夹、脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件、用于存放仿真执行后生成结果的case仿真输出文件夹和用于存放回归测试后输出结果的回归测试文件夹；

src子文件夹；包含可综合的源代码；

lib子文件夹；包含IP模型和工艺库文件。

优选的，所述tb文件夹中各个模块的文件夹与源代码中模块的名称一一对应。

优选的，所述脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件中包括vcs生成的可编译执行文件；在同一个源代码和CASE不变的情况下，能够通过脚本文件直接调用vcs生成的可编译执行文件，执行仿真。

本发明的有益效果是：1、通过脚本自动化实现了手动拷贝的过程，采用了如图4所示的文件结构，同时在脚本中解决多个仿真CASE并行仿真后不能同时保存所有仿真文件的问题。2、脚本会自动对每个CASE创建分层次的文件结构，在每一个CASE都新建一个文件夹，以及子文件夹，保证每个验证CASE生成的文件及波形文件都有独立的存储空间，防止并行验证CASE时产生冲突，满足调试上的可追溯分析需求，以及为并行验证CASE提供文件存储的条件，提出的验证方法在编译后能够生成独立命名的中间执行文件以及缓存文件，从而为CASE的并行运行创造了条件，加快仿真效率。3、在调试过程中可直接使用中间执行文件进行仿真分析以及结合产生的独立log以及原始编译文件，加快调试分析及验证。

附图说明

图1是本发明实施例中实现方法的流程图；

图2是本发明实施例中验证文件结构的示意图；

图3是本发明实施例中SOC芯片验证架构的示意图；

图4是本发明实施例中验证文件结构的具体实例；

图5是本发明实施例中脚本文件代码示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。

实施例一

如图1所示，本实施例中，提供了一种SOC芯片验证架构并行验证的实现方法，包括如下步骤，

S1、配置验证环境参数，包括case名字及仿真类型参数；

S2、判断仿真类型参数选择的是否为后仿真，若是，则生成独立命名的后仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的后仿真执行程序进行仿真；否则，进入步骤S3；

S3、判断仿真类型参数选择的是否为门防真，若是，则生成独立命名的门仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的门仿真执行程序进行防真；否则，进入步骤S4；

S4、判断仿真类型参数选择的是否为FPGA仿真，若是，则生成独立命名的FPGA仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的FPGA仿真执行程序进行防真；否则，进入步骤S5；

S5、判断仿真类型参数选择的是否为RTL仿真，若是，则生成独立命名的RTL仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的RTL仿真执行程序进行防真；否则，配置其他仿真类型参数，流程结束。

如图2所示，本实施例中，所述验证结构文件包括，

veri子文件夹；包含tb文件夹以及仿真运行目录simdir；

所述tb文件夹中包含case测试例以及common environment；

所述仿真运行目录simdir包括用于存放脚本文件的公共的脚本文件夹、脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件、用于存放仿真执行后生成结果的case仿真输出文件夹和用于存放回归测试后输出结果的回归测试文件夹；

src子文件夹；包含可综合的源代码；

lib子文件夹；包含IP模型和工艺库文件。

本实施例中，实现方法主要是首先配置验证环境参数，之后选择后仿真、门仿真、FPGA仿真和RTL仿真其中一种仿真类型，脚本文件会自动生成独立命令的运行执行程序和一些独立命名的中间文件，最后脚本会调用独命名的执行程序进行仿真。

实现方法主要依赖于SOC芯片验证架构进行实现。如图3所示，SOC芯片验证架构主要包括，

(1)全局仿真定义：sim define，主要是验证环境全局仿真定义(全局的系统切换仿真定义可以固定放在tb_define.v文件中)。

(2)clock gen：时钟产生器，产生时钟给系统和验证slave/master model。

(3)rst gen：复位产生器，产生系统复位给dut或者slave/master model。

(4)dut：design under test(在这里可以指soc系统)。

(5)init_test program：把验证程序放入dut的接口(主要是cpu验证程序的二进制码以及verilog的测试驱动激励)。

(6)slave/master model:从机/主机，系统中接口模块中的验证model(例如uart的slave或者master接口模块)。

(7)monitor 1、2…n检查模块，主要作用是验证进程中对某个模块的功能进行监测(例如监视cpu执行)。

实现方法是在此架构的基础上进行的一个验证方法，在进行仿真的过程中分别使用不同的测试激励进行发送和接收数据。

实施例二

本实施例中，给出一个具体的实例，具体说明SOC芯片验证架构的并行验证实现方法的验证结构文件。

参见图4，veri文件目录包括tb、lib、simdir文件夹。

tb中包含各模块的文件夹[module_name]与源代码中模块名字完全对应。例如源代码中有src/uart，tb新建的文件[module_name]为uart，与之对应uart模块仿真CASE放入其中；uart下面的子目录sti放入c code,transactor中放入verilog相关的测试激励，可操作uart接口进行接收和发送。

lib是一些公共的测试环境需要的文件,比如打印函数，loader，linker文件等代码。

simdir目录结构主要包括如下：

common:仿真中使用的一些公共的文件

logs:其中汇总了包括c code编译之后的log以及vcs仿真后生成的log文件，同时被链接到了simdir文件夹下

fw_[module_name][module_nu]*：是CASE生成的c code的二进制代码及原始文件

t_[module_name]_[module_nu]：是每个CASE仿真后的生成波形文件，生成log，以及pc调试的log文件，报告文件,以及使用到的原始输入，方便调试需求。

simv.[module_name][module_nu].RTL[RTLversion].LIB[LIB version].TB[tbversion]：是vcs生成的可编译执行文件。

regress:回归测试产生的log文件以及相关报告；

(其中*是通配符,logs，fw_[module_name][module_nu]*,crc_t*,regress*,simv.[module_name][module_nu].RTL[RTLversion].LIB[LIBversion].TB[tbversion],t_[module_name]_[module_nu](其中module_name以模块命名的,module_nu以CASE号命名的)是脚本生成的文件夹)

此文件结构能为不同CASE仿真后产生的log、分析文件以及输出的波形提供有独立标识的存储空间，并不会产生文件上的冲突,为并行验证和调试分析的实现提供了基础条件。如果在同一个源代码和CASE不变的情况下,可通过脚本直接调用simv.[module_name][module_nu].RTL[RTL version].LIB[LIB version].TB[tb version]执行仿真，可节省编译时间，有利于调试使用。

通过脚本生成t_[module_name]_[module_nu]文件夹,其子文件夹simv.[module_name][module_nu].RTL[RTL version].LIB[LIB version].TB[tb version].data也是通过脚本生成，vcs仿真后生成的log，coverage log以及其它需要的调试分析log及CASE，通过脚本自动拷贝到simv.[module_name][module_nu].RTL[RTL version].LIB[LIBversion].TB[tb version].data对应的文件夹中。通过这种文件结构，有利于并行验证的构建以及并行验证后的调试分析。

即所述脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件中包括vcs生成的可编译执行文件；在同一个源代码和CASE不变的情况下，能够通过脚本文件直接调用vcs生成的可编译执行文件，执行仿真。

如图5所示，实现方法的脚本具体实例，具体说明SOC芯片验证架构的并行验证实现方法的核心脚本，名为run_esim_vcs，其中包括如下几个部分：

(1)图5中735-743行为不同corner后仿真可执行文件的核心代码。

(2)图5中744-752行为gate仿真编译可执行文件核心脚本代码。

(3)图5中753-762行为fpga仿真编译可执行文件核心脚本代码。

(4)图5中764-768行为rtl仿真编译可执行文件核心脚本代码。

(5)图5中800行为编译后执行脚本代码。

通过vcs中的参数赋值-MDIR＝csrc_$TEST_DIR.$sim_level，以及重定向技术生成-o$SIMV不同执行文件的中间文件，其中($SIMV＝"$SIMV_DIR.$sim_level.$src_ver.$tb_ver"；$SIMV_DIR变量为仿真目录，$sim_level为不同仿真阶段的命名，如rtl,fpga,gate,postmax等,$src_ver为代码版本,$tb_ver为验证CASE版本，可通过脚本传递参数进行验证配置参数),通过这样的方法，并结合验证文件结构可并行编译生成多个可执行文件而不产生冲突，为并行验证提供保证，可在利用此技术方法上，只需要收集所有CASE并切分执行，可快速构建并行回归验证，加快仿真时间，并不需要多次进行复制验证环境工程进行并行仿真CASE,从而达到节省存储资源。

具体执行可通过在不同linux下terminal或者不同执行窗口执行run_esim_vcs脚本.通过传参,如下:./run_esim_vcs–mod_nmtimer–mod_nu001–sim_lvpostmax–nodump即可以执行仿真验证。

(注：./run_esim_vcs–mod_nm timer–mod_nu 001–nodump其它参数可缺省,run_esim_vcs为执行脚本,下面是一些参数的介绍：

--src_ver为source version number[src文件夹版本]

--lib_ver为lib version number[library文件夹版本]

--tb_ver为veri version number[veri文件夹版本]

--sim_lv为区分前后仿真，默认为rtl，可选变量为postmin,postmax

--ucli为调试模式参数，打开这个可直接执行中间执行文件进行仿真

--dump为不生成波形可选项)

可以根据验证需求,传入不同参数，比如,./run_esim_vcs–mod_nm mmu–mod_nu005–sim_lv postmax–nodump构建一个执行单元,与./run_esim_vcs–mod_nmtimer–mod_nu001–sim_lv postmax–nodump在不同执行窗口进行并行验证。此次只是一个简单例子，在回归验证的时候，可以按照这种方式构建执行单元，进行并行验证，从而节省验证时间，如果需要调试的，可不需要重新编译。可执行./run_esim_vcs–mod_nm timer–mod_nu 001–sim_lv postmax–ucli–nodump，即会跳过编译过程，直接执行图5中第800行的脚本代码。

通过采用本发明公开的上述技术方案，得到了如下有益的效果：

本发明提供了一种SOC芯片验证架构的并行验证实现方法，通过脚本自动化实现了手动拷贝的过程，采用了如图4所示的文件结构，同时在脚本中解决多个仿真CASE并行仿真后不能同时保存所有仿真文件的问题。脚本会自动对每个CASE创建分层次的文件结构，在每一个CASE都新建一个文件夹，以及子文件夹，保证每个验证CASE生成的文件及波形文件都有独立的存储空间，防止并行验证CASE时产生冲突，满足调试上的可追溯分析需求，以及为并行验证CASE提供文件存储的条件，提出的验证方法在编译后能够生成独立命名的中间执行文件以及缓存文件，从而为CASE的并行运行创造了条件，加快仿真效率。在调试过程中可直接使用中间执行文件进行仿真分析以及结合产生的独立log以及原始编译文件，加快调试分析及验证。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (4)

1.一种SOC芯片验证架构并行验证的实现方法，其特征在于：包括如下步骤，

S1、配置验证环境参数，包括case名字及仿真类型参数；

S2、判断仿真类型参数选择的是否为后仿真，若是，则生成独立命名的后仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的后仿真执行程序进行仿真；否则，进入步骤S3；

S3、判断仿真类型参数选择的是否为门防真，若是，则生成独立命名的门仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的门仿真执行程序进行防真；否则，进入步骤S4；

S4、判断仿真类型参数选择的是否为FPGA仿真，若是，则生成独立命名的FPGA仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的FPGA仿真执行程序进行防真；否则，进入步骤S5；

S5、判断仿真类型参数选择的是否为RTL仿真，若是，则生成独立命名的RTL仿真执行程序以及缓存空间，验证文件结构中的脚本文件调用独立命名的RTL仿真执行程序进行防真；否则，配置其他仿真类型参数，流程结束。

2.根据权利要求1所述的SOC芯片验证架构并行验证的实现方法，其特征在于：所述验证结构文件包括，

veri子文件夹；包含tb文件夹以及仿真运行目录simdir；

所述tb文件夹中包含case测试例以及common environment；

所述仿真运行目录simdir包括用于存放脚本文件的公共的脚本文件夹、脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件、用于存放仿真执行后生成结果的case仿真输出文件夹和用于存放回归测试后输出结果的回归测试文件夹；

src子文件夹；包含可综合的源代码；

lib子文件夹；包含IP模型和工艺库文件。

3.根据权利要求2所述的SOC芯片验证架构并行验证的实现方法，其特征在于：所述tb文件夹中各个模块的文件夹与源代码中模块的名称一一对应。

4.根据权利要求2所述的SOC芯片验证架构并行验证的实现方法，其特征在于：所述脚本文件生成后可用于仿真执行的case编译后的独立命名的执行文件中包括vcs生成的可编译执行文件；在同一个源代码和CASE不变的情况下，能够通过脚本文件直接调用vcs生成的可编译执行文件，执行仿真。

Images