CN114357939A - 芯片ip准入验证方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明的实施例公开了一种芯片IP准入验证方法、装置、电子设备及存储介质，涉及集成电路技术领域，用以在IP改动后集成到SoC之前对IP进行验收，避免因IP质量不过关而把问题带入SoC。所述芯片IP准入验证方法包括：获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

Description

芯片IP准入验证方法、装置、电子设备及存储介质

技术领域

本发明涉及集成电路技术领域，尤其涉及一种芯片IP准入验证方法、装置、电子设备及存储介质。

背景技术

随着设计与工艺技术的不断发展，集成电路设计的规模越来越大，组成SoC(片上系统)的IP模块种类和数量也越来越多。系统上进行SoC验证的复杂度也呈现指数级的增长。因此一个高效的验证平台使得验证迅速收敛显得尤为重要。为了缩短芯片的上市时间，节约开发成本，大部分芯片设计采用第三方IP与已有传承(legacy)设计混合开发的方式，典型SoC架构如图1所示。

各个IP模块层次结构在SoC的划分，及大规模集成电路版图布局的优化等，使得芯片上数据网络的结构和设计在项目中需要进行多次调整，每次调整都要进行相应的验证操作。相关技术中，大规模集成电路的验证通常采用IP(模块)级验证和SoC级验证分别进行的方式，即各子系统在IP级验证通过后直接集成到SoC，由于IP级验证与SoC级验证存在较大差异，常常出现已经通过IP级验证的IP模块无法通过SoC级验证的情况，从而浪费了宝贵的验证资源，大大增加了验证迭代周期。

发明内容

有鉴于此，本发明实施例提供一种能够减少芯片验证迭代周期的芯片IP准入验证方法、装置、电子设备及存储介质。

第一方面，本发明实施例提供一种芯片IP准入验证方法，包括：

获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

结合第一方面，在第一方面的一种实施方式中，所述获取目标IP的待验证版本之前包括：

设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoC DB，所述数据库的目录采用嵌套子系统架构，所述数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库。

结合第一方面，在第一方面的另一种实施方式中，所述搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本，包括：

将所述待验证版本集成到所述IP分支数据库。

结合第一方面，在第一方面的再一种实施方式中，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。

结合第一方面，在第一方面的又一种实施方式中，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

结合第一方面，在第一方面的又一种实施方式中，所述在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC，包括：

在所述SoC级验证环境中芯片的数据通路划分为数据总线子系统和内存子系统两个层次，其中：

针对芯片的数据总线子系统，所述可用性测试所使用的测试集包括以下至少一种：寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；

和/或，针对芯片的内存子系统，所述内存子系统是在芯片的数据总线子系统的基础上进一步扩展封装得到，所述可用性测试所使用的测试集包括以下至少一种：不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；不同验证平台配置下从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；针对所述内存子系统的特殊性提取的典型特征测试。

第二方面，本发明实施例提供一种芯片IP准入验证装置，包括：

获取模块，用于获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

第一测试模块，用于搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

组建模块，用于根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

第二测试模块，用于在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

结合第二方面，在第二方面的一种实施方式中，所述装置还包括：

设定模块，用于设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoC DB，所述数据库的目录采用嵌套子系统架构，所述数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库。

结合第二方面，在第二方面的另一种实施方式中，所述第一测试模块包括：

集成子单元，用于将所述待验证版本集成到所述IP分支数据库。

结合第二方面，在第二方面的再一种实施方式中，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。

结合第二方面，在第二方面的又一种实施方式中，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

结合第二方面，在第二方面的又一种实施方式中，所述第二测试模块包括：

划分子单元，用于在所述SoC级验证环境中芯片的数据通路划分为数据总线子系统和内存子系统两个层次，其中：

针对芯片的数据总线子系统，所述可用性测试所使用的测试集包括以下至少一种：寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；

