CN116992804A - 芯片验证的方法及计算设备 - Google Patents

Abstract

本申请提供一种芯片验证的方法及计算设备，应用于芯片验证，涉及芯片仿真技术领域。所述芯片验证的方法包括：执行测试用例仿真流程；保存第一仿真节点；判断是否需要修改配置；若需要修改配置，配置动态配置文件以使用配置接口的方式动态修改仿真配置；以动态修改后的仿真配置执行测试用例仿真流程。利用本申请的方法可通过动态配置进行仿真流程，提高仿真效率。

Description

芯片验证的方法及计算设备

技术领域

本申请涉及芯片仿真技术领域，具体涉及芯片验证的方法及计算设备。

背景技术

随着芯片设计的复杂度不断增加，需要更多的测试用例来验证这些功能，验证仿真的编译时间和仿真时间都在不断增加。当仿真中使用了大量的处理器和存储器，以实现大规模的并行计算和存储时，仿真规模上升到IT/ST（集成测试/系统测试）级别，可能需要数千个处理器和数百个TB的存储器。这种规模的仿真需要使用高效的并行计算和存储技术，仿真成本也非常高，而在门级网表的仿真中，需要更多的计算资源。仿真时间同样如此，一条IT/ST用例仿真可能需要几个小时，门级网表的仿真时间甚至达到好几天。

通常的芯片验证，主要依靠静态配置的方式来实现用例，以UVM验证方法学为例，编写tc(test case：测试用例)，重载配置类的约束；编写配置序列（seq），关联配置类和实现逻辑；对配置类做随机，将随机后的配置通过seq传递到驱动器（driver），通过driver驱动配置接口，完成芯片配置；开始仿真。静态配置每次修改配置后，都需要重新编译，重新仿真。

动态配置可以省掉重新编译的时间，提升仿真的效率。传统的动态的配置比较单一，主要依靠强制改变DUT（Design under Test：测试的设计）信号的方式，来改变部分配置值。

因此，需要一种区别于传统动态配置的方法对芯片进行仿真，解决仿真时间过长的问题。

发明内容

本申请旨在提供一种芯片验证的方法，面对芯片功能不断增加的情况，解决编译时间和仿真时间增加的问题。

根据本申请的一方面，提供一种芯片验证的方法，所述方法包括：

生成测试用例并完成芯片配置之后，执行测试用例仿真流程；

根据预定仿真状态判断是否需要修改配置；

若需要修改配置，暂停仿真，配置动态配置文件以使用配置接口的方式动态修改仿真配置，从而复用中间仿真结果且保证时序；

以动态修改后的仿真配置执行测试用例仿真流程。

根据一些实施例，所述配置动态配置文件以使用配置接口的方式动态修改仿真配置，包括：

根据配置接口时序，生成接口驱动脚本；

根据配置项的关联，生成关联配置函数，所述关联配置函数通过调用所述驱动脚本，实现仿真配置。

根据一些实施例，配置动态配置文件以使用配置接口的方式动态修改仿真配置，还包括：

根据测试用例仿真流程的要求，调用所述关联配置函数和/或所述接口驱动脚本，生成配置项文件。

根据一些实施例，生成所述接口驱动脚本，包括：

使用仿真语句来实现驱动；和/或

使用命令行的仿真语句来实现驱动；和/或

使用脚本语言的程序语句封装驱动；和/或

通过参数传递提供驱动需要的信息。

根据一些实施例，所述生成关联配置函数，包括：

直接生成文件；和/或

使用脚本语言的程序函数封装。

根据一些实施例，针对数据沿采沿或对齐采样，生成所述接口驱动脚本，包括：

使用运行的方式来进行延迟；和/或

错开时钟沿和变化的参数信号；和/或

使用接口连接，并设置合理的接口建立时间和/或保持时间。

根据一些实施例，执行测试用例仿真流程包括：保存第一仿真节点；

所述以动态修改后的仿真配置执行测试用例仿真流程，包括：

若需要回到第一仿真节点，则恢复已保存的第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置重新进行仿真。

根据一些实施例，所述以动态修改后的仿真配置执行测试用例仿真流程，还包括：若不需要回到第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置继续进行仿真。

