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

Abstract

本公开提供一种芯片验证方法、验证装置、电子设备及存储介质。该方法包括：获取第一待测对象模块，第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行第一随机激励信号后得到第一响应信号，用以验证第一待测对象模块；获取参考监控信息，参考监控信息包括第一模式下的错误场景对应的第一响应信号中的至少一个信号特征；基于第一随机激励获取目标文件，基于目标文件获取用于在第二模式向第一待测对象模块进行发送的第二直接激励，以及基于第二直接激励获取第一待测对象模块在执行第二直接激励后得到的第二响应信号；基于第二响应信号获取目标监控信息，基于目标监控信息和参考监控信息，获取错误场景是否复现的监控结果，目标监控信息包括第二响应信号中的至少一个信号特征。本公开可以排除随机稳定性对错误场景复现的影响，实现了对错误场景的稳定复现。

Description

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

技术领域

本公开的实施例涉及一种芯片验证方法、验证装置、电子设备及存储介质。

背景技术

验证是芯片设计过程中的一个关键步骤，通常利用验证平台实现。具体的，验证平台可模拟芯片的实际运行环境，使芯片基于预先设计的测试用例运行，并根据芯片的运行结果，检验芯片功能的正确性。

随着数字集成电路在规模和复杂性上的快速增长，以及大量功能类似芯片的快速发布需求，对芯片验证在时间和成本上提出了更高的要求。因此如何进一步优化芯片验证方案，以降低芯片验证的验证时间和验证成本，成为了本领域技术人员亟需解决的技术问题。

发明内容

本公开至少一实施例提供了一种芯片验证方法，包括：获取第一待测对象模块，其中，所述第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行所述第一随机激励后得到第一响应信号，用以验证所述第一待测对象模块；获取参考监控信息，其中，所述参考监控信息包括所述第一模式下的错误场景对应的第一响应信号中的至少一个信号特征；基于所述第一随机激励获取目标文件，并且基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，以及基于所述第二直接激励获取所述第一待测对象模块在执行所述第二直接激励后得到的第二响应信号；基于所述第二响应信号获取目标监控信息，并且基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，其中，所述目标监控信息包括所述第二响应信号中的至少一个信号特征。

例如，在本公开至少一实施例提供的一种芯片验证方法中，基于所述第一随机激励获取目标文件，包括：使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向所述第一待测对象模块发送第三激励；基于所述第三激励获取对应的成员信息；获取用于所述目标文件的预设文本格式；基于所述预设文本格式和所述成员信息获取所述目标文件。

例如，在本公开至少一实施例提供的一种芯片验证方法中，基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，包括：读取所述目标文件，并且解析所述目标文件以获取对应的成员信息；基于解析得到的成员信息，生成所述第二直接激励，其中，所述第二直接激励包括对应于所述第三激励的固定激励序列；响应于所述第二模式，向所述第一待测对象模块发送所述第二直接激励。

例如，在本公开至少一实施例提供的一种芯片验证方法中，所述第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行所述第一随机激励后得到第一响应信号，用以验证所述第一待测对象模块，包括：通过运行随机序列发生器以在所述第一模式下向所述第一待测对象模块发送所述第一随机激励，并且获取所述第一待测对象模块在执行所述第一随机激励后得到的第一响应信号；基于所述第一随机激励确定所述第一待测对象模块的第一期望值；对比所述第一响应信号和所述第一期望值，确定所述第一待测对象模块的验证结果，其中，所述第一待测对象模块的验证结果包括发生错误场景或者未发生错误场景。

例如，在本公开至少一实施例提供的一种芯片验证方法中，获取参考监控信息，包括：响应于所述第一待测对象模块的验证结果包括所述发生错误场景，启动错误复现监控功能，获取所述参考监控信息。

例如，本公开至少一实施例提供的一种芯片验证方法还包括：在获取所述目标文件之后，从所述第一模式切换至所述第二模式，使得基于所述目标文件获取所述第二直接激励。

例如，在本公开至少一实施例提供的一种芯片验证方法中，基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，包括：响应于所述目标监控信息中的信号特征和所述参考监控信息中的信号特征相匹配，所述监控结果包括错误场景复现；以及响应于所述目标监控信息中的信号特征和所述参考监控信息中的信号特征不匹配，所述监控结果包括错误场景未复现。

例如，本公开至少一实施例提供的一种芯片验证方法还包括：响应于所述监控结果包括所述错误场景复现，获取第二待测对象模块，其中，所述第二待测对象模块是基于所述第一待测对象模块进行修正的待测模块；基于所述目标文件获取用于向所述第二待测对象模块进行发送的所述第二直接激励，并且基于所述第二直接激励获取所述第二待测对象模块在执行所述第二直接激励后得到的第三响应信号；基于所述第二直接激励确定所述第二待测对象模块的第二期望值；对比所述第三响应信号和所述第二期望值，确定所述第二待测对象模块的验证结果。

例如，本公开至少一实施例提供的一种芯片验证方法还包括：在启动所述错误复现监控功能以及获取所述参考监控信息之后，确定所述错误复现监控功能是否正常。

例如，在本公开至少一实施例提供的一种芯片验证方法中，确定所述错误复现监控功能是否正常，包括：通过使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行所述随机序列发生器以向所述第一待测对象模块发送第四激励，用以确定所述错误复现监控功能是否正常。

例如，在本公开至少一实施例提供的一种芯片验证方法中，基于所述第三激励获取对应的成员信息，包括：通过发起方监视器监视所述第一待测对象模块的输入信号，获取向所述第一待测对象模块提供的第三激励，其中，所述输入信号是基于所述第三激励转换成的接口信号；从所述发起方监视器接收所述第三激励；其中，从所述发起方监视器接收的所述第三激励的类型是事务包或者接口信号；基于接收到的所述第三激励获取对应的成员信息。

本公开至少一实施例提供了一种芯片验证装置，包括：第一待测对象模块；第一验证模块，被配置为在第一模式下向所述第一待测对象模块提供第一随机激励且在所述第一待测对象模块执行所述第一随机激励后得到第一响应信号，以验证所述第一待测对象模块；目标文件获取模块，被配置为基于所述第一随机激励获取目标文件；直接激励获取模块，被配置为基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，使得基于所述第二直接激励获取所述第一待测对象模块在执行所述第二直接激励后得到的第二响应信号；错误复现监控模块，被配置为：获取参考监控信息以及目标监控信息，并且基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，其中，所述参考监控信息包括所述第一模式下的错误场景对应的第一响应信号中的至少一个信号特征，所述目标监控信息被配置为基于所述第二响应信号获取且所述目标监控信息包括所述第二响应信号中的至少一个信号特征。

例如，在本公开至少一实施例提供的一种芯片验证装置中，所述第一验证模块包括：随机序列发生器，被配置为在所述第一模式向所述第一待测对象模块提供所述第一随机激励；期望值确定单元，被配置为基于所述第一随机激励确定所述第一待测对象模块的第一期望值；验证结果确定单元，被配置为对比所述第一响应信号和所述第一期望值，确定所述第一待测对象模块的验证结果，其中，所述第一待测对象模块的验证结果包括发生错误场景或者未发生错误场景。

例如，在本公开至少一实施例提供的一种芯片验证装置中，所述目标文件获取模块被配置为：响应于使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向所述第一待测对象模块发送第三激励，并基于所述第三激励获取对应的成员信息；获取用于所述目标文件的预设文本格式，并基于所述预设文本格式和所述成员信息获取所述目标文件。

例如，在本公开至少一实施例提供的一种芯片验证装置中，所述直接激励获取模块被配置为：读取所述目标文件，并且解析所述目标文件以获取对应的成员信息；基于解析得到的成员信息，生成所述第二直接激励，其中，所述第二直接激励包括对应于所述第三激励的固定激励序列；响应于所述第二模式，向所述第一待测对象模块发送所述第二直接激励。

例如，本公开至少一实施例提供的一种芯片验证装置还包括模式切换器，其中，所述模式切换器被配置为选择所述第一模式或所述第二模式。

