一种基于UVM的通用数据检查方法、计算机设备及存储介质

技术领域

本发明设计集成电路测试技术领域，尤其涉及种基于UVM的通用数据检查方法。

背景技术

芯片验证作为整个芯片开发周期中至关重要的一个环节，是决定DUT所对应RTL代码正确、可靠与否的重要关键点。然而，随着芯片规模的增大，DUT验证分为模块级验证、子系统级验证以及SOC级验证并独立开发相应的检查器(Checker)，这就导致当低层级的检查器向更高层级移植时往往需要进行大量的修改才能够被重复利用，无形中增加了芯片的研发周期。

具体的讲，目前模块级的Checker常采用的数据检查方式为，在DUT输出一定的数据量后，通过后门直接访问保存在队列或者动态数组中的理想值输出以完成与DUT输出的数据对比，但由于后门访问操作是不可见的，这就导致理想值数据在传入Checker的过程中，不能被更高层级的验证环境中直接获取，以至于需要对更高层级的验证环境(如子系统级或SOC级)的Checker进行相应修改。在上述过程中，一旦不同的验证人员对同一功能点的理解出现偏差，相应功能模块在不同层级验证的完备性将会受到影响，如部分DUT漏洞无法被及时发现，导致研发周期延长。

发明内容

为了保证模块级的数据检查能够被更高层级的数据检查复用，并避免发生数据漏检，在本发明的第一方面，提出了一种基于UVM的通用数据检查方法，所述方法包括：控制IP核以transaction数据包的形式向待测硬件设计和参考模型发送激励；控制检查器以transaction数据包的形式分别获取所述待测硬件设计和所述参考模型的输出，并执行指令收集以及数据处理完成标志收集；由所述检查器根据所述指令收集与所述数据处理完成标志收集的情况进行数据检查。

在一个或多个实施例中，所述控制IP核以transaction数据包的形式向待测硬件设计和参考模型发送激励，包括：控制IP核以transaction数据包的形式向待测硬件设计和参考模型先发送指令后发送验证数据。

在一个或多个实施例中，所述方法还包括在执行执行指令收集以及数据处理完成标志收集之前，根据所述transaction数据包中的目的地址判断所述transaction数据包中的数据属性，其中，所述数据属性包括指令数据和输出验证数据。

在一个或多个实施例中，本发明的方法还包括：响应于所述transaction数据包中的数据为指令数据，执行执行指令收集；响应于所述transaction数据包中的数据为理想值输出验证数据，执行数据处理完成标志收集。

在一个或多个实施例中，所述响应于所述transaction数据包中的数据为指令数据，执行执行指令收集，包括：根据所述transaction数据包中预设的指令标记判断指令属性，所述指令属性包括正常指令和注错指令；分别统计所述transaction数据包中正常指令和所述注错指令的类型和数量，并分别存储到不同的第一队列或第一联合数组中；

根据所述第一队列或第一联合联组中保存的为正常指令或注错指令的类型和数量，标记所述第一队列或第一联合联组的属性为正常或注错。

在一个或多个实施例中，所述响应于所述transaction数据包中的数据为理想值输出验证数据，执行数据处理完成标志收集，包括：判断所述transaction数据包中的实际值输出验证数据中是否存在数据处理完成标志；响应于所述实际值输出验证数据中存在数据处理完成标志，判断所述输出验证数据为正常输出或为注错输出；分别将所述正常输出和所述注错输出的实际值输出验证数据的类型和数量保存至不同的第二队列或第二联合联组中；根据所述第二队列或第二联合联组中保存的实际值输出验证数据的类型标记所述第二队列或第二联合联组的属性为正常或注错。

在一个或多个实施例中，所述由所述检查器根据所述执行指令收集与所述数据处理完成标志收集的情况进行数据检查，包括：响应于所述实际值输出验证数据中不存在数据处理完成标志，分别判断具有相同属性的所述第一队列或第一联合数组中指令的类型和数量是否与所述第二队列或第二联合数组中实际值输出验证数据的类型和数量是否一致；若一致，则依次从所述第二队列或第二联合联组中获取实际值输出验证数据，并与所述参考模型输出的理想值输出验证数据进行比较；若实际值输出验证数与理想值输出验证数据不一致，则打印指令收集的相关信息；其中，所述方法还包括：为指令类型配置检查优先级；根据所述检查优先级对所述第一队列或第一联合联组中保存的指令的类型和数量进行排序；依次根据所述第一队列或第一联合联组中保存的指令的类型和数量从所述第二队列或第二联合联组中获取相应的实际值输出验证数据，并与所述参考模型输出的对应理想值输出验证数据进行比较。

