如何提高验证组件的垂直复用、水平复用和平台复用？

 

摘要：

本文提出了实用的方案，以增强基于AMBA的SoC设计验证的验证组件的复用。AMBA统一验证系统（AUVS，AMBA Unified Verification System）可以通过为每个配置预先定义AMBA agent块来减少构建测试平台的时间，并且还可以通过提供AMBA VIP的抽象层来提高验证组件的平台复用。固件类的序列（FLS，Firmware-Like Sequence）是一种仅使用硬件抽象层（HAL，Hardware Abstraction Layer）提供的任务描述测试序列的方案，该任务将自身定位在测试序列和agent块之间，从而增强了测试序列的垂直复用和水平复用。

一. 引言

一项研究发现，总验证时间的22%和23%分别花费在测试平台构建和测试方案编码上，而36%花费在调试时间[1]上。换句话说，准备测试的总时间（包括搭建测试平台和提出测试方案所花费的时间）相对大于实际的验证工作时间：45%比36%。这就是为什么要进行很多努力来改善组成测试平台和测试用例的验证组件的可复用性的一个很好的理由。这些努力中包括System Verilog和通用验证方法学（UVM），它们提高了这种可复用性[2] [3]。尽管System Verilog和UVM通过提供基本的验证组件和方法学可以促进设计验证环境，但它们不能保证此类验证组件的复用。相反，只有当验证工程师在使用或创建此类验证组件时要牢记复用的概念，才能提高可复用性。可复用性可分为三种：垂直复用、水平复用和平台复用[1]。

本文针对以AMBA为基础的SoC设计（这是SoC的一般形式），提出了提高验证组件的所有三种可复用性的使用方案。该使用方案由两个主要概念组成：1. AMBA统一验证系统（AUVS）不仅可以提高验证组件的平台复用，也可以缩短测试平台的建立时间；2. 固件类的序列（FLS）通过在测试序列和agent块之间提供硬件抽象层（HAL），可以改善测试序列的垂直复用和水平复用。

二. 复用问题

在引入我们所建议的解决方案之前，这个部分总结了验证工程师在工作中遇到的三个主要的复用问题，并发现它们很耗时。

问题1. 测试平台的构建

在IP模块级验证中，我们需要几乎与IP块数量一样多的测试平台。每个测试平台的构建都被视为一系列常规工作：agent块的创建及其配置，接口的创建及其配置，验证组件的连接，sequence的创建等。如果有一种简单而系统的方法可以这样做，那么可以减少建立测试平台所需的大量时间和精力，这将是一个很好的好处。

问题2. 测试序列的平台复用

出于多种原因，我们可能需要使用多个供应商的AMBA VIP，包括VIP许可问题，协同仿真器的可合成性，仿真器的兼容性，甚至内部VIP的使用等。这种情况迫使我们找出如何为每个不同的VIP有效地使用不同的测试序列，即所谓的平台复用问题。

问题3. 测试序列的垂直复用和水平复用

出于一些良好的因素，包括IP级别之间的不同环境，在IP模块级验证中使用的序列无法在更高级别复用的情况并不罕见。结果就是，在IP块上使用的AMBA总线序列无法在更高级别上直接复用，即所谓的垂直复用问题。图1显示了垂直复用的示例，其中由于AXI总线在IP级别使用的AHB驱动器（driver）无法在子系统级别复用。同样，当DUT在另一个项目中复用时，我们也会遇到类似的问题 - 例如，将SFR访问端口从AHB更改为AXI。这就是所谓的水平复用问题。

在下文中，第三部分和第四部分分别提出了复用问题1、2和3的独立解决方案。第三部分介绍了AUVS方案，该方案是基于UVM预先构建的验证平台，具有针对每个总线协议的包装agent块，旨在通过减少测试平台的构建时间并使用独立于特定VIP的包装代理来解决复用问题1和2。在第四部分中，提出了FLS方案，其仅具有着描述HAL任务的测试序列，正因为它使测试序列摆脱了SFR端口协议，所以其可以作为问题3的解决方案。

 

                                                                                               图1. 垂直复用示例

 

 

三. AMBA统一验证系统（AUVS）