例如，在本公开至少一实施例提供的一种芯片验证装置中，所述芯片验证装置被配置为通过以下方式获取：基于激励事务包的成员信息获取预设文本格式；根据所述预设文本格式构建所述目标文件的下载功能，并且集成到验证环境中，与发起方监视器进行连接；根据所述预设文本格式构建所述目标文件的加载和解析功能，构建解析的成员信息与环境内建事务包的映射的功能，以及构建直接激励的启动功能；构建随机激励和所述直接激励的切换功能；集成空的功能到所述验证环境，与响应方监视器进行连接；根据错误场景下的响应事务包，构建错误复现被触发和/或报告的功能。

本公开至少一实施例提供了一种电子设备，包括：处理器和存储器，其中，所述存储器上存储有计算机程序，所述计算机程序被所述处理器执行时，实现如上文任一项所述的芯片验证方法。

本公开至少一实施例提供了一种计算机可读存储介质，其中，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时，实现如上述任一示例中所述的芯片验证方法。

附图说明

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

图1为一种验证平台示意图；

图2-图4为本公开一些实施例提供的一种芯片验证装置的示意图；

图5为本公开另一些实施例提供的一种芯片验证装置的示意图；

图6为本公开一些实施例提供的用户自定义文件的格式示例图；

图7为本公开一些实施例提供的芯片验证装置的组件构建和集成的示意图；

图8为本公开一些实施例提供的一种芯片验证方法的流程图；

图9为本公开一些实施例提供的基于第一随机激励获取目标文件的执行过程的流程图；

图10为图9中的步骤S312的一种执行过程的流程图；

图11为本公开一些实施例提供的基于目标文件获取第二直接激励的执行过程的流程图；

图12为本公开又一些实施例提供的一种芯片验证方法的流程图；

图13为本公开另一些实施例提供的芯片验证方法的流程图

图14为本公开一些实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

除非另有定义，本公开实施例使用的所有术语(包括技术和科学术语)具有与本公开所属领域的普通技术人员共同理解的相同含义。还应当理解，诸如在通常字典里定义的那些术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非本公开实施例明确地这样定义。

本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。同样，“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。本公开实施例中使用了流程图用来说明根据本公开实施例的方法的步骤。应当理解的是，前面或后面的步骤不一定按照顺序来精确的进行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步。

目前，采用验证方法学是芯片验证的趋势之一，通用验证方法学(UniversalVerification Methodology，简称UVM)是其中的典型代表。UVM是以SystemVerilog类为主的通用验证方法学，利用它的可重用组件，能够构建具有标准化层次结构和接口的功能验证环境，即UVM验证环境。UVM验证环境规定了UVM中的基本类(即可重用组件)，例如，序列编辑器(Sequencer，也可称为序列发生器)、监视器(Monitor)、激励器(Driver，也可称驱动器)等以及通信接口等(图1还省略了功能覆盖率组件)。对于目前一些主流的UVM验证平台，例如，如图1所示，Sequence为序列，意指它是UVM验证方法学定义的一种机制，用于在UVM验证平台中产生激励事务包(item，意指它是UVM验证方法学定义的类，用于把某一特定功能的一组信息封装在一起)并通过序列发生器(Sequencer)按照一定的顺序传递给激励器(Driver)；又例如，激励器用于在UVM验证平台中将激励事务包转为接口(Interface)信号输出给待测设计(Design Under Test，DUT，也可称待测对象)。例如，监视器(Monitor)可以包括发起方监视器(Master Monitor)和响应方监视器(Slave Monitor)。验证人员可在基本类的基础上扩展自己需要的类，然后用UVM标准的通信语句将各个类的通信接口连接起来。例如，接口(Interface)是一个用于连接DUT和UVM验证平台的信号级接口，在UVM验证平台组件内使用虚拟接口(Virtual Interface，Vif)进行接口信号的传递。例如，本公开的实施例的接口信号Vif可以理解为基于抓完实际的数据以后，使用虚拟接口并且通过软件层进行处理而得到的信号。例如，一个或多个代理(Agent)加上计分板构成了仿真环境(ENV，也可称验证环境)，例如仿真环境是一个分层组件，它将相互关联的验证组件组合在一起，封装了所有针对DUT的验证组件。测试用例是UVM测试平台中最顶层的组件，其负责执行测试，并将序列关联到序列发生器上。

随着超大规模集成电路设计复杂度的与日俱增，验证调试难度也呈指数级的增长。为了尽可能地在动态仿真中遍历各种预期场景，目前主流的UVM等验证方法学提供了受约束的随机结合功能覆盖率分析的方法，在确保激励有效性和全面性的前提下，自动生成测试集，从而避免编写庞大的定向测试集，提高激励生成的效率。但是本公开的发明人发现，现有的随机化验证方法，本身引入了“随机稳定性”问题：随机数发生器(Random NumberGenerator，RNG，意指它是一种由算法来模拟随机过程的程序，基于一个给定的范围内自动生成随机数)受验证环境随机种子设置、随机条目增减以及线程中随机调用顺序等影响，在版本迭代的过程中，激励的生成极易因验证环境的改变而波动，给错误用例的分析造成干扰，难以再次复现该错误场景。

本公开的发明人还发现，当错误场景间歇出现时，对随机值的错误复现最常用的方式就是增加其随机的次数，以提高该错误出现的几率。通常采用的方法是，在单支测试用例中手动增加随机激励生成的轮数，或者在服务器上增加该测试用例并行运行的次数。该方法的效率高低受限于设计规模：设计规模越大，单次仿真时间消耗就越大，多次运行以击中特定错误场景所需的时间就越长。

本公开的发明人又发现，目前还有一种错误复现的方法，该另一种错误复现的方法是固定错误用例对应的仿真种子号。该方法的效率高低受限于控制RNG的种子和算法的稳定性：验证环境运行时每个对象和线程都拥有属于自己的RNG，初始种子从父节点获取，经过一次随机后计算出新的种子号，供下一次随机使用。当其中任意节点的随机算法发生改变时，都会影响整体的随机结果。此外，在固定种子号的情况下，修改设计(例如被测试的设计，Design Under Test，DUT)会改变原有逻辑节点上的状态空间，也会使错误不再复现，却无法判断缺陷是否真的被修复。

例如，对于目前一些主流的UVM验证平台，如图1所示，激励的发送是通过受约束的随机序列(Constraint Sequence)产生事务包item，再经驱动器(Driver)组件转化为接口级信号输出给DUT。例如，该通用机制虽然便捷地产生了符合约束条件的序列向量，却受随机稳定性等影响使得序列无法固定。序列的差异性会导致重新运行测试用例时，无法复现之前的仿真场景。

本公开的发明人进一步发现，当仿真出现错误需要对场景进行复现时，上述较通用的两种错误复现方法均存在各自的弊端：对于通用方法一，本公开的发明人发现了在超大规模集成电路设计中的使用效率极低，因验证激励的随机数成员构成以及约束关系异常复杂，即使在用例多线程运行的条件下，该方法也无法做到短时间内快速地覆盖指定错误激励对应的随机数，而且对服务器计算和存储资源的整体占用是庞大的；对于通用方法二，本公开的发明人发现了在调试过程中，事实上不可避免地需要进行验证环境修改或者设计修复，会导致原有随机激励条目总数/顺序或者设计状态空间的改变。这种细微的改变不易察觉，却影响了对仿真结果的判断，无法确认错误是正确地被修复了，还是因无法复现掩盖了真实存在的问题。另外即使固定种子号，对于不同厂商的仿真工具，甚至各自的不同版本，RNG的算法都有差异，直接影响到随机数系统函数的生成，给分析结果带来极大的不确定性。

如上所述，本公开的发明人发现上述两种错误复现方法均难以高效执行，调试时间和资源占用消耗巨大，甚至最终会遗漏问题，无法从根本上排除随机稳定性带来的影响。