和/或，针对芯片的内存子系统，所述内存子系统是在芯片的数据总线子系统的基础上进一步扩展封装得到，所述可用性测试所使用的测试集包括以下至少一种：不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；不同验证平台配置下从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；针对所述内存子系统的特殊性提取的典型特征测试。

第三方面，本发明实施例提供一种电子设备，所述电子设备包括：壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码；处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一所述的方法。

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现前述任一所述的方法。

本发明实施例提供的芯片IP准入验证方法、装置、电子设备及存储介质，对目标IP的待验证版本既进行了IP级验证，又进行了SoC级验证，其中SoC级验证环境复用了IP级验证环境，这样能够在IP改动后集成到SoC之前对IP进行验收，避免因IP质量不过关而把问题带入SoC，在有效的短时间内，能够完成对IP集成进入SoC进行质量监督，使得SoC验证能够顺利进入下一步，从而能够节省验证资源，减少芯片验证迭代周期。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为现有技术中复杂系统芯片的结构示意图；

图2为现有技术中片上数据网路的验证环境组成示意图；

图3为现有技术中外部存储子系统的验证环境组成示意图；

图4为本发明的芯片IP准入验证方法实施例的流程示意图；

图5为本发明中IP/SoC DB组建示意图；

图6为本发明中SoC子系统的层级示意图；

图7为本发明中数据总线子系统的验证环境示意图；

图8为本发明的芯片IP准入验证装置实施例的结构示意图；

图9为本发明的电子设备一个实施例的结构示意图。

具体实施方式

下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

当前大规模集成电路的验证通常采用的是IP级验证和SoC级验证分别进行的方式。对于MemSub(memory subsystem，内存子系统，是指由片上数据网络和外部存储子系统共同构建的SoC小生态)子系统来说，分为两个部分：片上数据网络和外部存储子系统。

对于片上数据网络，如图2所示，这个子系统的验证环境通常由如下部分组成：(1)终端节点：Master_*接口模块，Slave_*接口模块，其中A、B、C代表不同的接口模块类型；(2)数据网络传输层：虚线框中标示的部分，由数据路由节点和数据通道组成；(3)模块级scoreboard(计分板，简称sb)：Sub-module*sb，其中不同sub module(子模块)有独立的sb对其进行检查。

对于外部存储子系统，如图3所示，这个子系统的验证环境通常由如下部分组成：(1)终端节点：Master_*接口模块，*接口模块，其中A、B、C代表不同的接口模块类型；(2)外部存储子系统：虚线框中标示的部分，由3个子模块和子模块级scoreboard组成；(3)模块级scoreboard：Sub-module*sb，其中不同sub module有独立的sb对其进行检查。

IP级验证的对象就是图2和图3中标示出的部分。IP级验证中，将所有的Master(主)和Slave(从)接口模块连接的单元用对应的接口UVC(UVM Verification Component，UVM验证组件)驱动，优点是仿真时间快，可以通过灵活地控制每个Master发出特定的操作，每个Slave进行特定的响应来实现高验证覆盖率。对于外部存储子系统，还可以根据数据通路的复杂性，划分为3个验证平台配置(tb configuration)，使用对应的接口UVC来组成完整数据通路，以方便更快捷有重点的验证。

SoC级验证的对象通常是如图1所示的部分，或者将其中某部分行为比较规范的子系统用行为模型替换。SoC级验证由于采用的是RTL(Register Transfer Level，寄存器传输级)设计，通过模拟软件驱动的方式来驱动各个子系统发出相应的操作与访问，可以验证设计的真实行为。大型SoC芯片就是集成了多个复杂的IP子系统后形成的产品。

发明人在研究过程中发现，现有技术至少存在以下缺点：

