CN106407516A - 一种并行验证的验证方法 - Google Patents

Abstract

本发明描述了一种并行验证的验证方法，该发明可对若干个算法原理相同，但实现方式不同的逻辑设计模块进行并行验证，并将每个逻辑设计模块的结果和参考模型的预期计算结果进行比对，产生比对结果。该发明将把多个逻辑模块信号接口的差异性，封装在验证平台的最低层，而将通用的验证脚本及事务配置方法提供给验证平台的顶层，供验证人员使用，以便进行验证平台以及测试用例的重用，简化验证人员的工作量，并缩短验证周期。该发明将适用于算法原理相同，但由于需求不同，造成实现方式不同的模块的验证。经过验证后的模块组，将用于不同的项目，或用于性能对比及评估。

Description

一种并行验证的验证方法

技术领域

本发明属于集成电路芯片的逻辑验证领域，具体涉及芯片数字模块的并行验证方法。

背景技术

伴随微电子技术的快速发展，芯片的CPU处理能力、存储器容量等硬件指标均得到很大提高。芯片技术的不断成熟，使其成为许多行业解决传统问题的理想方案。芯片的逻辑功能日臻复杂，性能也在不断的得到完善。为了让芯片以及其衍生或升级产品的性能更优、功能更稳定，芯片中的某个关键功能模块可能会存在多个临时版本，而对这多个版本的有效评估，将是芯片研发团队面临的重大考验。而保证多个评估版本的功能正确性，将是评估工作的首要前提。

针对上述背景，芯片研发团队的一个或多个产品研发过程中，可能会对某个关键功能模块开发多个临时版本。这些临时版本的模块算法原理相同，但实现方式不同，其差异将体现在处理带宽、接口、内部是否包含流水等各个方面。而对这多个版本的并行验证方法，将有效的节省验证平台的开发周期，降低验证人员的工作量，提高一个或多个芯片产品的研发效率。

发明内容

本发明提出了一个针对原理相同，实现方式不同的多个功能模块验证需求的高效验证方法。

本发明提出的验证方法对应的平台架构，将以分层结构进行设计。自顶向下分别为：用户层、脚本层、测试层、场景层、功能层、命令层、信号层。这样搭建的目的，是为了方便各个组件的重用，以便节省验证平台的开发及测试时间，同时也能让验证平台层次清晰，便于理解和维护。

从功能层往上，所有的验证组件，以及测试层的初始化、运行、结果输出以及异常处理流程，均与被测模块的个数无关。由于使用了统一的接口模板，在功能层往下，被测模块输入信号的驱动方式，以及输出信号的监控方式，也与被测模块的个数无关。因此，无论有多少个被测模块，验证平台的工作流程都是固定的。当被测模块的个数发生变化时，与工作流程相关的验证组件均无需修改。唯一与被测模块个数相关的内容，就是驱动器、监视器、接口、快照的个数，以及他们在验证平台底层的连接。因此，在验证平台中，仅有信号层才会体现出不同被测模块的接口差异性。在信号层之上，所有验证组件对不同的被测模块的控制方式是相同的，他们的差异性仅区别于处理带宽。

所有和被测模块相关的部分，都可以集中在一个文件内部进行开发，便于调试、维护和其他项目继承。

附图说明

图1并行验证平台结构图

图2并行验证平台工作流程图

具体实施方式

以下结合说明书附图对本发明的具体实施方式进行详细说明。

如图1本发明验证平台架构图所示，数字N为被测模块的个数。101～10N代表被测模块，110代表断言，121～12N代表接口，131～13N代表快照，上述组件均为信号层组件。201～20N代表驱动器，211～21N代表监视器，220代表参考模型，上述组件均为命令层组件。300代表代理器、310代表检查器，320代表积分板，上述组件均为功能层组件。400代表场景层的事务产生器，500代表测试层的验证环境顶层，600代表脚本层的验证脚本，700代表用户层的输入输出设备。

图1中的101～10N代表被测模块，每个被测模块将根据不同的需求进行开发，彼此之间没有联系。每个被测模块的算法原理相同，工作流程相同。

图1中的110代表断言，断言将搜集每个被测模块中的内部或接口信号，对关键时序进行实施的检测，如有异常，断言将实时的将异常信息上报给测试层。

图1中的121～12N代表接口，每个接口的信号列表名均相同，但位宽不一定相同。接口与被测模块的连接在信号层实现。由于被测模块的差异性，接口在设计时将考虑通用性，其信号列表要兼容所有的被测模块的输入输出信号列表。接口的输入信号将由上层的驱动器进行驱动，接口的输出信号将由上层的监视器监控。