本公开至少一实施例提供了一种芯片验证方法，该方法包括：获取第一待测对象模块，其中，第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行第一随机激励后得到第一响应信号，用以验证第一待测对象模块；获取参考监控信息，其中，参考监控信息包括第一模式下的错误场景对应的第一响应信号中的至少一个信号特征；基于第一随机激励获取目标文件，并且基于目标文件获取用于在第二模式向第一待测对象模块进行发送的第二直接激励，以及基于第二直接激励获取第一待测对象模块在执行第二直接激励后得到的第二响应信号；基于第二响应信号获取目标监控信息，并且基于目标监控信息和参考监控信息，获取错误场景是否复现的监控结果，其中，目标监控信息包括第二响应信号中的至少一个信号特征。

本公开的实施例的芯片验证方法通过对验证环境的改良和优化，对错误场景的激励进行可控收集以及复刻，重新获取固定激励，可以从根本上排除了随机稳定性对错误场景复现的影响，实现了对错误场景的稳定复现。本公开一些实施例的芯片验证方法还可以实现在错误能稳定复现的前提下，确保在对设计进行修改后，能够提供固定可靠的序列来验证修改的正确性，从而避免设计缺陷被遗漏。

本公开至少一实施例还提供了一种与上述芯片验证方法对应的芯片验证装置。

在本公开中的各种激励是指用于激活或驱动系统的输入，例如当施加一个激励，它会对应呈现一种响应，即激励可视为系统的输入，而响应可视为系统的输出。例如，本公开的实施例的激励的类型可以是事务包或者接口信号，具体可见下文。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

在本公开一些实施例中，序列(Sequence)用来产生事务包(item)，并借助序列发生器(Sequencer)这种组件传递给激励器(Driver)，激励器会将事务包(item)转化为接口信号输出。

下面结合附图对本公开的实施例及其示例进行详细说明。

图2-图4为本公开一些实施例提供的一种芯片验证装置的示意图。

例如，如图2所示，本公开至少一实施例提供的芯片验证装置包括待测设计100(Design Under Test，DUT)、第一验证模块200、目标文件获取模块300、直接激励获取模块400和错误复现监控模块500。例如，本公开的实施例的芯片验证装置是一种用于芯片验证的UVM验证平台。

例如，DUT 100是一种可测性设计，也可称待测对象，其可以是一个验证工程师主要负责验证的对象。例如，如果需要对缓存进行验证，则DUT 100包括该被验证的缓存。例如DUT 100通过相应的设计代码实现。当然，此仅仅为示例性的，并不为本公开的实施例的限制，其可以视芯片验证需求而定的任意的电路模块，这里不做穷举和赘述。

在一些示例中，DUT 100可以选择下文的第一待测对象模块，也可以选择下文的第二待测对象模块。示例地，第二待测对象模块可以是基于第一待测对象模块进行修正的待测模块。例如，本公开的实施例还可在错误场景能够稳定复现的前提下，确保在对设计进行修改后(例如修改得到的设计可记为第二待测对象模块)，可以提供固定可靠的序列来验证设计修改的正确性，从而避免设计缺陷被遗漏。例如，下文一些实施例将结合本公开实施例中的附图，主要以验证平台上进行仿真验证的当前的待测设计是第一待测对象模块为例进行说明。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

例如，第一验证模块200被配置为在第一模式下向第一待测对象模块提供第一随机激励且在第一待测对象模块执行第一随机激励后得到第一响应信号，以验证第一待测对象模块。

例如，第一模式是指随机生成激励的模式。本公开的实施例的第一模式是指关于本公开的芯片验证装置的激励的两种发送途径的模式的其中一种，且在第一模式下是发送随机序列并且产生受约束的随机激励，可以用于正常仿真与回归，如第一随机激励。例如，第一随机激励可以为一个数据包信号(如随机激励事务包)。

在一些示例中，第一验证模块200包括序列发生单元210，如图3和图4所示，序列发生单元210可以产生一系列数据，比如产生高抽象级的数据包，高抽象级可以是事务级建模。例如，序列发生单元210包括随机序列发生器211，随机序列发生器211被配置为在第一模式向第一待测对象模块提供第一随机激励。例如，本公开的实施例的随机序列发生器211可以生成随机序列并且通过TLM端口将产生的随机激励事务包传递给激励器以产生接口信号输出给DUT。本公开的实施例的TLM是指事务级建模(Transaction Level Modeling)，它是UVM验证方法学定义的一种机制，用于事务包在UVM验证平台中各组件之间的传递。

在一些示例中，第一验证模块200还包括期望值确定单元220和验证结果确定单元230，如图3所示，期望值确定单元220被配置为基于第一随机激励确定第一待测对象模块的第一期望值，验证结果确定单元230被配置为对比第一响应信号和第一期望值，确定第一待测对象模块的验证结果。

例如，如图3和图4所示，期望值确定单元220包括发起方监视器221和参考模型(未图示)。例如，如图3和图4所示，验证结果确定单元230包括计分板231和响应方监视器232。发起方监视器221获取第一随机激励并发送给参考模型，例如，参考模型是在待测对象模块(DUT)实现之前，早期阶段构思的理想模型，在抽象的高级别上模拟DUT(如第一待测对象模块)，参考模型根据第一激励产生对应的预期的响应信号并发送给计分板231。响应方监视器232用于收集响应信号(如第一响应信号)并将响应信号发送给计分板231。计分板231用于检查DUT产生的传输是否正确，计分板231接收的实际数据(如第一响应信号)来自DUT，计分板231接收的期望数据(如第一期望值)来自参考模型，由此计分板231比较第一响应信号和第一期望值，确定DUT的验证结果。在一些示例中，DUT(如第一待测对象模块)的验证结果包括发生错误场景或者未发生错误场景。

在一些示例中，第一验证模块200还包括发起方驱动器240，如图3和图4所示，发起方驱动器240接收序列发生单元210产生的一系列数据。例如，序列发生单元210提供给发起方驱动器240的是激励事务包，并且DUT(如第一待测对象模块)接收的是接口信号，因此，发起方驱动器240可以将来自序列发生单元210的事务包转换成接口(Interface)信号送入DUT。由于发起方驱动器240能实现事务包到接口信号的转换，所以平台还需要一个模块实现与发起方驱动器行为相对的功能，即将接口信号转换成事务包，例如，发起方监视器221可以执行这样的功能。发起方监视器221用于收集发起方驱动器240与DUT之间的接口信号，并将其转换成事务包。

在一些示例中，目标文件获取模块300被配置为基于第一随机激励获取目标文件310。例如，目标文件310用于获取固定的激励，例如，目标文件310用于获取固定的直接序列(Direct Sequence)，示例地，可见下文中目标文件310用于生成下文的第二直接激励。

例如，目标文件310可以是基于一种用户自定义文件(User Defined File)得到，用户自定义文件具有自定义的字符串格式(即预设文本格式)。

在一些示例中，直接激励获取模块400被配置为基于目标文件310获取用于在第二模式向第一待测对象模块进行发送的第二直接激励，使得基于第二直接激励获取第一待测对象模块在执行第二直接激励后得到的第二响应信号。

例如，第二模式是指生成直接激励的模式。本公开的实施例的第二模式是指关于本公开的芯片验证装置的激励的两种发送途径的模式的其中一种，且在第二模式下是发送直接序列并且产生直接激励(如第二直接激励)，用于仿真出现错误后的场景复现和调试。

例如，第二直接激励可以为一个数据包信号，如激励事务包。例如，本公开的实施例的直接序列是指按照可控方式产生或发出，其还可以包括一些确定的数据包，示例地，直接序列是一种固定序列，其顺序确定且可以包括一些确定的数据包内容。

本公开的实施例的芯片验证装置是一种能够精准复现特定错误场景的仿真验证平台，其通过对验证环境的改良和优化，对错误场景激励进行可控下载以及复刻，重新获取固定激励，以维持新老验证环境中错误场景对应激励的一致性，从而可以从根本上排除随机稳定性对错误场景复现的影响，实现对错误场景的稳定复现，能够提升错误场景复现的效率和准确度。