根据一些实施例，以动态修改后的仿真配置执行测试用例仿真流程，包括：

判断用例配置是否符合预期，如不符合预期，则继续修改配置，重新进行仿真流程。

根据一些实施例，判断用例配置是否符合预期， 包括：

判断是否出现异常告警表示配置错误；和/或

判断配置顺序是否符合预期；和/或

判断模块是否已运行指定的功能；和/或

判断是否完成预期的动作。

根据本申请的另一方面，提供一种计算设备，包括处理器，以及存储器，存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行如上任一项所述的方法。

根据本申请的另一方面，提供一种非瞬时性计算机可读存储介质，其上存储有计算机可读指令，当所述指令被处理器执行时，使得所述处理器执行如上任一项所述的方法。

根据本申请实施例的技术方法，使用配置接口的方式进行动态修改仿真配置，可以做到和静态配置相同的时序控制，保证了仿真的可行性和有效性。通过动态配置的机制，允许在运行时从外部源获取配置信息，而不需要重新编译程序。这样可以提高开发效率和灵活性，使得在开发过程中更容易进行配置更改。本申请基于动态配置的方式，相比静态配置，可以节省编译时间；相比传统强制信号值的方式，由于使用配置接口进行驱动，可以保证和静态配置相同的时序，验证到相同的功能。

根据本申请实施例的使用动态配置的方法，符合芯片时序，可以实现大规模配置。结合仿真工具的断点执行功能，可以保存仿真进度，直接从某个节点开始仿真，节省了到达该节点前的仿真时间，效率更高。

相比传统强制信号值的方式，配置接口信号可以找到时序约束边界，后端很容易收敛时序，进行信号对齐，避免强制信号方式不满足信号间时序关系，引起仿真的X态传递。

根据一些实施例，配合实时波形转储命令，可以随时刷新波形，反映动态配置流程，方便定位问题。

根据本申请实施例的技术方法，相比传统强制信号值的方式，使用配置接口的方式，可以和具体代码实现解耦，和网表综合也解耦，不会受到综合后信号变化的影响。无论代码修改或者重新综合网表，都不影响已写好的动态配置项，保证了配置项的可重用性，并且兼容UVM方法学和静态配置流程，互不冲突。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。

图1示出根据一些实施例芯片仿真的静态配置流程示意图。

图2示出根据一些实施例传统芯片验证的动态配置流程示意图。

图3示出根据示例实施例芯片验证的方法流程图。

图4示出根据示例实施例配置动态配置文件的方法流程图。

图5示出根据示例实施例的仿真过程中使用动态配置的方法流程图。

图6示出根据示例实施例的计算设备的框图。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本申请将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应理解，虽然本文中可能使用术语第一、第二、第三等来描述各种组件，但这些组件不应受这些术语限制。这些术语乃用以区分一组件与另一组件。因此，下文论述的第一组件可称为第二组件而不偏离本申请概念的教示。如本文中所使用，术语“及/或”包括相关联的列出项目中的任一个及一或多者的所有组合。

本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本申请所必须的，因此不能用于限制本申请的保护范围。

针对现有芯片功能的不断优化，芯片的设计越来越复杂，需要验证的功能越来越多，需要使用的验证工具和方法也越来越多。为了提高验证效率，需要探索一种可行性好的方法，缩短芯片验证的时间，提高仿真的效率。为此，本申请提出一种芯片验证的方法。

根据示例实施例，本申请提出了一种芯片验证的方法，此方法可以做到和静态配置相同的时序控制，保证了仿真的有效性；也可以和具体代码实现解耦，不会受到综合后信号变化的影响，保证了配置项的可重用性。

在描述本申请实施例之前，对本申请实施例涉及到的一些术语或概念进行解释说明。

IT（Integration Testing）集成测试，是在单元测试之后的测试阶段，它的目的是测试不同模块之间的交互和集成。集成测试是在单元测试之后进行的。

ST（System Testing）系统测试，是在完成集成测试后进行的测试，它的目的是验证整个系统是否符合需求和规格。系统测试是在模块和子系统集成测试之后进行的。