首先，现有IP到SoC数据库(data base，以下简称为DB)的版本维护方式大多为两类：一类是完全分离的维护方式，由IP按照项目节点发布大版本，SoC统一只拿对应节点的大版本进行验证；另一类是按照项目分离的维护方式，各个项目之间完全隔开，每个项目的IP和SoC都独立存在，只维护指定项目的IP和SoC DB。这两种方式都有各自的缺点和局限性，为了更好的适应大型项目开发以及各个项目之间的继承性和延展性，迫切地需要去改进DB的维护方式。

其次，在现有的IP级验证方法中，一般采用接口UVC代替各子系统，在利用了UVC灵活性的同时，也就无法和实际设计模块的行为一致，因此验证相对而言受限于UVC本身的质量，IP验证并不充分。

再次，在SoC中，由于会跨越不同的时钟域、电源区域，会在数据通道中插入对应的时钟同步电路、电压转换电路；而且，因为要满足时序要求的限制，保证芯片达到预期的工作频率，对于接口模块之间在版图上距离较远的部分，需要插入数个中继单元(repeater)。在目前的大规模集成电路设计流程中，上述部分是根据版图设计的需求，在SoC中进行插入的，并且在项目进行的过程中会经过多次的迭代调整。IP级别的验证也无法覆盖这部分。

从次，在从IP集成到SoC时，为了后端物理版图设计的方案，往往在SoC会重新进行模块的划分。有些IP会被重新规划后打散分布在芯片各个位置，有些IP会被划分到不同的物理模块中，因此SoC级别与IP级别的架构层级(hierarchy)和互联会有较大区别，这也是IP验证无法覆盖的部分。

最后，SoC级验证，随着集成电路规模的不断增加，不可避免地会存在前文中提到的仿真时间长，验证场景受限等问题。对于IP到SoC的集成，需要尽可能的避免不必要的人为引发的错误而耽误SoC验证时间。各个IP在更新迭代过程中，如何能够在重要节点进入SoC时互不干扰地有序进行，且能够在进入时以一个标准流程去保证IP质量，而不会把问题带入SoC，以免各IP混乱进入导致各种问题错乱叠加，不仅增加调试的难度，更是延长了验证的周期。

本发明实施例面向芯片子系统(以MemSub子系统部分为例，但不局限于此)的设计验证，针对现有DB版本维护方式存在的局限性，并考虑IP级验证无法验证SoC的实际数据通路以及物理设计中插入的中继单元、时钟同步电路、电压转换电路等问题，而IP改动后需要及时集成到SoC进行验证，提出了一种改进的验证流程标准和方式，实现了对IP在SoC的重新规划后进行验证时，IP进入SoC的准入流程，进行对IP最基本的验收，避免因IP质量不过关而把问题带入SoC的问题。

一方面，本发明实施例提供一种芯片IP准入验证方法，如图4所示，本实施例可以包括：

步骤101：获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

步骤102：搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

本步骤中，IP级验证环境可参考前面关于图2和图3的相关描述；具体实施时，可以使用IP级验证环境需要提交的包含本次相关改动的修改清单(changelist，也即所述待验证版本相对所述前一版本的修改清单)，完成IP回归测试，保证所述待验证版本在IP级是通过验证的。

步骤103：根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

本步骤中，也就是IP的改动在匹配SoC去做相应的调整(插入时钟同步电路、电压转换电路、中继单元等物理版图设计工作)并完成C/VCS编译通过。

步骤104：在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

本步骤中，可在SoC针对不同验证平台配置，定义相关的可用性测试，包括对每个验证平台配置的基本通路的简单访问等，以完成SoC可用性测试。

本发明实施例提供的芯片IP准入验证方法，对目标IP的待验证版本既进行了IP级验证，又进行了SoC级验证，其中SoC级验证环境复用了IP级验证环境，这样能够在IP改动后集成到SoC之前对IP进行验收，避免因IP质量不过关而把问题带入SoC，在有效的短时间内，能够完成对IP集成进入SoC进行质量监督，使得SoC验证能够顺利进入下一步，从而能够节省验证资源，减少芯片验证迭代周期。