在一些示例中，在进行用户自定义文件的格式制定时，可以将激励的类型分为两大类，并且分别根据各自的关键特征，可以确认需要精准控制的成员构成，并进行字符串格式的设定。例如，这两类分别是基于数据流以及基于控制流。对于基于数据流，比如是存储类等大数据量传输的激励。对于基于控制流，比如是微控制单元等指令集、控制集的激励。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

在一些示例中，错误复现监控模块500用于对响应信号的监视，比如监视当前的响应信号(待检查的场景)和之前的响应信号(需复现的错误场景)是否保持一致。例如，本公开的实施例的错误复现监控模块500被配置为：获取参考监控信息以及目标监控信息，并且基于目标监控信息和参考监控信息，获取错误场景是否复现的监控结果。参考监控信息包括第一模式下的错误场景对应的第一响应信号中的至少一个信号特征，第一响应信号与错误场景相应的第一随机激励相对应。目标监控信息被配置为基于第二响应信号进行获取且目标监控信息包括第二响应信号中的至少一个信号特征。参考监控信息用作后续判断错误场景是否复现的参考。

本公开的实施例的各个响应信号是指DUT在执行相应的激励后得到的激励结果，其可以参照一些主流的验证平台的技术方案，这里不再赘述。

例如，本公开的实施例的各个响应信号(例如第一响应信号或第二响应信号)中的信号特征是指响应信号中的成员信息，响应信号的成员信息是指响应信号的各个构成区域的具体信息，例如响应信号的成员信息不仅是指成员构成，还包括成员的顺序以及成员设置值，需要说明的是，本公开的实施例的响应信号的成员信息的具体信息可以视具体的响应信号而定，只要能体现出响应信号的特征以使得其能够被唯一确定即可，这里不再穷举和赘述。

在一些示例中，在第一待测对象模块的验证结果包括发生错误场景，即仿真出现错误，此时需要开启错误复现监控模块500的错误复现监控功能，并且获取参考监控信息。

在一些示例中，错误复现监控模块500在第一待测对象模块向验证环境返回响应信号的过程中，可以通过响应方监视器232的TLM端口，实时收集并记录响应信号(如响应事务包)的成员信息，并且可以根据记录的成员信息进行检查。当满足错误场景复现的相关条件，则触发错误场景已复现的提示信息，当不满足错误场景复现的相关条件，则判定复现失败。由此，本公开的实施例通过错误复现监控模块对错误场景是否被复现进行监管，从而实现对错误场景的稳定复现。

在一些示例中，上述的满足错误场景复现的相关条件是指目标监控信息中的信号特征和参考监控信息中的信号特征相匹配，例如目标监控信息和参考监控信息中的每个相应特征均完全相同。示例地，若期望的字段信息(即参考监控信息)是特征b，但从DUT返回过来的字段信息(即目标监控信息)是特征a，由此可知监控结果是两者不匹配，则表明场景未复现成功。当然，此仅仅为示例性的，并不为本公开的实施例的限制，只要目标监控信息和参考监控信息中的各个信号特征对上即可，这里不再赘述。

本公开的实施例的芯片验证装置可以通过在现有的验证平台架构对验证组件进行扩展和增补，在保留原有受约束的随机激励产生机制的基础上，增加了可精准控制对应场景激励产生的通用机制，弥补了在错误发生时无法高效复现的功能缺失，能够解决现有验证平台存在随机稳定性的问题，从而能够实现对错误场景的稳定复现，提升错误场景复现的效率和准确度，并且还能够避免设计缺陷被遗漏。

在一些示例中，目标文件获取模块300是一种激励下载器(Dumper)320，激励下载器320被配置为：响应于使用与错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器211以向第一待测对象模块发送第三激励，并且基于第三激励获取对应的成员信息，以及获取用于目标文件的预设文本格式，并且基于预设文本格式和成员信息(即基于第三激励获取的成员信息)获取目标文件。例如，初始用例种子是指初始种子号。

本公开的实施例的芯片验证装置通过使用与错误场景对应的随机激励相同的初始种子号，可以重新生成一一对应的固定发送序列，从而从根本上排除了随机稳定性对错误场景复现的影响，实现了对错误场景的稳定复现。

在一些示例中，在第一随机激励对应的初始用例种子和第三激励对应采用的初始用例种子相同，并且第一随机激励所对应的DUT和第三激励所对应的DUT是相同的，由此，本公开的实施例可以在提供第一随机激励进行验证的状况和在提供第三激励进行验证的状况相同的前提下，通过固定初始种子号进行激励等方面的复刻或复现，因此，本公开的实施例的第三激励也可理解是一种相对于与错误场景对应的第一随机激励的固定的激励(即通过复制对应的第一随机激励得到第三激励)。

在一些示例中，对于本公开的实施例中的第三激励向DUT提供的过程中的响应信号(比如可记为第四响应信号)的输出和计分板的工作等操作均可参照上述有关第一激励和第一验证模块的部分，为了本文的清楚和简洁，此处不再赘述。

在一个示例中，对于上述示例中的基于第三激励获取对应的成员信息，其可以是：通过发起方监视器221的TLM端口实时收集并记录第三激励中的成员信息，并且对记录的成员信息进行整理，按照用户自定义的字符串格式，产生一个本地文本文件(即上述的目标文件)，供直接激励获取模块400加载使用。例如，该本地文本文件可以是一个临时的本地文本文件，当然，此仅仅为示例性的，并不为本公开的实施例的限制，例如其还可以作为一个备份而一直保留的文件，其可以根据实际需求进行自由调整，这里不做限制和赘述。

例如，如图4所示，本公开的实施例通过发起方监视器221监视DUT的输入信号，获取向DUT发送的第三激励，这里的DUT的输入信号是基于第三激励转换成的接口信号(例如该输入信号是发起方驱动器240与DUT之间的接口信号)，也即基于事务包形式的第三激励转换成对应的接口信号并输出给DUT。

在一些示例中，上述的从发起方监视器221接收的第三激励的类型是事务包或者接口信号(如下文图5示例中的虚拟接口信号，该虚拟接口信号是一种软件层面定义的接口信号)。需要说明的是，关于本公开的实施例涉及的诸如软件层面和硬件层面的接口信号的定义和一些相关细节，其是本领域技术人员所公知的，为了本文的清楚和简洁，在此不做赘述。

例如，在图4的示例中，从发起方监视器221接收的第三激励的类型是事务包，即在图4的示例中，激励下载器320从发起方监视器221接收到的第三激励是激励事务包，这也依赖于发起方监视器221能够将接口信号转换成事务包。

又例如，在图5的示例中，发起方监视器221向激励下载器320传递对应接口信号，即激励下载器320从发起方监视器221接收的第三激励的类型是虚拟接口信号，具体可见下文。

本公开上述实施例可以通过在激励下载器中构建目标文件的下载功能，以及在直接激励获取模块中构建目标文件的加载和解析功能时，均是基于对事务包的成员组成这个维度进行精准控制，通过激励序列载体来高效复现错误场景。

图5为本公开另一些实施例提供的一种芯片验证装置的示意图。

例如，在图5的示例中，从发起方监视器221接收的第三激励的类型是接口信号。例如，如图5所述，本公开的实施例通过在激励下载器320中使用发起方监视器221传递的接口信号(虚拟接口信号Vif)生成目标文件，在发起方驱动器240中增加了用于文本解析的接口信号生成器710，用以对目标文件310进行加载和解析并转为接口信号，同时使用模式切换器600与随机激励事务包(即来自于随机序列发生器211的激励，如上文的第一激励或第三激励等)产生的接口信号形成切换，例如，来自于随机序列发生器211的激励通过接口信号生成器720产生对应的接口信号。例如，接口信号生成器720对应第一模式，接口信号生成器710对应第二模式。对于图5示例中有关错误复现操作流程等其他方面的内容可以参照本文其他地方，这里不再赘述。

