一种控制器验证方法、装置、系统、电子设备及存储介质

摘要

本发明的实施例公开一种控制器验证方法、装置、系统、电子设备及存储介质，涉及计算机技术领域，能够克服验证过程中寄存器访问部分不便移植的弊端，提高验证效率。所述方法包括：建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；接收到控制器发送的配置请求后：通过统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应。本发明适用于多VIP参与控制器验证场景下寄存器访问部分不便移植、验证效率低下的问题。

权利要求

1.一种控制器验证方法，其特征在于，所述方法包括：建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

接收到控制器发送的配置请求后：通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应；

其中，建立寄存器的仿真模型,包括：分层次逐层创建各层对象并初始化，其中从高到低各层次分别为寄存器映射、寄存器和寄存器字段；

其中，最底层对象包括用于访问VIP的寄存器字段的虚函数定义；不同VIP的寄存器下用于访问寄存器字段的虚函数的不同实现。

2.根据权利要求1所述的方法，其特征在于，分层次逐层创建各层对象并初始化，包括：初始化寄存器映射对象时，设置寄存器字段类型重载，添加不同VIP的寄存器到不同地址；

添加VIP的寄存器到对应地址时，创建VIP的寄存器对象并初始化；

初始化VIP的寄存器对象时，添加寄存器字段到所在VIP的寄存器的相应位置；

添加寄存器字段到所在VIP的寄存器的相应位置时，使用重载的寄存器字段类型替换预设的寄存器字段类型来创建寄存器字段对象，初始化寄存器字段对象。

3.根据权利要求2所述的方法，其特征在于，通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器，包括：获取配置请求中携带的用于标识VIP寄存器的寄存器字段地址信息；

从高到低逐级调用各层对象的读取函数，以触发对如下虚函数的调用：获取的地址信息对应的VIP寄存器下实现的用于访问寄存器字段的虚函数；

基于所述虚函数被调用时读取的寄存器字段存储值，驱动被访问的寄存器字段含义对应的功能。

4.根据权利要求1所述的方法，其特征在于，所述虚函数的参数包括：输入参数：所要访问的VIP的寄存器字段的地址信息和操作类型；

输入或者输出参数：存储值；

其中，当所述虚函数的参数中的操作类型为读操作时，存储值为输出参数；当所述虚函数的参数中的操作类型为写操作时，存储值为输入参数。

5.根据权利要求1‑4中任一项所述的方法，其特征在于，在接收到控制器发送的配置请求后，向控制器返回配置响应前，通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能。

6.根据权利要求5所述的方法，其特征在于，在配置响应返回控制器之前预置有回调函数点位，所述回调函数点位上装载有自定义的回调函数；

在接收到控制器发送的配置请求后，生成配置响应准备返回；

调用自定义的回调函数，以通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；

向控制器返回生成的配置响应。

7.根据权利要求6所述的方法，其特征在于，所述回调函数点位位于准备返回的配置响应从传输层发送到数据链路层之前。

8.一种控制器验证装置，其特征在于，所述装置包括：

模型建立单元，用于建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

请求响应单元，用于接收到控制器发送的配置请求后：通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应；

其中，模型建立单元用于建立寄存器的仿真模型,包括：分层次逐层创建各层对象并初始化，其中从高到低各层次分别为寄存器映射、寄存器和寄存器字段；

其中，最底层对象包括用于访问VIP的寄存器字段的虚函数定义；不同VIP的寄存器下用于访问寄存器字段的虚函数的不同实现。

9.一种控制器验证系统，其特征在于，所述系统包括验证控制模块、控制器、VIP和寄存器的仿真模型；

验证控制模块控制第一驱动器驱动控制器向VIP发起配置请求；

验证控制模块控制第二驱动器驱动VIP在接收到来自控制器的配置请求后，通过统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能，向控制器返回配置响应；

其中，寄存器的仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