在一个或多个实施例中，本发明的方法还包括：若实际值验证数据与理想值输出验证数据一致，则从所述第二队列或第二联合联组中删除相应的实际值输出验证数据以及从第一队列或第一联合数组中删除相应的指令。

在本发明的第二方面，提出了一种计算机设备，包括：至少一个处理器；以及存储器，所述存储器中存储有可执行的计算机程序，所述计算机程序被所述至少一个处理器执行时用于实现如上述任意一方法实施例中所述的一种基于UVM的通用数据检查方法的步骤。

在本发明的第三方面，提出了一种可读存储介质，包括：可执行的计算机程序，所述计算机程序被执行器执行时用于实现如上述任意一方法实施例中所述的一种基于UVM的通用数据检查方法的步骤。

本发明的有益效果包括：本发明技术方案适用于经过transaction与DUT进行交互的验证环境，首先，DUT的输入数据和输出数据均从transaction中获取，从而避免了跨越验证环境组件传输理想值的情况，使得模块级的Checker的数据流动在子系统层级依然可见，即更高层级的验证环境可以直接复用模块级验证环境中的Checker，因此采用本发明的技术方案，可有效提升不同层级验证工作的开展效率。其次，本发明的技术方案采用了指令收集、数据处理完成标志收集、数据检查三部分结合的方式，即在数据检查之前确保正常或异常处理过程已经完成，同时在确保正常处理与异常处理的次数符合指令需求时才会开启数据检查，该特性使得正常场景和异常场景能够自动识别并进行相应的数据检查，有利于项目后期多种复杂场景的构建以及混合场景下DUT的数据检查，方便后期需求变更时Checker的复用以及检查功能的修改。最后，本发明技术方案中，指令收集、数据处理完成标志收集、数据检查这三个部分在每一轮获取transaction的循环内进行，并且三个部分彼此之前存在先后顺序，因此，对于每一笔传输而言，在获取到指令之后，立即判断相应的数据处理完成标志是否产生，如产生则立即进行数据检查。该方法有效避免了等待全部数据均处理完成之后才进行数据检查的严重滞后性，避免了滞后检查无法应对乱序处理的地址重合问题。

附图说明

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

图1为本发明实施例的一种基于UVM的通用数据检查方法的工作流程图；

图2为本发明实施例的模块级验证的系统结构示意图；

图3为本发明实施例的模块级验证的系统结构示意图；

图4为本发明实施例的各数据通道的时序对比示意图；

图5为本发明实施例的完整的工作流程图；

图6为本发明的一种计算机设备的结构示意图；

图7为本发明的一种可读存储介质的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明实施例进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

为了使得模块级的数据验证方法能够被复用到更高层级的数据验证中，如子系统级或SOC级，本发明提出了一种基于UVM的通用数据检查方法，通过统一由transaction数据包的形式获得激励和输出验证数据，使得激励和输出验证数据对所有层级可见、能够被获取从而被复用到更高层级的数据检查中，并且通过指令收集以及数据处理完成标志收集步骤保证了数据不会被漏检。以下将结合附图对本发明方法进行更加详细的阐述。

请参见图1，其示出了本发明实施例的一种基于UVM的通用数据检查方法的工作流程，包括：步骤S1、控制IP核以transaction数据包的形式向待测硬件设计和参考模型发送激励；步骤S2、控制检查器以transaction数据包的形式分别获取待测硬件设计和参考模型的输出，并执行指令收集以及数据处理完成标志收集；步骤S3、由检查器根据指令收集与数据处理完成标志收集的情况进行数据检查。

具体的，通用验证方法学(Universal Verification Methodology,UVM)是一个以SystemVerilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境，因此如何能够保证能接口获得想要的数据尤为关键。传统的模块级验证由采用后门访问的方式获取理想值数据，导致理想值数据在传入检查器(Checker)的过程中，不能被更高层级的验证环境中直接获取，从而不得不进行相应修改，而采用transaction数据包的数据传输方式时，数据传输对各层级均为可见且容易获取，但由于其需要指令与数据分开传输，为此本发明还通过指令收集以及数据处理完成标志收集步骤来避免数据漏检的发生。