作为一种可选的实施例，为解决现有技术中IP DB和SoC DB版本混乱的问题，所述获取目标IP的待验证版本(步骤101)之前可以包括：

步骤100：设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoCDB，如图5所示，该数据库的目录采用嵌套子系统架构，数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，优选的，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。总之，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库(SoC DB)。

本申请提出了一种新的数据库架构，用于存放多个项目的IP DB和SoC DB，该数据库的组建流程可以参考如下：

首先，定义整个DB目录采用嵌套子系统(nested subsystem)架构，将整个项目所使用的文件目录进行分类，按照IP DB和SoC DB所使用的方式，将公共的及多个IP需要共享的资源提取出来放置于公用库(common libraries)目录下，然后根据各个IP的属性，将IP本身的资源放置于IP主数据库(IP main DB)，需要使用别的IP的资源时以引进(import)的方式从其他IP main DB获取相应的版本来进行。这样IP main DB就组建完成。

然后，在各IP main DB形成的基础上，按照不同的项目对各IP的定义需求，长出不同的分支数据库(branch，注意从main到branch的branch视图是完整的branch)来为不同的项目服务。注意IP main DB上对于不同项目的划分方式，可以是main DB本身src(资源)对于不同项目有不同的define(定义)参数，也可以是不同的import需求，或者是commonlibraries里使用的不同目录等等。总之，IP branch DB是IP main DB的直接镜像，拥有同样的目录结构，仅通过顶层的配置就可以完成对不同branch DB的组建。

最后，我们按照IP branch DB的定义，去组建SoC DB，使用类似的方式定义，配置需要的common libraries内容、各IP branch DB版本、以及SoC DB的src目录一起就完成了对应项目的SoC DB组建。

在图5所示实施例中，存在四个项目和三个IP，四个项目分别为Project A、Project B、Project C和Project D，三个IP分别为IP 1、IP 2和IP 3。在IP 1中，基于IPmain DB，为四个项目分别生成了四个分支数据库，即IP branch DB A、IP branch DB B、IPbranch DB C和IP branch DB D，四个分支数据库分别对应每个项目的SoC DB。这样对于每个项目，只需维护相应的common libraries、IP main/branch DB、SoC DB即可。

需要注意的是，对于所有common libraries、IP main/branch DB、SoC DB的版本发布，都需要维护相应的发布说明(Release note)来进行相应的记录和同步。保持良好的历史记录说明，非常有益于大型SoC系统版本的跟踪和维护。

基于上述数据库架构，IP/SoC DB的版本集成可以采用从下而上(bottom up)的方式进行。当IP main DB有设计/环境改动或周期性更新时，要求：

1.IP main DB的改动基于IP main DB最新回归测试(regression)通过的版本进行相应改动；

2.通过IP可用性(sanity)测试及regression正常运行的基础上，可集成到IPbranch DB；

3.IP branch DB发布版本，需要通过branch sanity测试，可集成到SoC；

4.通过SoC sanity test后，可发布IP版本。

上述要求中提及的回归(regression)测试和可用性(sanity)测试等均为本领域常规技术，可根据公知常识实现，此处不再赘述。

也就是说，作为一种可选的实施例，所述搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本(步骤102)，可以包括：将所述待验证版本集成到所述IP分支数据库。

作为另一种可选的实施例，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

作为再一种可选的实施例，所述在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC(步骤104)，可以包括：

允许所述待验证版本集成到SoC时，发布IP新版本(即所述待验证版本)。

对于IP main DB的维护，要求任何设计、验证环境或者流程上的改动都需要通过IP main DB sanity测试后才能提交。另外可以以一定周期(自定义，可以是每三天/每周/每两周等)起IP main DB回归测试，保证规律的发布稳定版本供branch/SoC使用。

