CN113704043A - 芯片功能验证方法、装置、可读存储介质及电子设备 - Google Patents

Abstract

本公开实施例公开了一种芯片功能验证方法、装置、计算机可读存储介质及电子设备，其中，该方法包括：接收输入的验证工具选择参数；响应于确定验证工具选择参数表示软件方式验证工具被选择，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；基于软件激励信号，控制软件模拟被测对象生成软件执行结果；响应于确定验证工具选择参数表示硬件方式验证工具被选择，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号；基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。本公开实施例可以实现快速地对针对同一芯片设计的不同类型的被测对象进行验证，降低了芯片验证成本，提高了芯片验证方法的复用性。

Description

芯片功能验证方法、装置、可读存储介质及电子设备

技术领域

本公开涉及芯片技术领域，尤其是一种芯片功能验证方法、装置、计算机可读存储介质及电子设备。

背景技术

随着数字芯片设计规模越来越大，验证也变的越来越重要，在一些复杂芯片项目中，验证工作量可能会占整个芯片开发工作的70％。在芯片设计完成后，目前存在多种针对芯片的验证方法，例如EDA(Electronic Design Automation，电子设计自动化)验证、EMU(Emulator，仿真硬件加速器)验证等。

数字芯片验证流程，一般包括用例设计、TestBench(测试平台)开发、软硬件编译和仿真等，其中，TestBench是软件，DUT(Device Under Test，被测器件)是硬件，在数字芯片验证领域一般指芯片设计源代码。数字芯片验证是将DUT放置在TestBench中，验证工程师构造TestCase(测试用例)来控制TestBench产生各种各样的激励并输入到DUT中，验证DUT在各种输入场景下的工作状态。

发明内容

本公开的实施例提供了一种芯片功能验证方法、装置、计算机可读存储介质及电子设备。

本公开的实施例提供了一种芯片功能验证方法，该方法包括：接收输入的验证工具选择参数；响应于确定验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；基于软件激励信号，控制软件模拟被测对象生成软件执行结果；响应于确定验证工具选择参数表示硬件方式验证工具被选择，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号；基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

根据本公开实施例的另一个方面，提供了一种芯片功能验证装置，该装置包括：接收模块，用于接收输入的验证工具选择参数；第一生成模块，用于响应于确定验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；第一控制模块，用于基于软件激励信号，控制软件模拟被测对象生成软件执行结果；第二生成模块，用于响应于确定验证工具选择参数表示硬件方式验证工具被选择，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号；第二控制模块，用于基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

根据本公开实施例的另一个方面，提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序用于执行上述芯片功能验证方法。

根据本公开实施例的另一个方面，提供了一种电子设备，电子设备包括：处理器；用于存储处理器可执行指令的存储器；处理器，用于从存储器中读取可执行指令，并执行指令以实现上述芯片功能验证方法。

基于本公开上述实施例提供的芯片功能验证方法、装置、计算机可读存储介质及电子设备，通过在输入的验证工具选择参数的控制下，选择软件方式验证工具或硬件方式验证工具，若选择软件方式验证工具，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号，基于软件激励信号，控制软件模拟被测对象生成软件执行结果，若选择硬件方式验证工具，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号，基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果，从而实现了将软件方式验证工具和硬件方式验证工具融合在同一个测试平台下进行测试，在利用其中一个验证工具对被测对象进行测试后，无需再修改测试用例和调整测试平台即可利用另一个验证工具对另一个被测对象进行测试，可以实现快速地对针对同一芯片设计的不同类型的被测对象进行验证，降低了芯片验证成本，提高了芯片验证方法的复用性，有利于测试用例的跨平台移植。

下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。

附图说明

通过结合附图对本公开实施例进行更详细的描述，本公开的上述以及其他目的、特征和优势将变得更加明显。附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开实施例一起用于解释本公开，并不构成对本公开的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1是本公开所适用的系统图。

图2是本公开一示例性实施例提供的芯片功能验证方法的流程示意图。

图3是本公开的实施例的芯片功能验证方法的一个应用场景的示意图。

图4是本公开一示例性实施例提供的芯片功能验证装置的结构示意图。

图5是本公开另一示例性实施例提供的芯片功能验证装置的结构示意图。

图6是本公开一示例性实施例提供的电子设备的结构图。

具体实施方式

下面，将参考附图详细地描述根据本公开的示例实施例。显然，所描述的实施例仅仅是本公开的一部分实施例，而不是本公开的全部实施例，应理解，本公开不受这里描述的示例实施例的限制。

应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

本领域技术人员可以理解，本公开实施例中的“第一”、“第二”等术语仅用于区别不同步骤、设备或模块等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。

还应理解，在本公开实施例中，“多个”可以指两个或两个以上，“至少一个”可以指一个、两个或两个以上。

还应理解，对于本公开实施例中提及的任一部件、数据或结构，在没有明确限定或者在前后文给出相反启示的情况下，一般可以理解为一个或多个。