TCL（Tool Command Language）驱动脚本，是一种解释性脚本语言，TCL脚本可以用于执行各种任务，包括文件操作、系统命令执行、网络通信、文本处理等。

TC（Test Case）测试用例，是一组条件或变量，用于验证软件或系统的一个或多个特定方面的功能是否正常工作。

下面结合附图对本申请的示例实施例进行说明。

图1示出芯片仿真的静态配置流程示意图。

根据一些实施例，静态配置是指使用systemverilog语言在用例或者env组件中编写代码，进行配置，需要先编译为可执行文件，然后再运行该文件，进行仿真。编译后的文件是固定的，如果修改，就需要重新编译。

参见图1，以UVM验证方法学为例，通常的芯片验证，主要依靠静态配置的方式来实现用例。

编写配置类，分析软件或系统的功能需求和规格说明，确定需要测试的功能和场景，编写tc，重载配置类的约束。

编写配置seq（sv），确定需要配置的参数和选项，编写所述配置seq，关联配置类和实现逻辑。

对所述配置类生成随机值，将随机后的配置通过seq传递到driver，通过driver驱动配置接口，完成芯片配置；开始仿真。

模块一般会有数据接口和配置接口，数据接口传输数据，配置接口进行模块控制。配置接口的操作对象一般为寄存器，例如mpi，apb，ahb等。

静态配置每次修改配置后，都需要重新编译，重新仿真。所述静态配置是将配置信息直接嵌入到程序代码中，而不是在运行时动态地从外部源获取。因此，当配置信息发生变化时，必须修改程序代码并重新编译，才能将最新的配置信息嵌入到程序中。

这种重新编译的方法会增加开发和测试的复杂性，特别是对于需要频繁修改配置的情况。为了解决这个问题，提出了动态配置的机制，允许在运行时从外部源获取配置信息，复用中间仿真结果而不需要重新编译程序。这样可以提高开发效率和灵活性，使得在开发过程中更容易进行配置更改。

图2示出根据传统芯片验证的动态配置流程图。

动态配置是指通过仿真工具提供的一些传参接口，可以在执行前述编译的可执行文件时，同步修改一些参数或者信号值，实现仿真中途的随时改动，不需要重新编译。

参见图2，在传统的动态配置中，是通过Verilog的force工具修改要配置的信号。

执行测试用例仿真流程，判断是否需要修改配置，若需要修改所述配置，通过force直接强制改写信号值，重新进行仿真流程。若不需要修改所述配置，执行测试用例仿真流程，结束流程。

force信号值的方式没有时序配合，会在调用时刻直接改写对应的信号值，可能导致DUT行为和通过配置接口产生配置后的行为不同。在force信号值的方式下，类似配置采样、低功耗门控等特性无法被验证到。因此，这种方式有验证遗漏风险和时序问题。

通常强制改变信号值的方式作用于特定信号，多为模块内部信号。如果代码修改，或者在综合成网表时，信号名称发生改变，则必须修改配置force路径；甚至信号直接被综合优化掉了，无法通过强制改变个别信号来实现动态配置的目的。此外，每次重新综合网表时，都需要重新确认信号的变化，效率较低。

根据一些实施例，强制改变信号值是单点功能，只能修改个别信号值，没有时序或者配置流程的配合，无法实现大规模按流程的配置，很难做到从某个节点开始，执行一套全新配置。只能结合静态配置流程，从头开始仿真，修改其中少量配置。如果配置量较大，修改复杂，还是只能修改静态配置，重新编译再进行仿真。

在带时序的网表仿真中，如带有SDF（Standard Delay Format：标准延时格式）文件，每个信号之间的时序关系都是有要求的。通过force直接改写信号值，会导致信号间时序关系不满足，出现时序冲突和X态传递，仿真无法执行。而模块内部信号的时序关系很复杂，且每次综合都会改变，很难处理。

综上所述，采用强制修改信号的方法，具有不可预测性，兼容性和稳定性都存有潜在的问题，只适用于日常调试和测试阶段。

图3示出根据示例实施例芯片验证的方法流程图。