请参见图2，其示出了本发明实施例的模块级验证的系统结构，其中，待测硬件设计(DUT)，可以与一个多个虚拟IP核(VIP)连接，并使得每个虚拟IP核均以transaction数据包的形式向待测硬件设计和参考模型发送激励；检查器(Checker)也需要以transaction数据包的形式获取待测硬件设计和参考模型的输出值，而后进行数据对比。更具体的，对于模块级验证而言，DUT的输入与输出端口均与VIP相连，即DUT数据激励由VIP发出，经过数据转换后的数据输出由VIP接收。ref model在验证环境中为可选组件(可集成在检查器中)，主要用于对VIP发出的数据进行相应的处理，以得到DUT输出的理想值。另外，虽然ref model的输入与DUT的输入来源相同，但参考模型(ref model)通过transaction数据包的形式获取DUT输入，经过解析和计算产生理想输出值。而Checker从ref model获取理想输出值，从DUT的输出端获取输出值，比较二者值是否一致，以判断DUT是否正常工作。

请参见图3，其示出了本发明实施例的SOC级验证的系统结构，其中，对于子系统级的验证，验证人员更关注DUT在子系统环境中与在其它组件的交互关系。此时，DUT的激励不再由VIP发起，而是由子系统中真实的组件(Device1)产生。而VIP承担监测器的角色，即从Device1到DUT的输入方向获取transaction，从DUT到Device2的输出方向获取transaction，ref model依旧可选，负责从VIP获取DUT的输入后，将DUT理想输出传给Checker，Checker负责检查DUT的实际输出与理想输出是否一致。

在上述两种数据验证的系统结构中，各模块之间传出均采用transaction数据包的形式进行传输，是个各个模块之间的数据传递对各层级均为可见，从而保证了本发明方法的可复用性。

在进一步的实施例中，控制IP核以transaction数据包的形式向待测硬件设计和参考模型发送激励，包括：控制IP核以transaction数据包的形式向待测硬件设计和参考模型先发送指令后发送验证数据。具体的，先发送指令的目的在于让待测硬件设计和参考模型做好接受数据并处理的准备，数据紧接着指令到达后待测硬件设计和参考模型即可立即做出反应。需指出的是，在一个transaction数据包中可以携带一个或多个指令，或者携带一个多个数据，本发明对此不作限制。

更具体的，请参见图4，其示出了本发明实施例的各数据通道的时序对比，其中，指令通道的指令1、指令2及指令3均要早于数据通道中输入数据2、输入数据1及输入数据3，在参考模型或待测硬件设计获得指令和数据后才会得到输出数据2、输出数据1和输出数据3。图4中的“其它”是指封装在transaction中的数据也并非全部都是激励，其还可以是指定业务长度和业务速率等相关数据，其作用包括序列(Sequence)可以根据业务长度来生成指定大小的以太网帧，驱动器(Driver)在加载时可以根据业务速率这个参数来延时加载，但是这两个参数在driver加载给DUT时将被剥离。

在进一步的实施例中，本发明的方法还包括在执行执行指令收集以及数据处理完成标志收集之前，根据transaction数据包中的目的地址判断transaction数据包中的数据属性，其中，数据属性包括指令数据和输出验证数据；响应于transaction数据包中的数据为指令数据，执行执行指令收集；响应于transaction数据包中的数据为理想值输出验证数据，执行数据处理完成标志收集。具体的，由于指令和数据需要由待测硬件设计的不同区域接收，因而相应transaction数据包中的目的地址存在差异，本发明方法事先将会在系统中确定数据处理区域的地址范围和指令处理区域的地址范围，从而可以根据transaction数据包中的目的地址区分该数据包中传输的数据属性。

在一些实施例中，参考模型有时并不会对输入验证数据进行处理，而是会直接传递给检查器并由检查器执行对特定输入验证数据的处理，因此，本发明的数据属性除了指令数据和输出验证数据之外还包括输入验证数据。