另外，本公开中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本公开中字符“/”，一般表示前后关联对象是一种“或”的关系。

还应理解，本公开对各个实施例的描述着重强调各个实施例之间的不同之处，其相同或相似之处可以相互参考，为了简洁，不再一一赘述。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本公开实施例可以应用于终端设备、计算机系统、服务器等电子设备，其可与众多其它通用或专用计算系统环境或配置一起操作。适于与终端设备、计算机系统、服务器等电子设备一起使用的众所周知的终端设备、计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统、大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。

终端设备、计算机系统、服务器等电子设备可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。

申请概述

目前，由于存在多种验证工具(例如EDA验证和EMU验证作为两种重要的验证工具)，跨平台验证也越来越常见。一般情况下，跨平台验证会带来很大的平台适配工作量，极大的减缓了验证进度。

由于EDA和EMU这两种验证工具的固有差异，在大多数情况下，还是把它们作为两种独立的验证工具使用。TBA(Transaction Based Acceleration)模式的EMU验证可以带Testbench仿真，这使得EDA验证和EMU验证在原理上具备了融合统一的可能性。

但是这两个平台之间仍然存在许多固有差异。EDA验证的TestBench和DUT在仿真过程中都以软件的形式运行在电子设备(例如服务器)上。TBA模式的EMU验证，TestBench以软件的形式运行在电子设备上，DUT以硬件门电路的形式运行在EMU硬件上。另外，EDA验证的TestBench和DUT交互是信号级的，而TBA模式EMU验证的TestBench和DUT交互是传输块级的。

上面的差异导致两者的TestBench仍然存在较大差别，这给日益频繁的跨平台验证工作带来了困难。现有的利用上述两种验证方法进行DUT验证的做法是，EDA验证和EMU验证各维护一套TestBench，或者采用大量的分隔宏在一套TestBench上实现各自的功能，导致两种验证方法融合度低，复用性差，维护成本高，不利于验证用例的跨平台移植。

示例性系统

图1示出了可以应用本公开的实施例的芯片功能验证方法或芯片功能验证装置的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101，网络102和服务器103。网络102用于在终端设备101和服务器103之间提供通信链路的介质。网络102可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101通过网络102与服务器103交互，以接收或发送消息等。终端设备101可以是各种电子设备，包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。

服务器103可以是提供各种服务的服务器，例如对终端设备101上传的软件模拟被测对象、硬件模拟被测对象等进行验证的后台服务器。后台服务器可以根据接收的验证工具选择参数，选择相应的被测对象并进行功能验证。

需要说明的是，本公开的实施例所提供的芯片功能验证方法可以由服务器103执行，也可以由终端设备101执行，相应地，芯片功能验证装置可以设置于服务器103中，也可以设置于终端设备101中。一般的，该芯片功能验证方法和芯片功能验证装置需要依托于用于对芯片功能进行验证的测试平台，即测试平台可以设置于终端设备101或服务器103中。例如，测试平台可以是现有的TestBench平台，在TestBench平台中，提供了对软件模拟被测对象和硬件模拟被测对象进行测试的相关功能和组件。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

示例性方法

图2是本公开一示例性实施例提供的芯片功能验证方法的流程示意图。本实施例可应用在电子设备(如图1所示的终端设备101或服务器103)上，如图2所示，该方法包括如下步骤：

步骤201，接收输入的验证工具选择参数。

在本实施例中，电子设备可以从本地或从远程接收输入的验证工具选择参数。其中，验证工具选择参数用于指示当前选择用于对芯片设计数据进行软件仿真验证的软件方式验证工具和/或用于对芯片设计数据进行硬件仿真验证的硬件方式验证工具。通常，上述软件方式验证工具可以是现有的EDA验证工具，可以运行在上述电子设备上。硬件方式验证工具可以是现有的EMU验证工具，包括EMU硬件(例如现有的Palladium硬件仿真平台)。

作为示例，本公开的实施例提供的芯片功能验证方法可以利用TestBench测试平台实现，在TestBench中，用户可以输入启动仿真命令加上工具类型参数作为验证工具选择参数。例如，run_cmd表示启动仿真命令，run_cmd eda表示用于EDA验证工具被选择进行芯片功能验证，run_cmd emu表示EMU验证工具被选择进行芯片功能验证。

步骤202，响应于确定验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号。

在本实施例中，电子设备可以响应于确定验证工具选择参数表示软件方式验证工具被选择，首先基于预设的芯片设计数据，生成软件模拟被测对象。

其中，芯片设计数据是预先设置的用于模拟芯片功能的数据(例如基于verilog语言编写的代码生成的数据)。软件模拟被测对象为通过软件模拟的方式生成的用于模拟芯片功能的软件代码块。芯片设计数据可以转换为软件方式验证工具支持的数据作为软件模拟被测对象，例如通过EDA验证工具进行编译，生成软件模拟被测对象。软件模拟被测对象通常只能在上述电子设备中运行，运行过程即模拟芯片的工作过程。针对软件模拟被测对象进行的验证过程可以为目前常用的EDA验证(详见上述背景技术和申请概述中的描述)。