对于IP branch DB的维护，无论是周期性或者有设计/验证环境改动的情况，要求选择IP main DB sanity测试通过，regression正常的版本进行集成(integrate)，并且IPbranch DB sanity测试通过后，进行提交。需要注意的是，如有临时漏洞修补(fix)需求，需要马上完成，可进行部分branch，这种情况下可以只集成相应文件到branch，后续再跟进IPmain DB发布版本集成相关其他文件到branch来保证版本统一，要求是通过IP branch DBsanity测试后可以提交。

对于SoC DB的维护，所有common libraries/IP/SoC main DB的改动，都需要通过SoC sanity测试后才可以进行提交，并且要求是基于上一个完好版本对应的修改列表(changelist)进行，以此来保证每一个SoC DB版本的健康发布。

按照以上规范流程操作，各个IP可以在互不干扰的情况下，各自完成到SoC DB的集成，并且能够井然有序地保证每一个SoC版本都健康完好。而且从IP到SoC的集成版本有迹可循，如果出现问题需要做回退或者合并时非常便捷且易于同步。为大型SoC系统的维护工作提供了事半功倍的效果。

在进一步的实施例中，为方便芯片验证的逐步开展，本发明实施例提出在SoC级验证环境中对芯片的数据通路的划分方式，具体划分为：数据总线子系统(即图1中的片上数据网络部分)和内存子系统(即图1中的MemSub)两个层次。

发明人在研究过程中发现：

对于数据总线子系统，在后端布局布线时，由于此IP的特殊性，并未以一个完整的顶层设计去进行布局，而是被打散后分布在多个位置，且需要调整数据总线内部模块的摆放位置及距离，那么最终布局确定后，会把插入的中继单元(repeater)或者同步单元(synccells)反标回被测设备(Device-Under-Test，DUT)去增加相应的模块，这也是和IP环境里的DUT最大区别。其次这个数据总线IP和其他模块的接口设计都是跨时钟电压域的设计，相应的跨时钟电压域模块也是在SoC级别集成时才会插入到DUT中去，对于IP DUT仍不可见，这是和IP环境里的DUT的另一区别。

对于内存子系统，由于芯片级对高带宽存储器的摆放位置有一定的要求和限制，因此其他模块会在布局布线时配合这些无法打破的规则，也包括对于插入的中继单元及跨时钟电压域设计，在SoC构建的子系统层次和连接已经发生了很大改变。由此可见，芯片级的设计本身就已经和IP级设计有了很多的不一样，因此很有必要在SoC级验证划分出子系统的定义，用来弥补IP验证的不足，也对SoC级验证的压力进行了分担。

如图6所示，本发明实施例中的验证思路为：按照SoC hierarchy(层次架构)逐级封装为两个层次的子系统：数据总线子系统和内存子系统MemSub。数据总线子系统是进行SoC级验证的第一步，只有数据总线子系统调试通过后，整个SoC才可以进入启动调试(bringup)阶段。在数据总线子系统的基础上，可以按照不同的侧重点扩展例如MemSub子系统、IO(输入输出)子系统、dma(Direct Memory Access，直接存储器访问)子系统、dsp(Digital Signal Processing，数字信号处理)子系统、计算子系统等等这样的区域划分，逐步扩大验证区域(domain)来开展对整个SoC验证的全覆盖。

针对内存子系统，本发明实施例定义了两个层次的子系统(即上述的数据总线子系统和内存子系统)验收，下面分别说明如下：

首先，针对数据总线子系统，此处，SoC级验证环境的搭建按照本领域常规技术进行即可，简要说明如下：

在验证环境中，将SoC视图的数据总线子系统(即图1的片上数据网络部分)单独封装为DUT进行验收。确定SoC子系统设计划分后，相应进行SoC级验证环境的搭建。这个SoC级验证环境的特点是充分利用IP级验证环境已经创建并验证过的验证组件，集成到SoC子系统环境中复用。根据需求增加SoC数据通路的检查器(checker)/记分板(scoreboard)，以达到充分验证子系统功能的要求。对于数据总线子系统来说，搭建的SoC级验证环境如图6所示。