参见图3，根据一些实施例，使用驱动脚本（例如，TCL脚本），通过配置接口进行动态修改仿真配置，可以做到和静态配置相同的时序控制，复用中间仿真结果，保证仿真的可行性和有效性。例如，通过配置接口，产生一次apb接口写操作，改变寄存器值，寄存器值传递给使用该值的模块。这个传递过程是实际的电路，会和网表一样产生时序延迟，然后被该模块用它的时钟采样，得到控制信号值，然后运行该模块内部的逻辑功能。这样的流程是与真实芯片工作流程一致的。而传统直接force信号值，就是只进行了最后一步，前面几步的功能是验证不到的，并且force是一次对信号值所有bit生效，还会有时序对齐等问题。

参见图3，根据示例实施例，在S301，执行测试用例仿真流程。

例如，生成测试用例，重载配置类的约束，生成配置序列，关联配置类和实现逻辑。对配置类做随机，将随机后的配置通过序列传递到驱动器，再通过驱动器驱动配置接口，完成芯片配置，开始执行测试用例仿真。

根据一些实施例，执行测试用例仿真流程包括保存第一仿真节点以用于后续重新进行仿真。例如，保存芯片解复位、完成静态配置的时刻作为初始时刻（第一仿真节点），后续都可从该时刻开始重新仿真。

在S305，判断是否需要修改配置，若是，则转到S307。

根据一些实施例，检测一些特定的条件，判断当前的配置是否合理。如果不合理，可暂停仿真，修改配置。

在S307，配置动态配置文件以使用配置接口的方式动态修改仿真配置。

根据一些实施例，可以根据配置接口时序，生成接口驱动脚本。根据另一些实施例，可以根据配置项的关联，生成关联配置函数，所述关联配置函数通过调用所述驱动脚本，实现仿真配置。另外，还可根据测试用例仿真流程的要求，调用所述关联配置函数和/或所述接口驱动脚本，生成配置项文件。

根据一些实施例，可以在仿真过程中，通过编写TCL脚本，按时序驱动DUT配置接口的方式，来实现动态配置。

在S309，以动态修改后的仿真配置，继续执行测试用例仿真流程。

根据一些实施例，若需要回到第一仿真节点，则恢复已保存的第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置重新进行仿真。

根据另一些实施例，若不需要回到第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置继续进行仿真。

使用配置接口的方式进行动态修改仿真配置，可以做到和静态配置相同的时序控制，复用中间仿真结果，保证了仿真的可行性和有效性。根据示例实施例，所述动态修改仿真配置的方法可以和具体代码实现解耦，和网表综合也解耦，不会受到综合后信号变化的影响，保证了配置项的可重用性，并且兼容UVM方法学和静态配置流程，互不冲突。

图4示出根据示例实施例配置动态配置文件的流程图。

在S401，根据配置接口时序，生成接口驱动脚本。

这里，驱动是指控制RTL的信号，实现接口操作的功能。驱动者是仿真工具和/或脚本，驱动的对象是RTL的接口信号线，驱动的目的是从该接口发起一次有效的访问操作。

接口驱动脚本（例如，TCL脚本）是指具体操作配置的文件，是最底层的控制说明。例如，比如对于apb接口，将asel信号通过仿真工具force改写为1，同时改写addr=4，awrite=0，下一拍force a_enable为1，则可以认为驱动该apb接口，发起了一次apb读操作。

根据示例实施例，可根据DUT的配置接口时序图或者环境驱动器（DRIVER）的时序函数，编写生成配置驱动的TCL脚本。例如，可使用VCS（Verilog Compile Simulator：Verilog编译模拟器）的UCLI（VCS的命令行输入接口）的仿真语句来实现驱动，例如forceabc.vld、run 10ns和stop-posedge等等，但本申请不限于此。根据一些实施例，驱动语句可以使用TCL脚本语言的proc（程序）语句来进行封装，如proc a_interface_set_data()。根据一些实施例，可以通过传参来提供驱动所需的信息，包括但不限于数据、地址等信息。传参有多种方式，例如在cfg.ini文件中setenv para，在环境中直接使用para；或者在定义TCL脚本语言的proc时预留参数接口，例如proc abc{addr data},在调用时就可以使用abc32’h4 32’h55来给addr传参=4，data传参=55。