然后，电子设备可以基于预设的软件驱动代码生成软件激励信号。

其中，上述软件驱动代码用于生成软件激励信号，软件激励信号用于驱动上述软件模拟被测对象执行相应的芯片设计功能。通常，软件驱动代码可以是按照现有的UVM(Universal Verification Methodology，通用验证方法学)框架构建的代码。在该框架中，可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境，从而生成上述软件驱动代码。

步骤203，基于软件激励信号，控制软件模拟被测对象生成软件执行结果。

在本实施例中，电子设备可以基于软件激励信号，控制软件模拟被测对象生成软件执行结果。

通过软件激励信号，可以将软件模拟被测对象在执行时所需的数据输入软件模拟被测对象。例如，当软件模拟被测对象用来模拟加法器时，软件激励信号可以包括两个相加的数字，软件模拟被测对象将这两个数字相加，得到的计算结果即为软件执行结果。

步骤204，响应于确定验证工具选择参数表示硬件方式验证工具被选择，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号。

在本实施例中，电子设备可以响应于确定验证工具选择参数表示硬件方式验证工具被选择，首先基于芯片设计数据，生成硬件模拟被测对象。

其中，硬件模拟被测对象为模拟真实的硬件芯片的代码块，例如硬件模拟被测对象可以包括真实芯片内的各种门电路、地址线、数据线等实体。芯片设计数据可以转换为硬件方式验证工具支持的数据作为硬件模拟被测对象，例如通过EMU验证工具进行编译，生成硬件模拟被测对象。通常，硬件模拟被测对象的验证过程可以为目前常用的EMU验证(详见上述背景技术和申请概述中的描述)。由于硬件模拟被测对象是模拟真实硬件的，因此，硬件模拟被测对象通常可以直接被加载到硬件(例如现有的Palladium硬件仿真平台)中，并在硬件中运行仿真过程。

然后，电子设备可以基于预设的硬件驱动代码生成硬件激励信号。上述硬件驱动代码用于生成硬件激励信号，硬件激励信号用于驱动上述硬件模拟被测对象执行相应的芯片设计功能。通常，硬件激励信号可以通过模拟真实芯片的接口输入到硬件模拟被测对象中。

步骤205，基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

在本实施例中，电子设备可以基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

通过硬件激励信号，可以将硬件模拟被测对象在执行时所需的数据输入硬件模拟被测对象。例如，当硬件模拟被测对象用来模拟加法器时，硬件激励信号可以包括两个相加的数字，硬件模拟被测对象将这两个数字相加，得到的计算结果即为硬件执行结果。

本公开的上述实施例提供的方法，通过在输入的验证工具选择参数的控制下，选择软件方式验证工具或硬件方式验证工具，若选择软件方式验证工具，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号，基于软件激励信号，控制软件模拟被测对象生成软件执行结果，若选择硬件方式验证工具，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号，基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果，从而实现了将软件方式验证工具和硬件方式验证工具融合在同一个测试平台下进行测试，在利用其中一个验证工具对被测对象进行测试后，无需再修改测试用例和调整测试平台即可利用另一个验证工具对另一个被测对象进行测试，可以实现快速地对针对同一芯片设计的不同类型的被测对象进行验证，降低了芯片验证成本，提高了芯片验证方法的复用性，有利于测试用例的跨平台移植。

在一些可选的实现方式中，步骤203可以如下执行：

首先，将软件激励信号经由第一软件驱动接口发送至软件模拟被测对象。

其中，第一软件驱动接口可以是通过软件模拟的方式构建的虚拟接口，通过该接口可以直接将软件激励信号传递至软件模拟被测对象内部。与硬件驱动接口不同的是，本实施例中的软件驱动接口并发模拟真实的芯片管脚，而是通过诸如调用函数、虚拟探针等方式直接将软件激励信号传递给软件模拟被测对象。

然后，基于软件模拟被测对象生成软件执行结果。

软件模拟被测对象在从第一软件驱动接口获得软件激励信号后，可以执行相应的功能，得到软件执行结果。

本实现方式提供的第一软件驱动接口，可以专门用于传递软件激励信号，实现了在同一测试平台将软件激励信号和硬件激励信号分离，从而提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的效率。

在一些可选的实现方式中，在上述基于软件模拟被测对象生成软件执行结果之后，还可以执行如下步骤：

从第二软件驱动接口接收软件模拟被测对象生成的软件执行结果，并将软件执行结果输出。

其中，第二软件驱动接口可以是与上述第一软件接口相同的方式构建的虚拟接口，通过该接口可以直接将软件模拟被测对象生成的软件执行结果输出。可选的，在上述测试平台中可以预先设置监控组件，软件执行结果可以通过监控组件以各种方式输出，例如在显示器显示、发送至其他电子设备。