SoC级验证环境采用UVM(Universal Verification Methodology，通用验证方法学)验证框架，充分利用IP级验证环境已经调试好的验证组件，封装为独立的整个ENV(uvm_env组件)集成进入SoC。在此基础上需要针对SoC层级的数据通路以及关注点，开发DUT顶层的计分板(top scoreboard)去监控来自master UVC的数据交易，是否能和内存模型(memory model)记录的数据交易一一匹配，比对包括写数据检测、读数据检测、收发数量检测、合法性检测和一致性检测这些方面。这样整个验证环境就搭建完成。

SoC级验证环境启动调试(bringup)完成后，需要定义对于此数据总线子系统的验收标准。每一次IP的任何改动(包括设计改动和IP验证组件改动)在提交SoC时，需要通过此验收流程也即准入许可后才允许被提交。针对这个数据总线子系统，定义验收准入流程即前述步骤101-104。

为提高验收测试的准确性，对于数据总线子系统，步骤104中可用性测试所使用的测试集可以包括以下至少一种：

寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；

从验证环境的主接口模块(master)到从接口模块(slave)的完整数据访问通路；因数据总线的特殊性，master到slave的数据通路有几百条，按照master/slave本身属性，可以进行划分，然后用随机挑选多类中的某一条path进行测试；

基于所述修改清单(即此次更新的改动)所提出的相关特征(feature)测试，从IP测试集中移植典型测试序列到SoC，完成此次集成的质量监控。

其次，针对内存子系统，所述内存子系统是在所述数据总线子系统的基础上进一步扩展封装得到，此时验证平台可以包括为多种配置，例如可以为3种配置：配置1为数据总线+存储控制器，配置2为数据总线+存储控制器+物理层模块，配置3为数据总线+物理层模块+内存单元，所述内存子系统的IP准入验收方法用于每一次IP改动后在提交SoC时搭建验证环境对IP进行验证；

本实施例中，是在数据总线子系统的基础上，进一步做扩展，封装第二层级的包含内存单元模块的内存子系统，如图1所示。可以封装数据总线、存储控制器、物理层模块(PHY)和内存单元为一个子系统；在SoC采用了和IP同样的验证平台配置划分，将数据通路定义为3种配置：配置1为数据总线+存储控制器，配置2为数据总线+存储控制器+物理层模块，配置3为数据总线+物理层模块+内存单元(完整数据通路)。重点是关注数据总线和内存模块的读写访问，数据交互时的性能分析，以及多个平铺层级(tile)之间控制通路访问等。

对于内存子系统的SoC级验证环境搭建，同样可以按照本领域常规技术进行即可，简要说明如下：

如图7所示，在数据总线子系统的基础上，去除原有的slave UVC使用BYPASS(旁路)通路，并且增加内存模块IP验证环境中使用的ENV，其中包括各个子模块的监视器(monitor)、检查器(checker)以及顶层计分板(top scoreboard)等，用于监测内存模块数据通路的行为是否符合预期。需要注意的是，定义的不同验证平台配置，对应的IP验证组件一个也不能少，需要全部集成到SoC验证环境中去。

验证环境启动调试(bringup)完成后，需要定义对于此内存子系统的验收标准。每一次IP的任何改动(包括设计改动和IP验证组件改动)在提交SoC时，需要通过此验收流程也即准入许可后才允许被提交。针对这个内存子系统，定义验收准入流程即前述步骤101-104。

略有不同的是，前述步骤102还可以针对不同验证平台配置完成对应的SoC视图组建(view build)；前述步骤104还可以针对不同验证平台配置来制定准入测试集。

为提高验收测试的准确性，对于内存子系统，步骤104中可用性测试所使用的测试集可以包括：

不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；

不同验证平台配置下从验证环境的主接口模块(master)到从接口模块(slave)的完整数据访问通路；不同验证平台配置到达的数据末端不同，分步打通完整数据通路测试；