在进一步的实施例中，本发明的指令收集，包括：根据transaction数据包中预设的指令标记判断指令属性，指令属性包括正常指令和注错指令；分别统计transaction数据包中正常指令和注错指令的类型和数量，并分别存储到不同的第一队列或第一联合数组中；根据第一队列或第一联合联组中保存的为正常指令或注错指令的类型和数量，标记第一队列或第一联合联组的属性为正常或注错。

具体的，为了避免以transaction数据包形式传输数据时数据漏检的发生，本发明方法中设计了多种标记用来统计指令和数据的数量或执行状态。在本实施例中，本发明分别为正常指令和注错指令设计了不同的标记用于区分二者，检查器即可根据指令数据中的标记来判断指令的属性并将其分别存储到不同的队列或联合数组中，从而分类统计不同种类指令的数量，从而避免数据漏检的发生。

在进一步的实施例中，本发明的数据处理完成标志收集，包括：判断transaction数据包中的实际值输出验证数据中是否存在数据处理完成标志；响应于实际值输出验证数据中存在数据处理完成标志，判断输出验证数据为正常输出或为注错输出；分别将正常输出和注错输出的实际值输出验证数据的类型和数量保存至不同的第二队列或第二联合联组中；根据第二队列或第二联合联组中保存的实际值输出验证数据的类型标记第二队列或第二联合联组的属性为正常或注错。

具体的，本发明在根据相应指令处理数据时，将在待测硬件设计处理的最后一个数据后的输出验证数据中增加数据处理完成标志，若输出验证数据中未出现数据处理完成标志，则表示相应的指令还在执行中。本发明分别为正常输出和注错输出设计了不同的标记用于区分二者，该标记首先将随着输入验证数据(即为激励)传入待测硬件设计或参考模型，而后会出现在相应的输出验证数据中。检查器即可根据输出验证数据中的标记来判断指令的属性并将其分别存储到不同的队列或联合数组中，从而能够实现并发的对正常数据与注错数据进行数据对比检查，从而提升数据检查的效率，并且将数据完成标志的数量与上一个transaction数据包中的各种指令的数量进行对比，若相同才执行后续的数据对比检查，从而避免数据漏检的发生。

对于数据的对比检查，在一个可选的实施例中，先获取全部的待测硬件设计的输出验证数据(实际值)，根据其是正常输出还是注错输出将其分别存储在不同的队列或联合数组中，而后统一与参考模型输出的输出验证数据(理想值)进行对比；若一致，则从队列或联合数组中删除，并保存对比结果至非易失存储中。在一个优选的实施例中，也可以每当参考模型和待测硬件设计输出一个输出验证数据时即进行对比，若一致，则从队列或联合数组中删除相应数据，并保存对比结果至非易失存储中。

在进一步的实施例中，由检查器根据执行指令收集与数据处理完成标志收集的情况进行数据检查，包括：响应于实际值输出验证数据中不存在数据处理完成标志，分别判断具有相同属性的第一队列或第一联合数组中指令的类型和数量是否与第二队列或第二联合数组中实际值输出验证数据的类型和数量是否一致；若一致，则依次从第二队列或第二联合联组中获取实际值输出验证数据，并与参考模型输出的理想值输出验证数据进行比较；若实际值输出验证数与理想值输出验证数据不一致，则打印指令收集的相关信息；其中，上述方法还包括：为指令类型配置检查优先级；根据检查优先级对第一队列或第一联合联组中保存的指令的类型和数量进行排序；依次根据第一队列或第一联合联组中保存的指令的类型和数量从第二队列或第二联合联组中获取相应的实际值输出验证数据，并与参考模型输出的对应理想值输出验证数据进行比较。通过为指令类型配置检查优先级能够实现灵活的控制对一个或多个transaction数据包中相应指令的输出数据的数据检查顺序，对容易出错的设计部分优先进行数据检查，从而提升测试效率。

在进一步的实施例中，本发明的方法还包括：若实际值验证数据与理想值输出验证数据一致，则从第二队列或第二联合联组中删除相应的实际值输出验证数据以及从第一队列或第一联合数组中删除相应的指令。