本实现方式提供的第二软件驱动接口，可以专门用于输出软件执行结果，使软件执行结果更易被准确获取，从而提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的效率。

在一些可选的实现方式中，步骤205可以如下执行：

首先，将软件激励信号经由第一硬件驱动接口发送至硬件模拟被测对象。

其中，第一硬件驱动接口可以是模拟真实芯片的管脚的接口，通过该接口可以将硬件激励信号传递至硬件模拟被测对象包括的虚拟管脚。

然后，基于硬件模拟被测对象生成硬件执行结果。

硬件模拟被测对象可以在从虚拟管脚接收硬件激励信号后，执行相应的功能，得到硬件执行结果。

本实现方式提供的第一硬件驱动接口，可以模拟真实芯片的管脚，实现了更加接近真实场景的验证，同时第一硬件驱动接口专门用于传递硬件激励信号，实现了在同一测试平台将软件激励信号和硬件激励信号分离，从而提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的精确性。

在一些可选的实现方式中，在上述基于硬件模拟被测对象生成硬件执行结果之后，还可以执行如下步骤：

从第二硬件驱动接口接收硬件模拟被测对象生成的硬件执行结果，并将硬件执行结果输出。

其中，第二硬件驱动接口可以是模拟真实芯片的管脚的接口，通过该接口可以将硬件执行结果从芯片的虚拟管脚输出。可选的，硬件执行结果也可以通过上述监控组件以各种方式输出，例如在显示器显示、发送至其他电子设备。

本实现方式提供的第二硬件驱动接口，可以模拟真实芯片的管脚将硬件执行结果输出，实现了更加接近真实场景的验证，同时第二硬件驱动接口专门用于传递硬件执行结果，使硬件执行结果更易被准确获取，从而提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的效率。

在一些可选的实现方式中，该方法还可以包括如下步骤：

响应于用户对软件模拟被测对象进行的第一辅助测试操作，利用预设的软件测试辅助组件，对软件模拟被测对象实现的功能进行辅助测试。

响应于用户对硬件模拟被测对象进行的第二辅助测试操作，利用预设的硬件测试辅助组件，对硬件模拟被测对象实现的功能进行辅助测试。

上述第一辅助测试操作和第二辅助测试操作可以是用户通过点击按钮、输入命令等方式对软件模拟被测对象和硬件模拟被测对象进行的辅助测试。软件测试辅助组件和硬件测试辅助组件用于分别对软件模拟被测对象和硬件模拟被测对象进行辅助测试。

作为示例，当设计的芯片用于实现图像识别功能时，软件测试辅助组件和硬件辅助测试组件可以分别对软件模拟被测对象和硬件模拟被测对象进行图像识别的结果的正确性进行验证。再例如，当设计的芯片用于运行神经网络模型时，软件测试辅助组件和硬件辅助测试组件可以分别对软件模拟被测对象和硬件模拟被测对象在运行神经网络模型时生成的中间数据进行监控。

通常，软件测试辅助组件无法加载到真实硬件中，而硬件测试辅助组件可以同硬件模拟被测对象一起加载到硬件(例如Palladium硬件仿真平台)中。

本实现方式通过设置软件测试辅助组件和硬件测试辅助组件，可以实现将对芯片设计的软件验证和硬件验证完全分离，两种验证方式互不影响，从而进一步提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的准确性。

在一些可选的实现方式中，步骤202可以包括如下子步骤：

首先，运行软件驱动代码，生成初始软件激励信号。

然后，基于初始软件激励信号生成第一块级的软件激励信号。

通常，驱动软件模拟被测对象和硬件模拟被测对象的激励信号的传输可以是信号级传输或块级传输。信号级传输是指按照驱动代码的运行顺序，逐条生成激励信号并发送给被测对象。块级(又称事务级，transaction)传输是指测试平台和被测对象之间的信号传输是将多个激励信号打包成一个块(或称事务)，从而一次可以传输多个激励信号，减少激励信号的传输次数。

本实现方式通过将软件激励信号设置成块级传输方式，可以减少测试平台和软件模拟被测对象之间的信号传输次数，提高芯片功能验证效率。

在一些可选的实现方式中，基于预设的硬件驱动代码生成硬件激励信号，包括：

首先，运行硬件驱动代码，生成初始硬件激励信号。

然后，基于初始硬件激励信号生成第二块级的硬件激励信号。

其中，第二块级和上述第一块级的定义和处理方式可以相同。本实现方式通过将硬件激励信号设置成块级传输方式，可以减少测试平台和硬件模拟被测对象之间的信号传输次数，提高芯片功能验证效率。

当本实现方式和上述生成第一块级的软件激励信号的实现方式同时实现时，可以将测试平台与软件模拟被测对象、硬件模拟被测对象之间的信号传输统一设置为块级信号传输，从而提高了将软件模拟被测对象和硬件模拟被测对象融合在同一个测试平台下进行测试的效率。

