CN116719747B - 一种芯片多版本的验证方法 - Google Patents

Abstract

本申请涉及半导体领域，公开了一种芯片多版本的验证方法，可以用极少测试用例完成芯片多版本验证。该方法包括生成包含所有芯片版本信息和用户寄存器信息的父类。基于父类生成包含芯片版本约束关系、用户模式约束关系以及应用场景约束的子类，用户模式约束关系为芯片功能点与用户寄存器配置之间的约束关系。基于子类，根据验证的功能点，约束当前功能点必须配置信息，随机配置非必需芯片功能点，根据子类内的约束关系，自动随机选择对应的芯片版本、应用场景、寄存器配置信息，共同构成当前验证测试用例的所有激励信息，激励信息按照既定方式发送到待测模块的同时，自动触发对应的覆盖率并记录，此用例随机多次，直至覆盖率达到预设目标结束验证。

Description

一种芯片多版本的验证方法

技术领域

本申请涉及半导体领域，具体涉及一种芯片多版本的验证方法。

背景技术

本部分旨在为权利要求书中陈述的本申请的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是已被公开的现有技术。

芯片验证就是采用相应的验证语言，验证工具和验证方法，在芯片生产之前验证芯片设计是否符合芯片定义的需求规格。

随着芯片规模越来越大，功能越来越复杂，对验证的挑战越来越大，芯片验证的方法学，就是研究怎样降低验证工程复杂度的同时，保证验证的可靠性。从它被提出到今天，其核心依然是带约束的随机激励、覆盖率驱动以及重用，并利用面向对像语言的特性对常用功能进行高度封装，再提供统一的事物层接口使不同抽象层级的建模数据得以共享和有效通信，从而提高验证平台的构建效率，并加速EDA仿真，最终缩短芯片面市周期。

目前的芯片开发过程中，芯片验证存在以下问题：芯片版本更新迭代m版，每一个芯片版本需要n个测试用例对n个功能点进行验证，此时就需要同步更新m*n个测试用例，工作量巨大，且和版本更新频次成正比；检查特定功能时，只配置对应的寄存器，但是如果各个功能之间存在耦合，例如使能A功能就无法使能B功能，这将可能导致实际应用上的风险；验证激励的随机性/多样性受限；验证环境子模块到系统验证的集成性受限。

发明内容

本申请的目的在于提供一种芯片多版本的验证方法，可以用极少数的测试用例完成芯片多版本验证。

本申请公开了一种芯片多版本的验证方法，包括：

生成包含所有芯片版本信息和用户寄存器信息的父类；

基于所述父类，生成包含芯片版本约束关系、用户模式约束关系以及应用场景约束的子类，所述用户模式约束关系为芯片功能点与用户寄存器配置之间的约束关系；

基于所述子类，根据验证的功能点，约束当前功能点必须配置信息 ，随机配置非相关芯片功能点的配置信息，根据子类内的约束关系，自动随机选择对应的所述芯片版本、所述应用场景、所述用户寄存器配置信息，共同构成当前验证测试用例的所有激励信息，所述激励信息按照既定方式发送到待测模块的同时，自动触发对应的覆盖率并记录，此用例会被随机多次，直至覆盖率达到预设目标结束验证。

在一个优选例中，还包括生成单一功能覆盖率和交叉功能覆盖率；

所述单一功能覆盖率指和芯片版本无约束关系的功能点的统计数据；

交叉功能覆盖率指在特定配置条件下、特定应用场景或者特定芯片版本情况下的才生效的功能点的统计数据，包括但不限于芯片功能以及用户模式的约束关系。

在一个优选例中，还包括生成RALF文件，所述RALF文件可用来生成验证环境的用户寄存器的模型，同时也可以用于设计生成寄存器相关的RTL代码。

在一个优选例中，所述芯片功能点与用户寄存器配置之间的约束关系被配置为描述不同的芯片版本使能的功能点以及所述用户寄存器的分配。

在一个优选例中，所述芯片版本约束关系被配置为描述各个芯片版本功能点对应的配置约束关系，其中包括出厂前电子熔断器数值 、功能点对应用户寄存器的配置约束，以及当前芯片功能点验证非必需的寄存器的随机程度和分布。

在一个优选例中，所述应用场景约束包括但不限于时钟源、时钟频率、通信接口类型、频率和时序，供电电压、模拟信号输入以及芯片连接方法。

在一个优选例中，还包括基于所述芯片版本的信息和所述芯片功能点的增删，使用脚本改变所述父类中的所述芯片版本信息和所述用户寄存器信息。

本申请还公开了一种芯片验证设备，包括：

存储器，用于存储计算机可执行指令；以及，

处理器，与所述存储器耦合，用于在执行所述计算机可执行指令时实现如前文描述的方法中的步骤。

本申请还公开了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如前文描述的方法中的步骤。

本申请的实施方式中，通过生成包含所有芯片版本信息和用户寄存器信息的父类，并基于父类派生包含芯片版本约束关系、用户模式约束关系以及应用场景约束的子类，可以在子类中设置当前功能点必须配置的信息，其余非相关功能点随机配置的方式保证对必须验证的芯片版本的功能点进行验证，通过确保覆盖率达到预设目标可以保证随机验证的完备性。芯片迭代开发过程中，大部分情况，只需要在子类中进行相应的修改，父类做少量的修改即可，因此极限条件下只需要一个测试用例，完全随机情况下，可完成对芯片多版本的验证；

进一步地，父类可以通过脚本自动生成，每次功能的增删，直接脚本重新生成一个新的父类，既保证信息的唯一性，又节省人力资源；

进一步地，单一功能覆盖率和交叉功能覆盖率可以保证和芯片版本无约束关系的功能点以及在特定配置条件下、特定应用场景或者特定芯片版本情况下的才生效的功能点的统计数据、芯片功能以及用户模式的约束关系是否被全部覆盖，从而进一步保证了验证的完备性。

上述发明内容中公开的各个技术特征、在下文各个实施方式和例子中公开的各技术特征、以及附图中公开的各个技术特征，都可以自由地互相组合，从而构成各种新的技术方案（这些技术方案均应该视为在本说明书中已经记载），除非这种技术特征的组合在技术上是不可行的。例如，在一个例子中公开了特征A+B+C，在另一个例子中公开了特征A+B+D+E，而特征C和D是起到相同作用的等同技术手段，技术上只要择一使用即可，不可能同时采用，特征E技术上可以与特征C相组合，则，A+B+C+D的方案因技术不可行而应当不被视为已经记载，而A+B+C+E的方案应当视为已经被记载。

附图说明

图1是根据本申请的一个实施方式的流程示意图；

图2是根据本申请的一个实施方式的流程示意图。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

部分概念的说明：

如本文所用，“电子熔断器”，又称为eFuse，全称为electronic fuse，是一种可编程电子保险丝，是一种用于存储信息和保护芯片的非易失性存储器件。

如本文所用，“regmap”是在linux内核为减少慢速I/O驱动上的重复逻辑，提供一种通用的接口来操作底层硬件寄存器的模型框架。

如本文所用，“RALF文件”是对寄存器的描述文件。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。

本申请的第一实施方式涉及一种芯片多版本的验证方法，其流程如图1所示，该方法包括以下步骤：

在步骤S101中，生成包含所有芯片版本信息和用户寄存器信息的父类。

在步骤S102中，基于父类，生成包含芯片版本约束关系、用户模式约束关系以及应用场景约束的子类，用户模式约束关系为芯片功能点与用户寄存器配置之间的约束关系。

在步骤S103中，基于子类，根据验证的功能点，约束当前功能点必须配置的信息，随机配置非相关芯片功能点的配置信息，根据子类内的约束关系，自动随机选择对应的芯片版本、应用场景、用户寄存器配置信息，共同构成当前验证测试用例的所有激励信息，激励信息按照既定方式发送到待测模块的同时，自动触发对应的覆盖率并记录，此用例会被随机多次，直至覆盖率达到预设目标结束验证。

在一个可选的实施例中，在步骤S101之前，还可以包括输入信息，输入的信息可以包括芯片版本的定义、芯片各版本用户寄存器的定义、测试寄存器的定义、芯片功能点的描述以及应用场景。

在一个可选的实施例中，还可以包括生成单一功能覆盖率文件和交叉功能覆盖率文件。单一功能覆盖率指和芯片版本无约束关系的功能点的统计数据，可选的，单一功能覆盖率为所有版本所共有的功能点或者某特定版本特有的功能点。交叉功能覆盖率指在特定配置条件下、特定应用场景或者特定芯片版本情况下的才生效的功能点的统计数据，包括但不限于芯片功能以及用户模式的约束关系，可以较强地体现芯片版本。

在一个可选的实施例中，还可以包括生成寄存器RALF文件，RALF文件可以用于验证生成验证环境的寄存器模型，以及用于设计生成寄存器相关RTL代码。

在一个可选的实施例中，芯片功能点与用户寄存器配置之间的约束关系可以被配置为描述不同的芯片版本使能的功能点以及用户寄存器的分配。

在一个可选的实施例中，芯片版本约束关系可以被配置为描述各个芯片版本功能点对应的配置约束关系，其中包括出厂前电子熔断器数值（可选的，同一芯片不同版本，开放的功能点可能不同，硬件资源可能不同，性能可能不同，功耗可能不同）、功能点对应用户寄存器的配置约束，以及当前芯片功能点验证非相关的寄存器的随机程度和分布。

在一个可选的实施例中，应用场景约束可以包括时钟源、时钟频率、通信接口类型、频率和时序、供电电压、模拟信号输入以及芯片连接方法等。

在一个可选的实施例中，还可以包括基于芯片版本的信息和芯片功能点的增删，使用脚本改变父类中的芯片版本信息和用户寄存器信息等。

为了能够更好地理解本申请的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请的保护范围的限制。如图2所示：

在步骤S201中，输入信息。

在步骤S202中，对芯片版本定义、各芯片版本用户寄存器或测试寄存器定义进行抽象，生成表格。

在步骤S203中，基于步骤S202中的表格，生成包含芯片版本信息和用户寄存器的父类。

在步骤S204中，基于步骤S202中的表格，生成不包含交叉覆盖率的覆盖率文件，仿真工具可以基于此文件统计生成覆盖率数据。

在步骤S205中，基于步骤S202中的表格，生成RALF文件。

在步骤S2051中，将步骤S205中的RALF文件用于生成验证环境的寄存器配置文件regmap。

在步骤S2052中，将步骤S205中的RALF文件用于设计用特定的工具生成寄存器相关的RTL代码。

在步骤S206中，基于步骤S203中的父类，派生出1个新的子类。其中，子类在父类的基础上增加了以下内容：①功能点的拆分：芯片拆分成不同粒度的功能点，包括单项功能点，以及多个功能点之间的配合；②功能点的配置约束关系：描述功能点对应的配置约束关系，包括用户寄存器/Fuse值的设置范围，以及不相关寄存器的随机程度和分布；③芯片版本和寄存器之间约束关系：描述不同芯片版本对应功能点的开放以及用户寄存器的分配。④应用场景的约束：如外部晶振频率、通信接口类型、频率、时序、芯片连接关系(单片，串联，并联)等。

在步骤S207中，基于步骤S206生成的信息类，用于芯片的出厂Fuse值的烧写、应用场景的选择（内部时钟/外部时钟频率/功耗等）或用户寄存器的配置。

在步骤S208中，基于步骤S206，在步骤S204中生成的覆盖率文件中增加交叉覆盖率。交叉覆盖率的内容包括特殊功能点与芯片版本之间的映射关系，确保对应不同版本独有的独特功能点被覆盖、公共功能点之间相互约束关系，确保功能点之间的配合关系被覆盖，以及包括一些其它特殊的约束关系。

在步骤S209中，基于步骤S206，写对应的检查项。

在步骤S210中，跑测试用例，收集覆盖率。

本申请的第二实施方式涉及一种芯片验证设备，该芯片验证设备包括：

存储器，用于存储计算机可执行指令；以及，

处理器，与所述存储器耦合，用于在执行所述计算机可执行指令时实现如上所述的方法中的任意步骤。

第一实施方式是与本实施方式相对应的方法实施方式，第一实施方式中的技术细节可以应用于本实施方式，本实施方式中的技术细节也可以应用于第一实施方式。