A. AUVS概述

图2显示了AMBA统一验证系统（AUVS）的总体体系架构，该体系架构由AUVS TPI序列、AUVS环境和AUVS线束组成。AUVS可以被认为是基于UVM预先构建的验证平台，其为用户提供了可复用的AMBA事务生成机制。本部分简要介绍了三个主要组件，然后在后面的部分中提供了更详细的解释以及代码片段。

AUVS环境的创建、配置和连接AUVS的agent块，每个总线协议（AXI、AHB和APB）都有各自的AUVS agent块，每个agent块都包含有各种供应商的AMBA VIP agent块。用户可以选择特定供应商的VIP、其实例数以及AUVS agent块的其他协议参数。一旦创建和配置好AUVS agent块后，它们将连接到AUVS接口。AUVS工具根据每个用户的配置会生成一系列AUVS接口，并将其注册到UVM资源池中，以便AUVS环境可以在需要时提取它们。因此，只需使用适当的用户配置实例化此AUVS环境，就可以使用所有的AMBA agent块（无论所需的种类和数量如何），从而显著减少测试平台的建立时间（问题1）。

此外，由于AUVS接口内部包含参数，因此不需要单独的配置类即可将总线协议参数传递给agent块。因为这些参数与每个总线协议都相关，所以这种方法很有意义。尽管为它们分配了默认值，但是如果需要，以后可以由外部的用户给出特定值覆盖它们。

                                                                                                  图2. AUVS架构

 

TPI代表测试编程接口（Test Programming Interface），它是继承uvm_sequence的类，旨在为所有的测试序列提供应用程序编程接口（API，Application Programming Interface），以访问独立于VIP供应商的AMBA事务。即使目标AMBA VIP发生改变，也可以实现复用继承了TPI的测试序列，而无需进行任何修改，从而解决了测试序列的平台复用问题（问题2）。

由于AUVS环境是一个预先构建的平台，因此您要做的就是正确使用AUVS接口和AUVS TPI序列。以下两部分将从AUVS界面开始，从用户视角解释它们的工作方式。在本文的示例代码中，假设Synopsys AMBA SVT、Mentor AMBA QVIP和内部AMBA VIP是目标AMBA VIP的备选，其不会浪费不必要的VIP许可证来选择在编译时使用哪个VIP。

B. AUVS接口

每个总线协议都有一对AUVS接口：主从接口。如下代码片段1是以AXI主接口代码为例。各种供应商的AXI VIP接口都是预先内置和连接好的。其中之一将在编译时使用`define进行选择。如前所述，总线协议特定的参数（如addr_width和data_width）已定义并分配了默认值。为了配置AUVS agent块，AUVS环境将引用这些参数。

代码片段1. auvs_axi_master_interface.sv             

C. AUVS工具

如下代码片段2显示了AUVS工具，它是所有可用AMBA接口的集合。接口被实例化，分配给虚接口，然后注册到UVM资源池中，以便测试平台可用通过uvm_config_db::get获取它们。因为不允许在SystemVerilog中继承接口，则可以使用testbench中的`include来访问AUVS工具。有关此内容，请参见代码片段7。

代码片段2. auvs_harness.svi                                       

 

D. TPI序列

如下代码片段3显示了TPI序列类的标头部分。TPI序列类为每个总线协议提供了一对写/读任务，通过其继承的测试序列可以生成总线通信流。其任务是通过参数传递事务输入/输出数据。参数agt_id会在许多可用agent块中选择一个目标agent块。

代码片段3. auvs_tpi_sequence.sv（标头部分）                

摘录代码片段4以AXI写入任务axi_write()为例来说明其工作原理。该代码片段显示了将Synopsys AXI VIP选择为目标agent块的情况。如代码片段4中的注释所述，将生成特定于供应商的序列项或事务，可使用输入参数进行设置，使用端口时序值进行配置，然后发出该序列。在每个TPI任务中都会预先构建此类特定于供应商的流程。

代码片段4. auvs_tpi_sequence::axi_write()（主体部分）                                           

 

E. AUVS环境