在一些可选的实现方式中，步骤202中，基于预设的芯片设计数据，生成软件模拟被测对象，包括：

首先，基于第一编译方式，对芯片设计数据进行编译，得到软件模拟被测对象。

其中，第一编译方式是对软件模被测对象进行编译采用的方式。例如，第一编译方式可以是VCS编译(一种EDA验证的软硬件编译流程)方式。基于编译后的数据，可以得到软件模拟被测对象。例如编译后的数据即可作为软件模拟被测对象，或将编译后的数据进行一定的处理(例如对编译后的数据打包、拆解等方式)得到软件模拟被测对象。

基于此，步骤203可以如下执行：

基于软件激励信号，按照第一仿真方式对软件模拟被测对象进行仿真，得到软件执行结果。

其中，第一仿真方式是用于对软件模拟被测对象进行仿真的方式。例如SIM仿真(一种EDA验证的仿真方式)。软件模拟被测对象可以在软件激励信号的作用下运行，生成软件执行结果。

本实现方式通过在对软件模拟被测对象进行测试时，利用专用的第一编译方式和第一仿真方式进行编译和仿真，可以实现与硬件模拟被测对象的编译和仿真过程分离，进一步提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的效率。

在一些可选的实现方式中，步骤204中，基于芯片设计数据，生成硬件模拟被测对象，包括：

基于第二编译方式，对芯片设计数据进行编译，得到硬件模拟被测对象。

其中，第二编译方式是对硬件模被测对象进行编译采用的方式。例如，第二编译方式可以是IXCOM编译(一种TBA模式的EMU验证的软硬件编译流程)方式。基于编译后的数据，可以得到硬件模拟被测对象。例如编译后的数据即可作为硬件模拟被测对象，或将编译后的数据进行一定的处理(例如对编译后的数据打包、拆解等方式)得到硬件模拟被测对象。

基于此，步骤205可以如下执行：

首先，将硬件模拟被测对象加载至硬件仿真设备。

其中，硬件仿真设备用于通过硬件仿真的方式模拟真实的芯片功能。作为示例，硬件仿真设备可以是现有的Palladium硬件仿真平台。

然后，基于硬件激励信号，控制硬件仿真设备按照第二仿真方式对硬件模拟被测对象进行仿真，得到硬件执行结果。

其中，第二仿真方式是用于对硬件模拟被测对象进行仿真的方式。例如XRUN仿真(一种TBA模式的EMU验证的仿真方式)。硬件仿真平台可以在硬件激励信号的作用下运行硬件模拟被测对象，生成硬件执行结果。

本实现方式通过在对硬件模拟被测对象进行测试时，利用专用的第二编译方式和第二仿真方式进行编译和仿真，可以实现与软件模拟被测对象的编译和仿真过程分离，进一步提高了在同一测试平台进行芯片的软件仿真验证和硬件仿真验证的效率。

下面参考图3，其示出了本公开的实施例的芯片功能验证方法的应用场景的一个示意图。如图3所示，该芯片功能验证方法在测试平台TestBench中实现。其中，Test Case301用于对测试任务进行描述，其内容可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。Virtual Sequence 302为TestBench的一个组件，负责根据测试用例产生测试激励，包括软件激励信号和硬件激励信号。Virtual Sequencer303为TestBench的一个组件，负责在Virtual Sequence 302和Driver 304之间传递测试激励。Driver 304为TestBench的一个组件，负责从Virtual Sequencer 303获得测试激励，并根据时序要求将软件激励信号通过第一软件驱动接口(即图中的IF00 305)驱动到软件模拟被测对象(即图中的DUT_SW 306)上，然后通过第二软件驱动接口(即图中的IF10 307)将DUT_SW 306生成的软件执行结果发送到TestBench中的监控组件(即图中的Monitor 308)，由Monitor 308输出及校验软件执行结果。

Driver 304将硬件激励信号通过第一硬件驱动接口(即图中的IF01 309)驱动到硬件模拟被测对象(即图中的DUT_HW 310)上。然后通过第二硬件驱动接口(即图中的IF11311)将DUT_HW 310生成的硬件执行结果发送到Monitor 308，由Monitor 308输出及校验软件执行结果。

图中的Agent_Master 312为输入激励代理，是Virtual Sequencer 303和Driver304的封装，Agent_Monitor 313为输出校验代理，是Monitor 308的封装。

图中的DUT_TOOLS_SW 314为软件测试辅助组件，DUT_TOOLS_HW 315为硬件测试辅助组件，分别用于对DUT_SW 306和DUT_HW 310进行辅助测试。DUT_TOP 316为硬件模拟子系统，是对DUT_TOOLS_HW 315、DUT_HW 310、IF01 309、IF11 311的顶层封装。

示例性装置