本公开的实施例还能从接口信号的维度考虑，可以进行更细粒度的控制，例如，尤其对于控制流的场景，激励往往由琐碎的单根信号组成，这样对接口信号进行直接控制会更便利、更精准。

在一些示例中，直接激励获取模块400被配置为：读取目标文件310，并且解析目标文件310以获取对应的成员信息；基于解析得到的成员信息，生成第二直接激励；响应于第二模式，向第一待测对象模块发送第二直接激励，第二直接激励是对应于第三激励的固定激励序列。

例如，本公开的实施例中的各个激励的成员信息是指激励的各个构成区域的具体信息，例如激励的成员信息不仅是指成员构成，还包括成员的顺序以及成员设置值，本公开的实施例的激励的成员信息的具体情况可以视具体响应信号而定，只要能体现出激励的特征以使得其能够被唯一确定即可，这里不再穷举和赘述。

在本公开的一些实施例中，基于所述第一随机激励获取目标文件是指：基于错误场景对应的第一随机激励来选择对应初始用例种子，以此重新运行随机序列发生器产生激励，再通过使用激励下载器获取第三激励且获取对应成员信息，用以得到目标文件。这也意味着，本公开的实施例的第三激励关联于第一随机激励，目标文件关联于第三激励。

如上所述，本公开的实施例的第三激励理解成一种相对于与错误场景对应的第一随机激励的固定的激励(使用相同的初始用例种子实现)，并且第二直接激励是对应于第三激励的固定激励序列，由此，本公开的实施例可以实现维持新老验证环境中错误场景对应激励的一致性。

在一些示例中，对于数据流的类型，激励的成员构成包括以下的至少一种：数据传输大小、数据传输地址、传输的数据。在另一些示例中，对于控制流的类型，激励的成员构成包括以下的至少一种：指令类型、指令地址、控制域。当然，此仅仅为示例性的，并不为本公开的实施例的限制，其可以根据实际需求而定，这里不再穷举和赘述。

图6为本公开一些实施例提供的用户自定义文件的格式示例图。

例如，如图6所示，在用户自定义文件(可简称自定义文件)中，记录有成员构成的定义、成员构成的布置、各个成员构成对应的设置值、各个激励序列对应的设置值等。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

在一些示例中，成员构成对应的设置值可以从发起方驱动器240实时获取，并且按照预定顺序依次排列，生成字符串写入自定义文件，从而获取目标文件310。在一些示例中，用户自定义文件具有的预设文本格式是通过人工自定义，例如，其在芯片验证装置搭建时进行预设而确定。在一些示例中，在读取目标文件310并且解析目标文件310以获取对应的成员信息的时候，也同样按照预设文本格式进行解析。

在一个示例中，直接激励获取模块400是一种直接序列发生器410，如图4所示，直接序列发生器410对激励下载器320生成的读取目标文件310进行读取和解析，并对解析完的成员信息进行整理，并与环境内建事务包进行映射，产生对应的固定激励序列，并通过序列发生单元210的TLM端口将激励事务包传递给发起方驱动器240，从而实现向DUT发送与错误场景对应的直接激励，如第二直接激励。

例如，如图4和图5所示，本公开的实施例的芯片验证装置还包括模式切换器600，模式切换器600是一种多路复用器(Mux)，模式切换器600用于第一模式和第二模式的选择和切换，即模式切换器600用于对UVM验证平台的序列的两种发送途径进行模式选择和切换，从而可以选择向DUT发送的激励。在一个示例中，第一模式可以作为验证装置的“默认”模式，第二模式可以作为验证装置的“调试”模式。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

在一些示例中，本公开的实施例的芯片验证装置中的目标文件获取模块300、直接激励获取模块400、错误复现监控模块500和模式切换器600均可在UVM验证方法学下实现，可以在芯片验证装置的搭建初期加入，也可在已有芯片验证装置上进行更新，最终可以将其设计为标准组件，在其他验证环境中进行灵活复用，可适配性极强。例如，在本公开一些实施例中，在仿真或回归运行前将这些核心组件准备好，并集成到UVM验证装置中，由此确保能够及时记录错误场景下的关键信息，其相较于在仿真出现错误后再增加这些核心组件的方式，更好地掌握了抓取错误场景的时机。

需要注意的是，在本公开的实施例中，该芯片验证装置可以包括更多或更少的模块，并且各个模块之间的连接关系不受限制，可以根据实际需求而定。各个模块的具体构成方式不受限制。

以上实施例中的各个模块可被分别配置为执行特定功能的软件、硬件、固件或上述项的任意组合。例如，这些模块可对应于专用的集成电路，也可对应于纯粹的软件代码，还可对应于软件与硬件相结合的模块。

需要说明的是，尽管以上在描述芯片验证装置时将其划分为用于分别执行相应处理的模块，然而，本领域技术人员清楚的是，各模块执行的处理也可以在验证平台不进行任何具体模块划分或者各模块之间并无明确划界的情况下执行。

图7为本公开一些实施例提供的芯片验证装置的组件构建和集成的示意图，例如，在图7的示例中，涉及构建和集成的组件主要包括上述的目标文件获取模块300、直接激励获取模块400、错误复现监控模块500和模式切换器600。

例如，本公开一些实施例提供的芯片验证装置被配置为通过以下方式获取得到：

基于激励事务包的成员信息获取预设文本格式；

根据预设文本格式构建目标文件的下载功能，并且集成到验证环境中，与发起方监视器进行连接，以构建和配置目标文件获取模块；

根据预设文本格式构建目标文件的加载和解析功能，构建解析的成员信息与环境内建事务包的映射的功能，以及构建直接激励的启动功能，以构建和配置直接激励获取模块；

构建随机激励和所述直接激励的切换功能，以构建和配置模式切换器；

集成空的功能到验证环境，与响应方监视器进行连接，以构建和配置错误复现监控模块；

根据错误场景下的响应事务包，构建错误复现被触发和/或报告的功能，以构建和配置错误复现监控模块。

本公开上述实施例通过构建的芯片验证装置，解决了现有通用技术中因UVM验证环境固有的随机稳定性问题导致的无法高效稳定复现错误场景的问题；通过对原有验证环境进行改良和优化，对错误场景激励事务包进行可控下载和解析，复刻其成员构成及共通特性，重新生成一一对应的固定发送序列，从而从根本上排除了随机稳定性对错误复现的影响，实现了对错误场景的稳定复现。

例如，如图7所示，本公开一些实施例提供的芯片验证装置的组件构建和集成的流程包括以下步骤或过程：

第一，分析激励事务包的成员组成，制定好用户自定义文件的文本格式。

第二，根据预设文本格式构建目标文件的下载功能(如在目标文件获取模块中构建目标文件的下载功能)，并且集成到验证环境中(如是将目标文件获取模块300和/或其对应的功能集成到验证环境中)，与发起方监视器进行TLM端口连接。例如，如图7所示，该第二步骤对应的组件为目标文件获取模块300(如激励下载器)。

第三，根据预设文本格式构建目标文件的加载和解析功能，然后构建解析值(即解析完的成员信息)和环境内建事务包的映射的功能，以及构建直接激励(如第二直接激励)的启动功能。例如，如图7所示该第三步骤对应的组件是直接激励获取模块400，示例地，可以在直接激励获取模块400中构建目标文件的加载和解析功能，完成解析值和环境内建事务包的映射的功能。

第四，构建随机激励和直接激励的切换功能。例如，该第四步骤对应的组件是模式切换器600。

第五，集成空的功能到验证环境，与响应方监视器进行TLM端口连接。例如，该第五步骤对应的组件是错误复现监控模块500。示例地，第五步骤是指在错误复现监控模块500中先构建空的功能，仅与响应方监视器进行TLM端口连接。

第六，当仿真出现错误之后，根据错误场景下的响应事务包，构建错误复现被触发和报告功能。例如，该第六步骤对应的组件是错误复现监控模块500。