基于所述修改清单(即此次更新的改动)所提出的相关特征(feature)测试，从IP测试集中移植典型测试序列到SoC，完成此次集成的质量监控；

针对内存子系统的特殊性提取的典型特征(feature)测试，比如初始化流程的方式多样性，或者不同时钟频率工作模式等方面。

综上，本发明实施例的芯片IP准入验证方法的技术效果是：

1.统一规范IP DB和SoC DB版本控制流程，保证代码版本统一有质量的监管；

2.针对IP的缺点，能够验证IP在SoC真实层次架构(hierarchy)和组成结构，并尽早尽快地验证IP集成到SOC的质量；

3.采用配置生成(configuration build)划分的概念，搭建内存子系统验证环境，分块分步完成不同IP在SoC的迭代验证；

4.改进了传统的SoC级芯片对IP集成进入SoC的质量监控，提高了系统验证的效率和质量，能有效快速地定位问题，避免IP错误瘫痪整个SoC验证回归。

本发明实施例主要的创新点在于，针对大规模集成电路芯片的复杂性，规范DB版本控制流程，并在IP和SoC级验证层级再一次进行划分，提出子系统的概念，并且针对IP与SoC的异同，在初期提高IP准入标准进行验收。能在有限的投入情况下，最大化的获得验证收益。此思路可以通用于任意SoC子系统的SoC级验证。

另一方面，本发明实施例提供一种芯片IP准入验证装置，如图8所示，该装置可以包括：

获取模块11，用于获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

第一测试模块12，用于搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

组建模块13，用于根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

第二测试模块14，用于在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

本实施例的装置，可以用于执行图4所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

优选的，所述装置还包括：

设定模块，用于设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoC DB，所述数据库的目录采用嵌套子系统架构，所述数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库。

优选的，所述第一测试模块12包括：

集成子单元，用于将所述待验证版本集成到所述IP分支数据库。

优选的，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。

优选的，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

优选的，所述第二测试模块14包括：

划分子单元，用于在所述SoC级验证环境中芯片的数据通路划分为数据总线子系统和内存子系统两个层次，其中：

针对芯片的数据总线子系统，所述可用性测试所使用的测试集包括以下至少一种：寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；

和/或，针对芯片的内存子系统，所述内存子系统是在芯片的数据总线子系统的基础上进一步扩展封装得到，所述可用性测试所使用的测试集包括以下至少一种：不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；不同验证平台配置下从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；针对所述内存子系统的特殊性提取的典型特征测试。

本发明实施例还提供一种电子设备，图9为本发明的电子设备一个实施例的结构示意图，可以实现本发明图4所示实施例的流程，如图9所示，上述电子设备可以包括：壳体41、处理器42、存储器43、电路板44和电源电路45，其中，电路板44安置在壳体41围成的空间内部，处理器42和存储器43设置在电路板44上；电源电路45，用于为上述电子设备的各个电路或器件供电；存储器43用于存储可执行程序代码；处理器42通过读取存储器43中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一方法实施例所述的方法。

处理器42对上述步骤的具体执行过程以及处理器42通过运行可执行程序代码来进一步执行的步骤，可以参见本发明图2所示实施例的描述，在此不再赘述。

该电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子设备。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例所述的方法步骤。

本发明的实施例还提供一种应用程序，所述应用程序被执行以实现本发明任一方法实施例提供的方法。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本发明时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (14)

1.一种芯片IP准入验证方法，其特征在于，包括：

获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

2.根据权利要求1所述的方法，其特征在于，所述获取目标IP的待验证版本之前包括：

设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoC DB，所述数据库的目录采用嵌套子系统架构，所述数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库。

3.根据权利要求2所述的方法，其特征在于，所述搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本，包括：

将所述待验证版本集成到所述IP分支数据库。

4.根据权利要求2所述的方法，其特征在于，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。

5.根据权利要求2所述的方法，其特征在于，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