图4是本公开一示例性实施例提供的芯片功能验证装置的结构示意图。本实施例可应用在电子设备上，如图4所示，芯片功能验证装置包括：接收模块401，用于接收输入的验证工具选择参数；第一生成模块402，用于响应于确定验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；第一控制模块403，用于基于软件激励信号，控制软件模拟被测对象生成软件执行结果；第二生成模块404，用于应于确定验证工具选择参数表示硬件方式验证工具被选择，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号；第二控制模块405，用于基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

在本实施例中，接收模块401可以从本地或从远程接收输入的验证工具选择参数。其中，验证工具选择参数用于指示当前选择用于对芯片设计数据进行软件仿真验证的软件方式验证工具和/或用于对芯片设计数据进行硬件仿真验证的硬件方式验证工具。通常，上述软件方式验证工具可以是现有的EDA验证工具，可以运行在上述电子设备上。硬件方式验证工具可以是现有的EMU验证工具，包括EMU硬件(例如现有的Palladium硬件仿真平台)。

作为示例，本公开的实施例提供的芯片功能验证方法可以利用TestBench测试平台实现，在TestBench中，用户可以输入启动仿真命令加上工具类型参数作为验证工具选择参数。例如，run_cmd表示启动仿真命令，run_cmd eda表示用于EDA验证工具被选择进行芯片功能验证，run_cmd emu表示EMU验证工具被选择进行芯片功能验证。

在本实施例中，第一生成模块402可以响应于确定验证工具选择参数表示软件方式验证工具被选择，首先基于预设的芯片设计数据，生成软件模拟被测对象。

其中，芯片设计数据是预先设置的用于模拟芯片功能的数据(例如基于verilog语言编写的代码生成的数据)。软件模拟被测对象为通过软件模拟的方式生成的用于模拟芯片功能的软件代码块。芯片设计数据可以转换为软件方式验证工具支持的数据作为软件模拟被测对象，例如通过EDA验证工具进行编译，生成软件模拟被测对象。软件模拟被测对象通常只能在上述电子设备中运行，运行过程即模拟芯片的工作过程。针对软件模拟被测对象进行的验证过程可以为目前常用的EDA验证(详见上述背景技术和申请概述中的描述)。

然后，第一生成模块402可以基于预设的软件驱动代码生成软件激励信号。

其中，上述软件驱动代码用于生成软件激励信号，软件激励信号用于驱动上述软件模拟被测对象执行相应的芯片设计功能。通常，软件驱动代码可以是按照现有的UVM(Universal Verification Methodology，通用验证方法学)框架构建的代码。在该框架中，可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境，从而生成上述软件驱动代码。

在本实施例中，第一控制模块403可以基于软件激励信号，控制软件模拟被测对象生成软件执行结果。

通过软件激励信号，可以将软件模拟被测对象在执行时所需的数据输入软件模拟被测对象。例如，当软件模拟被测对象用来模拟加法器时，软件激励信号可以包括两个相加的数字，软件模拟被测对象将这两个数字相加，得到的计算结果即为软件执行结果。

在本实施例中，第二生成模块404可以响应于确定验证工具选择参数表示硬件方式验证工具被选择，首先基于芯片设计数据，生成硬件模拟被测对象。

其中，硬件模拟被测对象为模拟真实的硬件芯片的代码块，例如硬件模拟被测对象可以包括真实芯片内的各种门电路、地址线、数据线等实体。芯片设计数据可以转换为硬件方式验证工具支持的数据作为硬件模拟被测对象，例如通过EMU验证工具进行编译，生成硬件模拟被测对象。通常，硬件模拟被测对象的验证过程可以为目前常用的EMU验证(详见上述背景技术和申请概述中的描述)。由于硬件模拟被测对象是模拟真实硬件的，因此，硬件模拟被测对象通常可以直接被加载到硬件(例如现有的Palladium硬件仿真平台)中，并在硬件中运行仿真过程。

然后，第二生成模块404可以基于预设的硬件驱动代码生成硬件激励信号。上述硬件驱动代码用于生成硬件激励信号，硬件激励信号用于驱动上述硬件模拟被测对象执行相应的芯片设计功能。通常，硬件激励信号可以通过模拟真实芯片的接口输入到硬件模拟被测对象中。

在本实施例中，第二控制模块405可以基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果。

通过硬件激励信号，可以将硬件模拟被测对象在执行时所需的数据输入硬件模拟被测对象。例如，当硬件模拟被测对象用来模拟加法器时，硬件激励信号可以包括两个相加的数字，硬件模拟被测对象将这两个数字相加，得到的计算结果即为硬件执行结果。

参照图5，图5是本公开另一示例性实施例提供的芯片功能验证装置的结构示意图。

在一些可选的实现方式中，第一控制模块403包括：第一发送单元4031，用于将软件激励信号经由第一软件驱动接口发送至软件模拟被测对象；第一生成单元4032，用于基于软件模拟被测对象生成软件执行结果。