控制器验证系统用于建立寄存器的仿真模型,包括：分层次逐层创建各层对象并初始化，其中从高到低各层次分别为寄存器映射、寄存器和寄存器字段；

其中，最底层对象包括用于访问VIP的寄存器字段的虚函数定义；不同VIP的寄存器下用于访问寄存器字段的虚函数的不同实现。

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

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

说明书

一种控制器验证方法、装置、系统、电子设备及存储介质

技术领域

[0001] 本发明涉及计算机技术领域，尤其涉及一种控制器验证方法、装置、系统、电子设备及存储介质。

背景技术

[0002] 控制器(例如PCI Express控制器)作为RC(root complex)时，在真实场景下可以与EP(endpoint)连接，向EP发起配置请求来访问EP的在配置空间中的寄存器，EP收到配置请求后需要返回响应，并且启动被访问寄存器相应的功能，例如速率切换、链路宽度切换等。

[0003] 在控制器设计的过程中，验证作为一个重要环节必不可少。而在进行控制器验证时，通常都需要使用VIP(verification IP)。VIP可以模拟链路对端的设备，在验证环境中与被验证的控制器形成连接，从而验证控制器是否可以按照协议中的规则与链路对端的设备正常交互以实现设计功能。

[0004] 目前业界内有多家PCIe VIP提供商，在特性支持、使用方法等方面各有不同。在PCIe控制器的验证中可以选用其中一种来搭建验证环境和构建验证用例。其中，用来实现配置空间寄存器的对应功能的API，是PCIe VIP的一个重要组成部分，利用这些API可以实现例如速率切换、链路宽度切换等功能。

[0005] 在实际运用当中，为了更加充分地进行PCIe控制器的验证，通常需要采用两种或两种以上的VIP作为互补。尤其是在PCIe控制器的某些特性无法被其中一种VIP所支持的情况下，便需要采用另一种支持该特性的VIP进行验证。然而，在这种多VIP参与验证的情况下，由于各个提供商的PCIe VIP使用方法各有不同，采用其中一种VIP的验证用例不便移植到另一种VIP场景下，验证工程师在移植工作中需要花费较多的时间，效率较低。

发明内容

[0006] 有鉴于此，本发明实施例提供一种控制器验证方法、装置、系统、电子设备及存储介质，以解决现有的多VIP参与控制器验证场景下寄存器访问部分不便移植、验证效率低下的问题。

[0007] 第一方面，本发明实施例提供一种控制器验证方法，包括：

[0008] 建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

[0009] 接收到控制器发送的配置请求后：通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应。

[0010] 第二方面，本发明实施例提供一种控制器验证装置，包括：

[0011] 模型建立单元，用于建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

[0012] 请求响应单元，用于接收到控制器发送的配置请求后：通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应。

[0013] 第三方面，本发明实施例提供一种控制器验证系统，包括验证控制模块、控制器、VIP和寄存器的仿真模型；

[0014] 验证控制模块控制第一驱动器驱动控制器向VIP发起配置请求；

[0015] 验证控制模块控制第二驱动器驱动VIP在接收到来自控制器的配置请求后，通过统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能，向控制器返回配置响应；

[0016] 其中，寄存器的仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现。

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

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

[0019] 本发明实施例提供的技术方案中，寄存器的仿真模型针对不同VIP提供了统一的访问寄存器的抽象接口，不同VIP下具体的寄存器访问以该统一接口为标准自定义实现，从而能够在收到来自控制器的配置请求后，可以以该统一接口访问仿真模型中请求对应的VIP寄存器，解决了在多种不同VIP参与控制器验证场景下，重复开发和维护寄存器访问部分的问题，使得验证效率提高。

附图说明

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

[0021] 图1为本发明实施例提供的一种控制器验证方法的流程图；

[0022] 图2为本发明实施例提供的控制器验证方法具体示例中仿真模型下寄存器结构示意图；

[0023] 图3为本发明实施例提供的控制器验证方法具体示例中仿真模型下函数调用关系示意图；