图1中的131～13N代表快照，每个快照的信号列表也均相同，它与接口的区别在于：接口信号与被测模块的输入输出端口进行连接。而快照信号将于被测模块的内部信号通过“跨模块引用”的方式进行连接。快照信号的所有信号都由上层的监视器监控。由于仅仅通过端口信号的监测，不能完全的对被测模块的功能点进行覆盖。故可通过快照的方式进行深入的监测，以达到验证目的。同样，快照的信号列表在设计时，也应考虑通用性。

图1中的201～20N代表驱动器，它将把上层的事务，转化成驱动信号列表，并通过接口传递给被测模块。所有的驱动器，都由同一个类模板例化。

图1中的211～21N代表监视器，它将监测接口和快照传递上来的信号，并从中提取出计算结果，填写到其事务中。所有的监视器，都由同一个类模板例化。

图1中的220代表参考模型，它通过将根据事务中的输入数据，进行期望结果的运算，并将其传递给积分板。

图1中的300代表代理器，代理器将把事务并行的进行分发，保证每个被测模块以及积分板都能得到相同的输入数据。

图1中的310代表检查器，检查器将并行的监控所有被测模块的计算结果数据，并传递给积分板。

图1中的320代表积分板，积分板将对所有被测模块的计算结果和参考模型的期望结果进行比对，并将所有比对结果反馈回测试层。

图1中的400代表事务产生器，事务产生器将根据上层的测试用例配置文件，生成当前测试用例的事务列表。事务列表中的每条事务将按照时间顺序依次分发给下层的代理器。

图1中的500代表验证环境顶层，从测试层往下，均为验证环境的功能。验证环境顶层将进行验证组件的初始化、运行、结果输出以及异常处理。在整个验证平台中，它具有承上启下的作用。一方面，它将初始化下层的验证组件，把上层提供的配置信息传递给下层验证组件，并运行验证人员手动配置的测试用例激励文件；另一方面，它将搜集下层组件上报的计算结果与异常信息，并以统一的格式反馈给用户层。

图1中的600代表验证脚本，验证脚本将处理用户层的脚本命令，并通过测试用例列表，找到对应的测试用例的描述信息。同时，它将根据该信息，生成测试用例配置文件。

图1中的700代表输入输出设备，用户(验证人员)通过输入设备输入脚本命令，以及手动测试用例配置文件，开始一条测试用例的验证。同时，用户通过输出设备，得到脚本和测试用例的运行结果。

图2中示例了并行验证平台的工作流程，从流程图中可以看出，并行验证平台的运行，是通过验证脚本和验证环境协调工作来实现的。除了手动测试用例配置文件中可能涉及一些与被测模块差异性相关的信息处理之外，其他配置输入信息均与多个被测模块的差异性无关。因此，该并行验证方法，是能够确保验证的简洁、高效与易维护性的。通过验证脚本的自动生成、以及验证人员的手动配置。验证平台可以覆盖所有的应用场景，满足功能覆盖率。

在验证平台上层，将以事务为数据处理的基本单元，因此将上层组件的控制与被测物的细节剥离开来，因此使其控制流程与被测模块无关，在验证平台下层，使用了验证组件模板的方式开发，使得组件本身的实现以及控制流程也与被测模块无关，唯一相关的仅仅是这些组件实例的个数，因此，所有和被测模块相关的部分，都可以集中在一个文件内部进行开发，便于调试、维护和其他项目继承。

Claims (9)

1.一种并行验证的验证方法，其特征在于，实现该验证方法的验证平台包括验证脚本与验证环境两部分，该验证方法支持相同算法不同实现方案的并行验证，使用并行化的方法进行验证，所有的被测模块(DUT)，将同时被灌入测试输入时序，同时，验证环境会搜集所有被测模块的计算结果，确保所有模块的计算结果都计算完成后，再进行下一次计算；验证环境对于被测模块输入信号的驱动，以及输出信号的监控，均并行且独立的执行，不同的被测模块间的输入信号和输出信号，不会互相干扰。

2.根据权利要求1所述验证方法，其特征在于，所述验证环境是验证平台的主体，它包括各个验证组件，实现整个验证过程；所述验证脚本为所述验证平台生成测试用例配置文件，以便于在不同的场景中进行验证。

3.根据权利要求1所述的验证方法，其特征在于，所述验证平台以分层的形式来进行搭建，自顶向下的顺序依次为：用户层、脚本层、测试层、场景层、功能层、命令层、信号层，这样搭建，是为了方便各个组件的重用，以便节省验证平台的开发及测试时间，同时也能让验证平台层次清晰，便于理解和维护，其中：