请参见图5，其示出了本发明实施例的完整的工作流程，其中，在指令收集部分流程中的提取错误指令标志与提取正常指令模式(也由相应标志确定)的目的即为统计正常指令和注错指令的种类和数量；在数据处理完成标志收集部分流程中，本发明的数据处理完成标志加进一步包括正常场景完成标志和异常场景完成标志，其分别用于标志正常数据处理和注错数据处理的完成情况；其中，判断当前传输是否为数据处理完成标志是指判断当前传输的transaction数据包是否具有数据处理完成标志，若具有表示已完成按照某一指令的数据处理工作，则记录相应输出验证数据中的标记种类和数量；若不具有数据处理完成标志，则跳转到数据检查部分流程，并进一步判断当前传输情况下，处理完成标志的个数是否与收集到的指令个数相等，其判断逻辑为，若按照某一指令的数据处理工作未完成，则处理完成标志的个数与收集到的指令个数一定不相等，则执行打印统计指令相关信息步骤，若相同则表示可以某一指令的数据处理工作已经完成，则可以进一步执行后续的数据对比检查工作；在数据检查部分流程中，在同时存在正常输出或注错输出时，本实施例将优先对注错输出进行对比。需说明的是，图5中的“异常”即指的是“注错”，并非是系统运行中出现的异常。

如上述各实施例，本发明技术方案适用于经过transaction与DUT进行交互的验证环境，首先，DUT的输入数据和输出数据均从transaction中获取，从而避免了跨越验证环境组件传输理想值的情况，使得模块级的Checker的数据流动在子系统层级依然可见，即更高层级的验证环境可以直接复用模块级验证环境中的Checker，因此采用本发明的技术方案，可有效提升不同层级验证工作的开展效率。其次，本发明的技术方案采用了指令收集、数据处理完成标志收集、数据检查三部分结合的方式，即在数据检查之前确保正常或异常处理过程已经完成，同时在确保正常处理与异常处理的次数符合指令需求时才会开启数据检查，该特性使得正常场景和异常场景能够自动识别并进行相应的数据检查，有利于项目后期多种复杂场景的构建以及混合场景下DUT的数据检查，方便后期需求变更时Checker的复用以及检查功能的修改。最后，本发明技术方案中，指令收集、数据处理完成标志收集、数据检查这三个部分在每一轮获取transaction的循环内进行，并且三个部分彼此之前存在先后顺序，因此，对于每一笔传输而言，在获取到指令之后，立即判断相应的数据处理完成标志是否产生，如产生则立即进行数据检查。该方法有效避免了等待全部数据均处理完成之后才进行数据检查的严重滞后性，避免了滞后检查无法应对乱序处理的地址重合问题。

在本发明的第二方面，提出了一种计算机设备，请参见图6，包括：至少一个处理器31；以及存储器30，存储器30中存储有可执行的计算机程序301，计算机程序301被至少一个处理器31执行时用于实现如上述任意一方法实施例中的的一种基于UVM的通用数据检查方法的步骤。

具体的，存储器30可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器30还可包括高速随机存取存储器，以及非易失性存储器，例如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器30至少用于存储以下计算机程序301，其中，该计算机程序被处理器31加载并执行之后，能够实现前述实施例提出的一种基于UVM的通用数据检查方法的相关步骤。另外，存储器30所存储的资源还可以包括操作系统302和数据303等，存储方式可以是短暂存储或者永久存储。其中，操作系统302可以包括Windows、Unix、Linux等。数据303可以包括但不限于执行结果对应的数据等。

处理器31可以包括一个或多个处理核心，例如4核心处理器、8核心处理器等。处理器31可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器31也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器31可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器31还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，本发明的计算机设备还可包括有显示屏32、输入输出接口33、通信接口34、电源35以及通信总线36。本领域技术人员可以理解，图6中示出的结构并不构成对本发明的计算机设备的限定，其可以包括比图示更多或更少的组件。

在本发明的第三方面，提出了一种可读存储介质40，请参见图7，包括：可执行的计算机程序，计算机程序被执行器执行时用于实现如上述任意一方法实施例中的的一种基于UVM的通用数据检查方法的步骤。

具体的，若上述方法实施例中的一种基于UVM的通用数据检查方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上是本发明公开的示例性实施例，但是应当注意，在不背离权利要求限定的本发明实施例公开的范围的前提下，可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外，尽管本发明实施例公开的元素可以以个体形式描述或要求，但除非明确限制为单数，也可以理解为多个。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。

上述本发明实施例公开实施例序号仅仅为了描述，不代表实施例的优劣。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子；在本发明实施例的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，并存在如上的本发明实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。