在一些可选的实现方式中，第一控制模块403还包括：第一输出单元4033，用于从第二软件驱动接口接收软件模拟被测对象生成的软件执行结果，并将软件执行结果输出。

在一些可选的实现方式中，第二控制模块405包括：第二发送单元4051，用于将软件激励信号经由第一硬件驱动接口发送至硬件模拟被测对象；第二生成单元4052，用于基于硬件模拟被测对象生成硬件执行结果。

在一些可选的实现方式中，第二控制模块405还包括：第二输出单元4053，用于从第二硬件驱动接口接收硬件模拟被测对象生成的硬件执行结果，并将硬件执行结果输出。

在一些可选的实现方式中，该装置还包括：第一辅助测试模块406，用于响应于用户对软件模拟被测对象进行的第一辅助测试操作，利用预设的软件测试辅助组件，对软件模拟被测对象实现的功能进行辅助测试；第二辅助测试模块407，用于响应于用户对硬件模拟被测对象进行的第二辅助测试操作，利用预设的硬件测试辅助组件，对硬件模拟被测对象实现的功能进行辅助测试。

在一些可选的实现方式中，第一生成模块402包括：第三生成单元4021，用于运行软件驱动代码，生成初始软件激励信号；第四生成单元4022，用于基于初始软件激励信号生成第一块级的软件激励信号。

在一些可选的实现方式中，第二生成模块404包括：第五生成单元4041，用于运行硬件驱动代码，生成初始硬件激励信号；第六生成单元4042，用于基于初始硬件激励信号生成第二块级的硬件激励信号。

在一些可选的实现方式中，第一生成模块402进一步用于：基于第一编译方式，对芯片设计数据进行编译，得到软件模拟被测对象；第一控制模块403进一步用于：基于软件激励信号，按照第一仿真方式对软件模拟被测对象进行仿真，得到软件执行结果。

在一些可选的实现方式中，第二生成模块404进一步用于：基于第二编译方式，对芯片设计数据进行编译，得到硬件模拟被测对象；第二控制模块405包括：第三发送单元4054，用于将硬件模拟被测对象加载至硬件仿真设备；仿真单元4055，用于基于硬件激励信号，控制硬件仿真设备按照第二仿真方式对硬件模拟被测对象进行仿真，得到硬件执行结果。

在一些可选的实现方式中，该装置还包括硬件模拟子系统，硬件模拟子系统408由硬件模拟被测对象的相关组件封装而成。其中，硬件模拟被测对象的相关组件包括硬件模拟被测对象本身，还可以包括但不限于上述各实施例中描述的以下至少一项：第一硬件驱动接口、第二硬件驱动接口、硬件测试辅助组件。如图3所示，DUT_TOP 316为本实施例的一个示例性结构，其是对DUT_TOOLS_HW 315(硬件测试辅助组件)、DUT_HW 310(硬件模拟被测对象)、IF01 309(第一硬件驱动接口)、IF11 311(第二硬件驱动接口)的顶层封装。

通过在芯片功能验证装置中设置硬件模拟子系统，可以实现将硬件验证相关的组件集成到一个部分，便于将软件验证和硬件验证分离，提高在同一测试平台对芯片设计进行软件验证和硬件验证的操作便利性。

本公开上述实施例提供的芯片功能验证装置，通过在输入的验证工具选择参数的控制下，选择软件方式验证工具或硬件方式验证工具，若选择软件方式验证工具，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号，基于软件激励信号，控制软件模拟被测对象生成软件执行结果，若选择硬件方式验证工具，基于芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号，基于硬件激励信号，控制硬件模拟被测对象生成硬件执行结果，从而实现了将软件方式验证工具和硬件方式验证工具融合在同一个测试平台下进行测试，在利用其中一个验证工具对被测对象进行测试后，无需再修改测试用例和调整测试平台即可利用另一个验证工具对另一个被测对象进行测试，可以实现快速地对针对同一芯片设计的不同类型的被测对象进行验证，降低了芯片验证成本，提高了芯片验证方法的复用性，有利于测试用例的跨平台移植。

示例性电子设备

下面，参考图6来描述根据本公开实施例的电子设备。该电子设备可以是如图1所示的终端设备101和服务器103中的任一个或两者、或与它们独立的单机设备，该单机设备可以与终端设备101和服务器103进行通信，以从它们接收所采集到的输入信号。

图6图示了根据本公开实施例的电子设备的框图。

如图6所示，电子设备600包括一个或多个处理器601和存储器602。

处理器601可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备600中的其他组件以执行期望的功能。

存储器602可以包括一个或多个计算机程序产品，计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器601可以运行程序指令，以实现上文的本公开的各个实施例的芯片功能验证方法以及/或者其他期望的功能。在计算机可读存储介质中还可以存储诸如验证工具选择参数等各种内容。

在一个示例中，电子设备600还可以包括：输入装置603和输出装置604，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。