[0024] 图4为本发明实施例提供的控制器验证方法具体示例中验证环境结构框图；

[0025] 图5为本发明实施例提供的一种控制器验证装置实施例的结构示意图；

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

具体实施方式

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

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

[0029] 以下，对本公开实施例中的部分用语进行解释说明，以便于本领域技术人员理解。

[0030] SOC：System‑on‑a‑Chip，称为系统级芯片或者称片上系统，意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。

[0031] PCIe：PCI express的简称，一种数据传输的高速接口，用来在系统与外设之间传输数据。

[0032] RC：root complex，PCIe链接结构中的顶端设备，一般位于系统主机CPU中。

[0033] EP：endpoint，PCIe链接结构中的最底端设备，一般作为外设连接在系统主机上，例如显卡。

[0034] DUT：design‑under‑test，被测设计，在验证环境中指代所要测试的硬件描述代码。

[0035] VIP：Verification IP，即用来做验证的IP。例如PCIe VIP，就是一个可以模拟PCIe设备的代码包，在验证环境中与DUT相连，用来仿真测试DUT是否满足协议要求。

[0036] API：application‑programming‑interface，应用编程接口，在本发明实施例中指VIP所提供的可以用来驱动VIP产生对应行为的接口方法。

[0037] Callback：回调函数，在本发明实施例中指的是可以装载在VIP所提供的特性点位上的函数，通过这些回调函数，可以手动更改VIP的特性行为，以便于验证环境和测试用例的开发。

[0038] SystemVerilog：业界通用的用于数字逻辑设计与验证的硬件描述语言。

[0039] UVM：业界通用的用于验证环境和测试用例开发的底层代码库。

[0040] 目前，在多VIP参与控制器验证场景下，由于各个提供商的PCIe VIP下寄存器访问使用方法各有不同，导致寄存器访问使用不便移植、验证效率低下。为解决该问题，发明人在研究的过程中发现，虽然不同PCIe VIP提供商对寄存器访问使用方法差异性很大，但是就其基本功能而言均可归结为：确定待访问的寄存器，对寄存器进行操作，该操作包括读操作和写操作。在此基础上，可以对实现各异的寄存器访问使用方法作统一的抽象接口设置，验证控制分只需要知道该统一接口的使用方法，便能够实现对不同PCIe VIP提供商的寄存器访问，简化了多VIP参与控制器验证时寄存器访问过程。

[0041] 具体的，参见图1，本发明实施例提供了一种控制器验证方法，包括如下步骤：

[0042] 步骤101、建立寄存器的仿真模型，其中该仿真模型提供有VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

[0043] 步骤102、接收到控制器发送的配置请求后：通过所述统一抽象接口访问仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应。

[0044] 示例性的，建立寄存器的仿真模型，包括：分层次逐层创建各层对象并初始化，其中从高到低各层次分别为寄存器映射、寄存器和寄存器字段；

[0045] 其中，最底层对象包括用于访问VIP的寄存器字段的虚函数定义；不同VIP的寄存器下用于访问寄存器字段的虚函数的不同实现。

[0046] 其中，分层次逐层创建各层对象并初始化，可包括：

[0047] 初始化寄存器映射对象时，设置寄存器字段类型重载，添加不同VIP的寄存器到不同地址；

[0048] 添加VIP的寄存器到对应地址时，创建VIP的寄存器对象并初始化；

[0049] 初始化VIP的寄存器对象时，添加寄存器字段到所在VIP的寄存器的相应位置；

[0050] 添加寄存器字段到所在VIP的寄存器的相应位置时，使用重载的寄存器字段类型替换预设的寄存器字段类型来创建寄存器字段对象，初始化寄存器字段对象。

[0051] 具体实施时，通过统一抽象接口访问仿真模型中配置请求对应的VIP的寄存器，包括：

[0052] 获取配置请求中携带的用于标识VIP寄存器的寄存器字段地址信息；