本公开上述实施例开发和搭建了一种用于高效准确复现错误场景的UVM验证环境组件，可作为标准验证组件供通用环境复用，通用性好。

本公开上述实施例提供的平台组件搭建的方法仅仅为示例性的，并不为本公开的实施例的限制，只要最终搭建好的芯片验证装置最终能够实现相应的功能和效果即可，该平台搭建方法的具体实现技术效果可以参考本公开上述实施例中提供的芯片验证装置，这里不再赘述。

图8为本公开一些实施例提供的一种芯片验证方法的流程图。本公开的实施例的芯片验证方法的示例的详细说明见下文。

例如，如图8所示，本公开至少一实施例提供的芯片验证方法包括步骤S1至步骤S4。

步骤S1、获取第一待测对象模块。

例如，在步骤S1中，第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行第一随机激励后得到第一响应信号，用以验证第一待测对象模块。

步骤S2、获取参考监控信息。

例如，在步骤S2中，参考监控信息包括第一模式下的错误场景对应的第一响应信号中的至少一个信号特征。

步骤S3、基于第一随机激励获取目标文件，并且基于目标文件获取用于在第二模式向第一待测对象模块进行发送的第二直接激励，以及基于第二直接激励获取第一待测对象模块在执行第二直接激励后得到的第二响应信号。

步骤S4、基于第二响应信号获取目标监控信息，并且基于目标监控信息和参考监控信息，获取错误场景是否复现的监控结果。

例如，在步骤S4中，目标监控信息包括第二响应信号中的至少一个信号特征。

本公开的实施例的芯片验证方法通过对验证环境的改良和优化，对错误场景的激励进行可控收集以及复刻，重新获取固定激励，可以从根本上排除了随机稳定性对错误场景复现的影响，实现了对错误场景的稳定复现。本公开一些实施例的芯片验证方法还可以实现在错误能稳定复现的前提下，确保在对设计进行修改后，能够提供固定可靠的序列来验证修改的正确性，从而避免设计缺陷被遗漏。

图9为本公开一些实施例提供的基于第一随机激励获取目标文件的执行过程的流程图。

例如，如图9所示，基于第一随机激励获取目标文件的一个示例至少包括步骤S311～S314。

步骤S311、使用与错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向第一待测对象模块发送第三激励。

步骤S312、基于第三激励获取对应的成员信息。

步骤S313、获取用于目标文件的预设文本格式。

步骤S314、基于预设文本格式和成员信息获取目标文件。

例如，本公开的实施例中的步骤S311～S314可通过命令行传递参数进行功能开启控制。

本公开的实施例的芯片验证方法通过使用与错误场景对应的随机激励相同的初始种子号，可以重新生成一一对应的固定发送序列，从而从根本上排除了随机稳定性对错误场景复现的影响，实现了对错误场景的稳定复现。

图10为图9中的步骤S312的一种执行过程的流程图。例如，如图10所示，步骤S312的一个示例至少包括步骤S3121～步骤S3123。

步骤S3121、通过发起方监视器监视第一待测对象模块的输入信号，获取向第一待测对象模块提供的第三激励。例如，在步骤S3121中，该第一待测对象模块的输入信号是基于第三激励转换成的接口信号(例如该输入信号是发起方驱动器240与DUT之间的接口信号)，也即基于事务包形式的第三激励转换成接口信号并直接输出给DUT。

步骤S3122、从发起方监视器接收第三激励。

例如，在步骤S3122中，从发起方监视器接收的第三激励的类型可以是事务包或者接口信号。

例如，在步骤S3122中，目标文件获取模块300(如激励下载器320)从发起方监视器211接收第三激励，如图4和图5所示。

例如，在图4的示例中，激励下载器320从发起方监视器211接收到的第三激励是激励事务包形式。

步骤S3123、基于接收到的第三激励获取对应的成员信息。

例如，在步骤S3121和步骤S3122中，通过发起方监视器监视第一待测对象模块的输入信号来获取第三激励，是指发起方监视器(如发起方监视器221)将来自于第一待测对象模块的接口信号转换成对应的事务包形式的激励，如第一激励，并且发起方监视器获取到的第三激励和随机序列发生器向第一待测对象模块提供的第三激励一致。

本公开上述实施例可以通过在激励下载器中构建目标文件的下载功能，以及在直接激励获取模块中构建目标文件的加载和解析功能时，均是基于对事务包的成员组成这个维度进行精准控制，通过激励序列载体来高效复现错误场景。另外，本公开的实施例还能从接口信号的维度考虑，从而可以进行更细粒度的控制，例如，尤其对于控制流的场景，激励往往由琐碎的单根信号组成，这样对接口信号进行直接控制会更便利、更精准。

图11为本公开一些实施例提供的基于目标文件获取第二直接激励的执行过程的流程图。

例如，如图11所示，基于目标文件获取用于在第二模式向第一待测对象模块进行发送的第二直接激励的一个示例至少包括步骤S321～S323。

步骤S321、读取目标文件，并且解析目标文件以获取对应的成员信息。

步骤S322、基于解析得到的成员信息，生成第二直接激励。

例如，在步骤S322中，第二直接激励包括对应于第三激励的固定激励序列。

步骤S323、响应于第二模式，向第一待测对象模块发送第二直接激励。

例如，本公开的实施例中的步骤S321～S323可通过命令行传递参数进行功能开启控制。

本公开的实施例中的芯片验证方法在正常仿真或回归中，可以按照第一模式(如“默认模式”)进行执行，即运行受约束的随机序列发生器211来对DUT进行验证，其过程包括以下：通过运行随机序列发生器211以在第一模式下向第一待测对象模块发送第一随机激励，并且获取第一待测对象模块在执行第一随机激励后得到的第一响应信号；基于第一随机激励确定第一待测对象模块的第一期望值；对比第一响应信号和第一期望值，确定第一待测对象模块的验证结果，其中，第一待测对象模块的验证结果包括发生错误场景或者未发生错误场景。

在一些示例中，本公开的芯片验证方法的步骤S2还可包括以下步骤或过程：响应于第一待测对象模块的验证结果包括发生错误场景，启动错误复现监控功能，获取参考监控信息。

本公开的实施例的芯片验证方法，结合了随机用例，既能确保激励测试集的全面性和有效性，又能在仿真出现错误时，拥有一套稳定高效的复现机制支持调试，防止因验证环境修改等导致的设计缺陷无法复现。

在一些示例中，本公开的芯片验证方法还包括以下步骤或过程：在获取目标文件310之后，从第一模式切换至第二模式，使得基于目标文件310获取第二直接激励。例如，对于该步骤或过程，可通过命令行传递参数进行模式选择控制。

在一些示例中，对于上述步骤S4中的基于第二响应信号获取目标监控信息，其可以包括以下步骤或过程：基于第二响应信号获取对应的成员信息，以获取目标监控信息。例如，目标监控信息可以包括第二响应信号获取对应的所有的成员信息，也可以包括部分的成员信息，其可根据实际情况进行自由调整，这里不做穷举和赘述。

在一些示例中，对于上述步骤S4中的基于目标监控信息和参考监控信息获取错误场景是否复现的监控结果，其可以包括以下步骤或过程：响应于目标监控信息中的信号特征和参考监控信息中的信号特征相匹配，监控结果包括错误场景复现；以及响应于目标监控信息中的信号特征和参考监控信息中的信号特征不匹配，监控结果包括错误场景未复现。例如，对于该步骤或过程，可通过命令行传递参数进行功能开启控制。

在一些示例中，目标监控信息中的信号特征和参考监控信息中的信号特征相匹配可以是指两者的相应特征完全相同。当然，此仅仅为示例性的，并不为本公开的实施例的限制，只要目标监控信息和参考监控信息中的各个信号特征能够对上即可，这里不再赘述。

