CN117312176A - 一种基于uvm的芯片验证测试方法、系统及电子设备 - Google Patents

Abstract

本发明公开了一种基于UVM的芯片验证测试方法、系统及电子设备，属于芯片验证技术领域，包括，步骤S1，在UVM验证环境中添加存储器模型，生成UVM_MEM模型；步骤S2，重载UVM_MEM模型中的uvm_reg_frontdoor和uvm_reg_backdoor类；以及，步骤S3，重写重载的类中的body函数，形成自建body函数。本发明通过在UVM验证环境中的UVM_MEM模型的基础上封装一层公共的表项配置方式，使得在对不同芯片的存储器进行验证测试时，面对不同规格和类型的表项都能适配，减少模块级验证人员需维护的配置表项代码量，提高了验证测试的效率，提高了复用性及可移植性。

Description

一种基于UVM的芯片验证测试方法、系统及电子设备

技术领域

本发明涉及芯片验证技术领域，且特别是有关于一种基于UVM的芯片验证测试方法、系统及电子设备。

背景技术

随着集成电子电路技术的发展，电子设备趋于体积小型化、功能多样化，电子设备上往往集成有多个芯片，电子设备通过集成的这些芯片实现各种功能。为了确保各芯片中寄存器的正常运行，需要对芯片进行验证。例如，在交换机芯片中，经常会涉及到二层数据交互和三层路由等功能，实现这些功能的协议处理都需要借由对相应的表项进行查找匹配来完成，特别的对于某些协议处理十分复杂的交换机芯片，所需要进行查找匹配的表项的数量也是非常庞大的。在对交换机芯片进行验证时，需要配置不同协议表项上的数据，以达到验证交换机芯片功能正确性的目的。验证中，芯片内部表项是通过寄存器间接访问的，配置一张表项的数据就需要配置若干个寄存器，配置寄存器次数会随着表项容量而增加。

当面对较多不同规格的表项时，以往的方法中，配置表项的工作一般交由各个模块级（即Block Test）验证人员来完成，但这样的方式会导致各个模块级验证人员各自维护自己负责的配置表项代码，但由于各个模块级验证人员之间缺少可公共维护的配置表项代码，彼此间的代码无法复用，因而无形中增加了模块级验证人员的工作量，维护性差。另外，常规的配置表项方式的可移植性不高，难以适配不同的验证项目，仅能实现基于一个项目配置一套配置表项代码的逻辑。因此，需要一种方法解决代码复用及可移植性的问题。

发明内容

本发明旨在提供一种基于UVM的芯片验证测试方法、系统及电子设备，提高在对芯片的存储器进行验证测试时的复用性及可移植性。

为达到上述目的，本发明技术方案是：

一种基于UVM的芯片验证测试方法，包括，步骤S1，在UVM验证环境中添加存储器模型，生成UVM_MEM模型；步骤S2，重载UVM_MEM模型中的uvm_reg_frontdoor和uvm_reg_backdoor类；以及，步骤S3，重写uvm_reg_frontdoor和uvm_reg_backdoor类中的body函数，形成自建body函数。

上述基于UVM的芯片验证测试方法中，所述步骤S3中重写后的body函数的具体执行步骤包括，步骤S31，识别表项类型；步骤S32，依据识别出的表项类型，获取表项规格、表项配置方式、以及表项组成结构需要配置数据的次数；步骤S33，依据表项规格、表项配置方式、以及表项组成结构需要配置数据的次数，结合验证对象的设计方案，配置表项激励组成并下发；以及步骤S34，进行错误检查，并上报检测结果。

上述基于UVM的芯片验证测试方法中，所述表项类型包括，线性表、TCAM、以及Hash表。

上述基于UVM的芯片验证测试方法中，所述表项规格包括，表深、以及表宽。

上述基于UVM的芯片验证测试方法中，所述表项配置方式包括，寄存器间接访问、以及可寻址访问。

一种基于UVM的芯片验证测试系统，使用上述的基于UVM的芯片验证测试方法。

一种基于UVM的芯片验证测试系统，使用上述的基于UVM的芯片验证测试方法。

有益效果，本发明提出的一种基于UVM的芯片验证测试方法、系统及电子设备，通过在UVM验证环境中的UVM_MEM模型的基础上封装一层公共的表项配置方式，使得在对不同芯片的存储器进行验证测试时，面对不同规格和类型的表项都能适配，减少模块级验证人员需维护的配置表项代码量，提高了验证测试的效率，提高了复用性及可移植性。

