IC验证培训——SV Interface 入门指导

路桑的个人网址：路科验证 -IC验证培训-数字芯片验证

当涉及到验证时，接口可能是SystemVerilog语言中经常用到的部分。接口广泛的应用在静态的被测设计（DUT）和动态的测试平台之间。本文介绍了在典型的片上系统（SOC）中不同的测试平台连接到DUT的方法。

 

一、介绍

将测试台连接到DUT的最常见方法是SystemVerilog虚拟接口。这种方法在许多情况下是连接到DUT的最佳方式。

 

根据我们的专业经验，应该把被测设计作为一个黑盒，并且测试台完全独立于被测设计。因此我们坚决反对将SystemVerilog动态的测试模型中层次化的行为模型做的同静态的DUT中一样。应该将测试平台的构造独立于DUT的层次。这将使测试平台更容易复用。当测试平台需要访问DUT中的实例时，例如通过后门寄存器进行读或写，我们展示了如何使用SystemVerilog绑定的结构体和类将DUT连接到测试平台上。这相当于保持了SystemVerilog在静态的DUT中的层次的参考。

 

在以下所有示例中，测试环境被构建成几乎所有验证IP(VIP)都是UVM兼容的。这允许用户在时间允许的情况下将传统VIP迁移到通用验证组件（UVCs）上，而不必更改测试环境，测试序列和测试用例。VHDL总线功能模型（BFMs）将被集成到一个环境中，看起来就像一个（UVC）。

 

图1是典型的SOC处理器，外设和自定义逻辑模块的高层次框图。下面的示例参考了我们的SOC的UART模块。

二、VHDL总线功能模型

与人们的想法相反，VHDL仍然广泛用于FPGA的开发。在许多情况下，用户可能拥有现有VHDL BFM的大型库，并希望迁移到UVM测试环境，但可能不知道如何将BFM集成到UVM测试平台。其中一些用户假定所有的传统VHDL模型必须转换为SystemVerilog UVC。 在这里，我们证明转换到UVC不是必须的。虽然不像Verilog BFM有多种方法可以集成到UVM测试环境中，但在UVM测试台中也有一种方法连接VHDL BFM。

 

使用VHDL BFM时需要解决几个问题，最重要的一个是没有VHDL-SystemVerilog仿真的语言参考手册（LRM）。这意味着每个模拟器的供应商对于这两种语言的互通性都有自己特定的规则（限制VHDL的端口类型，常量和数据类型）。下一个问题，不可能在SystemVerilog中调用VHDL的程序；或者将SystemVerilog中的跨模块参考模型（XMR）应用到VHDL的实体中（注意：由于取决于供应商，在UVM基类库中也不支持通过寄存器模型后门访问VHDL）。

 

交互性和程序调用的问题可以通过向BFM中添加两个层次的代码的方法来解决。第一层是将VHDL进行封装：将record类型的端口分解成单独的信号，并调用BFM过程。第二层是将VHDL BFM封装后连接到SystemVerilog虚拟接口上。为了最大可能的确保在不同的模拟器上都能交互成功，我们将VHDL BFM 的封装端口的数据类型定义为：std_logic， std_logic_vector， integer，和 real data types类型（注意：通常也支持strings类型）。

在图2的示例中，DUT是典型的UVM测试平台中的一个简单的UART。静态测试平台包含DUT，时钟和复位发生器，还有封装好的BFM和一些虚拟接口。

图3所示的传统BFM在其端口映射中有一个record类型。它从队列中弹出transaction并调用uart_read，uart_write和uart_reset任务，这些任务在图4所示的包中定义。这个包也定义了端口映射中使用到的record类型。

如图5所示VHDL BFM wrapper，将BFM的记录类型端口分解为单独的信号。基于由虚拟接口驱动的信号，它通过调用函数将transactions 插入到uart_bfm ben架构使用的队列中。