根据示例实施例，需要考虑数据沿采沿或者数据对齐采样的问题。时序逻辑在仿真时，会在时钟的上升沿的时刻，来将当前时刻的数据作为这一拍的数据来使用。仿真的时候，如果时钟上升沿的时刻与数据变化的时刻相同，则称为沿采沿。此时仿真工具无法判断数据到底是多少，会出现采样错误。对齐采样是指带时序的电路仿真中，同一组信号，比如addr的32个位（bit）信号线，由于路径不同可能时序不同，他们传递到达采样点的时间不同，比如bit31先到，bit25后到。如果在bit31到的时刻采样，则bit25的值是错误的。针对数据沿采沿或对齐采样问题，可以使用的方法包括但不限于：使用运行（run）的方式来进行延迟，使时钟沿与变化的参数信号错开；使用接口（interface）连接，并设置合理的接口建立/保持时间等。

根据一些实施例，驱动结束后可释放（release）信号，从而不影响后续用例中的驱动控制。

根据一些实施例，在驱动结束时，可调用VCS仿真工具提供的系统函数（fsdbDumpflush），立刻转储（dump）波形文件，使波形能够实时反映动态配置的过程。VCS工具在dump波形时，会先将波形放在缓存中，一定间隔才存放到fsdb（Verilog仿真器生成的仿真波形文件格式之一）文件中。打开波形观察时，只能看到fsdb文件的部分。因此，有时仿真已经进行了，但是打开波形看不到对应的操作，此时就需要调用该命令，将缓存中的内容存放到fsdb文件，方便观察实时波形。

在S403，根据配置项的关联，生成关联配置函数。

根据示例实施例，关联配置函数通过调用前述驱动脚本，实现仿真配置。

对于芯片的一些配置，是必须同步配置的。例如，配置b依赖配置a，则认为b和a是关联配置，需要写在一起。该关联配置函数通过调用前述驱动脚本（例如TCL文件），来实现具体的配置。

根据示例实施例，为生成配置项的关联配置函数，可以直接编写生成文件，也可以使用脚本语言TCL的程序(proc)函数封装。例如，使能A模块包括：先配置打开时钟门控，然后配置模块解复位，再配置模块使能。关联配置函数需要保证关联配置的流程符合要求，其中的配置可通过前述驱动脚本来实现。

在S405，根据测试用例仿真流程的要求，生成配置项文件。

针对一个测试的流程中，可能需要配置众多的模块，配置项文件是这一系列配置的集合。通过调用前述关联配置函数和/或接口驱动脚本，可实现整个测试流程的配置。

根据一些实施例，根据仿真意图编写生成配置项，可以直接编写文件，也可以使用TCL脚本语言的proc函数封装。例如，如果仿真需要用到A模块，则先配置使能A模块，然后配置A模块工作在C模式，等等。配置项文件不是必需的。如果配置项十分简单，使用前述关联配置函数文件即可实现。

根据一个实施例，芯片配置接口为APB协议，时钟频率100MHz，下面示例性地描述动态配置文件。

接口驱动脚本：包含写操作proc apb_write_dynamic，在时钟上升沿，延迟1fs，force apb_sel信号为1，force地址和数据和apb_strobe信号有效；run 10ns，force apb_enable为1；在每个时钟上升沿判断，apb_ready是否有效，如果有效，则run 10ns，forceapb_sel、apb_enable为0，run 10ns；fsdbdumpflush，释放所有信号，函数结束。如果apb_ready无效，则继续等待。

关联配置函数：proc cfg_module：包含写地址A，值U；写地址B，值V；写地址C，值X。其中写操作由前述apb_write_dynamic实现。仿真中发现配置效果不符合预期，需要修改地址B的值为Y。修改关联配置函数，包含写地址A，值U；写地址B，值Y；写地址C，值X。在仿真过程中，参见后面的描述，回到芯片解复位时刻重新仿真，通过命令行调用修改后的配置关联函数cfg_module，实现配置的动态修改，完成仿真。

根据示例实施例，在验证一复杂流程时，在前述接口驱动脚本和关联配置函数基础上，还可编写配置项文件。