[0053] 从高到低逐级调用各层对象的读取函数，以触发对如下虚函数的调用：获取的地址信息对应的VIP寄存器下实现的用于访问寄存器字段的虚函数；

[0054] 基于所述虚函数被调用时读取的寄存器字段存储值，驱动被访问的寄存器字段含义对应的功能。

[0055] 可选的，所述虚函数的参数包括：

[0056] 输入参数：所要访问的VIP的寄存器字段的地址信息和操作类型；

[0057] 输入或者输出参数：存储值；

[0058] 其中，当所述虚函数的参数中的操作类型为读操作时，存储值为输出参数；当所述虚函数的参数中的操作类型为写操作时，存储值为输入参数。

[0059] 示例性的，在上述步骤102中，在接收到控制器发送的配置请求后，向控制器返回配置响应前，通过统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能。

[0060] 具体实施时，在配置响应返回控制器之前预置有回调函数点位，所述回调函数点位上装载有自定义的回调函数；

[0061] 在接收到控制器发送的配置请求后，生成配置响应准备返回；

[0062] 调用自定义的回调函数，以通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；

[0063] 向控制器返回生成的配置响应。

[0064] 典型的，所述回调函数点位位于准备返回的配置响应从传输层发送到数据链路层之前。

[0065] 下面采用一个具体示例，对本发明实施例提供的技术方案进行详细说明。本具体示例的适用场景是多PCIe VIP参与下的PCIe控制器验证。当然，对其它类型控制器的验证，也可参考本实施例。并且，本具体示例中关于寄存器模型的各个类中，变量名称与函数名称可以选取别的名称，以代表相同的作用。

[0066] 一、首先，预先建立寄存器的仿真模型。

[0067] 典型的，本模型采用SystemVerilog语言与UVM底层库编写。

[0068] 整个模型分为三个层次的类型，相邻层次间为包含与被包含的关系，最上层的类型为寄存器映射reg_map，reg_map类型中包含若干reg_dw寄存器类型对象，可存储于名为regs_hash的关联数组内。reg_dw类型中包含若干reg_field寄存器字段类型对象，可存储于名为fields_q的队列中。如图2所示。

[0069] 最底层类reg_field的基类是uvm_object，在控制器验证时需要针对参与验证的每个PCIe VIP：编写继承于最底层类reg_field的子类，并重载最底层类reg_field中的寄存器访问access_vip_reg函数。

[0070] reg_field类型中包含如下几项成员变量：

[0071] field_name：寄存器字段名称，即对应于协议规定的各个寄存器字段的名称，类型可为strin；

[0072] dw_name：寄存器DW名称，即该字段所处的寄存器DW名称；

[0073] field_type：寄存器字段类型，为该寄存器字段的可读写属性，可以是HWINIT/R0/RW/RWIC/RSVD中的一种；

[0074] field_offset：寄存器字段偏移，即该字段在该寄存器DW中所处的位置，以其最低位所在的bit序号表示，类型可为int；

[0075] field_width：寄存器字段宽度，即该字段在该寄存器DW中所占据的宽度，类型可为int；

[0076] default_val：默认值，即该寄存器字段存储的初始值，类型可为bit[31：0]；

[0077] value：寄存器字段的存储值，即该寄存器字段当前存储的值，类型可为bit[31：0]。

[0078] 此外，reg_field类型中还包含如下成员函数：

[0079] initial_field：初始化函数，用于将该reg_field中的成员变量做初始化赋值。

[0080] access_vip_reg：VIP寄存器访问函数，用于调用VIP中各个寄存器字段存储值含义所对应的API。该函数定义为虚函数，使用时需要先重载，以便根据不同的VIP使用方法，在其中调用不同的API。在此函数中，需要按照各个寄存器字段存储值所对应含义以及读写操作，匹配不同的API，如果VIP不具备某些寄存器含义所对应的API，则忽略并返回。

