CN117709256A - 一种验证信息的生成方法、装置、电子设备及存储介质 - Google Patents
一种验证信息的生成方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN117709256A CN117709256A CN202410160054.8A CN202410160054A CN117709256A CN 117709256 A CN117709256 A CN 117709256A CN 202410160054 A CN202410160054 A CN 202410160054A CN 117709256 A CN117709256 A CN 117709256A
- Authority
- CN
- China
- Prior art keywords
- code
- information
- verified
- instance
- command
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012795 verification Methods 0.000 title claims abstract description 125
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000003860 storage Methods 0.000 title claims description 24
- 238000012360 testing method Methods 0.000 claims abstract description 130
- 230000006870 function Effects 0.000 claims description 29
- 238000012545 processing Methods 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 16
- 238000013507 mapping Methods 0.000 claims description 15
- 238000005538 encapsulation Methods 0.000 claims description 9
- 238000013101 initial test Methods 0.000 claims description 6
- 238000004458 analytical method Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 15
- 238000013461 design Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 11
- 230000014509 gene expression Effects 0.000 description 7
- 238000011161 development Methods 0.000 description 6
- 238000007689 inspection Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 238000004088 simulation Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000012942 design verification Methods 0.000 description 2
- 239000003607 modifier Substances 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Landscapes
- Tests Of Electronic Circuits (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
本申请公开一种验证信息的生成方法、装置、电子设备及存储介质，属于硬件测试技术领域，该方法中，获取待验证代码和验证配置文件，待验证代码用于描述待开发电路的电路信息，解析验证配置文件，得到验证配置信息，验证配置信息包括待验证代码的例化信息和用例描述信息，根据待验证代码的例化信息，生成待验证代码的实例，进而基于用例描述信息、待验证代码的实例和参考代码的实例，生成多个测试用例，参考代码用于描述具有指定功能的目标电路的电路信息，多个测试用例用于验证目标电路和待开发电路的功能等效性，这样，可自动生成电路等效性验证所需的测试用例，因此，可大幅提升验证信息的生成速度，进而提升验证效率。
Description
技术领域
本申请涉及硬件测试技术领域，尤其涉及一种验证信息的生成方法、装置、电子设备及存储介质。
背景技术
一般地，在芯片开发流程中，先利用高级语言如C ++进行芯片建模，得到建模代码如cmodel，之后，再利用逻辑设计工具如Verilog等开发，得到逻辑代码如寄存器传输级（Register Transfer Level，RTL）代码。
与逻辑代码开发同步进行的还有功能仿真，目的是保证逻辑代码的行为与建模代码一致，为此，验证人员需要以建模代码为参考代码、以RTL代码为待验证代码，手动编写大量的测试用例（Test Case）来验证待验证代码和参考代码的等效性，这样，代码编程耗时，验证效率也比较低。
发明内容
本申请实施例提供一种验证信息的生成方法、装置、电子设备及存储介质，用以解决相关技术中验证人员需要手动编写大量的测试用例而导致的验证信息的生成速度慢、验证效率低的问题。
第一方面，本申请实施例提供一种验证信息的生成方法，包括：
获取待验证代码和验证配置文件，所述待验证代码用于描述待开发电路的电路信息，
解析所述验证配置文件，得到验证配置信息，所述验证配置信息至少包括用例描述信息和所述待验证代码的例化信息；
根据所述待验证代码的例化信息，生成所述待验证代码的实例；
基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，所述参考代码用于描述具有指定功能的目标电路的电路信息，所述多个测试用例用于验证所述目标电路和所述待开发电路的功能等效性。
在一些实施例中，所述参考代码是建模代码时，所述待验证代码是建模代码或者逻辑代码；所述参考代码是逻辑代码时，所述待验证代码是逻辑代码。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是建模代码时，所述代码的例化信息包括顶层模块名、所述参考代码和所述待验证代码间输入输出映射关系、例化时所需的文件列表，以及所述代码的编译信息；
根据以下步骤生成所述代码的实例：
利用所述顶层模块名和所述映射关系，生成所述代码的封装文件；
利用所述封装文件、所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是逻辑代码时，所述代码的例化信息包括例化时所需的文件列表和所述代码的编译信息；
根据以下步骤生成所述代码的实例：
利用所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述用例描述信息存储在多张表中，不同表中用例描述信息的等效验证目的不同。
在一些实施例中，所述用例描述信息包括多条命令配置数据，基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，包括：
对每张表进行遍历；
对遍历到的表，逐条读取所述表中的命令配置数据；
基于所述命令配置数据和目标实例，生成一条命令，所述目标实例包括所述待验证代码的实例和所述参考代码的实例中的至少一个；
当遍历完所述表中的各命令配置数据时，基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例。
在一些实施例中，基于所述命令配置数据和目标实例，生成一条命令，包括：
若所述命令配置数据的类型是用于约束指定电路输入的assume类型，则针对所述指定电路对应的实例生成一条假设assume命令，所述指定电路是所述目标电路和所述待开发电路中的任一或组合；
若所述命令配置数据的类型是用于描述所述目标电路和所述待开发电路的等效结果的数据处理方式的引理lemma类型或内部引理inter_lemma类型，则针对所述待验证代码的实例和所述参考代码的实例生成一条lemma命令。
在一些实施例中，每条命令配置数据有作用域，所述作用域用于指明所述命令配置数据对应的命令应用于局部用例还是全局用例；
基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例，包括：
对作用域是相同测试用例的命令配置数据对应的命令进行组合，得到初始的多个测试用例；
基于每条inter_lemma类型的命令配置数据对应的lemma命令，生成一个新的测试用例，并将表示所述lemma命令已验证成功的assume命令添加到所述命令配置数据的作用域所指示的初始测试用例中。
在一些实施例中，还包括：
针对有模糊匹配规则的指定测试用例，若确定存在与所述模糊匹配规则匹配的目标测试用例，则将所述指定测试用例中的命令添加到所述目标测试用例中。
在一些实施例中，在基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例之前，还包括：
对所述用例描述信息进行约束检查；
对不符合要求的描述进行提示处理。
第二方面，本申请实施例提供一种验证信息的生成装置，包括：
获取模块，用于获取待验证代码和验证配置文件，所述待验证代码用于描述待开发电路的电路信息，
解析模块，用于解析所述验证配置文件，得到验证配置信息，所述验证配置信息至少包括用例描述信息和待验证代码的例化信息；
例化模块，用于根据所述待验证代码的例化信息，生成所述待验证代码的实例；
用例生成模块，用于基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，所述参考代码用于描述具有指定功能的目标电路的电路信息，所述多个测试用例用于验证所述目标电路和所述待开发电路的功能等效性。
在一些实施例中，所述参考代码是建模代码时所述待验证代码是建模代码或者逻辑代码；所述参考代码是逻辑代码时，所述待验证代码是逻辑代码。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是建模代码时，所述代码的例化信息包括顶层模块名、所述参考代码和所述待验证代码间输入输出映射关系、例化时所需的文件列表，以及所述代码的编译信息；
例化模块，具体用于根据以下步骤生成所述代码的实例：
利用所述顶层模块名和所述映射关系，生成所述代码的封装文件；
利用所述封装文件、所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是逻辑代码时，所述代码的例化信息包括例化时所需的文件列表和所述代码的编译信息；
例化模块，具体根据以下步骤生成所述代码的实例：
利用所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述用例描述信息存储在多张表中，不同表中用例描述信息的等效验证目的不同。
在一些实施例中，所述用例描述信息包括多条命令配置数据，用例生成模块具体用于：
对每张表进行遍历；
对遍历到的表，逐条读取所述表中的命令配置数据；
基于所述命令配置数据和目标实例，生成一条命令，所述目标实例包括所述待验证代码的实例和所述参考代码的实例中的至少一个；
当遍历完所述表中的各命令配置数据时，基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例。
在一些实施例中，用例生成模块具体用于：
若所述命令配置数据的类型是用于约束指定电路输入的assume类型，则针对所述指定电路对应的实例生成一条假设assume命令，所述指定电路是所述目标电路和所述待开发电路中的任一或组合；
若所述命令配置数据的类型是用于描述所述目标电路和所述待开发电路的等效结果的数据处理方式的引理lemma类型或内部引理inter_lemma类型，则针对所述待验证代码的实例和所述参考代码的实例生成一条lemma命令。
在一些实施例中，每条命令配置数据有作用域，所述作用域用于指明所述命令配置数据对应的命令应用于局部用例还是全局用例；
用例生成模块，具体用于：
对作用域是相同测试用例的命令配置数据对应的assume命令和/或lemma命令进行组合，得到初始的多个测试用例；
基于每条inter_lemma类型的命令配置数据对应的lemma命令，生成一个新的测试用例，并将表示所述lemma命令已验证成功的assume命令添加到所述命令配置数据的作用域所指示的初始测试用例中。
在一些实施例中，用例生成模块，还用于：
针对有模糊匹配规则的指定测试用例，若确定存在与所述模糊匹配规则匹配的目标测试用例，则将所述指定测试用例中的命令添加到所述目标测试用例中。
在一些实施例中，还包括检查模块，用于：
在基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例之前， 对所述用例描述信息进行约束检查；
对不符合要求的描述进行提示处理。
第三方面，本申请实施例提供一种电子设备，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：
存储器存储有可被至少一个处理器执行的计算机程序，该计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述验证信息的生成方法。
第四方面，本申请实施例提供一种存储介质，当所述存储介质中的计算机程序由电子设备的处理器执行时，所述电子设备能够执行上述验证信息的生成方法。
本申请实施例中，获取待验证代码和验证配置文件，待验证代码用于描述待开发电路的电路信息，解析验证配置文件，得到验证配置信息，验证配置信息至少包括用例描述信息和待验证代码的例化信息，然后，根据待验证代码的例化信息，生成待验证代码的实例，进而基于用例描述信息、待验证代码的实例和参考代码的实例，生成多个测试用例，参考代码用于描述具有指定功能的目标电路的电路信息，多个测试用例用于验证目标电路和待开发电路的功能等效性，这样，可自动生成电路等效性验证所需的测试用例，因此，可大幅提升验证信息的生成速度，进而提升验证效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的一种验证信息的生成方法的流程图；
图2为本申请实施例提供的一种验证信息的生成过程示意图；
图3为本申请实施例提供的一种Excel cfg的文件框架示意图；
图4为本申请实施例提供的一种测试用例的生成方法的流程图；
图5为本申请实施例提供的一条命令配置数据；
图6为本申请实施例提供的一条inter_lemma类型的命令配置数据；
图7为本申请实施例提供的又一条inter_lemma类型的命令配置数据；
图8为本申请实施例提供的一个表的示意图；
图9为本申请实施例提供的一种验证信息的生成装置的结构示意图；
图10为本申请实施例提供的一种用于实现验证信息的生成方法的电子设备的硬件结构示意图。
具体实施方式
为了解决相关技术中验证人员需要手动编写大量的测试用例而导致验证信息的生成速度慢、验证效率低的问题，本申请实施例提供了一种验证信息的生成方法、装置、电子设备及存储介质。
以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
为了便于理解本申请，本申请涉及的技术术语中：
数据通路验证（Data Path Validation，DPV），一种数据算法功能验证工具。
C ++到RTL的高级等价（High-level Equivalence C++ to RTL，Hector）。
YAML，一种可读的数据序列化语言，通常用于编写配置信息。
工具命令语言（Tool Command Language，TCL），一种脚本语言，被广泛应用于电子设计自动化（Electronic Design Automation，EDA）工具的自动化流程中。
以芯片开发为例，在芯片开发流程中，当明确芯片的架构之后，会对芯片进行建模（Modeling），芯片建模是用一种高级语言如C++对芯片的功能进行描述，芯片架构设计阶段的输出包括架构设计文档和cmodel代码，架构设计文档用于描述芯片的工作原理，cmodel代码则定义了芯片的输入输出行为。之后，进入芯片的逻辑设计阶段，逻辑设计阶段得到芯片的逻辑代码，常用的逻辑设计工具如Verilog等，这些逻辑设计工具输出的代码称为RTL代码。
与逻辑设计同步进行的是功能仿真，目的是保证RTL代码与cmodel代码的功能一致，为此验证人员需要根据RTL代码的功能手动编写大量测试用例，并且，不同功能的RTL代码的一些验证环境搭建工作也是重复进行的，这样，代码编程耗时，验证效率也比较低。
实际应用中，还可能会对cmodel代码和cmodel代码进行等效验证，或者，对RTL代码和RTL代码进行等效验证。在这些场景中，同样存在着代码编程耗时，验证效率比较低的问题。
为此，本申请实施例提供一种针对专用集成电路（Application SpecificIntegrated Circuit，ASIC）（或者叫芯片）的数据通路验证方案，提出了对验证场景规范化的统一管理方案，并可借助于dpv_gen工具自动生成验证环境（指生成cmodel hectorwrapper、cmodel代码的例化程序、以及RTL代码的例化程序），及相关场景的工具命令语言测试（TCL test）（即测试用例），有利于等效验证的开发和维护，不仅可大幅降低人力成本，而且可显著提高验证效率。
参见图1，图1为本申请实施例提供的一种验证信息的生成方法的流程图，该方法包括以下步骤。
在步骤101中，获取待验证代码和验证配置文件，待验证代码用于描述待开发电路的电路信息。
其中，待验证代码是正在开发的代码，描述的是待开发电路的电路信息。与待验证代码对应的是参考代码，参考代码是已开发好的代码，描述的是开发好的具有指定功能的目标电路的电路信息，这里，任一电路信息如电路包含哪些电子元器件，电子元器件之间的连接关系，电子元器件的输入输出是什么样的、电子元器件的时序关系等。
实际应用中，参考代码可以是建模代码如cmodel代码，也可以是逻辑代码如RTL代码。而当参考代码是建模代码时，待验证代码可以是建模代码或者逻辑代码，当参考代码是逻辑代码时，待验证代码也是逻辑代码。
一般地，验证配置文件可包括Yaml cfg和Excel cfg文件，当然验证配置文件还可以包括其他文件，本申请实施例对验证配置文件的文件类型和文件数量不做限制，只要配置文件能够提供验证时所需的验证配置信息即可。
在步骤102中，解析验证配置文件，得到验证配置信息，验证配置信息至少包括用例描述信息和待验证代码的例化信息。
在等效验证过程中，参考代码基本不会再更新了，而待验证代码是需要不断更新的，在有些情况下如待验证代码的改动比较小时，可能就不需要重复地对参考代码进行例化，所以在有些情况下，验证配置信息可仅包括用例描述信息和待验证代码的例化信息，而在另一些情况下，验证配置信息可能还包括参考代码的例化信息。
以参考代码是cmodel代码、待验证代码是RTL代码为例，dpv_gen工具解析验证配置文件的过程主要包括：
从Yaml cfg文件中解析出cmodel代码和RTL代码例化所需的文件列表和编译参数等，从Excel cfg中解析出cmodel代码和RTL代码间的端口映射关系，为生成cmodel代码和RTL代码的例化程序（TCL形式）做准备，并进行cmodel hector wrapper文件和TCL test文件的初始化工作。
在步骤103中，根据待验证代码的例化信息，生成待验证代码的实例。
在一些实施例中，待验证代码是建模代码，待验证代码的例化信息可包括待验证代码的顶层模块名、参考代码和待验证代码间输入输出映射关系、待验证代码例化时所需的文件列表，以及待验证代码的编译信息。其中，参考代码和待验证代码间输入输出映射关系用于说明目标电路的输入端口等效于待开发电路的哪个输入端口，目标电路的输出端口等效于待开发电路的哪个输出端口等效。
该种情况，可先根据待验证代码的顶层模块名、以及参考代码和待验证代码间输入输出映射关系，生成待验证代码的封装文件如cmodel hector wrapper文件，再利用待验证代码的封装文件、待验证代码例化时所需的文件列表和待验证代码的编译信息，生成待验证代码的例化程序如TCL程序，最后，利用待验证代码的例化程序对待验证代码进行例化，即可得到待验证代码的实例。
在另一些实施例中，待验证代码是逻辑代码，待验证代码的例化信息可包括待验证代码例化时所需的文件列表和待验证代码的编译信息。
该种情况，可先利用待验证代码例化时所需的文件列表和待验证代码的编译信息，生成待验证代码的例化程序，然后，利用待验证代码的例化程序对待验证代码进行例化，得到待验证代码的实例。
仍以参考代码是cmodel代码、待验证代码是RTL代码为例，dpv_gen工具对cmodel代码和RTL代码进行例化的主要步骤如下：
首先，构建验证环境，具体过程如下：
第1步、生成 cmodel hector wrapper：根据Excel cfg中的Type和Name确定信号的input/output属性，同时，可对用户定义的相同信号间的不同属性做检查，防止用户定义出错，利用解析的文件列表等信息生成cmodel hector wrapper文件，为例化程序（TCL形式）的产生和端口的比较做准备。
第2步、生成cmodel代码的例化程序和RTL代码的例化程序。
根据cmodel hector wrapper文件、以及Yaml cfg中为cmodel代码提供的编译信息，产生cmodel代码的TCL程序，根据Yaml cfg中为RTL代码提供的编译信息，产生RTL代码的TCL程序，从而完成验证平台的构建。
其次，基于验证环境例化代码，得到实例。
具体的，利用cmodel代码的TCL程序，对cmodel代码进行编译，得到cmodel代码的实例，利用RTL代码的TCL程序，对RTL代码进行编译，得到RTL代码的实例。
在步骤104中，基于用例描述信息、待验证代码的实例和参考代码的实例，生成多个测试用例，参考代码用于描述具有指定功能的目标电路的电路信息，多个测试用例用于验证目标电路和待开发电路的功能等效性。
实际应用中，参考代码的实例与待验证代码的实例的生成过程类似，具体说明如下。
在一些实施例中，参考代码是建模代码，参考代码的例化信息可包括参考代码的顶层模块名、参考代码和待验证代码间输入输出映射关系、参考代码例化时所需的文件列表，以及参考代码的编译信息。
该种情况，可先根据参考代码的顶层模块名、以及参考代码和待验证代码间输入输出映射关系，生成参考代码的封装文件如cmodel hector wrapper文件，再利用参考代码的封装文件、参考代码例化时所需的文件列表和参考代码的编译信息，生成参考代码的例化程序如TCL程序，最后，利用参考代码的例化程序对参考代码进行例化，即可得到参考代码的实例。
在另一些实施例中，参考代码是逻辑代码，参考代码的例化信息可包括参考代码例化时参考代码所需的文件列表和参考代码的编译信息。
该种情况，可先利用参考代码例化时所需的文件列表和参考代码的编译信息，生成参考代码的例化程序，然后，利用参考代码的例化程序对参考代码进行例化，得到参考代码的实例。
参见图2，图2示出了一种dpv_gen工具生成cmodel代码和RTL代码的验证信息的过程示意图，其中，Yaml cfg和Excel cfg是验证配置文件，cmodel hector wrapper是cmodel代码的封装文件，spec compile是cmodel代码的例化程序，impl compile是RTL代码的例化程序，spec指cmodel代码的实例（简称cmodel实例），impl 指RTL代码的实例（简称RTL实例），TCL test是生成的测试用例。具体说明如下。
Yaml cfg，主要用于提供cmodel代码的例化信息，如为cmodel代码提供例化所需的文件列表、顶层模块名等；为spec提供编译信息；为impl提供例化所需的文件列表、时钟和复位信号等编译信息；
Excel cfg，用于提供用例描述信息，用例描述信息包括多条命令配置数据，每条命令配置数据可用于描述RTL实例和cmodel实例中等效输入的约束条件如输入数据类型、输入范围等，可用于描述RTL实例或cmodel实例的输入，也可用于描述RTL实例和cmodel实例中等效输出的结果数据或中间数据的处理方式，如求和、比大小、取平均数等；
cmodel hector wrapper：根据Yaml cfg 中为cmodel代码提供的顶层模块名和从Excel cfg中解析出的端口等效信息（等效输入和等效输出），产生RTL实例和cmodel实例之间对应信号的输入/输出（input/output）属性和顶层声明；
spec compile：根据cmodel hector wrapper和Yaml cfg中为spec提供的编译信息，产生的cmodel代码的例化程序；
spec：利用cmodel代码的例化程序对cmodel代码进行编译，得到名为spec的cmodel实例；
impl compile：根据Yaml cfg中为impl提供的编译信息，产生的RTL代码的例化程序；
impl：利用RTL代码的例化程序对RTL代码进行编译，得到名为impl的cmodel实例；
TCL test：根据Excel cfg中的用例描述信息，产生对cmodel实例和RTL实例功能等效验证的多个测试用例。
这样，dpv_gen工具可根据Excel cfg和Yaml cfg，自动生成cmodel实例和RTL实例间的input/output 端口映射，为两者的功能等效检查做准备。同时，dpv_gen工具可以自动生成spec compile和impl compile，完成验证环境的搭建，自动生成功能等效检查所需的测试用例。
此外，dpv_gen工具还可根据Excel cfg的模板定义， 生成RTL实例在不同配置（不同配置一般对应不同验证场景）下的测试用例，实现对验证场景的精细化管理。
下面对Excel cfg进行介绍。
1、表头定义。
对Excel cfg的表头结构进行合理定义，可提升DPV的规范化，还便于对等效验证功能进行统一管理。
Excel cfg的表头关键字主要包括：
Type，用于区分表格中每条命令配置数据的类型为假设（assume）、引理（lemma）还是内部引理（inter_lemma），其中，assume类型的命令配置数据用于指明cmodel实例和RTL实例间等效输入的约束条件，也可用于指明cmodel实例或RTL实例的输入信号值，lemma类型的命令配置数据用于指明cmodel实例和RTL实例间等效输出结果的数据处理方式，inter_lemma类型的命令配置数据用于指明cmodel实例和RTL实例间等效中间结果的数据处理方式；
Name，用于指明每条命令配置数据的名字，assume类型的命令配置数据的名字可以为空；
impl_name，用于指明RTL实例的信号名字；
impl_bit，用于指明RTL实例的信号位宽；
impl_phase，用于指明RTL实例的信号相位；
impl_phase_keep，用于指明RTL实例的信号约束持续拍数；
Value，当impl_phase的值不同时用途不同，具体的，当impl_phase的值为自定义的特殊值如-2时，Value的内容用于兜底用（指将无法采用表格进行配置的命令直接作为Value的取值）；当impl_phase的值不为特殊值时，Value的取值由命令配置数据确定；
spec_name，用于指明cmodel实例的信号名字；
spec_bit，用于指明cmodel实例的信号位宽；
Data_type，用于指明cmodel实例的信号数据类型；
spec_phase，用于指明cmodel实例的信号相位；
Precondition，用于指明一条命令的执行前提。
以上关键字可以用来标识TCL程序中表达式的类型、对RTL侧和cmodel侧对等信号的约束和比较，以及表达式中用到的修饰符（以上除Name、impl_name、spec_name外均为修饰符），如impl_phase和spec_phase分别用于指定RTL实例和cmodel实例的相位，它指定了两边的时序依赖关系。
通过这些定义，用户可以灵活对RTL侧和cmodel侧的对等信号做约束和比较，生成丰富的命令行，并且通过分类管理，可一目了然得知用户验证意图，后期如果需要修改某条指令，只需要更改表格即可，维护起来也比较便捷。
另外，在对RTL侧中的多步复杂算法进行验证时，dpv_gen工具还支持用户对多步复杂算法进行拆分验证，为此，本方案利用inter_lemma来指明对拆分后中间结果的处理方式，即利用dpv_gen工具间接去实现验证速度比较慢的命令，从而加速验证收敛。
并且，假若有dpv_gen工具不能满足需求的复杂命令，还支持用户将复杂命令直接填入Value 字段所对应区域，后续，dpv_gen工具从Value 字段所对应区域复制命令即可。
2、Excel cfg的文件架构。
参见图3，图3为本申请实施例提供的一种Excel cfg的文件框架示意图，包括用例（case）、test和集（suite）三个层级，每个case最多可包括assume、lemma、inter_lemma三种类型的命令配置数据，不同case组成一个test，一个test对应一个表（sheet），不同test组成验证suite，一个suite对应一个工作簿（workbook）。一般地，不同test对应不同的cmodelhector wrapper、以及spec和impl间不同的约束和检查。
这样，将用例描述信息（包括多条命令配置数据）存储在多张表中，不同表中用例描述信息的等效验证目的不同，便于用户利用Excel去组织验证场景，Excel中每张表的验证目的比较清晰，也便于后续维护。
需要说明的是，这里每个表中的case只是用户在表中配置的用例，还不具备测试能力，而测试用例是指将表中的case转换成的一组命令，这组命令本质上是一段具有测试能力的程序。
另外，为了重用命令的和简化表格，还可在test内部兼顾case间的共享命令，主要包括两方面：一方面是test内命令由所有case重用，此时，重用命令放在图3所示的case外部空间，另一方面是部分case的重用，可借助于模糊匹配完成。
上述case的划分，体现了DPV验证的方法学。
除此之外，为了支持假设保证（assume-guarantee）验证策略，还提出了inter_lemma类型的命令配置数据，借助于inter_lemma类型的命令配置数据对验证中的复杂算法步骤做分割处理，从而加速对复杂设计的DPV的收敛速度。
具体的，dpv_gen工具支持用户将一条验证速度较慢的命令拆分成至少两条命令，比如将命令：（a+b）*c拆分成temp =（a+b）、temp*c这两条命令，然后，在sheet中对temp =（a+b）、temp*c分别进行配置。后续，针对temp =（a+b）可单独生成一个测试用例进行验证，而对于temp*c对应的测试用例可添加（a+b）已验证成功的假设。
这样，支持对命令进行拆分，分别进行验证，可起到并行验证的效果，所以可提升对此类命令的DPV的收敛速度。
具体实施时，针对参考代码和待验证代码，dpv_gen工具可按照图4所示的流程生成测试用例，包括以下步骤。
在步骤401中，对每张表进行遍历。
其中，不同表中用例描述信息对应的测试目的不同，每个表中也包括多条命令配置数据，每条命令配置数据还对应有作用域，用于指明命令配置数据对应命令作用于表中哪个用例。
在步骤402中，对遍历到的表，逐条读取表中的命令配置数据。
在步骤403中，基于命令配置数据和目标实例，生成一条命令，目标实例包括待验证代码的实例和参考代码的实例中的至少一个。
这里，当命令配置数据的类型是用于约束指定电路输入的assume类型时，针对指定电路对应的实例生成一条假设assume命令，指定电路是目标电路和待开发电路中的任一或组合。
比如，若命令配置数据用于约束待开发电路的输入信号值，则可针对待验证代码的实例生成一条assume命令，若命令配置数据用于约束目标电路的输入信号值，则可针对参考代码的实例生成一条assume命令，若命令配置数据用于约束目标电路和待开发电路的等效输入，则可对待验证代码的实例和参考代码的实例生成一条assume命令。
而当命令配置数据的类型是用于描述目标电路和待开发电路的等效结果的数据处理方式的引理lemma类型或内部引理inter_lemma类型，则可针对待验证代码的实例和参考代码的实例生成一条lemma命令。
其中，lemma和inter_lemma均用于描述对结果的处理方式，两者的区别是lemma用于描述对最终结果的数据处理方式，而inter_lemma用于描述对中间结果的数据处理方式。
实际应用中，无论assume命令还是lemma命令，均可根据抽象出来的assume/lemma命令规范产生对应的命令，进而生成TCL程序。
以assume命令为例，命令生成规则可为：
assume name=(preconditon)|->(<always_str>(express_left == express_right))，其中，name、preconditon、always_str、express_left和express_right均是要根据Excel解析得出assume命令的中间表达式，always_str为可选项。
图5为本申请实施例提供的一条命令配置数据，其中，impl_name非空、spec_name非空，生成的assume命令如下：
assume assu1 = impl.din[15:0](1) == spec.fp_in[15:0](3)，
即，对impl和spec两侧信号的第15到0个比特位进行比较，（1）用于指明对impl侧信号的检查时刻（即比较信号的哪一拍），（3）用于指明对spec侧信号的检查时刻；
由于信号一般是32位的，图5中的Disabl_auto的值缺失表示spec侧信号的其他位均为0，因此，会同步生成以下assume命令：
assume spec.fp_in[31:16](3) == 0。
lemma命令的生成规则类似，在此不再赘述。
在步骤404中，当遍历完表中的各命令配置数据时，基于各命令配置数据对应的命令，生成表对应的多个测试用例。
一般地，每条命令配置数据有作用域，作用域用于指明命令配置数据对应的assume命令或lemma命令应用于表中的局部用例还是全局用例。
以assume类型的命令配置数据为例，当命令配置数据的作用域是表中所有用例时，相应assume命令所描述的输入约束适用于表中所有用例；当命令配置数据的作用域是表中一个用例时，相应assume命令所描述的输入约束适用于这一个用例。
以lemma类型的命令配置数据为例，当命令配置数据的作用域是表中所有用例时，相应lemma命令所描述的输出结果的数据处理方式适用于表中所有用例；当命令配置数据的作用域是表中一个用例时，相应lemma命令所描述的输出结果的数据处理方式适用于这一个用例。
以inter_lemma类型的命令配置数据为例，当命令配置数据的作用域是表中所有用例时，表中所有用例均以inter_lemma类型的命令配置数据对应的lemma命令已验证成功为前提；当命令配置数据的作用域是表中一个测试用例时，仅有这个用例以相应lemma命令已验证成功为前提。
在一些实施例中，表中没有inter_lemma类型的命令配置数据，该种场景，在生成表对应的多个测试用例时，对作用域是相同测试用例的命令配置数据对应的命令进行组合，得到的即是表对应的多个测试用例。
在一些实施例中，表中有inter_lemma类型的命令配置数据，该种场景，在生成表对应的多个测试用例时，可先对作用域是相同测试用例的命令配置数据对应的assume命令和/或lemma命令进行组合，得到初始的多个测试用例，然后，基于类型是inter_lemma的每条命令配置数据对应的lemma命令，生成一个新的测试用例（需进行验证），并将表示lemma命令已验证成功的assume命令添加到命令配置数据的作用域所指示的至少一个初始测试用例中，从而为相应初始测试用例添加lemma命令已验证成功的约束。
这样，支持对命令进行拆分，并行进行验证，利于提升DPV验证速度。
下面对上述过程进行详细介绍。
inter_lemma类型的命令配置数据具有范围（scope）属性（也可叫做作用域），包括全局范围和case范围两种，dpv_gen可根据inter_lemma类型的命令配置数据产生一个新的测试用例，并根据inter_lemma的范围对相关测试用例产生影响。
图6为本申请实施例提供的一条inter_lemma类型的命令配置数据，其中inter_lemma类型的命令配置数据的范围是全局，会生成some_in的测试用例，该测试用例引入lemma：
lemma inter_some_in = {impl.d_tmp[31:0] == spec.fp_out2[31:0](1)}；
即，对impl和spec两侧信号的第31到0个比特位进行比较，（1）用于指明对信号的检查时刻（即比较信号的哪一拍）；
由于inter_lemma的范围是全局，所以可在除some_in之外的测试用例中添加上面lemma命令已验证成功的假设。
具体的，将上面的lemma命令转换成表示lemma命令已验证成功的assume命令，并置于公共部分以供test内除some_in外的其他测试用例使用，代码如下：
if {$caseName != "some_in"} {
assume relation_somein1 = {impl.d_tmp1[31:0] == spec.fp_out3[31:0](1)}
}
即，对测试用例名不是some_in的测试用例添加assume命令：relation_somein1 ={impl.d_tmp1[31:0] == spec.fp_out3[31:0](1)}。
图7为本申请实施例提供的又一条inter_lemma类型的命令配置数据，其中inter_lemma类型的命令配置数据的范围是case，会生成Case1_inter_lemma的测试用例，该测试用例除了复制原来Case1的assume命令和lemma命令，还加入lemma命令：
lemma inter_somein1 = {impl.d_tmp1[31:0] == spec.fp_out3[31:0](1)}，
即，对impl和spec两侧信号的第31到0个比特位进行比较，（1）用于指明对信号的检查时刻（即比较信号的哪一拍）；
由于inter_lemma类型的命令配置数据的范围是Case1，所以可在原来Case1中添加lemma命令已验证成功的假设即可，具体的，在原来Case1中加入assume命令:
assume relation_somein1 = {impl.d_tmp1[31:0] == spec.fp_out3[31:0](1)}。
具体实施时，还可以支持用例间的模糊匹配，具体的，针对有模糊匹配规则的指定测试用例，若确定存在与模糊匹配规则匹配的目标测试用例，则可将指定测试用例中的assume命令和/或lemma命令添加到目标测试用例中。
这样，可以直接复用指定测试用例，进一步提升用例配置的便捷性，提升测试用例的生成速度。
另外，还可把case从test中分离，生成case的独立文件，即每个测试用例的文件单独存放。其中，每个case都对一个特定功能进行验证，验证目的明确，利于后期维护。
这里，分拆成各个case的目的是为了方便验证复杂的待开发代码，提升验证收敛速度，而生成case的独立文件，分成多个sheet也是类似目的。
下面结合具体例子对本申请实施例的方案进行介绍。
参见图8，图8为本申请实施例提供的一个表的示意图，其所示的是一个sheet，即一个test，里面包含若干case，每个case包含至少一条命令配置数据，在图8中：
第2~7行是全局的assume、lemma或inter_lemma类型的命令配置数据，表中各个case可共享，这样，便于保持表格简洁，也容易维护；
第3、14行支持assume-guarantee策略，即用第3和14行的命令配置数据表示一条命令，并用inter_lemma进行标记；
第4~7行基本覆盖大部分场景中的命令配置数据，第6行是兜底的，不能通过配置实现的命令可直接写入value所在格，后续，直接复制value所在格的命令即可；
第16行支持模糊匹配，表示用例名字符合xx*yy规则的case之间可以共享其定义的assume/lemma 命令配置数据，从而达到共享assume/lemma 命令的目的。
通过以上方式，用户只需要聚焦待验证功能，填写表格，就会产生正确代码，验证信息的生成方式比较简单。
后续，生成sheet对应的测试用例的过程如下：
首先，解析每个sheet的表头，以确定表头各字段的含义。即，确定图8中第一行各字段所代表的含义。
其次，遍历sheet中每行的命令配置数据，先根据约束对该行命令配置数据做检查，若不通过，可进行提示处理，其中，约束检查如依据定义的表达式规范，某些字段内容的填写可能会有冲突不该填写或该填写的内容没有填写等问题，dpv_gen都会约束并引导用户正确填写。若通过，则依据命令配置数据中各字段的含义对命令配置数据进行解析，基于解析结果和总结的命令生成规则，产生一条assume命令或lemma命令。
然后，基于sheet中每行对应的命令，生成多个测试用例。
具体实施时，对作用域是相同用例的assume命令和/或lemma命令进行组装，得到初始的多个测试用例，之后，对Type为inter_lemma的命令配置数据对应的lemma命令进行特殊处理。具体的，根据Type为inter_lemma的命令配置数据对应的lemma命令，产生一个新的测试用例，并生成表示该lemma命令已验证成功的assume命令，当inter_lemma的命令配置数据的作用范围是sheet中所有用例时，将assume命令添加到全部测试用例中，当inter_lemma的命令配置数据的作用范围是sheet中一个用例时，将assume命令添加到相应测试用例中。
本申请实施例方案的优点有：
1、验证门槛低，快速上手。相关验证人员，如设计工程师（Design Engineer，DE）、设计验证工程师（Design Verification Engineer，DV）等，在熟悉了RTL代码的功能和接口后，不需要从头搭建验证环境和写测试用例，只需配置Yaml cfg文件、Excel cfg文件，运行dpv_gen工具即可产生验证环境和TCL的若干测试用例，而且dpv_gen工具可对用户在填表时的疏忽进行友好提示和指导，保证符合assume和lemma的语法编写规范。另外，不需要专门DV验证，所以还可节省人力成本。
2、dpv_gen工具使用灵活，扩展性强。该工具不绑定具体RTL代码，只要有数据通路验证需求的RTL代码均可以根据DPV方法学开展验证工作。
3、支持丰富的assume和lemma命令的生成。dpv_gen工具总结了大量的常见命令的表达式形式，如含逻辑操作符、蕴含条件等，也包含复杂的表达式，如循环的形式。对于非常复杂或dpv_gen生成工具没有实现的命令，一方面，用户可以利用dpv_gen现有定义的表达式去拆解直到符合约定规范；另一方面，还考虑了兜底方案，支持将无法配置在表格中的命令直接写进表格中，并正确产生TCL文件。
4、流程规范统一，不易出现错误，用户只需关注待验证功能。本申请实施例的方案严格定义填表规范，用户只需按照定义进行在表中进行配置，不必担心编写TCL的语法障碍，即可顺利进行功能验证。此外，还可避免用户过约束等错误的产生，保证验证的充分完备性。
5、支持用例切分case-split，assume-guarantee等验证策略。一个sheet包含了多个case，有利于case场景的隔离和划分，也有利于后续运行仿真能够验证完全；TCL test生成也支持RTL和spec内部状态变量的inter_lemma，方便对RTL加入切入点（cut-point）进行多步拆分验证，提升验证收敛速度。
6、支持生成多个test。每个sheet定义为一个test，该Excel可以根据每个sheet产生不同的cmodel wrapper和test，这样，比较清晰，管理起来也比较方便。
7、支持RTL代码和cmodel代码比对，cmodel代码和cmodel代码比对，以及RTL代码和RTL代码比对，功能比较全面。
基于相同的技术构思，本申请实施例还提供一种验证信息的生成装置，验证信息的生成装置解决问题的原理与上述验证信息的生成方法相似，因此验证信息的生成装置的实施可参见验证信息的生成方法的实施，重复之处不再赘述。
图9为本申请实施例提供的一种验证信息的生成装置的结构示意图，包括。
获取模块901，用于获取待验证代码和验证配置文件，所述待验证代码用于描述待开发电路的电路信息；
解析模块902，用于解析所述验证配置文件，得到验证配置信息，所述验证配置信息至少包括用例描述信息和所述待验证代码的例化信息；
例化模块903，用于根据所述待验证代码的例化信息，生成所述待验证代码的实例；
用例生成模块904，用于基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，所述参考代码用于描述具有指定功能的目标电路的电路信息，所述多个测试用例用于验证所述目标电路和所述待开发电路的功能等效性。
在一些实施例中，所述参考代码是建模代码时所述待验证代码是建模代码或者逻辑代码；所述参考代码是逻辑代码时，所述待验证代码是逻辑代码。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是建模代码时，所述代码的例化信息包括顶层模块名、所述参考代码和所述待验证代码间输入输出映射关系、例化时所需的文件列表，以及所述代码的编译信息；
例化模块903，具体用于根据以下步骤生成所述代码的实例：
利用所述顶层模块名和所述映射关系，生成所述代码的封装文件；
利用所述封装文件、所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是逻辑代码时，所述代码的例化信息包括例化时所需的文件列表和所述代码的编译信息；
例化模块903，具体根据以下步骤生成所述代码的实例：
利用所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
在一些实施例中，所述用例描述信息存储在多张表中，不同表中用例描述信息的等效验证目的不同。
在一些实施例中，所述用例描述信息包括多条命令配置数据，用例生成模块904具体用于：
对每张表进行遍历；
对遍历到的表，逐条读取所述表中的命令配置数据；
基于所述命令配置数据和目标实例，生成一条命令，所述目标实例包括所述待验证代码的实例和所述参考代码的实例中的至少一个；
当遍历完所述表中的各命令配置数据时，基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例。
在一些实施例中，用例生成模块904具体用于：
若所述命令配置数据的类型是用于约束指定电路输入的assume类型，则针对所述指定电路对应的实例生成一条假设assume命令，所述指定电路是所述目标电路和所述待开发电路中的任一或组合；
若所述命令配置数据的类型是用于描述所述目标电路和所述待开发电路的等效结果的数据处理方式的引理lemma类型或内部引理inter_lemma类型，则针对所述待验证代码的实例和所述参考代码的实例生成一条lemma命令。
在一些实施例中，每条命令配置数据有作用域，所述作用域用于指明所述命令配置数据对应的命令应用于局部用例还是全局用例；
用例生成模块904，具体用于：
对作用域是相同测试用例的命令配置数据对应的assume命令和/或lemma命令进行组合，得到初始的多个测试用例；
基于每条inter_lemma类型的命令配置数据对应的lemma命令，生成一个新的测试用例，并将表示所述lemma命令已验证成功的assume命令添加到所述命令配置数据的作用域所指示的初始测试用例中。
在一些实施例中，用例生成模块904，还用于：
针对有模糊匹配规则的指定测试用例，若确定存在与所述模糊匹配规则匹配的目标测试用例，则将所述指定测试用例中的命令添加到所述目标测试用例中。
在一些实施例中，还包括检查模块905，用于：
在基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例之前， 对所述用例描述信息进行约束检查；
对不符合要求的描述进行提示处理。
本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，本申请各实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。各个模块相互之间的耦合可以是通过一些接口实现，这些接口通常是电性通信接口，但是也不排除可能是机械接口或其它的形式接口。因此，作为分离部件说明的模块可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到同一个或不同设备的不同位置上。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
在介绍了本申请示例性实施方式的验证信息的生成方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。
下面参照图10来描述根据本申请的这种实施方式实现的电子设备130。图10显示的电子设备130仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图10所示，电子设备130以通用电子设备的形式表现。电子设备130的组件可以包括但不限于：上述至少一个处理器131、上述至少一个存储器132、连接不同系统组件（包括存储器132和处理器131）的总线133。
总线133表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。
存储器132可以包括易失性存储器形式的可读介质，例如随机存取存储器（RAM）1321和/或高速缓存存储器1322，还可以进一步包括只读存储器（ROM）1323。
存储器132还可以包括具有一组（至少一个）程序模块1324的程序/实用工具1325，这样的程序模块1324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
电子设备130也可以与一个或多个外部设备134（例如键盘、指向设备等）通信，还可与一个或者多个使得用户能与电子设备130交互的设备通信，和/或与使得该电子设备130能与一个或多个其它电子设备进行通信的任何设备（例如路由器、调制解调器等等）通信。这种通信可以通过输入/输出（I/O）接口135进行。并且，电子设备130还可以通过网络适配器136与一个或者多个网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特网）通信。如图所示，网络适配器136通过总线133与用于电子设备130的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备130使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
在示例性实施例中，还提供了一种存储介质，当存储介质中的计算机程序由电子设备的处理器执行时，电子设备能够执行上述验证信息的生成方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器（RAM）、CD-ROM、磁带、软盘和光数据存储设备等。
在示例性实施例中，本申请的电子设备可以至少包括至少一个处理器，以及与这至少一个处理器通信连接的存储器，其中，存储器存储有可被这至少一个处理器执行的计算机程序，计算机程序被这至少一个处理器执行时可使这至少一个处理器执行本申请实施例提供的任一验证信息的生成方法的步骤。
在示例性实施例中，还提供一种计算机程序产品，当计算机程序产品被电子设备执行时，电子设备能够实现本申请提供的任一示例性方法。
并且，计算机程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器（Erasable Programmable Read-Only Memory，EPROM）、闪存、光纤、光盘只读存储器（Compact Disk Read Only Memory，CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。
本申请实施例中用于芯片验证信息的程序产品可以采用CD-ROM并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、射频（Radio Frequency，RF）等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络如局域网（Local AreaNetwork，LAN）或广域网（Wide Area Network，WAN）连接到用户计算设备，或者，可以连接到外部计算设备（例如利用因特网服务提供商来通过因特网连接）。
应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、装置（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也包含这些改动和变型在内。
Claims (13)
1.一种验证信息的生成方法，其特征在于，包括：
获取待验证代码和验证配置文件，所述待验证代码用于描述待开发电路的电路信息，
解析所述验证配置文件，得到验证配置信息，所述验证配置信息至少包括用例描述信息和所述待验证代码的例化信息；
根据所述待验证代码的例化信息，生成所述待验证代码的实例；
基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，所述参考代码用于描述具有指定功能的目标电路的电路信息，所述多个测试用例用于验证所述目标电路和所述待开发电路的功能等效性。
2.如权利要求1所述的方法，其特征在于，所述参考代码是建模代码时，所述待验证代码是建模代码或者逻辑代码；所述参考代码是逻辑代码时，所述待验证代码是逻辑代码。
3.如权利要求2所述的方法，其特征在于，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是建模代码时，所述代码的例化信息包括顶层模块名、所述参考代码和所述待验证代码间输入输出映射关系、例化时所需的文件列表，以及所述代码的编译信息；
根据以下步骤生成所述代码的实例：
利用所述顶层模块名和所述映射关系，生成所述代码的封装文件；
利用所述封装文件、所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
4.如权利要求2所述的方法，其特征在于，所述验证配置信息还包括所述参考代码的例化信息，针对所述参考代码和所述待验证代码中的任一代码，当所述代码是逻辑代码时，所述代码的例化信息包括例化时所需的文件列表和所述代码的编译信息；
根据以下步骤生成所述代码的实例：
利用所述文件列表和所述编译信息，生成所述代码的例化程序；
利用所述例化程序对所述代码进行例化，得到所述代码的实例。
5.如权利要求1-4任一所述的方法，其特征在于，所述用例描述信息存储在多张表中，不同表中用例描述信息的等效验证目的不同。
6.如权利要求5所述的方法，其特征在于，所述用例描述信息包括多条命令配置数据，基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，包括：
对每张表进行遍历；
对遍历到的表，逐条读取所述表中的命令配置数据；
基于所述命令配置数据和目标实例，生成一条命令，所述目标实例包括所述待验证代码的实例和所述参考代码的实例中的至少一个；
当遍历完所述表中的各命令配置数据时，基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例。
7.如权利要求6所述的方法，其特征在于，基于所述命令配置数据和目标实例，生成一条命令，包括：
若所述命令配置数据的类型是用于约束指定电路输入的assume类型，则针对所述指定电路对应的实例生成一条假设assume命令，所述指定电路是所述目标电路和所述待开发电路中的任一或组合；
若所述命令配置数据的类型是用于描述所述目标电路和所述待开发电路的等效结果的数据处理方式的引理lemma类型或内部引理inter_lemma类型，则针对所述待验证代码的实例和所述参考代码的实例生成一条lemma命令。
8.如权利要求7所述的方法，其特征在于，每条命令配置数据有作用域，所述作用域用于指明所述命令配置数据对应的命令应用于局部用例还是全局用例；
基于所述各命令配置数据对应的命令，生成所述表对应的多个测试用例，包括：
对作用域是相同测试用例的命令配置数据对应的命令进行组合，得到初始的多个测试用例；
基于每条inter_lemma类型的命令配置数据对应的lemma命令，生成一个新的测试用例，并将表示所述lemma命令已验证成功的assume命令添加到所述命令配置数据的作用域所指示的初始测试用例中。
9.如权利要求8所述的方法，其特征在于，还包括：
针对有模糊匹配规则的指定测试用例，若确定存在与所述模糊匹配规则匹配的目标测试用例，则将所述指定测试用例中的命令添加到所述目标测试用例中。
10.如权利要求1所述的方法，其特征在于，在基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例之前，还包括：
对所述用例描述信息进行约束检查；
对不符合要求的描述进行提示处理。
11.一种验证信息的生成装置，其特征在于，包括：
获取模块，用于获取待验证代码和验证配置文件，所述待验证代码用于描述待开发电路的电路信息，
解析模块，用于解析所述验证配置文件，得到验证配置信息，所述验证配置信息至少包括用例描述信息和待验证代码的例化信息；
例化模块，用于根据所述待验证代码的例化信息，生成所述待验证代码的实例；
用例生成模块，用于基于所述用例描述信息、所述待验证代码的实例和参考代码的实例，生成多个测试用例，所述参考代码用于描述具有指定功能的目标电路的电路信息，所述多个测试用例用于验证所述目标电路和所述待开发电路的功能等效性。
12.一种电子设备，其特征在于，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：
所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-10任一所述的方法。
13.一种存储介质，其特征在于，当所述存储介质中的计算机程序由电子设备的处理器执行时，所述电子设备能够执行如权利要求1-10任一所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410160054.8A CN117709256B (zh) | 2024-02-04 | 2024-02-04 | 一种验证信息的生成方法、装置、电子设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410160054.8A CN117709256B (zh) | 2024-02-04 | 2024-02-04 | 一种验证信息的生成方法、装置、电子设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117709256A true CN117709256A (zh) | 2024-03-15 |
| CN117709256B CN117709256B (zh) | 2024-04-26 |
Family
ID=90146541
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410160054.8A Active CN117709256B (zh) | 2024-02-04 | 2024-02-04 | 一种验证信息的生成方法、装置、电子设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117709256B (zh) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070226664A1 (en) * | 2006-03-24 | 2007-09-27 | International Business Machines Corporation | Method and system for verifying the equivalence of digital circuits |
| CN116107893A (zh) * | 2023-02-13 | 2023-05-12 | 中国电子科技集团公司第二十九研究所 | 一种异构平台嵌入式软件测试验证系统及方法 |
| CN116467211A (zh) * | 2023-04-26 | 2023-07-21 | 北京计算机技术及应用研究所 | 一种基于数字化仿真环境的系统级测试验证方法 |
| CN117272896A (zh) * | 2022-06-21 | 2023-12-22 | 德州仪器公司 | 用于电路设计验证的机器学习技术 |
| CN117272974A (zh) * | 2023-09-04 | 2023-12-22 | 温州电力建设有限公司 | 一种智能变电站scl文件的验证方法、装置及相关设备 |
-
2024
- 2024-02-04 CN CN202410160054.8A patent/CN117709256B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070226664A1 (en) * | 2006-03-24 | 2007-09-27 | International Business Machines Corporation | Method and system for verifying the equivalence of digital circuits |
| CN117272896A (zh) * | 2022-06-21 | 2023-12-22 | 德州仪器公司 | 用于电路设计验证的机器学习技术 |
| CN116107893A (zh) * | 2023-02-13 | 2023-05-12 | 中国电子科技集团公司第二十九研究所 | 一种异构平台嵌入式软件测试验证系统及方法 |
| CN116467211A (zh) * | 2023-04-26 | 2023-07-21 | 北京计算机技术及应用研究所 | 一种基于数字化仿真环境的系统级测试验证方法 |
| CN117272974A (zh) * | 2023-09-04 | 2023-12-22 | 温州电力建设有限公司 | 一种智能变电站scl文件的验证方法、装置及相关设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117709256B (zh) | 2024-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7685576B2 (en) | System and method for model based system testing of interactive applications | |
| Sidorova et al. | Soundness verification for conceptual workflow nets with data: Early detection of errors with the most precision possible | |
| CN105701008B (zh) | 用于测试用例生成的系统和方法 | |
| Küster et al. | Validation of model transformations–first experiences using a white box approach | |
| Semeráth et al. | Formal validation of domain-specific languages with derived features and well-formedness constraints | |
| Forster et al. | Verification of business process quality constraints based on visual process patterns | |
| KR20210149045A (ko) | 인공 지능 칩 검증 | |
| US20090077532A1 (en) | Automated annotation inference for safety certification of automatically generated code | |
| JP2009087354A (ja) | ウェブアプリケーションの自動テスト生成システム及び方法 | |
| Klassen et al. | EMorF-A tool for model transformations | |
| CN109739740A (zh) | 一种aadl模型组合形式化验证方法 | |
| US8145992B2 (en) | Validation assisted document conversion design | |
| CN111103861B (zh) | 开发基于车辆售后诊断需求的集成系统的方法和装置 | |
| US8612954B2 (en) | Fine slicing: generating an executable bounded slice for program | |
| Kesserwan et al. | From use case maps to executable test procedures: a scenario-based approach | |
| CN115357289A (zh) | 寄存器应用信息生成方法、装置、电子设备和存储介质 | |
| Svendsen et al. | The future of train signaling | |
| US20190303279A1 (en) | Modeling system | |
| Di Natale et al. | A Model-based approach for the synthesis of software to firmware adapters for use with automatically generated components | |
| CN117709256B (zh) | 一种验证信息的生成方法、装置、电子设备及存储介质 | |
| JP2008305079A (ja) | 要求仕様自動検証方式 | |
| Elmqvist et al. | Safety-oriented design of component assemblies using safety interfaces | |
| Balogh et al. | Workflow-driven tool integration using model transformations | |
| Horváth et al. | Hardware-software allocation specification of ima systems for early simulation | |
| de Freitas | From Circus to Java: Implementation and verification of a translation strategy |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |