CN116341428B - 构建参考模型的方法、芯片验证方法及系统 - Google Patents

Abstract

本申请提供了构建参考模型的方法、芯片验证方法及系统，其响应于收到芯片的硬件规范定义，在与参考模型对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义，根据经修改后的硬件描述文件更新所述参考模型的头文件，并根据更新后的参考模型头文件调整参考模型以使其适配新版本的硬件定义，以及利用经调整后的参考模型对基于所述硬件规范定义实现的寄存器转换级电路进行功能验证。该方案通过加速参考模型的开发，缩短了芯片设计时间并提高了芯片设计效率。

Description

构建参考模型的方法、芯片验证方法及系统

技术领域

本申请涉及芯片技术领域，尤其涉及构建参考模型的方法、基于参考模型的芯片验证方法及系统。

背景技术

本部分的陈述仅仅是为了提供与本申请的技术方案有关的背景信息，以帮助理解，其对于本申请的技术方案而言并不一定构成现有技术。

芯片验证是指在流片前，对每一个环节的芯片设计所进行的检验，目的是确保当前设计阶段的产出能满足芯片设计规范所定义的功能和性能要求。在芯片设计开发的过程中验证技术非常重要，基本能占据芯片产品开发时间的70%左右，占代码总量的80%左右。按照自顶向下的芯片设计流程，芯片验证基本上可以划分为三个阶段：基于设计规范来验证寄存器传输级(RTL，register transfer level)电路、基于RTL电路来验证逻辑电路、基于逻辑电路来验证印制布线板（PCB，Printed Circuit Board，也称为印刷电路板）布局电路（Layout)。其中基于设计规范验证RTL电路的过程（也可称为功能验证）更是非常关键，能否在流片前对芯片设计进行充分有效的功能验证直接影响着芯片产品开发的时间和成本。

基于参考模型的验证方法是目前被广泛使用的功能验证方法。参考模型是通过诸如SystemC、C/C++之类的高级编程语言并根据芯片设计规范开发的对芯片硬件进行仿真的虚拟硬件模型。该虚拟硬件模型可以像真实硬件一样工作，提供和真实硬件完全一样的使用方法，其不要求完全照搬硬件设计，但须在行为级上与芯片设计规范相一致，有时也被称为金模型（Golden Model）。在进行功能验证时，可通过将RTL电路与参考模型的运行状态进行实时比较来发现RTL电路设计中的漏洞或缺陷。此外通过该参考模型还可以将芯片软件开发的工作提前到与芯片硬件开发同步进行，即在按照芯片设计规范进行硬件开发的同时，也可以在参考模型上进行相应软件的开发与调试。可以看出，快速有效地得到参考模型是改善芯片设计效率和流片成功率的关键因素之一。

需要说明的是，上述内容仅用于帮助理解本申请的技术方案，并不作为评价本申请的现有技术的依据。

发明内容

本申请的目的是提供一种构建参考模型的方法、基于参考模型的芯片验证方法及系统，以加速参考模型的开发和芯片验证，从而缩短芯片设计时间并提高芯片设计效率。

上述目的是通过以下技术方案实现的：

根据本申请实施例的第一方面，提供了一种构建参考模型的方法，其包括：基于芯片架构规格生成与待构建的参考模型对应的、初始的硬件描述文件，在所述硬件描述文件中包括与所述芯片架构规格的各功能模块对应的第一版本的硬件定义；基于硬件描述文件生成与所述参考模型关联的头文件，并基于该头文件得到第一版本的参考模型；响应于收到芯片的硬件规范定义，在所述硬件描述文件中添加与新收到的硬件规范定义对应的第二版本的硬件定义；根据经修改后的硬件描述文件更新与所述参考模型关联的头文件；以及根据更新后的头文件调整第一版本的参考模型，以使其兼容或适配第二版本的硬件定义。

在本申请的实施例中，将参考模型的开发与具体硬件规范定义进行解耦，使其不再依赖于具体的硬件规范定义，而是与具体的硬件规范定义的设计阶段并行执行。这样，在具体的硬件规范定义完成之前，提前进行参考模型大部分功能的开发和测试；在获得具体的硬件规范定义后，将预先开发的参考模型进行快速迁移以使其匹配新获取的硬件规范定义。由此实现参考模型的快速且高质量的交付，有利于快速进行功能验证以及后续软件栈的开发，缩短了整个芯片设计阶段的周期，改善了芯片设计效率。

在一些实施例中，在所述硬件描述文件中，与每个功能模块对应的硬件定义至少可以包括：该功能模块与其他功能模块之间的接口信息；以及该功能模块与软件之间的接口信息。

在一些实施例中，在所述硬件描述文件中，与每个功能模块对应的硬件定义至少可以包括对于连线、寄存器和状态的硬件定义，其中连线属于该功能模块与其他功能模块之间的接口信息，寄存器和状态属于该功能模块与软件之间的接口信息。