[0081] 其原型定义如下：

[0082] Virtual function access_vip_reg(string dw_name，string field_name，ref bit[31：0]val_，input bit wr)；

[0083] //override this function in extended class

[0084] endfunction

[0085] read_field：读寄存器字段函数，用于对寄存器字段存储值进行读操作。该函数首先读取当前寄存器字段值value，再调用access_vip_reg来读取VIP中该寄存器字段含义所对应的值，例如某些状态量，或者特性支持情况。如果VIP支持该寄存器字段含义所对应的API，则access_vip_reg会传递回寄存器字段存储值从而覆盖函数返回值。

[0086] 其代码如下所示：

[0087] function bit[31：0]read_field()；

[0088] read_field＝value；

[0089] access_vip_reg(dw_name，field_name，read_field，0)；

[0090] endfunction

[0091] write_field：写寄存器字段函数，用于对寄存器字段进行存储值的写操作。该函数首先判断寄存器字段类型是否是RW或者RW1C。如果寄存器字段类型是RW，则进行写入，首先将值写入寄存器字段值变量value进行存储，然后再调用access_vip_reg。如果寄存器字段类型是RW1C，则判断写入值是否是1，如果是则将寄存器字段存储值清零，并调用access_vip_reg。如果VIP具备该寄存器字段含义所对应的API，access_vip_reg会调用此API来触发VIP中该寄存器字段含义所对应的功能。

[0092] 其代码如下所示：

[0093]

[0094]

[0095] 中间层类reg_dw的基类是uvm‑object，reg_dw类型中包含如下几项成员变量：

[0096] dw_name：DW名，即该寄存器DW的名字，类型可为string；

[0097] fields_q[$]：fields队列，用于存储该DW所包含的所有reg_field类型对象。

[0098] 此外，reg_dw还包含如下成员函数：

[0099] initial_dw：初始化函数，用于将该reg_dw中的成员变量做初始化赋值，此函数依据传入的dw_name，以offset的次序调用add_field，各个字段所在的offset和width遵循PCIe协议的规定；

[0100] add_field：添加寄存器字段函数，用于将寄存器字段添加到该DW中，该函数创建reg_field类型对象，并调用所创建的reg_field对象的initial_field函数，最后添加到当前DW的fields_q中。

[0101] read_dw：读DW函数，用于读取DW中的全部4个字节。该函数执行时，遍历该DW中的所有寄存器字段，将所有寄存器字段的存储值组合为double word，并返回。

[0102] 其代码如下所示：

[0103]

[0104] write_dw：写DW函数，用于写入该DW的所有寄存器字段。该函数执行时，遍历该DW中的所有寄存器字段，向寄存器字段中写入所对应的存储值。

[0105] 其代码如下所示：

[0106]

[0107] 最上层类reg_map的基类是uvm‑object，reg_map中包含如下成员函数：

[0108] regs_hash[int]：寄存器哈希，即用来存储所有reg_dw类型对象的的哈希结构，其索引值为寄存器的地址，单位为double word；

[0109] cust_field_type：自定义寄存器字段类名，即针对参与控制器验证的VIP而编写的继承于reg_field类的自定义子类名称，类型可为string。

[0110] 此外，reg_map还包含如下成员函数：

[0111] initial_map：初始化函数，用于构建整个寄存器模型，此函数首先调用UVM的内建函数来设置reg_field类型重载，代码如下所示：

[0112] set_type_override_by_type(cust_field_type，reg_field：：get_type())；

[0113] 然后按照寄存器地址顺序调用add_reg，寄存器地址的映射规则遵循以PCIe协议的规范。

[0114] add_reg：添加寄存器函数，用于创建reg_dw类型的对象并添加到reg_hash中，此函数依据传入的dw_name来创建reg_dw对象，并调用所创建reg_dw对象的initial_dw函数来初始化。