为让发明的上述特征和优点能更明显易懂，下文特举实施例，并配合所附图式作详细说明如下。

附图说明

图1为本发明基于UVM_MEM模型封装表项访问的步骤流程图。

图2为本发明重写后的body函数的执行步骤流程图。

图3本发明中基于UVM_MEM封装表项访问的结构图。

具体实施方式

为使本发明实施例的目的和技术方案更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了解决目前芯片的寄存器验证中表项配置方式存在的维护性差和移植性不足的问题，本发明将利用UVM存储器模型对表项访问流程进行封装，整合存在差异和特殊性的配置表项模式，如：寄存器间接访问的表项、不同表项规格配置寄存器个数不同、特殊访问的表项存在特定配置顺序要求等情况，将表项配置流程进行统一实现，使得代码维护性得到大大提升。最终封装好的存储器模型能完成所有不同规格类型的表项配置，减少验证人员工作量的同时也大大提升了代码在不同项目之间的复用性。

本发明的技术方案由UVM验证环境、DUT_TABLE表项、UVM_MEM模型、用户自定义配置表项类四个部分组成。其中，UVM验证环境（即，Universal Verification Methodology，简称UVM）是一个以SystemVerilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境，是本发明进行验证的基础框架。DUT_TABLE表项为待测设计表项，即本发明中需要进行配置数据的表项。UVM_MEM模型是对应DUT_TABLE表项的模型，其中包含最基本的访问方式。用户自定义配置表项类是本发明的核心，是基于UVM_MEM模型中的uvm_reg_frontdoor和uvm_reg_backdoor重载的类，重写write、write_mem等方式完成不同表项激励组成和发送。

本发明是通过在UVM_MEM模型中已有架构的基础上，再封装一层适用于不同规格和类型的验证对象的表项配置方式来实现的，以下对本发明的具体流程进行说明，图1为本发明基于UVM_MEM模型封装表项访问的步骤流程图。如图1所示，本发明的具体步骤如下。

步骤S1，在UVM验证环境中添加存储器模型，生成UVM_MEM模型。具体来说，是在UVM验证环境的ralf文件中添加memory类型结构，memory类型结构中包含基本表项规格（即表项深度、表项宽度、以及访问方式等信息），生成UVM组织形式的UVM_MEM模型。由此，验证环境就得到了基础的访问架构，后续操作都是基于UVM_MEM模型进行重载的。

步骤S2，重载UVM_MEM模型中的uvm_reg_frontdoor和uvm_reg_backdoor类。uvm_reg_frontdoor和uvm_reg_backdoor这两个类分别对应着前门配置表项和后门配置表项流程，两者通过调用存储器访问时uvm_path_e参数进行区别，重载这两个类主要目的是为了在以下步骤中编写公共配置表项方法，然后在UVM验证环境中通过set_frontdoor和set_backdoor将重载好的uvm_reg_frontdoor和uvm_reg_backdoor类绑定在生成的存储器模型上，以实现按照自定义方式调用存储器模型访问进行表项配置。

步骤S3，重写uvm_reg_frontdoor和uvm_reg_backdoor类中的body函数，形成自建body函数，形成公共表项配置。在所述步骤S2的前门配置表项和后门配置表项类的基础上，进一步重写uvm_reg_frontdoor和uvm_reg_backdoor类中的body函数。重写body函数的目的是使激励的产生（uvm_sequence）调用自建的body函数，重写body函数达到了按照新的方式进行激励发送的目的。这里具体激励为配置表项相关流程，接下来将具体展开body函数中需要完成的流程。

在UVM验证环境中，body函数是一个抽象类，它定义了一些虚函数，这些虚函数可以被子类继承和实现。body函数的主要作用是管理UVM验证环境中的各种对象，具体包括UVM组件（Component）、UVM配置（Configuration）、UVM工厂（Factory）、以及UVM消息（Message）。

图2为本发明重写后的body函数的执行步骤流程图。如图2所示，所述步骤S3中的重写后的body函数的具体执行步骤如下。

步骤S31，识别表项类型。表项类型包括线性表、TCAM、Hash表等，表项特性包括表项规格（表项规格包括表深、表宽等）、表项配置方式（表项配置方式包括寄存器间接访问、可寻址访问等）等。不同的表项类型会有不同的表项特性，因此通过对各个表项类型的表项特性进行归纳，就可以根据识别出的表项规格，确定不同表项规格对应的表项特性。