在本公开一些实施例中，发生错误场景的对应的第一随机激励的数量不作限制，其可以是一个，也可以是多个。本公开的实施例的错误场景是否复现的监控可以设置为在所有的第一随机激励跑完之后再执行，本公开的实施例在仿真正在执行的过程当中不做复现的检查和监控。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

在一些示例中，本公开的实施例的错误复现监控模块实时监控错误场景复现的触发时刻，一旦击中即给出场景已复现的报告，提示错误场景复现成功；若场景复现失败，则需要进行复核工作。例如，复核的工作内容包括以下的至少一种：复核目标文件的格式制定的合理性、对随机激励和直接激励出现差异的时刻进行重点分析以找出影响因素。当然，此仅仅为示例性的，并不为本公开的实施例的限制，其可以视实际情况而定，此处不在穷举和赘述。

在一些示例中，在复核之后若发现是对成员信息的分析出现遗漏，造成与实际错误场景的激励偏差等，则可以根据调整后的格式，对激励下载器310和直接激励获取模块400中的目标文件生成和解析功能进行更新，并切换模式切换器600为第一模式(“默认”模式)，使用出错的初始用例种子(如与错误场景对应的第一随机激励相同的初始用例种子)，重新运行受约束的随机序列发生器211，生成更新后的目标文件310供第二模式(“调试”模式)运行使用。

在一些示例中，本公开的实施例的芯片验证方法还可以包括以下步骤或过程：在启动错误复现监控功能以及获取参考监控信息之后，确定错误复现监控功能是否正常。例如，上述示例中的确定错误复现监控功能是否正常的过程是在步骤S3之前。

在一些示例中，上述中的确定错误复现监控功能是否正常可以包括以下步骤或过程：通过使用与错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向第一待测对象模块发送第四激励，用以确定错误复现监控功能是否正常。

例如，若错误复现监控功能正常，则能够触发错误场景已复现的提示信息并打印报告；若错误复现监控功能不正常，即错误复现监控模块500组件无法按照期望工作，则需要对功能组件进行复核和更新，例如可以对触发条件进行复核以确保监管机制的正常运行。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

本公开的实施例中有关第四激励和第一随机激励的关联可以参照上文中的第三随机激励和第一随机激励之间的关联，这里不再赘述。由此，本公开的实施例能够保证错误复现监控功能的正常，从而有利于错误场景的稳定复现的实现，有利于提升错误场景复现的效率和准确度。

图12为本公开又一些实施例提供的一种芯片验证方法的流程图。

例如，如图12所示，本公开一些实施例提供的芯片验证方法还可包括以下步骤：

步骤S5、响应于监控结果包括错误场景复现，获取第二待测对象模块。例如，在步骤S5中，第二待测对象模块是基于第一待测对象模块进行修正的待测模块。

步骤S6、基于目标文件获取用于向第二待测对象模块进行发送的第二直接激励，并且基于第二直接激励获取第二待测对象模块在执行第二直接激励后得到的第三响应信号。

步骤S7、基于第二直接激励确定第二待测对象模块的第二期望值。

步骤S8、对比第三响应信号和第二期望值，确定第二待测对象模块的验证结果。

本公开的实施例可以实现在错误能够稳定复现的前提下，确保在对待测设计进行修改后，可以提供固定可靠的激励序列来验证修改的设计的正确性，从而避免设计缺陷被遗漏。

例如，步骤S8可由计分板来实现，由此可以验证修改的设计是否正确。

例如，本公开的实施例针对第二待测对象模块(即对应修改后的设计)，可以通过监测计分板是否报错并结合关注错误复现监控模块是否出现错误复现来确定修改的设计是否正确。示例地，针对第二待测对象模块时，计分板没有报错并且也没有错误复现，这说明修改的设计正确。这样本公开的实施例能够更加精准地确定设计是否准确，很好地避免设计缺陷被遗漏。当然，此仅仅为示例性的，并不为本公开的实施例的限制。

图13为本公开另一些实施例提供的芯片验证方法的流程图。

例如，如图13所示，本公开一些实施例的芯片验证方法包括步骤T1至步骤T13。

步骤T1、模式切换器的模式选择设置为“默认”模式，运行随机序列发生器，由此进行正常仿真和回归。

例如，在步骤T1中通过运行随机序列发生器产生的激励可以是上文所述的第一随机激励。

步骤T2、判断验证用例是否出错，即判断仿真是否出现错误。若是，即仿真出现错误，继续执行步骤T3；若否，则仿真未出现错误，继续执行T1步骤的仿真。

步骤T3、开启错误复现监控模块的功能。

步骤T4、在错误复现监控模块中构建错误场景触发和报告功能。

例如，在步骤T4中，在分析错误场景下响应信号的关键特征之后，根据从响应方监视器获取的响应事务包来构建错误场景的触发条件以及触发后的报告打印功能。

步骤T5、使用出错的用例种子，重新运行随机序列发生器。

例如，在步骤T5中通过运行随机序列发生器产生的激励可以是上文的第四激励。

步骤T6、判断错误复现监控模块是否能够正常工作，即判断错误复现监控模块是否触发错误复现报告；若是，继续执行步骤T7；若否，则转至步骤T4。

步骤T7、开启激励下载器的功能。

步骤T8、使用出错的用例种子，重新运行随机序列发生器，下载目标文件。

例如，在步骤T8中通过运行随机序列发生器产生的激励可以是上文的第三激励。

例如，在步骤T8中，使用出错的用例种子并且重新运行的随机序列发生器之后，激励下载器根据从发起方监视器获取的激励事务包自动生成目标文件并且下载到本地。

步骤T9、模式切换器的模式选择设置为“调试”模式，即运行直接序列发生器，直接序列发生器自动加载并解析目标文件，从而发起与错误场景一一对应的固定序列。

例如，步骤T9中产生的固定序列可以是上文的第二直接激励。

步骤T10、错误复现监控模块实时监控错误复现的触发时刻，判断是否触发错误复现报告；若是，提供错误场景已复现的报告，提示错误复现成功，从而结束；若否，即错误场景复现失败，则继续执行步骤T11。

步骤T11、分析原目标文件的格式制定的合理性。

步骤T12、调整激励下载器和直接序列发生器这两个组件的功能，如调整它们的目标文件生成和解析功能。

步骤T13、模式切换器的模式选择设置为“默认”模式，使用出错的用例种子，重新运行随机序列发生器，生成更新后的目标文件供“调试”模式运行使用，直至复现成功。

本公开上述实施例的芯片验证方法解决了现有通用技术中因UVM验证环境固有的随机稳定性问题导致的无法高效稳定复现错误场景的问题，本公开通过对原有验证环境进行改良和优化，对错误场景激励事务包进行可控下载和解析，复刻其成员构成及共通特性，重新生成一一对应的固定发送序列，从而从根本上排除了随机稳定性对错误复现的影响，实现了对错误场景的稳定复现。

本公开上述实施例的芯片验证方法，结合了随机用例，既能确保激励测试集的全面性和有效性，又能在仿真出现错误时，拥有一套稳定高效的复现机制支持调试，防止因验证环境修改等导致的设计缺陷无法复现；并且在错误能够稳定复现的前提下，可以确保在对设计进行修改后，可以提供固定可靠的序列来验证修改的正确性，从而避免设计缺陷被遗漏。

本公开其他一些实施例的芯片验证方法的具体实施技术效果可以参考本公开上述实施例中提供的芯片验证装置，这里不再赘述。

图14为本公开至少一实施例提供的一种电子设备的结构示意图。

例如，如图14所示，本公开至少一实施例提供的电子设备2000包括处理器2100和存储器2200，其中，存储器2200上存储有计算机程序，计算机程序被处理器2100执行时，实现本公开至少一些实施例的芯片验证方法。

本公开实施例中的电子设备可以包括但不限于诸如笔记本电脑、平板电脑等等的移动终端以及诸如台式计算机等等的固定终端。图14示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

例如，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处处理器执行时，执行本公开实施例的芯片验证方法。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

需要说明的是，本公开的实施例中，电子设备2000的具体功能和技术效果可以参考上文中关于芯片验证方法的描述，此处不再赘述。