配置项文件file1：包含cfg_module（H），cfg_module（J），cfg_module（K）。其中，cfg_module为已经调试好的有效配置函数。在仿真过程中，回到芯片解复位时刻，通过source调用file1，执行完cfg_module（J）后发现，需要先配置模块L，再配置模块K。此时编写配置项文件file2：包含cfg_module（L），cfg_module（K）。通过source的方式调用file2，进行动态修改配置流程，继续仿真。

图5示出根据示例实施例的仿真过程中使用动态配置的方法流程图。

在S501，执行测试用例仿真流程。

仿真开始执行。

在S503，保存第一仿真节点。

保存第一仿真节点，所述第一仿真节点作为一个特定的仿真节点，用于修改配置后从该节点重新进行仿真。本申请对第一节点没有特别限制。例如，保存芯片解复位、完成静态配置的时刻作为第一节点，后续都可从该节点开始重新仿真。芯片解复位是指解除芯片复位信号的操作，只有解除复位后，芯片才开始工作。这里是指将解除了芯片复位、并且完成静态配置的时刻的仿真状态保存下来，之后都可以从该状态时刻点来重启仿真。

在S504，从保存的第一仿真节点继续仿真。

在S505，根据预定仿真状态判断是否需要修改配置。

根据一些实施例，检测一些特定的条件，判断当前的配置是否合理，可以人工监测调试，也可以通过脚本监测。例如，实时监控fifo的满标志，如果fifo出现满状态，代表fifo设置不合理，暂停仿真。

若判断需要修改配置项，则转到S507；若判断不需要修改配置项，则转到S513。

在S507，配置动态配置文件，以使用配置接口的方式动态修改仿真配置。

根据一些实施例，如前面描述的，配置动态配置文件可以从前述生成的接口驱动脚本、关联配置函数和/或配置项文件修改得到。

根据一些实施例，通过修改配置属性配置动态配置文件。

根据一些实施例，前述修改包括但不限于修改其中不合理的配置项、添加配置内容、或者修改配置项以验证新的一组功能。根据一些实施例，如果进行一项新的验证，动态配置文件可以提前准备好。

在S508，判断是否需要回到第一仿真节点。

根据仿真流程判断是否需要在特定时刻（例如，第一节点）重新仿真。如果需要，则转到S509；否则转到S511。

在S509，恢复保存的第一仿真节点，从而后续从该时刻开始重新仿真。

在S510，调用修改后的动态配置文件，进入S504，从保存的第一仿真节点以动态修改后的仿真配置重新进行仿真。

在S511，调用修改后的动态配置文件，进入S513，以动态修改后的仿真配置继续进行仿真。

根据一些实施例，可以通过在命令行输入单个驱动函数和/或关联配置函数的方式逐个调用，也可以直接执行（例如，source指令方式）写好的配置项文件进行调用。

在S513，继续执行测试用例仿真流程。

以动态配置的内容为基础，继续进行用例仿真。

在S515，判断用例配置是否符合预期，确定所有验证是否都已执行结束。

根据一些实施例，判断用例配置是否符合预期，包括但不限于判断：是否出现异常告警表示配置错误、配置顺序是否符合预期、模块是否运行了指定的功能、是否完成了预期的动作、是否可以开始下一套配置的验证等。

根据一些实施例，若配置错误则回到S505进行修改配置，通过动态配置方式重新仿真；如果配置正确仿真错误则进行debug；如果配置正确仿真也正确，则转到S517，结束当前用例仿真流程，然后可以加载新的一套配置项，通过动态配置方式验证下一项功能。

图6示出根据本发明示例实施例的计算设备的框图。

如图6所示，计算设备30包括处理器12和存储器14。计算设备30还可以包括总线22、网络接口16以及I/O接口18。处理器12、存储器14、网络接口16以及I/O接口18可以通过总线22相互通信。

处理器12可以包括一个或多个通用CPU(Central Processing Unit，处理器)、微处理器、或专用集成电路等，用于执行相关程序指令。根据一些实施例，计算设备30还可包括为处理器12进行加速的高性能显示适配器（GPU）20。

