CN112668262B - SoC验证方法、系统、装置和计算机可读介质 - Google Patents

Abstract

本申请提供了一种SoC验证方法、系统、装置和计算机可读介质。该方法包括获取公用平台文件；获取保存在用户本地的用户平台文件；接收用户对用户文件和/或用户配置单元的修改；运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中系统级验证平台文件包括公用平台文件和用户平台文件；通过软件激励编译环境对软件激励和结果检测程序进行编译并生成二进制文件；以及基于可执行文件和二进制文件对SoC进行仿真验证并得到验证报告。该方法能够大幅度减少搭建系统级验证平台的时间和提高SoC验证工作的效率。

Description

SoC验证方法、系统、装置和计算机可读介质

技术领域

本申请主要涉及芯片验证领域，尤其涉及一种SoC验证方法、系统、装置和计算机可读介质。

背景技术

随着半导体工艺的发展，半导体集成电路已发展为系统芯片(SoC)的形式，通常一个SoC的规模在几百万门至几千万门左右。SoC验证是使用电子设计自动化(ElectronicDesign Automation，EDA)工具对SoC进行仿真验证，以确保SoC设计的正确性。

SoC验证平台由Verilog、VHDL、SystemVerilog等硬件描述语言或硬件验证语言构建。SoC验证平台中的测试激励包括软件激励和硬件激励两种类型的激励，通过对SoC施加这些激励进行仿真验证。其中，软件激励由C语言等软件语言编码后经编译器编译生成二进制文件，存放在SoC 的存储器中；硬件激励由硬件描述语言或硬件验证语言编码。验证平台和 SoC硬件代码经过仿真工具编译后，生成可执行文件，然后运行可执行文件进行仿真。仿真开始后，CPU从存储器中程序存储器中读取指令并执行，通过预先设置的判断条件，可以检测SoC是否能够完成设计的功能，即 SoC是否通过验证。

由于SoC的复杂度越来越高，验证平台也会变得更加复杂。验证平台越复杂，验证平台本身存在的问题也会越多。因此，如何能够在较短时间内解决SoC验证平台自身的问题，完成一个正常运行的SoC验证平台的搭建，是本领域技术人员亟需解决的问题。

发明内容

本申请要解决的技术问题是提供一种SoC验证方法、系统、装置和计算机可读介质，能够大幅度减少搭建系统级验证平台的时间和提高SoC验证工作的效率。

为解决上述技术问题，本申请提供了一种SoC验证方法，包括：获取公用平台文件，所述公用平台文件至少包括软件激励编译环境和公用硬件激励；获取保存在用户本地的用户平台文件，所述用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序；接收用户对所述用户文件和/或所述用户配置单元的修改；运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中所述系统级验证平台文件包括所述公用平台文件和所述用户平台文件；通过所述软件激励编译环境对软件激励和所述结果检测程序进行编译并生成二进制文件，其中所述软件激励至少包括所述用户软件激励；以及基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告。

在本申请的一实施例中，所述公用平台文件还包括公用配置单元；所述方法还包括：基于所述验证报告判断是否存在问题，若不存在问题则结束；若存在问题，当接收到用户对所述软件激励编译环境和/或所述软件激励的修改时，重新通过所述软件激励编译环境对所述软件激励和所述结果检测程序进行编译并生成新的二进制文件；若存在问题，当接收到用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件；以及若存在问题，当接收到用户对所述SoC硬件代码的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件。

在本申请的一实施例中，所述若存在问题，当接收到用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件的步骤包括：当所述用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改包括对所述公用配置单元的修改时，根据所述对公用配置单元的修改在所述公用平台文件中进行相应修改，并在所述用户平台文件中修改与所述对所述公用配置单元的修改相对应的代码；当所述用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改包括对所述用户文件和/或所述用户配置单元的修改时，根据所述对所述用户文件和/或所述用户配置单元的修改在所述用户平台文件中进行相应修改；以及重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件。

在本申请的一实施例中，所述公用平台文件还包括公用软件激励，所述软件激励还包括公用软件激励。

在本申请的一实施例中，所述方法还包括：接收用户编写的所述软件激励。

在本申请的一实施例中，所述二进制文件包括公用二进制文件和用户二进制文件；所述公用平台文件还包括顶层文件；所述基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告包括：所述顶层文件加载所述公用二进制文件到SoC存储器的第一指定地址；所述用户文件加载所述用户二进制文件到所述SoC存储器的第二指定地址；从所述SoC 存储器读取所述公用二进制文件；从所述SoC存储器读取所述用户二进制文件；基于所述公用二进制文件中的指令进行所述SoC的启动和模块初始化；基于所述用户二进制文件中的指令控制所述SoC的运行；以及根据结果检测指令检测SoC运行结果并得到所述验证报告。

在本申请的一实施例中，所述用户平台文件还包括结果检测程序；所述根据结果检测指令检测SoC运行结果并得到所述验证报告的步骤包括：使用所述结果检测程序检测所述SoC运行结果得到所述SoC输出的GPIO 信号；基于所述用户文件检查所述GPIO信号是否出现预期变化；当出现预期变化时，根据所述GPIO信号打印相应的验证通过信息或验证未通过信息到所述验证报告中；以及当未出现预期变化时，在经过预设时间后打印验证强制结束信息到所述验证报告中，并强制结束。

在本申请的一实施例中，所述公用平台文件还包括公用管理单元、顶层文件、公用配置单元、公用控制单元和公用软件激励。

在本申请的一实施例中，所述用户平台文件还包括用户管理单元和用户控制单元。

为解决上述技术问题，本申请还提供了一种SoC验证系统，包括：存储器，用于存储可由处理器执行的指令；以及处理器，用于执行所述指令以实现如上所述的SoC验证方法。

为解决上述技术问题，本申请还提供了一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如上所述的 SoC验证方法。

为解决上述技术问题，本申请还提供了一种SoC验证装置，包括：公用平台获取模块，用于获取公用平台文件，所述公用平台文件至少包括软件激励编译环境和公用硬件激励；用户平台获取模块，用于获取保存在用户本地的用户平台文件，所述用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序；接收模块，用于接收用户对所述用户文件和/或所述用户配置单元的修改；编译模块，用于运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中所述系统级验证平台包括所述公用平台文件和所述用户平台文件；第一软件编译模块，用于通过所述软件激励编译环境对软件激励和所述结果检测程序进行编译并生成二进制文件，其中所述软件激励至少包括所述用户软件激励；以及仿真验证模块，用于基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告。

在本申请的一实施例中，所述公用平台文件还包括公用配置单元；所述装置还包括：判断模块，用于基于所述验证报告判断是否存在问题，若不存在问题则结束；第二软件编译模块，用于若存在问题，当接收到用户对所述软件激励编译环境和/或所述软件激励的修改时，重新通过所述软件激励编译环境对所述软件激励和所述结果检测程序进行编译并生成新的二进制文件；第一修改模块，用于若存在问题，当接收到用户对所述用户文件和/或所述用户配置单元的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件；以及第二修改模块，用于若存在问题，当接收到用户对所述SoC硬件代码的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述 SoC硬件代码进行编译并生成新的可执行文件。

与现有技术相比，本申请的SoC验证方法、系统、装置和计算机可读介质能够大幅度减少搭建系统级验证平台的时间和提高SoC验证工作的效率。

附图说明

包括附图是为提供对本申请进一步的理解，它们被收录并构成本申请的一部分，附图示出了本申请的实施例，并与本说明书一起起到解释本申请原理的作用。附图中：

图1是根据本申请一实施例示出的SoC验证方法的流程示意图；

图2是根据本申请一实施例示出的图1的步骤106的流程示意图；

图3是根据本申请一实施例示出的图2的步骤207的流程示意图；

图4是根据本申请一实施例示出的SoC验证装置的示意框图；

图5是根据本申请一实施例示出的SoC验证系统的系统框图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，或将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请提供了一种SoC验证方法。图1是根据本申请一实施例示出的 SoC验证方法的流程示意图。如图1所示，本实施例的SoC验证方法包括以下步骤101-106：

步骤101，获取公用平台文件，公用平台文件至少包括软件激励编译环境和公用硬件激励；

步骤102，获取保存在用户本地的用户平台文件，用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序；

步骤103，接收用户对用户文件和/或用户配置单元的修改；

步骤104，运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中系统级验证平台文件包括公用平台文件和用户平台文件；

步骤105，通过软件激励编译环境对软件激励和结果检测程序进行编译并生成二进制文件，其中软件激励至少包括用户软件激励；以及

步骤106，基于可执行文件和二进制文件对SoC进行仿真验证并得到验证报告。

下面对上述步骤101-106进行详细说明，步骤101-106可以由SoC验证系统来执行：

在步骤101中，系统获取公用平台文件，公用平台文件至少包括软件激励编译环境和公用硬件激励。公用平台文件是用于搭建公用平台的文件，用户可使用Verilog或SystemVerilog等软件编写公用平台文件，本申请对此不作限定。公用平台可以包括进行SoC验证时所需的基础模块，这些模块为每个验证SoC的用户共同使用。公用硬件激励可以指验证SoC时所需要的基础的硬件激励，包括时钟、复位以及对SoC硬件代码中一些信号的操作等。软件激励编译环境可以用于对公用软件激励、用户软件激励和结果检测程序进行编译，例如生成SoC处理器启动时需要的二进制文件以及用户需要SoC处理器执行的二进制文件等。软件激励编译环境包含编译所需的编译器、脚本、头文件等文件，并且把编译出来的二进制文件放到指定位置。

在本申请的一实施例中，公用平台文件还可以包括公用软件激励，公用软件激励属于软件激励。公用软件激励可以为SoC正常启动和运行所需要的一系列软件程序，包括SoC启动所需的软件激励以及SoC中一些模块的初始化程序等。

在本申请的一实施例中，公用平台文件还可以包括公用管理单元、顶层文件、公用配置单元、公用控制单元和公用软件激励。顶层文件可以用于实例化待测试的SoC的硬件代码、加载公用软件激励的二进制文件到SoC 存储器等，可以由Verilog或SystemVerilog编写。公用配置单元可以用于对整个验证平台进行配置，包括验证环境需要的公用的宏定义参数、以及其他验证需要的配置文件等。公用控制单元可以用于对整个验证平台的操作进行控制，例如对整个验证平台进行编译、启动仿真等。公用管理单元可以用于对验证所用的工具等进行设置，以实现验证工具、SoC硬件代码版本的统一管理，避免由于工具和版本等引起的验证结果不可靠等问题。通过使用公共平台的公用管理单元，可以确保每个验证人员使用的验证工具、SoC硬件代码版本是统一的，避免了工具和版本导致的问题，使验证人员能够更多地关注SoC硬件代码本身的问题，提高验证的效率和可靠性。

在步骤102中，系统获取保存在用户本地的用户平台文件，用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序。用户平台文件是用于搭建用户平台的文件。用户平台在本地搭建，可以使用脚本或图形界面等方式。在一个示例中，用户可以参考公用平台自行搭建用户平台，或者通过脚本自动搭建用户平台。用户的验证工作在用户平台中进行，例如用户软件激励的编写、用户的自定义配置、验证结果的检测等。用户文件可以包含用户根据自己验证的需要所自定义的一些任务或指令，其中可以包括加载用户软件激励的二进制文件到SoC的存储器、自定义验证的停止条件以结束验证进程、信息的打印以及设置仿真运行的结束的时间等，还可以对SoC硬件代码中的一些信号进行操作。用户配置单元可以用于使用户对本地验证环境运行时做出设置，例如是否去掉不需要仿真的模块、是否保存波形、是否统计覆盖率等，用户可以根据需要对这些功能进行取舍，以达到节省仿真验证服务器资源和加快仿真验证速度的目的。用户软件激励可以为用户编写的软件程序，以通过SoC中的处理器控制SoC的运行。结果检测程序可以为用户编写的检测程序，用于检测仿真结果是否符合预期，并操作SoC硬件代码中的某些信号，这些信号可以作为用户文件判断验证是否通过的条件。

在本申请的一实施例中，用户平台文件还可以包括用户管理单元和用户控制单元。用户管理单元可以用于通过引用公用管理单元来实现与公用平台统一的工具和硬件代码版本。此外，用户管理单元还可以保留用户自行管理的接口，用户可以根据验证工作的需要自行修改工具SoC硬件代码版本等。用户控制单元可以用于通过调用公用控制单元来控制编译和验证的操作。

在步骤103中，系统接收用户对用户文件和/或用户配置单元的修改。用户可以根据验证需要来修改用户文件和/或用户配置单元。修改用户文件可以包括设置验证是否通过的判断条件、设置验证停止的时间、验证信息的打印等。修改用户配置单元可以包括对验证环境进行配置，例如对不需要验证的SoC硬件代码中的模块进行屏蔽、对是否保存波形文件进行设置、对是否收集覆盖率进行设置等。

在步骤104中，系统运行用户控制脚本对系统级验证平台文件和SoC 硬件代码进行编译并生成可执行文件。可执行文件是指仿真工具对验证平台和SoC硬件代码进行分析和elaborate(可理解为编译)以后生成目标代码，把目标代码和SoC硬件代码静态链接产生的二进制可执行文件。通过运行这个二进制可执行文件能够进行仿真。系统级验证平台文件包括公用平台文件和用户平台文件，系统级验证平台文件用于搭建系统级验证平台，系统级验证平台由公用平台和用户平台两部分组成。

在步骤105中，系统通过软件激励编译环境对软件激励和结果检测程序进行编译并生成二进制文件，其中软件激励至少包括用户软件激励。在本申请的一实施例中，该SoC验证方法还可以包括：接收用户编写的软件激励。软件激励使用软件语言编写，通过软件激励编译环境进行编译。在本申请的一实施例中，二进制文件可以包括公用二进制文件和用户二进制文件。公用二进制文件放到公用平台指定目录，用户二进制文件并放到用户指定目录。

在步骤106中，系统基于可执行文件和二进制文件对SoC进行仿真验证并得到验证报告。

图2是根据本申请一实施例示出的图1的步骤106的流程示意图。在本申请的一实施例中，如图2所示，步骤106可以包括以下步骤201-207：

步骤201，顶层文件加载公用二进制文件到SoC存储器的第一指定地址；

步骤202，用户文件加载用户二进制文件到SoC存储器的第二指定地址；

步骤203，从SoC存储器读取公用二进制文件；

步骤204，从SoC存储器读取用户二进制文件；

步骤205，基于公用二进制文件中的指令进行SoC的启动和模块初始化；

步骤206，基于用户二进制文件中的指令控制SoC的运行；以及

步骤207，根据结果检测指令检测SoC运行结果并得到验证报告。

其中，步骤201和202可以同时进行，也可以依次执行，本申请对执行顺序不做限定。如果公用软件激励没有修改则无需每次都编译，而用户软件激励可以每次都编译。

图3是根据本申请一实施例示出的图2的步骤207的流程示意图。在本申请的一实施例中，如图3所示，步骤207可以包括以下步骤301-304：

步骤301，使用结果检测程序检测SoC运行结果得到SoC输出的GPIO (General-purpose input/output，通用型之输入输出)信号；

步骤302，基于用户文件检查GPIO信号是否出现预期变化，当出现预期变化时进入步骤303，当未出现预期变化时进入步骤304；

步骤303，根据GPIO信号打印相应的验证通过信息或验证未通过信息到验证报告中；以及

步骤304，在经过预设时间后打印验证强制结束信息到验证报告中，并强制结束。

通过步骤301-304，系统能够适用软件编写的结构检测程序判断SoC 仿真运行的结果是否符合预期，并通过SoC输出的GPIO信号作为结果检测程序与用户文件传递信息的媒介，使得用户文件能够根据GPIO信号打印相应的验证结果。当GPIO信号未出现预期变化时，用户文件不能检查到表示验证通过或验证未通过的GPOI信号，则系统在经过一定时间后打印验证强制结束信息到验证报告，并强制结束仿真进程，以减少服务器资源的浪费。

通过上述步骤201-207将二进制文件分为公用二进制文件和用户二进制文件，让用户能够在修改二进制文件时灵活地根据需要选择修改对象。当不涉及公用部分的修改时，用户可以选择只修改用户二进制文件。当涉及公用部分的修改时，可以直接在公共平台的公用二进制文件进行修改，不需要所有验证人员再一一自行修改，能够大幅度节省验证人员的时间和提高验证效率。并且，将二进制文件分为公用二进制文件和用户二进制文件能够避免其中一个的修改对另一个造成影响，提高了验证的稳定性。

在本申请的一实施例中，系统可以在有中间结果输出的任一步骤后对该步骤所输出的中间结果进行检查来定位验证中的问题。

综上步骤101-106所述，本申请的SoC验证方法能够减少搭建系统级验证平台的时间和提高验证工作的效率，并具有以下技术效果：

1、使用公用平台和用户平台相结合的方式，在公用平台具备基本的功能以后，即可让更多的验证人员使用，这能够让更多的验证人员提前开始验证工作，而不必等待完整的验证平台再开始验证工作；

2、使用公用平台和用户平台相结合的方式，在多个用户使用的情况下，能够更快发现系统级验证平台的问题，在新建一个验证平台或者验证平台改动较大的情况下，能够更快地完成系统级验证平台的搭建和排除系统级验证平台的问题；