事实上，对于用户来说，为了充分利用AUVS，参考AUVS接口和TPI序列（到目前为止已在前面解释过）就足够了。下面两部分则深入探讨了AUVS环境，它是使所有这些成为可能的底层引擎，因此您可以了解如何在内部处理AUVS接口和TPI序列。

如下代码片段5所示，auvs_env具有agent块（auvs_axi_master_agent）、配置（auvs_axi_config）、虚接口（auvs_axi_master_interface）和虚sequencer（auvs_sequencer）等作为其成员。在构建阶段，将创建各种AMBA协议的主agent块和从agent块，以及它们的配置，然后是从UVM资源数据库检索的虚接口，agents/configs配置，以及AUVS虚sequencer（auvs_sequencer）注册的例程。代码片段5仅以AXI的master端案例为例，但其他总线协议看起来也都相似。在连接阶段（即connect phase阶段），每个agent的sequencer都连接到AUVS的虚sequencer（auvs_sequencer），以便TPI序列以后可以使用它将序列项放入特定的agent块中。接下来是AUVS agent块，它是AUVS环境中最重要的组件。

代码片段5. auvs_env.sv                                        

 

F. AUVS agent块

如下代码片段6展示了AUVS agent块的其中之一，即AUVS AXI主agent块。该AUVS agent块充当占位符，以包含用户选择的agent及其sequencer。创建目标agent块，然后在构建阶段（即build phase阶段）将其分配给AUVS环境向下传递的配置实例。在连接阶段（即connect phase阶段），目标agent块的sequencer连接到AUVS agent块的sequencer（即auvs_axi_sequencer），而该sequencer又连接到AUVS环境的虚sequencer（即auvs_sequencer），如代码片段5所示。TPI序列可以利用在这种机制中目标agent块的sequencer，将目标agent块、AUVS agent块、AUVS环境和TPI序列都按sequence/sequencer连接在一起。

代码片段6. auvs_axi_master_agent.sv                              

 

G. 测试平台的实现

到目前为止，从TPI序列到AUVS接口，我们已经了解了AUVS的构建方式和工作方式。现在该展示如何以实际方式使用它们了。请回想一下，从用户的角度来看，只有两个领域需要关注：AUVS接口和TPI序列。

代码片段7展示了示例testbench模块，tb_top用于处理AUVS接口。该模块包括用于复用AUVS工具的“auvs_harness.svi”文件，并将DUT的端口连接到AUVS工具的AMBA agent块的接口。通过将AMBA agent块配置的参数分配给相应的接口来最终确定DUT与AUVS环境之间的连接。

代码片段7. tb_top.sv

代码片段8显示了AUVS测试序列处理TPI序列的示例代码。该序列继承了auvs_tpi_sequence并通过TPI序列提供的API任务描述了一个测试场景。请注意，在任务pre_body()中，将在UVM资源池中注册的auvs_sequencer分配给auvs_tpi_sequence的成员auvs_seqr。即使AMBA VIP agent块的内容发生了变化，该机制也可以根据API任务继续复用auvs_sample_sequence。

代码片段8. auvs_sample_sequence.sv

 

四. 具有硬件抽象层（HAL）方案的固件类序列（FLS）

A. FLS概述

固件类序列（FLS）是一种可以通过硬件抽象层（HAL）创建测试序列的方案。HAL是一种验证组件，它能提供抽象DUT功能的API任务。此类API任务仅与驱动器（driver）任务（write_driver()和read_driver()）一起编写，以访问DUT的SFR。驱动器任务仅使用地址和数据，就像固件编程中通常使用的内存映射块访问一样。反过来，write_driver()和read_driver()分别调用虚任务bus_write()和bus_read()，它们允许稍后实现特定的或VIP依赖的实现。由于HAL的总线操作是通过回调决定的，基于HAL的测试序列也可以重用，从而实现垂直复用和水平复用（问题3）。图3显示了FLS的总体架构。您会注意到上面的w.r.t. HAL与协议无关，而较低的则与协议相关。在以下各部分中，我们将解释FLS的主要组件行为。

 

                                                                                           图3. FLS架构

 

B. HAL基类和HAL回调基类