步骤S32，依据识别出的表项类型，获取表项规格、表项配置方式、以及表项组成结构需要配置数据的次数。例如，以识别出的表项类型为TCAM的情况下，则表项组成结构需要配置两次数据，表项配置方式是寄存器间接访问，进而由TCAM对应的表项规格中获取需要配置寄存器个数和从uvm_reg_map上配置哪个寄存器。对于其他类型表项，该步骤的流程也是一样的。

步骤S33，依据表项规格、表项配置方式、以及表项组成结构需要配置数据的次数，结合验证对象的设计方案，配置表项激励组成并下发。此处还是以表项类型为TCAM的情况进行举例说明，通过上述步骤S32，已获取了TCAM表项类型的参数，最后按照设计方案组成表项激励，下发到DUT_TABLE表项。

步骤S34，进行错误检查，并上报检测结果。即在整个表项访问封装流程中添加错误检查，例如，进行配置表项超时检查、进行配置地址越界检测、检测是否存在配置寄存器不存在情况等，如果存在错误能在仿真时被发现。

对于上述步骤S31来说，例如对于表项类型为TCAM的情况，其表项配置方式为寄存器间接访问，而表项类型不属于TCAM的表项，其表项配置方式为可寻址访问，在调用寄存器模型的write方式进行配置表项时，其中输入的参数extension主要用途为用户自定义传参，extension类型为uvm_object，在此可以继承于这个类添加针对不表特性的参数以达到识别出用哪种方式进行激励发送。

对于本发明的使用方式，也就是如何在步骤S31中将不同点归纳的细节实现，这里应用到的是存储器模型内部函数获取需要配置寄存器个数和从uvm_reg_map上配置哪个寄存器。这样的好处是能将通过ralf文件的模型中添加memory类型结构时将表深和表宽参数化，且使用者不再关心配置表项涉及那些寄存器访问，从而达到复用的目的。除了获取配置表项必要参数外，配置寄存器顺序和次数也需要参数化，例如通过识别此时配置表项类型为TCAM，需要配置TCAM_DATA和TCAM_MASK两列数据，则调用两次配置流程；而表项类型非TCAM时，仅需要配置一列数据则调用一次配置流程，那编写者将配置流程公共部分提取，通过传入参数值确认调用次数，这样的参数化的好处是仅判断外层调用次数，而不会影响调用逻辑从而达到复用的目的。

对于上述步骤S32，以识别出的表项类型为TCAM的情况为例，则表项组成结构需要配置两次数据，表项配置方式是寄存器间接访问，在访问之前需要获取必要的表项特性信息，如表深、表宽、配置哪个寄存器、以及并且配置寄存器的顺序和次数为何。

图3本发明中基于UVM_MEM封装表项访问的结构图。本发明中基于UVM存储器模型的芯片验证测试方法已经上文中各步骤进行了说明，将基于UVM_MEM模型封装表项访问的步骤及重写后的body函数的具体执行步骤相结合，可得出本发明的概略结构图如图3所示。如图3所示，在UVM验证环境中建立了UVM_MEM模型后，用户自定义配置表项类。用户自定义配置表项类由识别表项规格和类型、配置方式检查、激励组成和发送、访问超检查组成四部分组成，先识别表项规格和类型，再配置方式检查、后进行激励组成和发送，最后下发到DUT_TABLE表项，并通过访问超时检查，依据检查结果再进行激励组成和发送连接。

下面结合具体实例分别介绍使用UVM_MEM封装方式配置表项和常规方式配置表项不同点。以下为本发明进行常规表项配置的一具体实施例的示意伪代码。

table_select(输入表名，由表名获取表项宽度和深度);

if(此时访问表项操作为配置数据)begin

if(此时访问表项类型是TCAM类型)begin

准备配置数据;

通过寄存器间接访问，需要显示指明使用哪一个寄存器，如配置TBL_ACCESS_METHOD_CTRL_1才能成功配置tcam，将使用如下命令：

handle.TBL_ACCESS_METHOD_CTRL_1.write(配置寄存器参数);

end

等待配置完成;

end

将上述伪代码封装成函数后，进行调用将会传入如下参数：寄存器模型、表名、访问地址、配置数据。这些参数传入主要是：寄存器模型获取寄存器，从中找到需要配置的寄存器、表名对应上述的table_select方法（获取表深和表宽）、访问地址和配置数据是配置表项不可缺少部分。