3、使用公用平台和用户平台相结合的方式，具有更好的扩展性，能够根据用户验证需求的不同在用户平台中定制配置文件，关闭仿真中一些不必要的功能，减少对验证服务器资源的占用，同时减少仿真运行的时间；

4、使用公用平台和用户平台相结合的方式，能够将一些共有的硬件激励和配置问题放到公用平台，简化用户在验证时的操作流程；

5、使用软硬件协同仿真的方式，以软件激励和软件编写的结果检测程序为实现验证的主要部分，编写和编译软件激励时不需要对整个系统级验证平台进行编译，能够尽量减少系统级验证平台编译的次数，从而节省验证工作的时间和提高效率；

6、具有更好的可重用性，可以作为模板或素材，实现验证平台库的建设；

7、用户可以通过用户平台在特殊场景下根据验证工作的需求，自行修改用户文件和/或用户配置单元，提高了验证平台的灵活性。

在本申请的一实施例中，该方法还可以包括以下步骤107-110：

步骤107，基于验证报告判断是否存在问题，若不存在问题则结束，若存在问题，则进入步骤108-110中的一个或多个步骤；

步骤108，当接收到用户对软件激励编译环境和/或软件激励的修改时，重新通过软件激励编译环境对软件激励和结果检测程序中进行编译并生成新的二进制文件；

步骤109，当接收到用户对用户文件、用户配置单元和公用配置单元中的一项或多项时，重新运行用户控制脚本对系统级验证平台文件和SoC 硬件代码进行编译并生成新的可执行文件；以及

步骤110，当接收到用户对SoC硬件代码的修改时，重新运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成新的可执行文件。

下面对上述步骤107-110进行详细说明，步骤107-110可以由SoC验证系统来执行：

在步骤107中，系统基于验证报告判断是否存在问题，若不存在问题则结束。若存在问题，则进入步骤108-110中的一个或多个步骤，用户需要对系统级验证平台文件和/或SoC硬件代码进行修改。

在步骤108中，当用户通过问题定位判断需要修改软件时，用户可以对软件激励编译环境和/或软件激励进行修改。当接收到用户对软件激励编译环境和/或软件激励的修改时，系统基于修改后的软件激励编译环境和/ 或软件激励重新通过软件激励编译环境对软件激励和结果检测程序进行编译并生成新的二进制文件。

在步骤109中，当用户通过问题定位判断需要修改用户文件、用户配置单元和公用配置单元中的一项或多项时，用户可以对用户文件、用户配置单元和公用配置单元中的一项或多项进行修改。当接收到用户对用户文件、用户配置单元和公用配置单元中的一项或多项的修改时，系统基于修改后的用户文件、用户配置单元和公用配置单元中的一项或多项重新运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成新的可执行文件。

在本申请的一实施例中，步骤109可以包括以下步骤109a-109c：

步骤109a，当用户对用户文件、用户配置单元和公用配置单元中的一项或多项的修改包括对公用配置单元的修改时，也就是说用户对公用配置单元进行了修改时，系统根据对公用配置单元的修改在公用平台文件中进行相应修改，并在用户平台文件中修改与对公用配置单元的修改相对应的代码；

步骤109b，当用户对用户文件、用户配置单元和公用配置单元中的一项或多项的修改包括对平台的修改时，也就是说用户对用户文件和/或用户配置单元进行了修改时，系统根据对用户文件和/或用户配置单元的修改在用户平台文件中进行相应修改；以及

步骤109c，系统重新运行用户控制脚本对系统级验证平台文件和SoC 硬件代码进行编译并生成新的可执行文件。

在步骤109a中，当用户通过对问题定位进行判断后认为问题是通用问题时，即问题为公用平台的问题，用户可以选择在公用配置单元中进行修改。通过在公用配置单元中进行修改，可以让其它用户使用系统进行验证时避免出现相同问题，进一步地提高了验证效率。当用户在公用配置单元进行了修改时，需要在用户平台文件中修改与该修改相对应的代码。例如，当用户在公用配置单元增加了一段原本在用户平台文件中的代码，则需要在用户平台文件中删除与该修改相对应的代码，避免出现重复的情况。又如，当用户在公用配置单元删除了一段代码，则需要在用户平台文件中增加与该修改相对应的代码，避免出现代码缺失的情况。

在步骤109b中，当用户通过对问题定位进行判断后认为问题不是通用问题时，用户可以选择在用户平台文件中的用户文件和/或用户配置单元进行修改。在用户平台文件中的修改不会影响到其它用户的验证。

在步骤110中，当用户通过问题定位判断需要修改SoC硬件代码时，用户可以对SoC硬件代码进行修改。当接收到用户对SoC硬件代码的修改时，系统重新运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成新的可执行文件。

步骤108-110可以同时进行，也可以依次执行，本申请对执行顺序不做限定。

综上步骤107-110所述，当验证出现问题时，用户能够根据实际需要灵活地对系统级验证平台进行修改，进一步地提高了验证效率和可靠性。

本申请还提供了一种SoC验证装置。图4是根据本申请一实施例示出的SoC验证装置的示意框图。如图4所示，SoC验证装置400包括公用平台获取模块401、用户平台获取模块402、接收模块403、编译模块404、第一软件编译模块405以及仿真验证模块406。

公用平台获取模块401用于获取公用平台文件，公用平台文件至少包括软件激励编译环境和公用硬件激励。公用平台获取模块401所执行的步骤可以参考前述实施例中对步骤101的描述，在此不再赘述。

用户平台获取模块402用于获取保存在用户本地的用户平台文件，用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序。用户平台获取模块402所执行的步骤可以参考前述实施例中对步骤 102的描述，在此不再赘述。

接收模块403用于接收用户对用户文件和/或用户配置单元的修改。接收模块403所执行的步骤可以参考前述实施例中对步骤103的描述，在此不再赘述。

编译模块404用于运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中系统级验证平台包括公用平台文件和用户平台文件。编译模块404所执行的步骤可以参考前述实施例中对步骤104的描述，在此不再赘述。

第一软件编译模块405用于通过软件激励编译环境对软件激励和结果检测程序进行编译并生成二进制文件，其中软件激励至少包括用户软件激励。第一软件编译模块405所执行的步骤可以参考前述实施例中对步骤105 的描述，在此不再赘述。

仿真验证模块406用于基于可执行文件和二进制文件对SoC进行仿真验证并得到验证报告。仿真验证模块406所执行的步骤可以参考前述实施例中对步骤106的描述，在此不再赘述。

本申请的SoC验证装置能够减少搭建系统级验证平台的时间和提高验证工作的效率，并具有以下技术效果：

1、使用公用平台和用户平台相结合的方式，在公用平台具备基本的功能以后，即可让更多的验证人员使用，这能够让更多的验证人员提前开始验证工作，而不必等待完整的验证平台再开始验证工作；

2、使用公用平台和用户平台相结合的方式，在多个用户使用的情况下，能够更快发现系统级验证平台的问题，在新建一个验证平台或者验证平台改动较大的情况下，能够更快地完成系统级验证平台的搭建和排除系统级验证平台的问题；

3、使用公用平台和用户平台相结合的方式，具有更好的扩展性，能够根据用户验证需求的不同在用户平台中定制配置文件，关闭仿真中一些不必要的功能，减少对验证服务器资源的占用，同时减少仿真运行的时间；

4、使用公用平台和用户平台相结合的方式，能够将一些共有的硬件激励和配置问题放到公用平台，简化用户在验证时的操作流程；

5、使用软硬件协同仿真的方式，以软件激励和软件编写的结果检测程序为实现验证的主要部分，编写和编译软件激励时不需要对整个系统级验证平台进行编译，能够尽量减少系统级验证平台编译的次数，从而节省验证工作的时间和提高效率；

6、具有更好的可重用性，可以作为模板或素材，实现验证平台库的建设；

7、用户可以通过用户平台在特殊场景下根据验证工作的需求，自行修改用户文件和/或用户配置单元，提高了验证平台的灵活性。

在本申请的一实施例中，该SoC验证装置400还可以包括判断模块407、第二软件编译模块408、第一修改模块409以及第二修改模块410，公用平台文件还可以包括公用配置单元。

判断模块407用于基于验证报告判断是否存在问题，若不存在问题则结束。判断模块407所执行的步骤可以参考前述实施例中对步骤107的描述，在此不再赘述。

第二软件编译模块408用于若存在问题，当接收到用户对软件激励编译环境和/或软件激励的修改时，重新通过软件激励编译环境对软件激励和结果检测程序中进行编译并生成新的二进制文件。第二软件编译模块408 所执行的步骤可以参考前述实施例中对步骤108的描述，在此不再赘述。

第一修改模块409用于若存在问题，当接收到用户对用户文件和/或用户配置单元的修改时，重新运行用户控制脚本对系统级验证平台文件和 SoC硬件代码进行编译并生成新的可执行文件。第一修改模块409所执行的步骤可以参考前述实施例中对步骤109的描述，在此不再赘述。

第二修改模块410用于若存在问题，当接收到用户对SoC硬件代码的修改时，重新运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成新的可执行文件。第二修改模块410所执行的步骤可以参考前述实施例中对步骤110的描述，在此不再赘述。

通过SoC验证装置400的上述模块407-410，当验证出现问题时，用户能够根据实际需要灵活地对系统级验证平台进行修改，进一步地提高了验证效率和可靠性。

本申请还提供了一种SoC验证系统，包括：存储器，用于存储可由处理器执行的指令；以及处理器，用于执行所述指令以实现如上所述的SoC 验证方法。

图5是根据本申请一实施例示出的SoC验证系统的系统框图。SoC验证系统500可包括内部通信总线501、处理器(Processor)502、只读存储器(ROM)503、随机存取存储器(RAM)504、以及通信端口505。当应用在个人计算机上时，SoC验证系统500还可以包括硬盘507。内部通信总线501可以实现SoC验证系统500组件间的数据通信。处理器502可以进行判断和发出提示。在一些实施例中，处理器502可以由一个或多个处理器组成。通信端口505可以实现SoC验证系统500与外部的数据通信。在一些实施例中，SoC验证系统500可以通过通信端口505从网络发送和接受信息及数据。SoC验证系统500还可以包括不同形式的程序储存单元以及数据储存单元，例如硬盘507，只读存储器(ROM)503和随机存取存储器(RAM)504，能够存储计算机处理和/或通信使用的各种数据文件，以及处理器502所执行的可能的程序指令。处理器执行这些指令以实现方法的主要部分。处理器处理的结果通过通信端口传给用户设备，在用户界面上显示。

上述的SoC验证方法可以实施为计算机程序，保存在硬盘507中，并可记载到处理器502中执行，以实施本申请中的任一种SoC验证方法。

本申请还提供了一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如上所述的SoC验证方法。

SoC验证方法实施为计算机程序时，也可以存储在计算机可读存储介质中作为制品。例如，计算机可读存储介质可以包括但不限于磁存储设备 (例如，硬盘、软盘、磁条)、光盘(例如，压缩盘(CD)、数字多功能盘(DVD))、智能卡和闪存设备(例如，电可擦除可编程只读存储器 (EPROM)、卡、棒、键驱动)。此外，本文描述的各种存储介质能代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于能存储、包含和/或承载代码和/或指令和/或数据的无线信道和各种其它介质(和/或存储介质)。

应该理解，上文所描述的实施例仅是示意。本文描述的实施例可在硬件、软件、固件、中间件、微码或者其任意组合中实现。对于硬件实现，处理单元可以在一个或者多个特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器和/或设计为执行本文所述功能的其它电子单元或者其结合内实现。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述申请披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示例性实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