[0115] read_reg：读寄存器函数，用来读取寄存器的存储值，此函数执行时，首先判断地址是否有效，如果地址无效则返回0；如果地址有效，则在regs_hash中选取相应地址的reg_dw对象，并调用其read_dw函数；

[0116] 其代码如下所示：

[0117]

[0118] write_reg：写寄存器函数，用来写入寄存器的存储值，此函数执行时，首先判断地址是否有效，如果地址有效，则在regs_hash中选取相应地址的reg_dw对象，并调用其write_dw函数；

[0119] 其代码如下：

[0120] Function write_reg(bit[11：0]addr，bit[31：0]val)；

[0121] Int dw_addr＝addr/4；

[0122] If(regs_hash.exists(dw_addr))begin

[0123] Regs_hash[dw_addr].write_dw(va1)；

[0124] end

[0125] endfunction

[0126] 二、初始化寄存器的仿真模型

[0127] 寄存器的仿真模型在初始化时，会逐级创建各个层次的对象，从而形成完整的寄存器结构。

[0128] Reg_map的initial_map在执行时，会设置reg_field的类型重载，并调用reg_map类型成员函数add_reg来添加寄存器到各个地址。而add_reg函数在执行时，会在创建reg_dw类型对象以添加到成员变量regs_hash的指定序号上，并调用reg_dw类型成员函数initial_dw。而initial_dw函数在执行时，会调用reg_dw成员函数add_field，来将各个字段添加到指定位置。而add_field在执行时，会利用UVM的factory机制来创建reg_field对象，该机制会自动使用重载类型替换reg_field类型来创建对象，最后调用reg_field类型成员函数initial_field来做字段初始化。这样整个寄存器模型的框架便构建完成。此调用关系如图3所示。

[0129] 三、对寄存器进行操作

[0130] 寄存器的仿真模型在初始化完成之后，便可以进行寄存器的读写操作。

[0131] 当进行写寄存器操作时，通过调用reg_map的write_reg函数并传入地址参数，reg_dw的write_dw和reg_field的write_field被逐级调用，最终调用access_vip_reg来访问VIP所对应的API。当进行读寄存器操作时，通过调用reg_map的read_reg函数并传入地址参数，reg_dw的read_dw和reg_field的read_field被逐级调用，最终调用access_vip_reg来访问VIP所对应的API。

[0132] 这样，本寄存器的仿真模型的框架搭建完成，在验证环境中便可以创建和配置本模型。进行控制器验证时时还需要另外再编写自定义的类来重载reg_field类，尤其需要编写access_vip_reg函数，以根据寄存器字段存储值的含义来调用所使用的VIP对应的API。编译时，此自定义的类需要放在VIP的编译文件和寄存器模型的编译文件之后。

[0133] 四、将寄存器的仿真模型与VIP相互连接。

[0134] 按照PCIe协议的规范，对EP寄存器访问操作是配置请求流程的一个部分。EP在收到RC发出的配置请求后，要完成寄存器访问和返回配置响应两个动作。功能完备的VIP均会在配置响应返回前预置一个callback点位，以方便使用者在返回配置响应前加载自定义的代码，例如用来修改自动返回的配置响应。本寄存器的仿真模型便可以利用这类callback功能，自定义callback函数并重载，从而与VIP进行连接。这样VIP在收到配置请求后，自动产生响应准备返回，此时VIP自动调用已经被自定义过的callback函数，此函数执行时会先访问寄存器模型，从而触发VIP相关的API，接着再返回配置响应。

[0135] 一种典型的应用实例描述如下。