6.根据权利要求1-5中任一所述的方法，其特征在于，所述在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC，包括：

在所述SoC级验证环境中芯片的数据通路划分为数据总线子系统和内存子系统两个层次，其中：

针对芯片的数据总线子系统，所述可用性测试所使用的测试集包括以下至少一种：寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；

和/或，针对芯片的内存子系统，所述内存子系统是在芯片的数据总线子系统的基础上进一步扩展封装得到，所述可用性测试所使用的测试集包括以下至少一种：不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；不同验证平台配置下从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；针对所述内存子系统的特殊性提取的典型特征测试。

7.一种芯片IP准入验证装置，其特征在于，包括：

获取模块，用于获取目标IP的待验证版本，其中所述待验证版本是在前一版本的基础上修改得到，所述前一版本为IP级验证通过的版本；

第一测试模块，用于搭建IP级验证环境，对所述待验证版本进行测试，确保所述待验证版本为IP级验证通过的版本；

组建模块，用于根据所述待验证版本相对所述前一版本的修改清单，完成SoC配置组建；

第二测试模块，用于在所述IP级验证环境的基础上，搭建SoC级验证环境对所述SoC进行可用性测试，并在所述可用性测试通过的情况下，允许所述待验证版本集成到SoC。

8.根据权利要求7所述的装置，其特征在于，还包括：

设定模块，用于设定数据库DB架构，所述DB架构用于存放至少两个项目的IP DB和SoCDB，所述数据库的目录采用嵌套子系统架构，所述数据库包括一个公用库、至少两个IP主数据库、至少两个IP分支数据库和至少两个SoC数据库，其中：

每个项目所使用的文件目录分类按照IP DB和SoC DB所使用的方式，公共的及多个IP需要共享的资源放置于所述公用库的目录下，根据各个IP的属性不同，IP本身的资源放置于IP主数据库，需要使用别的IP的资源时以引进的方式从其他IP主数据库获取相应的版本来进行；

IP分支数据库是在IP主数据库的基础上，按照不同的项目对各IP的定义需求生成得到，IP分支数据库是IP主数据库的直接镜像，拥有同样的目录结构，仅通过顶层的配置形成不同项目所需的IP分支数据库；

按照IP分支数据库的定义，配置需要的公用库内容、各IP分支数据库版本、以及SoC数据库的资源目录，即可形成不同项目所需的SoC数据库。

9.根据权利要求8所述的装置，其特征在于，所述第一测试模块包括：

集成子单元，用于将所述待验证版本集成到所述IP分支数据库。

10.根据权利要求8所述的装置，其特征在于，不同项目所需的IP分支数据库的形成，是基于IP主数据库本身资源对于不同项目有不同的定义参数，或者是不同的引进需求，或者是公用库里使用的不同目录。

11.根据权利要求8所述的装置，其特征在于，所述待验证版本是基于IP主数据库最新回归测试通过的版本进行修改得到。

12.根据权利要求7-11中任一所述的装置，其特征在于，所述第二测试模块包括：

划分子单元，用于在所述SoC级验证环境中芯片的数据通路划分为数据总线子系统和内存子系统两个层次，其中：

针对芯片的数据总线子系统，所述可用性测试所使用的测试集包括以下至少一种：寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；

和/或，针对芯片的内存子系统，所述内存子系统是在芯片的数据总线子系统的基础上进一步扩展封装得到，所述可用性测试所使用的测试集包括以下至少一种：不同验证平台配置下寄存器读写访问数据通路，包括寄存器模型的前门和后门的随机寄存器测试；不同验证平台配置下从验证环境的主接口模块到从接口模块的完整数据访问通路；基于所述修改清单所提出的相关特征测试；针对所述内存子系统的特殊性提取的典型特征测试。

13.一种电子设备，其特征在于，所述电子设备包括：壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码；处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行上述权利要求1-6任一所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述权利要求1-6任一所述的方法。

Images