有以下几点需要说明：

(1)本公开实施例附图只涉及到本公开实施例涉及到的结构，其他结构可参考通常设计。

(2)在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合以得到新的实施例。

以上，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，本公开的保护范围应以权利要求的保护范围为准。

Claims (19)

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

获取第一待测对象模块，其中，所述第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行所述第一随机激励后得到第一响应信号，用以验证所述第一待测对象模块；

获取参考监控信息，其中，所述参考监控信息包括所述第一模式下的错误场景对应的第一响应信号中的至少一个信号特征；

基于所述第一随机激励获取目标文件，并且基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，以及基于所述第二直接激励获取所述第一待测对象模块在执行所述第二直接激励后得到的第二响应信号；

基于所述第二响应信号获取目标监控信息，并且基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，其中，所述目标监控信息包括所述第二响应信号中的至少一个信号特征。

2.如权利要求1所述的芯片验证方法，其中，基于所述第一随机激励获取目标文件，包括：

使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向所述第一待测对象模块发送第三激励；

基于所述第三激励获取对应的成员信息；

获取用于所述目标文件的预设文本格式；

基于所述预设文本格式和所述成员信息获取所述目标文件。

3.如权利要求2所述的芯片验证方法，其中，基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，包括：

读取所述目标文件，并且解析所述目标文件以获取对应的成员信息；

基于解析得到的成员信息，生成所述第二直接激励，其中，所述第二直接激励包括对应于所述第三激励的固定激励序列；

响应于所述第二模式，向所述第一待测对象模块发送所述第二直接激励。

4.如权利要求1所述的芯片验证方法，其中，所述第一待测对象模块被配置为在第一模式下接收第一随机激励且在执行所述第一随机激励后得到第一响应信号，用以验证所述第一待测对象模块，包括：

通过运行随机序列发生器以在所述第一模式下向所述第一待测对象模块发送所述第一随机激励，并且获取所述第一待测对象模块在执行所述第一随机激励后得到的第一响应信号；

基于所述第一随机激励确定所述第一待测对象模块的第一期望值；

对比所述第一响应信号和所述第一期望值，确定所述第一待测对象模块的验证结果，其中，所述第一待测对象模块的验证结果包括发生错误场景或者未发生错误场景。

5.如权利要求4所述的芯片验证方法，其中，获取参考监控信息，包括：

响应于所述第一待测对象模块的验证结果包括所述发生错误场景，启动错误复现监控功能，获取所述参考监控信息。

6.如权利要求1所述的芯片验证方法，还包括：

在获取所述目标文件之后，从所述第一模式切换至所述第二模式，使得基于所述目标文件获取所述第二直接激励。

7.如权利要求1所述的芯片验证方法，其中，基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，包括：

响应于所述目标监控信息中的信号特征和所述参考监控信息中的信号特征相匹配，所述监控结果包括错误场景复现；以及

响应于所述目标监控信息中的信号特征和所述参考监控信息中的信号特征不匹配，所述监控结果包括错误场景未复现。

8.如权利要求7所述的芯片验证方法，还包括：

响应于所述监控结果包括所述错误场景复现，获取第二待测对象模块，其中，所述第二待测对象模块是基于所述第一待测对象模块进行修正的待测模块；

基于所述目标文件获取用于向所述第二待测对象模块进行发送的所述第二直接激励，并且基于所述第二直接激励获取所述第二待测对象模块在执行所述第二直接激励后得到的第三响应信号；

基于所述第二直接激励确定所述第二待测对象模块的第二期望值；

对比所述第三响应信号和所述第二期望值，确定所述第二待测对象模块的验证结果。

9.如权利要求5所述的芯片验证方法，还包括：

在启动所述错误复现监控功能以及获取所述参考监控信息之后，确定所述错误复现监控功能是否正常。

10.如权利要求9所述的芯片验证方法，其中，确定所述错误复现监控功能是否正常，包括：

通过使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行所述随机序列发生器以向所述第一待测对象模块发送第四激励，用以确定所述错误复现监控功能是否正常。

11.如权利要求2所述的芯片验证方法，其中，基于所述第三激励获取对应的成员信息，包括：

通过发起方监视器监视所述第一待测对象模块的输入信号，获取向所述第一待测对象模块提供的第三激励，其中，所述输入信号是基于所述第三激励转换成的接口信号；

从所述发起方监视器接收所述第三激励；其中，从所述发起方监视器接收的所述第三激励的类型是事务包或者接口信号；

基于接收到的所述第三激励获取对应的成员信息。

12.一种芯片验证装置，包括：

第一待测对象模块；

第一验证模块，被配置为在第一模式下向所述第一待测对象模块提供第一随机激励且在所述第一待测对象模块执行所述第一随机激励后得到第一响应信号，以验证所述第一待测对象模块；

目标文件获取模块，被配置为基于所述第一随机激励获取目标文件；

直接激励获取模块，被配置为基于所述目标文件获取用于在第二模式向所述第一待测对象模块进行发送的第二直接激励，使得基于所述第二直接激励获取所述第一待测对象模块在执行所述第二直接激励后得到的第二响应信号；

错误复现监控模块，被配置为：获取参考监控信息以及目标监控信息，并且基于所述目标监控信息和所述参考监控信息，获取错误场景是否复现的监控结果，其中，所述参考监控信息包括所述第一模式下的错误场景对应的第一响应信号中的至少一个信号特征，所述目标监控信息被配置为基于所述第二响应信号获取且所述目标监控信息包括所述第二响应信号中的至少一个信号特征。

13.如权利要求12所述的芯片验证装置，其中，所述第一验证模块包括：

随机序列发生器，被配置为在所述第一模式向所述第一待测对象模块提供所述第一随机激励；

期望值确定单元，被配置为基于所述第一随机激励确定所述第一待测对象模块的第一期望值；

验证结果确定单元，被配置为对比所述第一响应信号和所述第一期望值，确定所述第一待测对象模块的验证结果，其中，所述第一待测对象模块的验证结果包括发生错误场景或者未发生错误场景。

14.如权利要求12所述的芯片验证装置，其中，所述目标文件获取模块被配置为：

响应于使用与所述错误场景对应的第一随机激励相同的初始用例种子，重新运行随机序列发生器以向所述第一待测对象模块发送第三激励，并基于所述第三激励获取对应的成员信息；

获取用于所述目标文件的预设文本格式，并基于所述预设文本格式和所述成员信息获取所述目标文件。

15.如权利要求12所述的芯片验证装置，其中，所述直接激励获取模块被配置为：

读取所述目标文件，并且解析所述目标文件以获取对应的成员信息；

基于解析得到的成员信息，生成所述第二直接激励，其中，所述第二直接激励包括对应于所述第三激励的固定激励序列；

响应于所述第二模式，向所述第一待测对象模块发送所述第二直接激励。

16.如权利要求12所述的芯片验证装置，还包括模式切换器，其中，所述模式切换器被配置为选择所述第一模式或所述第二模式。

17.如权利要求12所述的芯片验证装置，其中，所述芯片验证装置被配置为通过以下方式获取：

基于激励事务包的成员信息获取预设文本格式；

根据所述预设文本格式构建所述目标文件的下载功能，并且集成到验证环境中，与发起方监视器进行连接；

根据所述预设文本格式构建所述目标文件的加载和解析功能，构建解析的成员信息与环境内建事务包的映射的功能，以及构建直接激励的启动功能；

构建随机激励和所述直接激励的切换功能；

集成空的功能到所述验证环境，与响应方监视器进行连接；

根据错误场景下的响应事务包，构建错误复现被触发和/或报告的功能。

18.一种电子设备，包括：

处理器和存储器，

其中，所述存储器上存储有计算机程序，所述计算机程序被所述处理器执行时，实现权利要求1至11中任一项所述的芯片验证方法。

19.一种计算机可读存储介质，其中，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时，实现权利要求1至11中任一项所述的芯片验证方法。