用户层面向验证人员，对于大部分的验证场景，验证人员只需要通过输入设备，维护测试用例列表，并输入脚本命令，就可以运行仿真，仿真结束后，将得到脚本运行日志文件，以及测试用例的运行结果和异常信息；

脚本层处理用户层的脚本命令，并通过测试用例列表，找到对应的测试用例的描述信息，同时，它将根据该信、息，生成测试用例配置文件，以上步骤，都是验证脚本自动运行的，验证人员无需进行任何操作；

测试层包括验证环境顶层的所有功能，包括验证组件的初始化、运行、结果输出以及异常处理，在整个验证平台中，它具有承上启下的作用，一方面，它将初始化下层的验证组件，把上层提供的配置信息传递给下层验证组件，并运行验证人员手动配置的测试用例激励文件；另一方面，它将搜集下层组件上报的计算结果与异常信息，并以统一的格式反馈给用户层；

场景层根据上层的测试用例配置文件，生成当前测试用例的事务列表中，事务列表将包含所有的测试基本单元、即事务(Transaction)。不同的事务列表的组合将对应不同场景的测试；

功能层包含代理器、检查器和积分板，其中，代理器将把事务并行的进行分发，保证每个被测模块以及积分板都能得到相同的输入数据，检查器并行的监控所有被测模块的计算结果数据，并传递给积分板，最后，积分板对所有被测模块的计算结果和参考模型的期望结果进行比对，并将所有比对结果反馈回测试层；

命令层包含参考模型、驱动器组和监视器组，参考模型将根据事务中的输入数据，进行期望结果的运算，并将其传递给积分板，驱动器组包含多个驱动器，每个驱动器将生成不同的输入激励时序给不同的被测模块，且一一对应，监视器组包含多个监视器，每个监视器将监测不同被测模块的输出，并把输出结果写回到事务中，监视器与被测模块也是一一对应的；在命令层，所有驱动器从代理器得到的事务都是相同的，如果每个被测模块的计算过程都无误，所有监视器传递给检查器的事务也应该相同，且和参考模型产生的事务结果数据一致；

信号层包含接口组、快照组、断言和被测模块组，其中：接口组包含多个接口，每个接口都对应一簇输入输出信号，这簇输入信号将与一个被测模块连接，快招组包含多个快照，每个快照将对应一簇信号，这簇信号将对应一个被测模块的内部信号，断言将实时监测每个被测中的关键信号，当出现信号非法时，实时上报断言信息给测试层，被测模块组包含多个被测模块，各个被测模块的算法原理均相同，工作流程一致，但实现细节有差异。

4.根据权利要求1所述的验证方法，其特征在于，在自动生成测试用例配置文件的方式之外，所述验证平台还为用户开放了手动测试用例配置接口。

5.根据权利要求1所述的验证方法，通过验证脚本的自动生成、以及验证人员的手动配置。验证平台可以覆盖所有的应用场景，满足功能覆盖率。

6.根据权利要求3所述的验证方法，虽然在命令层之下，包含了多个驱动器、监视器、接口、快照，但他们均使用了统一的模板，即他们开发过程都是基于模板的开发，每个驱动器、监视器、接口、快照只是他们模板的一个实例(Instance)。

7.根据权利要求3所述的验证方法，不同的被测模块的实现细节的不同，可体现在接口工作频率、接口信号名、接口位宽、接口信号配置顺序与方式等各个方面，但，只要基本工作流程一致，就可以适用于本发明中的验证方法。

8.根据权利要求3所述的验证方法，从功能层往上，所有的验证组件，以及测试层的初始化、运行、结果输出以及异常处理流程，均与被测模块无关，由于使用了统一的接口模板，在功能层往下，被测模块输入信号的驱动方式，以及输出信号的监控方式，也与被测模块的个数无关，因此，无论有多少个被测模块，验证平台的工作流程都是固定的，当被测模块的个数发生变化时，与工作流程相关的验证组件均无需修改，唯一与被测模块个数相关的内容，就是驱动器、监视器、接口、快照的个数，以及他们在验证平台底层的连接。

9.根据权利要求3所述的验证方法，在验证平台上层，将以事务为数据处理的基本单元，因此将上层组件的控制与被测物的细节剥离开来，因此使其控制流程与被测模块无关，在验证平台下层，使用了验证组件模板的方式开发，使得组件本身的实现以及控制流程也与被测模块无关，唯一相关的仅仅是这些组件实例的个数，因此，所有和被测模块相关的部分，都可以集中在一个文件内部进行开发，便于调试、维护和其他项目继承。