[0136] 在验证环境中，DUT作为RC与作为EP的VIP通过串行总线相连。DUT另一侧的数据接口通常是片内系统总线，该系统总线上需要挂载一个驱动器DUT_driver，用来驱动DUT发起包括配置请求在内的各种数据传输，该驱动器的handle传入测试控制模块的测试用例Test case中以便调用。VIP1通常也需要驱动器VIP_driver1来驱动其产生各种类型的数据传输，VIP1驱动器的handle也传入Test case中以便调用。Callback1函数加载在VIP所提供的特定callback点位上，比如返回配置响应之前，将已在环境中创建好的本寄存器模型handle传入callback函数中，以便调用。寄存器的仿真模型通过调用access_vip_reg1来驱动VIP1的相应API。验证环境结构框图如图4所示。其中VIP1可以替换为另一种VIP，图中用VIP2表示，同步需要替换的还有VIP_driver2、callback2以及access_vip_reg2这些部分。切换VIP的方法有很多，比如可以通过条件编译宏来选取不同的VIP。

[0137] 这样，即使采用多种不同的PCIE VIP，Test case的EP配置空间寄存器请求部分的代码也可以保持不变，从而使得在不同PCIE VIP参与验证的环境下，开发和维护测试用例变得更加便捷，更有效率。

[0138] 在此示例中，为了使用此寄存器模型，需要以下步骤：

[0139] 编写reg_field1，利用VIP1的寄存器字段存储值含义相关的API来重载其access_vip_reg函数；

[0140] 在验证环境中创建reg_map，并将reg_field1的类型名设置到cust_field_type变量中，并调用initial_map；

[0141] 将callback函数加载到合适的VIP提供的callback点位上，使其被VIP在特定的条件下调用，例如在将配置响应从传输层发送到数据链路层前；

[0142] 编写callback函数，使其在配置响应发送前，获取当前配置请求的寄存器地址，并按以寄存器地址作为传入参数调用reg_map的read_reg/write_reg函数，如果是配置读请求，则将寄存器读取后的结果装配在配置响应的数据字段。

[0143] 本具体示例中所描述的寄存器仿真模型，可以模拟出完整的PCIE配置空间的寄存器结构，可以通过配置并重载底层函数的机制统一不同VIP的寄存器访问接口，将不同VIP寄存器操作的方式封装在模型中，从而解决了在多种不同VIP参与PCIE控制器验证场景下，重复开发和维护测试用例中寄存器访问部分的问题，使得验证工作效率提高。

[0144] 同时，本发明实施例还提供了一种控制器验证装置，参见图5，该装置可以包括：

[0145] 模型建立单元501，用于建立寄存器的仿真模型，其中该仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现；

[0146] 请求响应单元502，用于接收到控制器发送的配置请求后：通过所述统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能；向控制器返回配置响应。

[0147] 本实施例的装置，可以用于执行本发明任意方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

[0148] 此外，本发明实施例还提供一种控制器验证系统，该系统包括验证控制模块、控制器、VIP和寄存器的仿真模型；

[0149] 验证控制模块控制第一驱动器驱动控制器向VIP发起配置请求；

[0150] 验证控制模块控制第二驱动器驱动VIP在接收到来自控制器的配置请求后，通过统一抽象接口访问所述仿真模型中配置请求对应的VIP的寄存器以触发被访问寄存器对应的功能，向控制器返回配置响应；

[0151] 其中，寄存器的仿真模型提供有验证网际互联网协议VIP的寄存器访问的统一抽象接口以及不同VIP的寄存器访问在统一抽象接口下的不同实现。

[0152] 本发明实施例还提供一种电子设备，所述电子设备包含前述任一实施例所述的装置。

[0153] 图6为本发明电子设备一个实施例的结构示意图，可以实现本发明图1所示实施例的流程，如图6所示，上述电子设备可以包括：壳体61、处理器62、存储器63、电路板64和电源电路65，其中，电路板64安置在壳体61围成的空间内部，处理器62和存储器63设置在电路板64上；电源电路65，用于为上述电子设备的各个电路或器件供电；存储器63用于存储可执行程序代码；处理器62通过读取存储器63中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一实施例所述的控制器验证方法。

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

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

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

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

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

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

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

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

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

[0166] 本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

[0167] 尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

[0168] 为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本发明时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。

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

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