代码片段9显示了HAL基类，hal_base，它是所有HAL类的超类。基本HAL回调类hal_callback_base被注册为hal_base的回调类。hal_base包含两个驱动器任务：write_driver()和read_driver()。他们每个人都调用hal_callback_base的虚任务：bus_write()或bus_read()。

代码片段9. hal_base.sv

 

代码片段10显示了hal_callback_base类的代码。声明的虚任务预计将通过特定的AMBA协议操作实现。

代码片段10. hal_callback_base.sv                              

 

C. 测试平台的实现

在本部分中，让我们展示如何在创建VIP独立序列时使用HAL基类。为此，选择了DDR SDRAM主机控制器（也称DDR控制器）。代码片段11通过继承HAL基类或hal_base来显示DDR控制器的HAL类，ddrc_hal。ddrc_hal提供了API任务，这些任务抽象了DDR控制器的基本功能。请注意，这些API任务仅应与hal_base的任务一起编写：在此示例中为write_driver()和read_driver()，以便ddrc_hal可以独立于任何特定的总线协议。

代码片段11. ddrc_hal.sv                                              

如代码片段12中所示，可以在DDR控制器的HAL回调类中定义要使用的特定协议。在此示例中，AHB协议用于写入SFR或者从SFR读取。您会注意到，在hal_callback_base（代码片段10）中声明的虚任务最终在ddrc_hal_callback类中实现。当然，您可以稍后在不同级别的测试平台（垂直复用）或其他项目（水平复用）中更改任务，例如从AHB更改为AXI。

代码片段12. ddrc_hal_callback.sv

如果测试平台变成使用AXI总线协议进行SFR访问，代码片段13则是用于替换ddrc_hal_callback总线任务的代码。同样的情况适用于使用RAL（寄存器抽象层）的情况。在这种情况下，在这些总线任务中使用RAL操作就足够了。

代码片段13. AXI总线操作任务

一旦DDR控制器的HAL和HAL回调类准备就绪，就可以使用HAL API任务编写其序列，如代码片段14所示。

代码片段14. ddrc_sample_sequence.sv                        

总之，FLS方案允许我们通过使用HAL API任务来创建独立于特定SFR端口协议的测试序列。由于API下的总线操作任务是以回调的形式实现的，因此即使SFR端口协议改变了，也只需更改此类总线操作任务即可确保HAL的可复用性。

 

五. 总结

本文将SoC验证工程师在工作中很容易遇到的复用问题分为三类：测试平台的构建、测试序列的平台复用，以及测试序列的垂直复用和水平复用。在后文中，提出了一些单独的实用方案作为这些问题的解决方案，以提高验证组件的可复用性，从而减少基于AMBA的SoC验证时间的总量。

首先，AMBA统一验证系统（AUVS）提供了预先配置的AMBA验证平台和独立于VIP的AMBA事务生成机制。AUVS的采用有助于用户减少测试平台的建立时间（问题1），并有助于消除测试序列对VIP的依赖（问题2）。其次，固件类序列（FLS）是一种基于HAL的方案，即使SFR端口协议通过HAL描述测试序列而发生变化，也可以复用测试序列（问题3）。

将AUVS和FLS一起使用，有望实现验证组件的垂直复用、水平复用和平台复用等，这意味着验证工程师更有可能专注于实际验证工作本身，而不是通过大量节省以前在测试平台构建中投入的时间和精力来准备测试。

参考文献：

[1] Hans van der Schoot, “UVM & Emulation,” Mentor, 2014

[2] IEEE Standard for System Verilog. 2012.

[3] Accellera System Initiative. “Standard Universal Verification Methodology (UVM).”

原文来自：DVCon2017_USA, 点击阅读原文去路科官网下载DVCon2017论文合集，还有更多资料等你来哦！

扫描上图二维码可直达课程页面，马上试听

 

往期精彩：

获取验证通关密语，就在本周日开班的验证V2课程

30w+还送股送房？60+IC企业2019薪资全面攀升！

UVM RAL模型：用法和应用

我们准备做第二期线下培训，依旧认真且严肃

如果你突然被裁员了，你的Plan B是什么？

[彩虹糖带你入门UVM]

理解UVM-1.2到IEEE1800.2的变化，掌握这3点就够