图6显示了将动态验证环境连接到VHDL BFM wrapper上的接口。

 

图7中的测试平台例化了DUT，VHDL BFM wrapper和SystemVerilog接口：

环境中UART的主要任务是调用BFM中的过程。这个过程会反过来作用到DUT的引脚上。uart_uvc_if的start和done信号使得过程被调用。当一个读或者写操作的sequence在UART上启动时，driver将设置rw_start信号。这将启动从VHDL wrapper到BFM上的的一个读或者写的过程。当这个过程完成后，VHDL wrapper将设置rw_done信号来告诉uart_driver来调用item_done。driver的源代码见图8。

从测试环境的角度看来，这和普通的旧的UVM测试环境并没有什么差别。测试用例和测试环境可以不经修改的直接使用；并且如果项目进度允许的话，UART UVC可以在uart_driver上进行很小的修改从而迁移到标准UVC上。

 

三、Verilog总线功能模型

对于Verilog BFM，有多种方法可用于将BFM集成到UVM测试平台中。 所选择的方法需要考虑以下几个因素：

• BFM代码可以被修改吗？

• BFM需要参数吗？

• BFM使用参数化的接口吗？

这些因此决定那种方法最适合将特定的BFM集成到UVM测试平台中。所有以下解决方案允许在测试台中使用多个BFM，而不必在测试环境中硬编码实例化标识符。

 

（A）BFM Wrapper

如果现有的Verilog BFM不能被修改，一种处理方法是将BFM封装一下，如前面的VHDL示例一样。

 

（B） Abstract and Concrete Class

也可以通过使用抽象和具体类来集成Verilog BFM。这种情况下，静态测试平台和动态环境采用略有不同的形式，测试平台来例化一个具体的类，这个类是从测试环境中定义的抽象类中派生而来的:

注意在图9中，没有使用虚拟接口，而是在测试平台的代码中使用类型重载来将动态的测试环境连接到静态的测试平台上。派生类uart_driver_concrete可以定义在与例化BFM的同一个作用域中，以此来访问旧版Verilog BFM。当动态环境的基类成员uart_driver通过类型重载创建为uart_driver_concrete时，它们将具有相同的作用域，因此也可以访问BFM。参见图10，基类和派生类的使用给出了虚拟接口的错觉。这一切都是源于factory机制，基类在UVM factory中注册并在运行时被重载。

 

如果BFM具有参数化的接口，那么使用抽象/具体类是连接到DUT的一个不错的选择。

 

（C） Interface中的任务

如果用户幸运地拥有可以修改的BFM，那么最简单的方法是将任务复制并粘贴到SystemVerilog接口中。静态测试平台将具有包含BFM任务的虚拟接口。测试环境将包含shell UART agent。下图与之前显示的VHDL示例几乎相同。环境是相同的，但图11所示的静态测试平台的不同之处在于，虚拟接口直接连接到DUT，而不是通过BFM wrapper。

四、硬件/软件流程控制

验证任何SOC时都会遇到一个古老的问题：哪个先到，软件还是硬件？对于一个拥有大量优秀软件工程师的公司，建立一个在处理器上运行代码的仿真环境很有意义。这些公司通过运行与ASIC并行开发的实际应用程序代码来验证SOC。另一方面，如果使用现有硬件来验证软件，或者在真实硬件可用之后，仿真环境将以硬件为中心。在这两种情况下，都会有在处理器上运行的代码。主要区别是主要起控制作用的是硬件端还是软件端。

 

不管哪种情况，在硬件和软件之间需要某种类型的同步/握手机制。这种同步通常使用共享存储器（或邮箱）来实现。任何测试的一般流程如下：处理器加载代码，处理器启动，然后监视邮箱以获得告诉硬件要做什么的命令（例如，从VIP向DUT发送一些以太网分的包，或者将一些数据从DUT上的SPI端口发送到SPI VIP）。

 