本申请的一些方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。处理器可以是一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理器件(DAPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器或者其组合。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。例如，计算机可读介质可包括，但不限于，磁性存储设备(例如，硬盘、软盘、磁带……)、光盘(例如，压缩盘CD、数字多功能盘DVD……)、智能卡以及闪存设备(例如，卡、棒、键驱动器……)。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个申请实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

虽然本申请已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本申请，在没有脱离本申请精神的情况下还可做出各种等效的变化或替换，因此，只要在本申请的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。

Claims (11)

1.一种SoC验证方法，包括：

获取公用平台文件，所述公用平台文件至少包括软件激励编译环境、公用配置单元和公用硬件激励；

获取保存在用户本地的用户平台文件，所述用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序；

接收用户对所述用户文件和/或所述用户配置单元的修改；

运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中所述系统级验证平台文件包括所述公用平台文件和所述用户平台文件；

通过所述软件激励编译环境对软件激励和所述结果检测程序进行编译并生成二进制文件，其中所述软件激励至少包括所述用户软件激励；以及

基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告；

基于所述验证报告判断是否存在问题，若不存在问题则结束；

若存在问题，当接收到用户对所述软件激励编译环境和/或所述软件激励的修改时，重新通过所述软件激励编译环境对所述软件激励和所述结果检测程序进行编译并生成新的二进制文件；

若存在问题，当接收到用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件；以及

若存在问题，当接收到用户对所述SoC硬件代码的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件。

2.如权利要求1所述的方法，其特征在于，所述若存在问题，当接收到用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件的步骤包括：

当所述用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改包括对所述公用配置单元的修改时，根据所述对公用配置单元的修改在所述公用平台文件中进行相应修改，并在所述用户平台文件中修改与所述对所述公用配置单元的修改相对应的代码；

当所述用户对所述用户文件、所述用户配置单元和所述公用配置单元中的一项或多项的修改包括对所述用户文件和/或所述用户配置单元的修改时，根据所述对所述用户文件和/或所述用户配置单元的修改在所述用户平台文件中进行相应修改；以及

重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件。

3.如权利要求1所述的方法，其特征在于，所述公用平台文件还包括公用软件激励，所述软件激励还包括公用软件激励。

4.如权利要求1或3所述的方法，其特征在于，还包括：

接收用户编写的所述软件激励。

5.如权利要求1或3所述的方法，其特征在于，所述二进制文件包括公用二进制文件和用户二进制文件；所述公用平台文件还包括顶层文件；所述基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告包括：

所述顶层文件加载所述公用二进制文件到SoC存储器的第一指定地址；

所述用户文件加载所述用户二进制文件到所述SoC存储器的第二指定地址；

从所述SoC存储器读取所述公用二进制文件；

从所述SoC存储器读取所述用户二进制文件；

基于所述公用二进制文件中的指令进行所述SoC的启动和模块初始化；

基于所述用户二进制文件中的指令控制所述SoC的运行；以及

根据结果检测指令检测SoC运行结果并得到所述验证报告。

6.如权利要求5所述的方法，其特征在于，所述用户平台文件还包括结果检测程序；所述根据结果检测指令检测SoC运行结果并得到所述验证报告的步骤包括：

使用所述结果检测程序检测所述SoC运行结果得到所述SoC输出的GPIO信号；

基于所述用户文件检查所述GPIO信号是否出现预期变化；

当出现预期变化时，根据所述GPIO信号打印相应的验证通过信息或验证未通过信息到所述验证报告中；以及

当未出现预期变化时，在经过预设时间后打印验证强制结束信息到所述验证报告中，并强制结束。

7.如权利要求1所述的方法，其特征在于，所述公用平台文件还包括公用管理单元、顶层文件、公用配置单元、公用控制单元和公用软件激励。

8.如权利要求1所述的方法，其特征在于，所述用户平台文件还包括用户管理单元和用户控制单元。

9.一种SoC验证系统，包括：

存储器，用于存储可由处理器执行的指令；以及处理器，用于执行所述指令以实现如权利要求1-8任一项所述的方法。

10.一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如权利要求1-8任一项所述的方法。

11.一种SoC验证装置，包括：

公用平台获取模块，用于获取公用平台文件，所述公用平台文件至少包括软件激励编译环境、公用配置单元和公用硬件激励；

用户平台获取模块，用于获取保存在用户本地的用户平台文件，所述用户平台文件至少包括用户文件、用户配置单元、用户软件激励和结果检测程序；

接收模块，用于接收用户对所述用户文件和/或所述用户配置单元的修改；

编译模块，用于运行用户控制脚本对系统级验证平台文件和SoC硬件代码进行编译并生成可执行文件，其中所述系统级验证平台包括所述公用平台文件和所述用户平台文件；

第一软件编译模块，用于通过所述软件激励编译环境对软件激励和所述结果检测程序进行编译并生成二进制文件，其中所述软件激励至少包括所述用户软件激励；

仿真验证模块，用于基于所述可执行文件和所述二进制文件对SoC进行仿真验证并得到验证报告；

判断模块，用于基于所述验证报告判断是否存在问题，若不存在问题则结束；

第二软件编译模块，用于若存在问题，当接收到用户对所述软件激励编译环境和/或所述软件激励的修改时，重新通过所述软件激励编译环境对所述软件激励和所述结果检测程序进行编译并生成新的二进制文件；

第一修改模块，用于若存在问题，当接收到用户对所述用户文件和/或所述用户配置单元的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件；以及

第二修改模块，用于若存在问题，当接收到用户对所述SoC硬件代码的修改时，重新运行所述用户控制脚本对所述系统级验证平台文件和所述SoC硬件代码进行编译并生成新的可执行文件。

Images