VMM验证方法在AXI总线系统中的实现

芯片验证越来越像是软件而不是硬件工作，这点已逐渐成为业界的共识。本文以软件工程的视角切入，分析中科院计算所某片上系统(SoC)项目的验证平台，同时也介绍当前较为流行的验证方法，即以专门的验证语言结合商用的验证模型，快速建立测试平台(Test-bench)并在今后的项目中重用。

本文提及的高级验证语言、方法学、验证基本库和仿真模型，这一套方法在近几年中正逐渐被业界广为采用。计算所的工作就是以这些最新成果为起点，对基于AXI总线协议的SoC建立测试平台。

这种新方法可大幅度提高芯片验证的效率，尤其是项目初期投入极大地降低，原因之一是面向对象编程等软件工程方法的大量引入。当然，这也对验证工程师的技能提出了新的要求。

验证方法

在验证领域，显见的趋势是语言划一、仿真平台统一、更加正规和高效。以本文介绍的项目为例，语言是SystemVerilog，平台则基于VMM构建，更有验证模型(Verification IP)助力，大幅提升了效率。正是因为部件可重用、平台结构化、以覆盖率为导向和高度自动化等特点，验证工作也愈加正规，有流程可循。

专门的验证语言，面世已有数年之久。它们出自于传统的纯粹Verilog(有时部分引入C/C++)描述的验证系统，并有很大发展。Vera、e语言和目前已成IEEE标准的SystemVerilog就是这段时期技术创新的成果。

面向对象编程特性，溯其源头便是C++语言。早在纯Verilog语言验证的时代，已有利用C++开发可重用验证代码的做法。工程师们看中的恰是OOP的封装、继承、多态及可重用等优异特性。

验证语言没有相应函数库的支持，语言本身也很难发挥效力。举一个大家熟知的例子，视窗(Windows)编程中，使用C语言直接调用视窗系统的编程接口(API)实现，是较为传统的做法，可目前却鲜有视窗程序员这样应用。为什么？工作量巨大，需维护的信息太多，从窗口尺寸、菜单列表到程序算法，都要加以考虑。因而作为解决方案之一的微软基本库(MFC)才得以大行其道。与之相得益彰的是，C++作为微软基本库的描述语言，也随视窗系统的传播，广为流行开来。

现代芯片验证领域，无例外地也出现了类似状况。大量新方法、新模型和新类库不断涌现，减轻了验证工程师们重复开发底层代码的负担，将更多精力投入到实际项目上。这一套新思路中，主要构成部分便是验证语言(如Vera、SystemVerilog)，验证基本库(RVM、VMM)和相应的验证模型。

VMM的应用

VMM不仅是方法学，更是该方法的具体实现。它包括一系列的类库(class library)、类对象(object)联接关系以及用户定制的代码。如图1所示的测试平台中，各部件或即对象，是VMM基本类/扩展类的实例化(Instantiate)。所涉及到的VMM基本类有vmm_xactor、vmm_scenario_gen和vmm_data等。

图1：测试平台框图。

联接各部件，构成一个整体还需要其它一些基本类，包括vmm_env、vmm_channel以及vmm_xactor_callbacks等。除此之外，用户要根据芯片的实际状况，添加或修改约束条件、接口联线、执行步骤、覆盖率定义和自动比对机制(auto-check)。

1. 背景

该种类型的验证平台充分利用了软件工程的成果，将整个测试平台按照所实现的功能，分门别类予以切割，实现各模块独自开发、分别维护。目前，芯片规模趋于庞大，协议愈形复杂，通常要传递海量数据，并拥有数目繁多的端口。如果还以先前纯Verilog的方式建立验证系统，将很难满足芯片开发和投片的进度。

简而言之，简单地激励DUT输入端口、监控相应的输出端口和编写临时性的代码来做数据比对，这种验证方法已相当落后了。当然，我们也看到某些结构简单的芯片还有一定市场，纯粹Verilog语言的验证平台也可以做到非常复杂(但是很难维护)，并且学习面向对象编程的代价容易令人望而却步。但这些都是主流之外的个例，故对此本文不深入展开。

现代验证系统，尽管包含数量众多的模块、多样的数据类型/协议及各模块间复杂的信息传递(保持同步、共享数据等)，它仍然是继承传统方法，归纳以往的验证经验，依照惯常的步骤建立测试平台。

VMM方法也概莫能外。依照通常的流程，它为所有应用VMM的测试平台设定了九个步骤，定义在vmm_env中：gen_cfg、build、reset_dut、cfg_dut、start、wait_for_end、stop、cleanup和report。

另一方面，VMM平台的架构按抽象层次划分，由以下部件组成：测试例(test)、场景发生器(generator)、驱动部件(driver)、监控部件(monitor)、数据比对部件(scoreboard)、数据对象