在一些实施例中，在所述硬件描述文件中，每个硬件定义可具有类型信息、版本信息和模块信息；其中所述类型信息用于指示该硬件定义是属于对连线、寄存器还是状态的限定；所述模块信息用于指示该硬件定义属于哪个功能模块；所述版本信息是用于标记该硬件定义出自于哪个硬件规范定义。

在一些实施例中，所述基于硬件描述文件生成与所述参考模型关联的头文件可包括：根据所述硬件描述文件中各个硬件定义的版本信息将不同版本的硬件定义分别归类在头文件的不同命名空间中；以及根据所述硬件描述文件中各个硬件定义的类型信息将各个硬件定义转换成头文件中相应类型的数据结构。

在一些实施例中，所述参考模型可包括用于对每个功能模块的任务进行仿真的软件模块以及与其对应的工作负载准备模块；每个工作负载准备模块用于为其对应的软件模块准备其执行相应任务时所需的输入数据。

在一些实施例中，所述根据更新后的头文件调整第一版本的参考模型可包括：调整所述参考模型中各软件模块对应的工作负载准备模块，以使其访问所述头文件与第二版本的硬件定义对应的命名空间。

根据本申请实施例的第二方面，提供了一种基于参考模型的芯片验证方法，其包括：响应于收到芯片的硬件规范定义，在与参考模型对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义；根据经修改后的硬件描述文件更新所述参考模型的头文件；根据更新后的参考模型头文件调整所述参考模型，以使其适配新版本的硬件定义；以及利用经调整后的参考模型对基于所述硬件规范定义实现的寄存器转换级电路进行功能验证。其中参考模型是根据本申请第一方面所述的方法构建的。

在一些实施例中，与参考模型对应的初始的硬件描述文件可包括对芯片架构规格中不同功能模块的任务描述，以及按照预定格式生成的与每个功能模块对应的初始版本的硬件定义。

在一些实施例，该方法还可包括：基于芯片架构规格生成初始的硬件描述文件；基于该初始的硬件描述文件生成与参考模型关联的头文件，并基于该头文件得到初始的参考模型。

根据本发明实施例的第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被执行时实现如上述实施例第一方面或第二方面提供的方法。

根据本申请实施例的第四方面，提供了一种基于参考模型的芯片验证系统，其包括参考模型、版本适配模块和功能验证模块。其中参考模型是根据本申请实施例第一方面的方法构建的。版本适配模块被配置为用于：响应于收到芯片的硬件规范定义，在与参考模型对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义；根据经修改后的硬件描述文件更新所述参考模型的头文件；以及根据更新后的参考模型头文件调整所述参考模型，以使其适配新版本的硬件定义。功能验证模块被配置为响应于所述版本适配模块对参考模型的调整，利用经调整后的参考模型对基于所述硬件规范定义实现的寄存器转换级电路进行功能验证。

在上述实施例的芯片验证方法和系统中，用了可随时进行“版本兼容”的参考模型，使得参考模型的前期开发和测试，可以与芯片的硬件规范定义阶段同时进行。这样，在芯片的硬件规范定义完成之前和真正开始对其进行RTL编码之前，就能在参照芯片架构规格生成的硬件描述文件HDF基础上，完成参考模型大部分功能的开发和验证。这样，在硬件规范定义完成之后，可以对参考模型进行快速切换，使其适配新版本的硬件规范定义。因此在对RTL电路设计进行功能验证时，能够进行参考模型的快速且高质量的交付，从而能大大缩短芯片硬件开发阶段的时长，并且还可加快后续的软件开发阶段，完成了整个开发周期在时间轴上的左移，提高了芯片开发的效率。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了根据本申请一个实施例的构建参考模型的方法的流程示意图。

图2示出了根据本申请一个实施例的基于参考模型的芯片验证方法的流程示意图。

图3示出了根据本申请一个实施例的基于参考模型的芯片验证系统的结构示意图。

具体实施方式

为了使本申请的目的，技术方案及优点更加清楚明白，以下结合附图通过具体实施例对本申请进一步详细说明。应当理解，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动下获得的所有其他实施例，都属于本申请保护的范围。

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

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

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

芯片产品开发通常包括三个阶段：第一阶段是硬件开发；第二阶段是开发相应硬件上面的软件栈（包括系统集成、工具链、给用户的接口等）；第三阶段是在客户的软件环境中集成前两个阶段做的软件接口和硬件接口，并开发大量的集成测试集合。

在传统的芯片产品开发中，各个阶段的开发工作是串行的。第二阶段的软件开发在时间轴上的起点通常比第一阶段的硬件开发要晚，这是因为在串行开发过程中，只有在硬件有了良好且比较完备的定义信息后，才能在这个基础上做配套软件的开发。第三阶段的集成测试在第二阶段的软件开发的后期才能开始进行，这是因为只有有了比较完备的软、硬件，才能在整个系统环境中做正确的集成测试开发工作。

为了加快芯片设计的速度和效率，近年来，在芯片设计领域中，提出了开发左移(Shift left)的理念和策略。左移策略是指在时间轴上将软件开发阶段的整个过程向左移动，提前开发软件，最好能够和硬件开发同时进行，从而加速设计过程，缩短设计时间并提高设计成功率。从产品开发角度更重要的是能够帮助最后的系统集成和测试阶段更早地进行，更早地为用户提供完整、稳定的工具链，从而提前发布相应的软件和硬件产品，大幅缩短响应市场的时间。

实现左移策略的通常方式是利用对芯片硬件功能进行仿真的虚拟硬件模型（可称为参考模型或黄金验证模型golden reference model，该模型通常使用诸如SystemC、C/C++之类的高级编程语言实现）。该虚拟硬件模型可以像真实硬件一样工作，提供和真实硬件完全一样的使用方法，其不要求完全照搬硬件设计，但须在行为级上与芯片设计规范相一致。这样的虚拟硬件模型至少在下面两个方面起着非常关键的作用：（1）在第一阶段的硬件开发中，为RTL电路的功能验证提供了一个参考模型，通过将RTL电路文件与参考模型的运行状态进行实时比较来发现RTL电路设计中的漏洞或缺陷；（2）将第二阶段的软件开发提前到与第一阶段的硬件开发同步进行，即在按照芯片设计规范进行硬件开发的同时，在参考模型上进行相应软件的开发与调试，并且也相应地提前了第三阶段的软硬件集成测试。在目前的芯片设计领域，基于这样的参考模型的验证方法已经成为广泛使用的功能验证方法，可以加快芯片设计速度和效率。

在芯片硬件开发阶段，其设计流程通常可分为两个部分：前端设计和后端设计。其中前端设计以架构设计为起点，以生成可以布局布线的网表为终点，其包括：1）芯片架构规格设计，根据芯片设计需求确定芯片需要达到的具体功能和性能，将不同功能分成不同单元，并确定不同单元间连结的方法；2）对芯片的每个功能模块进行参数化和具体化，形成硬件规范定义；3）根据硬件规范定义用硬件描述语言进行编码来得到RTL电路（可以被呈现为RTL电路文件，在RTL级，集成电路由寄存器和寄存器之间的逻辑操作构成）；4）利用参考模型对RTL电路进行功能验证；5）将RTL电路的设计逻辑映射为门级网表(netlish)，并进行时序分析、形式验证等。后端设计包括可测性设计、布局规划、时钟树综合、布线、版图物理验证等，最终将设计好的版图以GDSII的文件格式移交给芯片代工厂去生产实际的芯片，再将代工厂生产出的晶圆硅片进行封装测试合格后得到的就是可使用的芯片产品。

在芯片的功能验证中，通常是使用参考模型和RTL电路文件在测试平台(通过测试脚本testbench)做事务级或者周期级的行为和数据对比，例如，会将参考模型和RTL电路，在给定的验证环境下进行事务级（transaction level）或周期级（cycle level）的数据比对，例如在验证环境下同时运行RTL电路对应的实际硬件代码和参考模型，并对每一笔事务级（transaction level）的结果进行对比，以验证RTL的正确性。为了支持这些验证需求，需要参考模型做到在连线（interface）、寄存器（register）和状态（states）的模拟上，与硬件几乎完全一致，即每一个比特位的数据都一致。如上文提到的，在硬件开发过程中，会根据芯片架构规格生成一份硬件规范定义的文档，里面详细定义了每个功能模块的连线、寄存器和状态的每一个比特位的具体数值，然后再基于该硬件规范定义文档进行RTL编码以得到RTL电路（可呈现为RTL电路功能设计文件）。而关于参考模型，也是在得到这样的芯片硬件规范定义文档之后才开始正式的软件编码工作。这就导致在RTL电路的连线、寄存器和状态的具体定义没有完成之前，参考模型的开发工作并不能有效展开。其次，虽然参考模型的开发工作量比RTL电路设计的开发工作量少，但少得有限，并不会比RTL电路设计早很多完成。并且，为了确保自身的正确性，参考模型本身还需要大量额外的验证和调试工作，这个工程通常会比较长，无疑也会拖慢了整个芯片产品开发周期。

在本申请的实施例中，提供了一种新的基于参考模型的芯片验证方法，将参考模型的开发与具体硬件规范定义进行解耦，使其不再依赖于具体的硬件规范定义，而是与具体的硬件规范定义的设计阶段并行执行。这样，在具体的硬件规范定义完成之前，提前进行参考模型大部分功能的开发和测试；在获得具体的硬件规范定义后，将预先开发的参考模型进行快速迁移以使其匹配新获取的硬件规范定义。

发明人在研究中发现，在进行参考模型的提前开发时，虽然还没有具体硬件规范定义对于各个硬件模块的具体“接口”（例如，连线、寄存器和状态等）规范进行明确定义（即RTL编码所需要的各种接口细节，例如数据类型、参数个数等），但是通过来自架构团队的芯片架构规格可明确获知各硬件模块的核心功能和目标。例如，以一个简单计算模块为例，其核心功能就是用两种输入数据a, b做“a + b”的加法运算。其中核心功能“加法运算”的行为和目标是明确的，但输入数据a、b 的类型和行为不清楚，这个和硬件的资源、时序等相关。数据a，b可以是16bit的数据，也可以是32bit的数据。加载数据a 和b 的时候，如果a、b的时序相同，则可以用同一个interface将a和b同时传入；也可能是异步的时序，用不同的interface在不同的时刻传入。但是这些并不会对于核心功能“a + b”这个运行操作本身的实现有所影响。

因此，在本发明的实施例中，在参考模型开发时，通过软件编码实现对各个硬件模块的核心功能进行仿真的软件模块，并为每个软件模块配备相应的为其加载数据的模块（也可以称为工作负载准备模块）。每个工作负载准备模块用于为其对应的软件模块准备其执行相应任务时所需的输入数据。每个软件模块仅接收由其相应的工作负载准备模块准备好的数据。以实现“a + b”的功能的软件模块为例，其仅在有来自对应的工作负载准备模块的数据输入时，才开始执行“a + b”的任务。但该软件模块本身并不需要考虑a, b到底是异步输入，还是同步输入的，这些细节都被其对应的工作负载准备模块隔离。在该工作负载准备模块中包含了输入数据a, b的定义。为了兼容位宽，a, b一般定义成可能的最大位宽，比如都是32bit的数，无论后期实际硬件定义为16bit还是32bit的数，也都足够存放。这样，当新的硬件定义加入的时候，参考模型中的软件模块“a + b”是不需要修改的；只需要修改其对应的工作负载准备模块里面的行为即可，这本身是很微小的改动，所以能够使参考模型快速适配至新的硬件规范定义。

与现有的基于参考模型的验证方法相比，本申请的方案通过加速参考模型的开发和测试，将其与具体的硬件规范定义阶段并行，在RTL电路设计开始编码之前，就可以完成参考模型的大部分编码工作和测试工作，从而实现对于参考模型的快速且高质量交付，有利于快速进行功能验证以及后续软件栈的开发，使得芯片的硬件开发、软件开发和软硬件集成阶段在时间轴上进一步左移，缩短整个芯片设计阶段的周期，改善芯片设计效率。

下面结合附图对于本申请的方案进行更详细的举例说明。

图1给出了根据本申请一个实施例的构建参考模型的方法的流程示意图。该方法可应用于具有数据处理能力的电子设备。在下文中以C/C++语言为例来对参考模型的开发进行示例说明，但应理解其他高级编码语言也适用于本申请的实施例。在该实施例中，参考模型的前期开发并不依赖于芯片的硬件规范定义，而是基于硬件描述文件 (HDF，hardwaredescribe file)来进行的。如图1所示，该方法主要包括下列步骤：

步骤S1）基于芯片架构规格生成与待构建的参考模型对应的、初始的硬件描述文件，该硬件描述文件HDF包括与芯片架构规格的各功能模块对应的第一版本的硬件定义；

硬件定义可视为硬件定义信息的简称。

步骤S2）基于硬件描述文件生成与参考模型关联的头文件，并基于该头文件得到第一版本的参考模型；

步骤S3）响应于收到芯片的硬件规范定义，在硬件描述文件HDF中添加与该硬件规范定义对应的第二版本的硬件定义；

步骤S4）根据经修改后的硬件描述文件更新参考模型的头文件；

步骤S5）根据更新后的头文件调整第一版本的参考模型，以使其兼容或适配第二版本的硬件定义。

更具体地，在步骤S1），基于芯片架构规格生成与待构建的参考模型对应的硬件描述文件HDF。

在一个示例中，该硬件描述文件HDF不仅可以包括对芯片架构规格中不同功能模块的任务描述，也可以包括各个功能模块的硬件定义（信息）。每个功能模块的硬件定义（信息）至少包括：该功能模块与其他功能模块之间的接口信息（即芯片里的“连线”或interface），以及该功能模块与软件之间的接口信息：register（寄存器） 和 states（状态）信息。在

另一示例中，该硬件描述文件HDF至少包括芯片架构规格中各个功能模块的硬件定义（信息）。

在基于芯片架构规格生成的初始的HDF中所包括的是：与每个功能模块对应的初始版本（也可以称为第一版本）的硬件定义，例如按照预定格式生成的与每个功能模块对应的interface、register、states以及其他信息。初始的或第一版本的硬件定义用于支撑参考模型的前期开发过程。

在芯片的功能验证过程中，参考模型用于验证RTL电路设计的功能是否能正确满足芯片架构规格中的功能需求，但并不要求完全照搬硬件设计，只需要在行为级上与RTL电路设计对应的硬件设计规范相一致即可。因此在参考模型的开发中，可以基于HDF中对芯片架构规格中不同功能模块的任务描述或者直接基于芯片架构规格，开发具备相应功能的软件模块，而对于每个功能模块对应的连线、寄存器、状态等接口信息，可以按照预先设定的硬件定义来进行编码。待获得完整的硬件规范定义之后，可以通过在硬件描述文件HDF中写入新版本的硬件定义，来使得参考模型能快速兼容或适配该硬件规范定义（将在下文详述）。

在一个示例的硬件描述文件HDF中，每个硬件定义可具有类型信息、版本信息和模块信息。关于interface、register、state的每个硬件定义可包含：类型信息、版本信息和模块信息。

每个硬件定义的类型信息，用于指示该硬件定义是对于interface、register、state中的哪一种所进行的具体限定。每个硬件定义的模块信息，用于指示该硬件定义属于对哪个功能模块。每个硬件定义的版本信息，用于标记该硬件定义出自于哪个硬件规范定义。

关于硬件定义的这些信息，在HDF中以预设的标准格式进行描述。例如每个硬件定义可以“键值”命名，其对应的类型、版本、模块等信息定义为该“键值”的一系列属性（例如，属性0、属性1…属性n）。

其中“键值”的格式为：[键值名]，例如：[interface0], [interface_a_to_b],[state_a], [register_a]都可视为合法的“键值”。通过在HDF中进行格式或标记检测，检测“[]”，可以遍历到每个硬件定义。

“属性”是定义在“键值”之后的一系列数值，其格式是“属性名 = 属性值”。其中“属性名”和“属性值”属于预先定义的类型，以供后续识别和解释。例如对于以下属性信息：

“version = 2.0”

“def_type = interface”

“field0 = U03”

“field1 = U02”

其中“version=2.0”代表版本号是2.0。通常可以“a.b”的形式表示版本信息，此处的a表示大版本，b表示小版本。例如HDF中旧的版本号是1.0, 更新后的新版本号可能是2.0。又例如，HDF中旧的版本号是2.0，如果新增的硬件定义是对版本号为2.0的硬件定义的微小调整，更新后的新版本号可以是2.1。“def_tpe = interface”代表硬件定义所属的类型是“interface”。而field0, field1 是该硬件定义的位域名字，U03表示“field0”占3个bit, U02表示“field1”占2个bit。

以功能模块a到功能模块b请求数据的连线“module_a_to_b_request”为例，其在硬件描述文件HDF中的定义可如下：

[module_a_to_b_request]

version=2.0

def_type=“interface”

field0=U01

field1=U32

其中“[]”里面的字符表示一个“硬件定义”，它可能是连线、状态、寄存器中的一种。“version”表示该硬件定义所属的版本号，其值“2.0”指示这个定义是2.0版本才有的。“def_type”表示“硬件定义”的类型，该例的类型是指对功能模块之间的连线进行限定。后面的“field0”, “field1”都是表示属于这个连线定义的位域名字，后面的U01，U32分别表示相应位域所占的比特数目，分别是1比特和32比特。

又例如，名为“data_type”的状态的定义如下：

[data_type]

version=1.0

def_type=states

module=a

field0=U03

field1=U17

field2=U12

value=0

这表示类型为状态的硬件定义“data_type”，其版本为1.0，“module=a”表示该定义属于功能模块a。每个state都是32bit的数，其中包含3个位域：field0占3个比特,field1占17个比特，field2占12个比特。这个32比特的状态的默认值value是0。

继续参考图1，在步骤S2），基于硬件描述文件HDF生成与参考模型关联的头文件，并基于该头文件得到第一版本的参考模型。硬件描述文件HDF中，每个部分在头文件中具有相对应的代码。例如，硬件描述文件HDF中的功能模块被转换成头文件中的核心功能函数；与每个功能模块对应的连线、寄存器、状态以及其他信息的硬件定义，被转换成头文件中供核心功能函数使用的数据结构（struct）。根据HDF中各个硬件定义的版本信息，可以将不同的硬件定义，分别归类在头文件中的不同命名空间。属于同一版本的硬件定义在同一命名空间中。

例如，仍以上面的功能模块a到功能模块b请求数据的interface“module_a_to_b_request”为例，其版本号为“2.0”，则该interface定义属于命名空间namespace v_2_0中的代码，可如下所示：

namespacev_2_0 {

structmodule_a_b_request {

U01 field0;

U32 field1;

};

usinginf_module_a_b_request = Interferce<module_a_b_request>;

}

上述代码表示在C++语言中，定义了一个“v_2_0”的命名空间，里面定义了module_a_b_request对应的数据结构，然后用该数据结构，使用模板类Inteface<>特例化了一个叫inf_module_a_b_request的interface类。该类型具有所有interface基本的功能，其内部的数据为“module_a_b_request”中包括的具体类型U01和U32。

类似地，上文data_type状态的定义，其版本号为“1.0”，则该状态的硬件定义对应到另一命名空间namespace v_1_0中的代码，可如下所示：

namespacev_1_0 {

structmodule_a_states {

U03 data_type = 0; //默认初始值为0

… //其他states

};

}

状态“data_type”会变成其所属的功能模块a的多个状态中的一个，从而在所转换的头文件代码中被定义在功能模块a的状态数据结构“module_a_states”里面。该状态默认值“data_type”就是其定义中的“value”。对于状态，“版本信息”，“模块信息”一致的所有状态会被定义在相应功能模块对应的状态数据结构“module_a_states”的里面。

以这样方式生成的头文件为基础，利用诸如C/C++之类的高级编程语言编码，来实现HDF中功能模块的相应功能进行仿真的软件模块。在没有获得芯片完整的硬件规范定义之前，对于每个功能模块对应的连线、寄存器、状态以及其他信息，可以按照预先设定的硬件定义来进行编码，从而得到初始的参考模型（也可以称为第一版本的参考模型）。其中该参考模型的软件模块还设置有与其对应的工作负载准备模块。每个工作负载准备模块，用于为其对应的软件模块准备其执行相应任务或功能时，所需的输入数据。可选的，可以是在得到头文件后，利用预设程序或脚本来获取头文件从而生成参考模型，也可以是将头文件发送给外部用于生成参考模型的目标设备进行后续处理和使用，然后从该目标设备处得到基于该头文件生成的参考模型，还可以是在得到头文件后，人为地根据该头文件进行编程开发后得到该头文件对应的参考模型，还可以是基于该头文件给出编程提示并提供给用户进行确认或选择，从而响应于用户实际编程行为进行模型生成，从而得到参考模型。本申请对这些方式不做限制，且这些得到参考模型的具体方式也不应理解为对本申请的限制。其中，在步骤S2）处得到的模型并不用于最终验证。

在步骤S3），在收到芯片的硬件规范定义之后，该硬件规范定义中与每个功能模块对应的连线、寄存器、状态以及其他信息，可以作为新版本（可记为第二版本）的硬件定义，添加在参考模型对应的硬件描述文件HDF中。每次在硬件描述文件HDF中加入新版本的硬件定义时, 都必须设置新增的硬件定义的版本信息，以便后续能确定该硬件定义出自于哪个硬件规范定义。

在步骤S4），在硬件描述文件HDF中加入新版本的硬件定义后，需要相应地更新参考模型的头文件，例如，将HDF中的硬件定义转化为参考模型所需要的C++语言头文件中的代码。仍以上文举例的硬件定义为例，可以按照符号“[]”检测每一个遇到的硬件定义，按照不同的类型信息转换成不同的数据结构，并按照版本信息归类至对应的命名空间中。

步骤S5）根据更新后的参考模型头文件调整第一版本的参考模型，以使其兼容或适配第二版本的硬件定义。在参考模型中通过为每个软件模块配备相应的工作负载准备模块，实现了各个硬件模块的核心功能与其接口信息的松耦合。每个软件模块仅接收由其相应的工作负载准备模块准备好的数据，而不必考虑接口细节。每个工作负载准备模块用于为其对应的软件模块准备其执行相应任务时所需的输入数据，其可以根据头文件中不同命名空间中所包含的不同版本对应的连线、寄存器、状态等硬件定义，为相应软件模块准备所需要的数据集。

在一个示例中，在参考模型的每个软件模块可以核心功能函数的形式实现，而其对应的工作负载准备模块可以接口函数的形式实现。该接口函数根据参考模型关联的头文件中相应版本的硬件定义，将对应核心功能函数所需的具体连线、寄存器、状态等信息，封装在称为工作负载workload的数据集中一起传递给该核心功能函数。通过这样的核心功能函数与其接口函数相分离的机制，使得在根据不同版本进行切换时，现有的软件模块不受版本切换影响。参考模型只需要根据当前版本信息，使用不同命名空间中所包含的定义，通过工作负载准备模块为相应的软件模块准备其需要的workload即可。

例如，现在有核心功能函数core_func(), 需要准备workload作为输入。在版本1时需要参数a, b来自interface0，而在版本2时需要a, c, d, 来自inteface0,interface1。在参考模型中可通过下列代码实现如下版本兼容功能：

if (current_version=”1.0”) {

a = inf0.get().a;

b = inf0.get().b;

workload= gen_v1_workload(a, b);

} else if (current_version ==“2.0”) {

a = inf0.get().a;

c = inf1.get().c;

d = inf1.get().d;

workload = gen_v2_workload(a, c, d);

}

return core_func(workload); //返回函数core_func()需要的工作数据集

在本申请的实施例中，当硬件开发团队完成对于连线、状态、寄存器等的具体硬件规范定义时，可以随时将新版本的硬件定义加入至硬件描述文件HDF中。假设硬件描述文件HDF中当前最新版本为2.0，新加入的版本为对于原先版本2.0的微调，可以将新版本的硬件定义记为“2.1”版本，然后重复执行步骤S3）-S5）就可以使参考模型兼容或适配新版本的硬件定义。在“2.0”版本几乎开发完成的情况下，后续的“2.1”版本可以复用在先版本的核心功能函数“core_func”中的功能，只需要通过相应工作负载准备模块为核心函数生成当前版本的workload即可。通过这样的微量调整，兼容或适配“2.1”版本的参考模型可以快速上线。

应理解，在上述实施例中，第一版本和第二版本仅是举例说明，仅代表在先版本和在后版本，而非限制于仅两个版本。最初的第一个版本可以是预先设置的，而在后续随着芯片的硬件规范定义的调整，也可以有第三个、第四个……等版本的硬件定义，重复执行步骤S3）-S5）就可以使参考模型兼容或适配新版本的硬件定义。

在上述实施例中提供了可进行“版本兼容”的硬件描述文件HDF，使得参考模型的开发，在前期与芯片的硬件规范定义解耦，仅依赖于硬件描述文件HDF中预设版本的硬件定义。这样，在芯片的硬件规范定义完成和真正开始对其进行RTL编码之前，就能依赖于硬件描述文件HDF中“虚拟”的硬件定义，完成参考模型大部分功能的开发和验证。

对于整个芯片开发周期而言，在上述实施例中，在硬件开发阶段，在RTL电路设计开始编码之前或完成的同时，可以完成对参考模型的大部分编码工作和测试工作，因此在对RTL电路进行功能验证时，能够进行参考模型的快速且高质量的交付，从而能大大缩短芯片硬件开发阶段的时长，并且还可加快后续的软件开发阶段，提高了芯片开发的效率。

图2给出了根据本申请一个实施例的基于参考模型的芯片验证方法的流程示意图。其中参考模型是利用结合图1介绍的方法构建的。该芯片验证方法主要包括下列步骤：

步骤201）响应于收到芯片的硬件规范定义，在参考模型对应的硬件描述文件HDF中添加该硬件规范定义中与每个功能模块对应的新版本的硬件定义；

步骤202）根据经修改后的硬件描述文件更新所述参考模型的头文件；

步骤203）根据更新后的参考模型头文件调整所述参考模型，以使其适配新版本的硬件定义；

步骤204）利用经调整后的参考模型对基于所述硬件规范定义实现的RTL电路进行功能验证。

上述步骤201）-步骤203）与结合图1介绍的步骤S3）-S5）类似，在此不再赘述。在步骤204），在收到基于步骤201）的硬件规范定义所实现的RTL电路后，利用经步骤S203）调整后的参考模型对于该待验证的RTL电路进行功能验证。如上文提到的，通常是利用设定的测试脚本对参考模型和RTL电路做事务级（或者周期级）的行为和数据对比，以验证RTL的正确性。对于具体的比对过程在此不再赘述。

在又一个实施例中，在步骤201）之前还包括构建初始的参考模型的下列步骤：

步骤a1）基于芯片架构规格生成初始的硬件描述文件HDF，该硬件描述文件HDF不仅可包括对芯片架构规格中不同功能模块的任务描述，还可包括按照预定格式生成的与每个功能模块对应的连线、寄存器、状态以及其他信息的硬件定义。

步骤a2）基于该初始的硬件描述文件生成与参考模型关联的头文件，以开发初始版本的参考模型。

上述步骤a1）-步骤a2）与结合图1介绍的步骤S1）-S2）类似，在此不再赘述。

图3示出了根据本申请一个实施例的基于参考模型的芯片验证系统的结构示意图。该系统300包括参考模型301，版本适配模块302和功能验证模块303。其中，参考模型301是根据上文结合图1所介绍的方法构建的。版本适配模块302用于在收到芯片的硬件规范定义时，在与参考模型301对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义；根据经修改后的硬件描述文件更新参考模型301的头文件；以及根据更新后的参考模型头文件调整参考模型301，以使其适配新版本的硬件定义。功能验证模块303被配置为响应于版本适配模块302对参考模型301的调整，利用经调整后的参考模型301对收到的待验证的寄存器转换级电路文件基进行功能验证。其中该待验证的RTL电路设计是基于版本适配模块302当前收到的硬件规范定义实现的。

在上述实施例的功能验证方法和系统中提供了可随时进行“版本兼容”的参考模型，使得参考模型的前期开发和测试可以与芯片的硬件规范定义阶段同时进行。这样，在芯片的硬件规范定义完成之前和真正开始对其进行RTL编码之前，就能在参照芯片架构规格生成的硬件描述文件HDF基础上，完成参考模型大部分功能的开发和验证。这样，在硬件规范定义完成之后，可以对参考模型进行快速切换，使其适配新版本的硬件规范定义。因此在对RTL电路进行功能验证时，能够进行参考模型的快速且高质量的交付，从而能大大缩短芯片硬件开发阶段的时长，并且还可加快后续的软件开发阶段，完成了整个开发周期在时间轴上的左移，提高了芯片开发的效率。

另外，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现前述用于构建参考模型的方法。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现前述基于参考模型的芯片验证方法。

本申请实施例还提供一种电子设备，该电子设备包括：存储器和处理器；存储器中存储有计算机程序，当该计算机程序被处理器执行时执行前述实施例的各方法。该电子设备可以是各种形式的具有数据处理能力的硬件实体，诸如笔记本电脑、台式电脑、工作站、个人数字助理、服务器、主机，以及其他合适的计算设备。存储器为该电子设备存储信息（例如计算机程序或计算机可读指令等），其可被作为一个或多个计算机可读介质、一个或多个易失性存储单元，或者一个或多个非易失性存储单元实施。处理器可以执行电子设备内的指令，包括存储于存储器中的指令或程序，本申请对电子设备中存储器和处理器的具体类型不做限制。

可以理解的是，该电子设备中可以部署上述芯片验证系统的部分或全部模块，用以实现前述基于参考模型的芯片验证方法。

本说明书中针对“各个实施例”、“一些实施例”、“一个实施例”、或“实施例”等的参考指代的是结合所述实施例所描述的特定特征、结构、或性质包括在至少一个实施例中。因此，短语“在各个实施例中”、“在一些实施例中”、“在一个实施例中”、或“在实施例中”等在整个说明书中各地方的出现并非必须指代相同的实施例。

本说明书中“包括”和“具有”以及类似含义的术语表达，意图在于覆盖不排他的包含，例如包含了一系列步骤或单元的过程、方法、系统、产品或设备并不限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。“一”或“一个”也不排除多个的情况。另外，本申请附图中的各个元素仅仅为了示意说明，并非按比例绘制。

虽然本申请已经通过上述实施例进行了描述，然而本申请并非局限于这里所描述的实施例，在不脱离本申请范围的情况下还包括所做出的各种改变以及变化。

Claims (9)

1.一种构建参考模型的方法，其特征在于，所述方法包括：

基于芯片架构规格生成与待构建的参考模型对应的、初始的硬件描述文件，在所述硬件描述文件中包括与所述芯片架构规格的各功能模块对应的第一版本的硬件定义；

基于硬件描述文件生成与参考模型关联的头文件，并基于该头文件得到第一版本的参考模型；

响应于收到芯片的硬件规范定义，在所述硬件描述文件中添加与新收到的硬件规范定义对应的第二版本的硬件定义；

根据经修改后的硬件描述文件更新与所述参考模型关联的头文件；

根据更新后的头文件调整第一版本的参考模型，以使其兼容或适配第二版本的硬件定义；

其中所述参考模型包括：用于对每个功能模块的任务进行仿真的软件模块以及与其对应的工作负载准备模块；每个工作负载准备模块用于为其对应的软件模块准备其执行相应任务时所需的输入数据。

2.根据权利要求1所述的构建参考模型的方法，其特征在于，在所述硬件描述文件中，与每个功能模块对应的硬件定义包括：

该功能模块与其他功能模块之间的接口信息；以及

该功能模块与软件之间的接口信息。

3.根据权利要求2所述的构建参考模型的方法，其特征在于，在所述硬件描述文件中，与每个功能模块对应的硬件定义包括：对于连线、寄存器和状态中至少一者的硬件定义，其中，连线属于该功能模块与其他功能模块之间的接口信息，寄存器和状态属于该功能模块与软件之间的接口信息。

4.根据权利要求1所述的构建参考模型的方法，其特征在于，所述基于硬件描述文件生成与参考模型关联的头文件包括：

根据所述硬件描述文件中各个硬件定义的版本信息，将不同版本的硬件定义分别归类在头文件的不同命名空间；

根据所述硬件描述文件中各个硬件定义的类型信息，将各个硬件定义转换成头文件中相应类型的数据结构。

5.根据权利要求1所述的构建参考模型的方法，其特征在于，所述根据更新后的头文件调整第一版本的参考模型包括：

调整所述参考模型中各软件模块对应的工作负载准备模块，以使其访问所述头文件与第二版本的硬件定义对应的命名空间。

6.一种基于参考模型的芯片验证方法，其特征在于，所述方法包括：

响应于收到芯片的硬件规范定义，在与参考模型对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义；

根据经修改后的硬件描述文件更新所述参考模型的头文件；

根据更新后的参考模型头文件调整所述参考模型，以使其适配新版本的硬件定义；

利用经调整后的参考模型对基于所述硬件规范定义实现的寄存器转换级电路进行功能验证；

其中参考模型是采用权利要求1-5中任一项所述的构建参考模型的方法构建的。

7.根据权利要求6所述的基于参考模型的芯片验证方法，其特征在于，所述方法还包括：

基于芯片架构规格生成初始的硬件描述文件，其中，与参考模型对应的初始的硬件描述文件中包括：对芯片架构规格中不同功能模块的任务描述，以及按照预定格式生成的与每个功能模块对应的初始版本的硬件定义；

基于该初始的硬件描述文件生成与参考模型关联的头文件，并基于该头文件得到初始的参考模型。

8.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述程序被处理器执行时实现权利要求1-5中任一项所述的构建参考模型的方法或权利要求6-7中任一项所述的基于参考模型的芯片验证方法。

9.一种基于参考模型的芯片验证系统，其特征在于，所述系统包括：

根据权利要求1-5中任一项所述的构建参考模型的方法构建的参考模型；

版本适配模块，其被配置为用于：

响应于收到芯片的硬件规范定义，在与参考模型对应的硬件描述文件中添加该硬件规范定义中与各个功能模块对应的新版本的硬件定义；

根据经修改后的硬件描述文件更新所述参考模型的头文件；

根据更新后的参考模型头文件调整所述参考模型，以使其适配新版本的硬件定义；以及

功能验证模块，其被配置为用于：响应于所述版本适配模块对参考模型的调整，利用经调整后的参考模型对基于所述硬件规范定义实现的寄存器转换级电路进行功能验证。