这是“软件为中心”的流程，“硬件为中心”的流程与其类似，一旦处理器启动完毕，控制命令将被传递到SystemVerilog段，并启动sequences。在以硬件为中心的流程中，处理器的操作被简化为三个命令：读，写，比较。这允许使用最小量的C（或汇编）代码来对SOC硬件进行功能验证。

 

要在硬件和软件之间来回传递控制，需要监视和驱动DUT内部的节点，理想情况下不需要在共享内存中创建层次化的行为模型。对于以硬件为中心的方法，我们将使用一个processor agent，将命令（读，写或比较）写入共享内存，并设置处理器中断。 处理器中断子程序读取共享存储器，执行请求的命令，然后在命令完成后清除中断。

 

如图13所示，processor agent是标准UVM agent，除了driver具有额外的接口。这个event_if接口在图14中被定义，它包含了一些事件，在这些事件中driver可以控制发送到处理器到命令。

如图14所示，monitor在存储内容改变时设置这些事件。除了被driver使用之外，这些事件将由在测试环境中运行的sequences使用来控制执行。为了监视共享内存，我们使用一个SystemVerilog绑定结构，类似于白盒验证技术。 使用虚拟接口中的任务来执行向共享存储器写入数据或从共享存储器读取数据。

五、UVM寄存器层后门访问

UVM基类库具有内置机制以允许后门访问寄存器，但是可能存在无法使用默认DPI访问寄存器的情况：VHDL DUT或者寄存器声明为多维数组，或者DPI对仿真性能有较大的影响。有一个代替方案是使用一个基类来进行用户自定义的后门访问。其中一种方法通过对DUT的层次化访问以绕过DPI并提高仿真性能，但是测试台不再能与DUT完全分离，并且寄存器模型的数据不能包含在数据包中。 另一种方法是将层次化的行为模型放到接口中。除了保持测试环境与DUT完全独立之外，这种方法还具有从寄存器模型中删除DUT层次结构的优点，并且可以与VHDL DUT一起使用（注意：从SystemVerilog到VHDL的后门写操作只能使用 模拟器特定程序）。如果DUT层级改变，但寄存器保持不变，则不需要更新寄存器模型，因为它不包含任何HDL层次化路径构造，例如add_hdl_path（“top_tb.dut_wrapper.dut”）或status_reg_h.configure this，null，“”）。

图15显示了SystemVerilog DUT的后门读/写任务。 如果DUT是VHDL，则必须使用如图16所示的绑定结构。

六、参数的问题

对于使用工业标准通信或总线协议的大多数设计，几乎所有VIP都使用参数化接口，如图17所示。参数化的接口需要创建一个参数化的类，它可以根据通用类和实际的参数值的不同被例化为不同样子。对于有多个参数相组合的设计，这将增加测试平台的复杂性，并且需要使用基于类型的factory而不是基于字符串的factory。

如果你的设计仅包含最少数量的参数值，多个AHB都具有相同的地址和数据宽度，那么使用参数化类可能是一个很好的选择。另一方面，如果有多个参数化接口需要许多值的组合，最好的解决方案是使用抽象基类-具体派生类。

当具体化变得很麻烦，抽象基类-具体派生类便能发挥很大的作用。图18所示的例子与本文第三节B部分的例子大致相同。测试平台例化了含有不同参数的接口。接口本身定义了一个具体的类，它扩展了一个抽象基类，并定义了用于切换DUT引脚的任务。这个抽象类是driver的成员并通过driver调用get_config_object()进行重载。唯一需要知道参数的实体是测试平台本身。

 

七、结论

本文介绍了在典型的片上系统（SOC）设计中使用不同的方法连接测试平台和DUT。它包括很多有关连接方法的例子，同时严格遵守将动态和静态原件分离的思想。用本文介绍的技术，用户可以利用其现有的验证IP创建高度可重用的测试环境，并且如果时间允许的话可以用UVC替换BFM。

 

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。