相应地，本申请的实施方式还提供一种计算机可读存储介质，其中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现本申请的各方法实施方式。计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于，相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读存储介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

需要说明的是，在本申请中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本申请中，如果提到根据某要素执行某行为，则是指至少根据该要素执行该行为的意思，其中包括了两种情况：仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。

在描述方法的步骤时使用的序号本身并不对这些步骤的顺序构成任何的限定。例如，序号大的步骤并非一定要在序号小的步骤之后执行，也可以是先执行序号大的步骤再执行序号小的步骤，还可以是并行执行，只要这种执行顺序对于本领域技术人员来说是合理的即可。又如，拥有连续编号序号的多个步骤（例如步骤101，步骤102，步骤103等）并不限制其他步骤可以在其间执行，例如步骤101和步骤102之间可以有其他的步骤。

本说明书包括本文所描述的各种实施例的组合。对实施例的单独提及（例如“一个实施例”或“一些实施例”或“优选实施例”）；然而，除非指示为是互斥的或者本领域技术人员很清楚是互斥的，否则这些实施例并不互斥。应当注意的是，除非上下文另外明确指示或者要求，否则在本说明书中以非排他性的意义使用“或者”一词。

在本说明书提及的所有文献都被认为是整体性地包括在本申请的公开内容中，以便在必要时可以作为修改的依据。此外应理解，以上所述仅为本说明书的较佳实施例而已，并非用于限定本说明书的保护范围。凡在本说明书一个或多个实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例的保护范围之内。

在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

Claims (9)

1.一种芯片多版本的验证方法，其特征在于，包括：

生成包含所有芯片版本信息和用户寄存器信息的父类；

基于所述父类，生成包含芯片版本约束关系、用户模式约束关系以及应用场景约束的子类，所述用户模式约束关系为芯片功能点与用户寄存器配置之间的约束关系；

基于所述子类，根据验证的功能点，约束当前功能点必须配置的信息，随机配置非相关芯片功能点的配置信息，根据子类内的约束关系，自动随机选择对应的所述芯片版本、所述应用场景、所述用户寄存器配置信息，共同构成当前验证测试用例的所有激励信息，所述激励信息按照既定方式发送到待测模块的同时，自动触发对应的覆盖率并记录，此用例会被随机多次，直至覆盖率达到预设目标结束验证。

2.如权利要求1所述的芯片多版本的验证方法，其特征在于，还包括生成单一功能覆盖率和交叉功能覆盖率；

所述单一功能覆盖率指和芯片版本无约束关系的功能点的统计数据；

所述交叉功能覆盖率指在特定配置条件下、特定应用场景或者特定芯片版本情况下的才生效的功能点的统计数据，包括芯片功能以及用户模式的约束关系。

3.如权利要求1所述的芯片多版本的验证方法，其特征在于，还包括生成寄存器RALF文件，所述RALF文件用于生成验证环境的寄存器模型，以及用于设计生成寄存器相关的RTL代码。

4.如权利要求1所述的芯片多版本的验证方法，其特征在于，所述芯片功能点与用户寄存器配置之间的约束关系被配置为描述不同的芯片版本使能的功能点以及所述用户寄存器的分配。

5.如权利要求1所述的芯片多版本的验证方法，其特征在于，所述芯片版本约束关系被配置为描述各个芯片版本功能点对应的配置约束关系，其中包括出厂前电子熔断器数值、功能点对应用户寄存器的配置约束，以及当前芯片功能点验证非相关寄存器的随机程度和分布。

6.如权利要求1所述的芯片多版本的验证方法，其特征在于，所述应用场景约束包括时钟源、时钟频率、通信接口类型、频率和时序，供电电压、模拟信号输入以及芯片连接方法。

7.如权利要求1所述的芯片多版本的验证方法，其特征在于，还包括基于所述芯片版本的信息和所述芯片功能点的增删，使用脚本改变所述父类中的所述芯片版本信息和所述用户寄存器信息。

8.一种芯片验证设备，其特征在于，包括：

存储器，用于存储计算机可执行指令；以及，

处理器，与所述存储器耦合，用于在执行所述计算机可执行指令时实现如权利要求1至7中任意一项所述的方法中的步骤。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如权利要求1至7中任意一项所述的方法中的步骤。