例如，在该电子设备是终端设备101或服务器103时，该输入装置603可以是鼠标、键盘等设备，用于输入各种命令。在该电子设备是单机设备时，该输入装置603可以是通信网络连接器，用于从终端设备101和服务器103接收所输入的各种命令。

该输出装置604可以向外部输出各种信息，包括确定出的软件执行结果、硬件执行结果等。该输出设备604可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图6中仅示出了该电子设备600中与本公开有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备600还可以包括任何其他适当的组件。

示例性计算机程序产品和计算机可读存储介质

除了上述方法和设备以外，本公开的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的芯片功能验证方法中的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本公开的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的芯片功能验证方法中的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，在本公开中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本公开的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本公开为必须采用上述具体的细节来实现。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本公开中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

可能以许多方式来实现本公开的方法和装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。

还需要指出的是，在本公开的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本公开的等效方案。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本公开。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本公开的范围。因此，本公开不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本公开的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

Claims (11)

1.一种芯片功能验证方法，包括：

接收输入的验证工具选择参数；

响应于确定所述验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；

基于所述软件激励信号，控制所述软件模拟被测对象生成软件执行结果；

响应于确定所述验证工具选择参数表示硬件方式验证工具被选择，基于所述芯片设计数据，生成硬件模拟被测对象，，m-并基于预设的硬件驱动代码生成硬件激励信号；

基于所述硬件激励信号，控制所述硬件模拟被测对象生成硬件执行结果。

2.根据权利要求1所述的方法，其中，所述基于所述软件激励信号，控制所述软件模拟被测对象生成软件执行结果，包括：

将所述软件激励信号经由第一软件驱动接口发送至所述软件模拟被测对象；

基于所述软件模拟被测对象生成软件执行结果。

3.根据权利要求1所述的方法，其中，所述基于所述硬件激励信号，控制所述硬件模拟被测对象生成硬件执行结果，包括：

将所述软件激励信号经由第一硬件驱动接口发送至所述硬件模拟被测对象；

基于所述硬件模拟被测对象生成硬件执行结果。

4.根据权利要求1所述的方法，其中，所述方法还包括：

响应于用户对所述软件模拟被测对象进行的第一辅助测试操作，利用预设的软件测试辅助组件，对所述软件模拟被测对象实现的功能进行辅助测试；

响应于用户对所述硬件模拟被测对象进行的第二辅助测试操作，利用预设的硬件测试辅助组件，对所述硬件模拟被测对象实现的功能进行辅助测试。

5.根据权利要求1所述的方法，其中，所述基于预设的软件驱动代码生成软件激励信号，包括：

运行所述软件驱动代码，生成初始软件激励信号；

基于所述初始软件激励信号生成第一块级的软件激励信号。

6.根据权利要求1所述的方法，其中，所述基于预设的硬件驱动代码生成硬件激励信号，包括：

运行所述硬件驱动代码，生成初始硬件激励信号；

基于所述初始硬件激励信号生成第二块级的硬件激励信号。

7.根据权利要求1所述的方法，其中，所述基于预设的芯片设计数据，生成软件模拟被测对象，包括：

基于第一编译方式，对所述芯片设计数据进行编译，得到所述软件模拟被测对象；

所述基于所述软件激励信号，控制所述软件模拟被测对象生成软件执行结果，包括：

基于所述软件激励信号，按照第一仿真方式对所述软件模拟被测对象进行仿真，得到所述软件执行结果。

8.根据权利要求1所述的方法，其中，所述基于所述芯片设计数据，生成硬件模拟被测对象，包括：

基于第二编译方式，对所述芯片设计数据进行编译，得到所述硬件模拟被测对象；

所述基于所述硬件激励信号，控制所述硬件模拟被测对象生成硬件执行结果，包括：

将所述硬件模拟被测对象加载至硬件仿真设备；

基于所述硬件激励信号，控制所述硬件仿真设备按照第二仿真方式对所述硬件模拟被测对象进行仿真，得到所述硬件执行结果。

9.一种芯片功能验证装置，包括：

接收模块，用于接收输入的验证工具选择参数；

第一生成模块，用于响应于确定所述验证工具选择参数表示软件方式验证工具被选择，基于预设的芯片设计数据，生成软件模拟被测对象，并基于预设的软件驱动代码生成软件激励信号；

第一控制模块，用于基于所述软件激励信号，控制所述软件模拟被测对象生成软件执行结果；

第二生成模块，用于响应于确定所述验证工具选择参数表示硬件方式验证工具被选择，基于所述芯片设计数据，生成硬件模拟被测对象，并基于预设的硬件驱动代码生成硬件激励信号；

第二控制模块，用于基于所述硬件激励信号，控制所述硬件模拟被测对象生成硬件执行结果。

10.一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行上述权利要求1-8任一所述的方法。

11.一种电子设备，所述电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述权利要求1-8任一所述的方法。

Images