在伪代码中表项配置方式为寄存器间接访问，需要显示指出是哪一个寄存器模型的哪一个寄存器名，就会存在以下问题，即配置不同寄存器时都需要显示指出使用哪一个寄存器（例如上述代码指出TBL_ACCESS_METHOD_CTRL_1寄存器以写方式访问），那样使用者必须指定要配置此寄存器才能访问表项，并且还有管理配置此寄存器数据组成如何，如果不同表配置数据组成不同，那就需要额外写多份类似上述的代码了。

以下为本发明进行UVM_MEM封装表项配置的一具体实施例的伪代码示例。

if (调用寄存器内建函数get_reg_by_name判断需要配置的寄存器是否存在)begin

不存在，继续寻找或上报警告。

end

else begin

存在，获取寄存器名（拿到TBL_ACCESS_METHOD_CTRL_1）

end

从存储器模型内建函数中获取表项深度和宽度。

if(配置表项类型是TCAM)begin

组成激励、配置寄存器

等待完成、超时检查

end

使用此方式将代码封装成函数后，进行调用仅传入如下参数：访问地址、配置数据。

按照UVM_MEM封装表项访问原理流程图，编写相关代码，上述伪代码为前门写表部分代码的示例，在UVM_MEM中操作的都是uvm_reg_item，通过内建函数即可得到表项规格。那么如果需要验证某个表项仅需要在ralf中添加memory时把规格指明即可，这部代码为所有表项复用。针对寄存器间接访问表项使用不同寄存器时，比较容易添加了寄存器存在性检查，调用起内建函数get_reg_by_name寻找寄存器只有存在了才能进行下一步配置。后续代码完成均是以公共方式完成，则当切换到配置其他表项时仍然适用，不用再显示指出使用哪一个寄存器，且使用者完全不用关心内部如何访问的。

上述基于UVM模型的芯片验证测试还可以集成在芯片验证测试系统，或芯片验证测试设备中，以实现对芯片内部存储器的有效测试。

综上所述，本发明提出了一种基于UVM的芯片验证测试方法、系统及电子设备，通过在UVM验证环境中的UVM_MEM模型的基础上封装一层公共的表项配置方式，使得在对不同芯片的存储器进行验证测试时，面对不同规格和类型的表项都能适配，减少模块级验证人员需维护的配置表项代码量，提高了验证测试的效率，提高了复用性及可移植性。

虽然本发明已以实施例揭露如上，然其并非用以限定本发明，任何所属技术领域中具有通常知识者，在不脱离本发明的精神和范围内，当可作些许的更动与润饰，故本发明的保护范围当视后附的申请专利范围所界定者为准。

Claims (7)

1.一种基于UVM的芯片验证测试方法，其特征在于，包括，

步骤S1，在UVM验证环境中添加存储器模型，生成UVM_MEM模型；

步骤S2，重载UVM_MEM模型中的uvm_reg_frontdoor和uvm_reg_backdoor类；以及，

步骤S3，重写uvm_reg_frontdoor和uvm_reg_backdoor类中的body函数，形成自建body函数。

2.如权利要求1所述一种基于UVM的芯片验证测试方法，其特征在于，所述步骤S3中重写后的body函数的具体执行步骤包括，

步骤S31，识别表项类型；

步骤S32，依据识别出的表项类型，获取表项规格、表项配置方式、以及表项组成结构需要配置数据的次数；

步骤S33，依据表项规格、表项配置方式、以及表项组成结构需要配置数据的次数，结合验证对象的设计方案，配置表项激励组成并下发；以及

步骤S34，进行错误检查，并上报检测结果。

3.如权利要求2所述一种基于UVM的芯片验证测试方法，其特征在于，所述表项类型包括，线性表、TCAM、以及Hash表。

4.如权利要求2所述一种基于UVM的芯片验证测试方法，其特征在于，所述表项规格包括，表深、以及表宽。

5.如权利要求2所述一种基于UVM的芯片验证测试方法，其特征在于，所述表项配置方式包括，寄存器间接访问、以及可寻址访问。

6.一种基于UVM的芯片验证测试系统，其特征在于，包括如权利要求1-5中任一项所述的基于UVM的芯片验证测试方法。

7.一种基于UVM的芯片验证测试电子设备，其特征在于，包括如权利要求1-5中任一项所述的基于UVM的芯片验证测试方法。