存储器14可以包括易失性存储器形式的机器系统可读介质，例如随机存取存储器（RAM）、只读存储器（ROM）和/或高速缓存存储器。存储器14用于存储包含指令的一个或多个程序以及数据。处理器12可读取存储在存储器14中的指令以执行上述根据本发明实施例的方法。

计算设备30也可以通过网络接口16与一个或者多个网络通信。该网络接口16可以是无线网络接口。

总线22可以为包括地址总线、数据总线、控制总线等。总线22提供了各组件之间交换信息的通路。

需要说明的是，在具体实施过程中，计算设备30还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。计算机可读存储介质可以包括但不限于任何类型的盘，包括软盘、光盘、DVD、CD-ROM、微型驱动器以及磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪速存储器设备、磁卡或光卡、纳米系统（包括分子存储器IC）、网络存储设备、云存储设备，或适合于存储指令和/或数据的任何类型的媒介或设备。

本发明实施例还提供一种计算机程序产品，该计算机程序产品包括存储计算机程序的非瞬时性计算机可读存储介质，该计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种方法的部分或全部步骤。

本领域的技术人员可以清楚地了解到本申请的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件，其中硬件例如可以是现场可编程门阵列、集成电路等。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些服务接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本申请各个实施例方法的全部或部分步骤。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

以上具体地展示和描述了本申请的示例性实施例。应可理解的是，本申请不限于这里描述的详细结构、设置方式或实现方法；相反，本申请意图涵盖包含在所附条款的精神和范围内的各种修改和等效设置。

Claims (10)

1.一种芯片验证的方法，其特征在于，所述方法包括：

生成测试用例并完成芯片配置之后，执行测试用例仿真流程；

根据预定仿真状态判断是否需要修改配置；

若需要修改配置，则暂停仿真，配置动态配置文件以使用配置接口的方式动态修改仿真配置，从而复用中间仿真结果且保证时序；

以动态修改后的仿真配置执行测试用例仿真流程。

2.根据权利要求1所述的方法，其特征在于，所述配置动态配置文件以使用配置接口的方式动态修改仿真配置，包括：

根据配置接口时序，生成接口驱动脚本；

根据配置项的关联，生成关联配置函数，所述关联配置函数通过调用所述驱动脚本，实现仿真配置。

3.根据权利要求2所述的方法，其特征在于，配置动态配置文件以使用配置接口的方式动态修改仿真配置，还包括：

根据测试用例仿真流程的要求，调用所述关联配置函数和/或所述接口驱动脚本，生成配置项文件。

4.根据权利要求3所述的方法，其特征在于，生成所述接口驱动脚本，包括：

使用仿真语句来实现驱动；和/或

使用命令行的仿真语句来实现驱动；和/或

使用脚本语言的程序语句封装驱动；和/或

通过参数传递提供驱动需要的信息。

5.根据权利要求4所述的方法，其特征在于，所述生成关联配置函数，包括：

直接生成文件；和/或

使用脚本语言的程序函数封装。

6.根据权利要求1所述的方法，其特征在于，

执行测试用例仿真流程包括：保存第一仿真节点；

所述以动态修改后的仿真配置执行测试用例仿真流程，包括：

若需要回到第一仿真节点，则恢复已保存的第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置重新进行仿真。

7.根据权利要求6所述的方法，其特征在于，所述以动态修改后的仿真配置执行测试用例仿真流程，还包括：

若不需要回到第一仿真节点，调用修改后的动态配置文件，以动态修改后的仿真配置继续进行仿真。

8.根据权利要求7所述的方法，其特征在于，以动态修改后的仿真配置执行测试用例仿真流程，包括：

判断用例配置是否符合预期，如不符合预期，则继续修改配置，重新进行仿真流程。

9.根据权利要求8所述的方法，其特征在于，判断用例配置是否符合预期， 包括：

判断是否出现异常告警表示配置错误；和/或

判断配置顺序是否符合预期；和/或

判断模块是否已运行指定的功能；和/或

判断是否完成预期的动作。

10.一种计算设备，其特征在于，包括：

处理器；以及

存储器，存储有计算机程序，当所述计算机程序被所述处理器执行时，实现如权利要求1-9中任一项所述的方法。