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

1、    VMM验证方法在AXI总线系统中的实现，SystemVerilog，验证IP，VMM1引言芯片验证(Verification)越来越像是软件而不是硬件工作。这点已逐渐成为业界的共识。本文以软件工程的视角切入，分析中科院计算所某片上系统(SoC)项目的验证平台，同时也介绍当前较为流行的验证方法，即以专门的验汪语言结合商用的验证模型，快速建立测试平台(Test-bench)并在今后的项目中重用(reuse)之。文中提及的高级验证语言、方法学、验证基本库和仿真模型，这一套方法在近几年中，正逐渐为业界广为采用。计算所的工作1引言芯片验证(Verifica

2、tion)越来越像是软件而不是硬件工作。这点已逐渐成为业界的共识。本文以软件工程的视角切入，分析中科院计算所某片上系统(SoC)项目的验证平台，同时也介绍当前较为流行的验证方法，即以专门的验汪语言结合商用的验证模型，快速建立测试平台(Test-bench)并在今后的项目中重用(reuse)之。文中提及的高级验证语言、方法学、验证基本库和仿真模型，这一套方法在近几年中，正逐渐为业界广为采用。计算所的工作，就是以这些最新成果为起点，对基于AXI总线协议的SoC，建立测试平台。这种新方法可大幅度提高芯片验证的效率，尤其使项目初期的投入极大地降低。原因之一是，面向对象编程等软件工程方法的大量引入。当然

3、，这也对验证工程师的技能提出了新的要求。2验证方法在验证领域，显见的趋势是语言划一、仿真平台统一、更加正规和高效。以本文介绍的项目为例，语言是SystemVerilog，平台则基于VMM构建，更有VerificationIP助力，大幅提升了效率。正是因为部件可重用、半台结构化、以覆盖率驱动和高度自动化等特点，验证工作也愈加正规，有流程可循。专门的验证语言，面世已有数年之久。它们出自于传统的纯粹Verilog(有时，部分引入CC+)描述的验证系统，并有很大发展：Vera、e语言和目前已成IEEE标准的SystemVerilog就足这段时期技术创新的成果。面向对象编程(Object-Oriente

4、d Programming)特性，溯其源头便是C+语言。早在纯Verilog语言验证的时代，已有利用C+开发可重用验证代码的做法。工程师们看中的恰是OOP的封装、继承、多态、及可重用等优异特性。验证语言没有相应函数库的支持，语言本身也很难发挥效力。举一个大家熟知的例子，视窗(Windows)编程中，使用C语言直接调用视窗系统的编程接口(APT)实现，是较为传统的做法，可目前却鲜有视窗程序员这样应用。为什么?工作量巨大，需维护的信息太多，从窗口尺寸，菜单列表，到程序算法，都要加以考虑。因而作为解决方案之一的微软基本库(MFC)才得以大行其道。与之相得益彰的是，C+作为微软基本库的描述语言，也随视

5、窗系统的传播，广为流行开来。现代芯片验证领域，无例外地也出现了类似状况。大量新方法、新模型、新类库，不断涌现，减轻了验证工程师们重复开发底层代码的负荷，将更多精力投入到实际项目上。这一套新思路中，主要构成部分便是验证语言(如Vera、SystemVerilog)、验证基本库(RVM、VMM)，和相应的验证模型(Verification IP)。3VMM的应用VMM不仪是方法学，更是该方法的具体实现。它包括一系列的类库(class library)、类对象(ob-ject)联接关系，以及用户定制的代码。如图1所示的测试平台中，各部件(component)，或即对象，是VMM基本类扩展类的实例化(

6、Instantiate)。所涉及到的VMM基本类有vmm_xactor、vmm_scenario_gen和vmm_data等。联接各部件，构成一个整体还需要其他一些基本类，包括vmm_env、vmm_channel以及vmm_xactor_callbacks等。除此之外，用户要根据芯片的实际状况，添加或修改约束条件(constraint)、接口联线(interface)、执行步骤、覆盖率定义和自动比对机制(au-to-check)。3.1 背景该种类型的验证平台充分利用了软件工程的成果，将整个测试平台按照所实现的功能，分门别类予以切割，实现各模块独自开发、分别维护。目前，芯片规模趋于庞大，协议

7、愈形复杂，通常要传递海量数据，并拥有数目繁多的端口。如果还以先前纯Verilog的方式建立验证系统，将很难满足芯片开发、投片的进度。极而言之，简单地激励DUT输入端口、监控相应的输出端口和编写临时性的代码来做数据比对，这种验证方法已相当落后了。当然，我们也看到：对某些结构简单的芯片还有一定市场，纯粹Verilog语言的验证平台也可以做到非常复杂(但是，很难维护)，并且学习面向对象编程的代价容易令人望而却步。但这些都是主流之外的个例，故对此本文不深入展开。现代验证系统，尽管包含数量众多的模块、多样的数据类型协议及各模块间复杂的信息传递(保持同步、共享数据等)，它仍然是继承传统方法，归纳以往的验证

8、经验，依照惯常的步骤建立测试平台。VMM方法也概莫能外。依照通常的流程，它为所有应用VMM的测试平台，设定了九个步骤，定义在 vmm_env 中 ：gen_cfg、build、reset_dut、cfg_dut、start、wait_for_end、stop、cleanup和report。另一方面，VMM平台的架构，按抽象层次划分，由以下部件组成：测试例(test)、场景发生器(gen-erator)、驱动部件(driver)、监控部件(monitor)、数据比对部件(scoreboard)、数据对象(data objects)、数据传输管道(channel)、回调函数集(callbacks)

9、、配置总集(dut_cfg与sys_cfg)、覆盖率统计部件，和联接并集成以上所有部件的环境对象(environmentobject)，如图2所示。VMM中各个部件的使用，可参看Synopsys与ARM共同出版的手册。3.2 评估标准本所此前的验证工作均采用高级验证语言ve-ra，使用SystemVerilog则是第一次。VMM方法的引入，究竟能在多大程度上提高验证效率?该项目既是实际工作，又是一次评估。我们设定预期值是基于以下几点考虑：(1) 建立一个范例平台，包含简单的数据交易、自检测、覆盖率统计，需要多长时间?(2) 可扩展性，即随机测试向量的约束条件更改、自动比对机制按需求定制、功能覆

10、盖点的添加及AXI协议的监控是否完备。(3) 验证流程可控性，如在已有的九步骤中插入额外动作；通过系统配置的改变，来控制各步骤执行的顺序和次数(比如一次reset多次cfg_dut以实现在线重复测试)。(4) 易用性也应当考虑在内。毕竟，VMM方法涵盖的内容很广，工程师们要完全掌握仍有个过程。在无法知其所以然的时候，能不能很快地知其然，并开展工作，显得非常重要。后文的叙述，都将围绕着这几方面展开。4 AXI-VIP的集成如前所述，VMM方法具备抽象分层结构、有九个执行步骤等优点，但它只是一个通用的方法，能否符合前面提出的四点判定标准，还是问题。举例来说，计算所的AXI主设备(master)仿真

11、模型，是以Verilog编写的，无法在短期内实现与VMM平台的互联；完整的AXI协议检测，对本所第一颗基于该总线的片上系统，显得尤为重要；由于时间仓促，AXI仿真模型还有待修正。这些都是项目进程中无法回避的问题，而VMM方法本身又没有提供解决方法。4.1 商用验证模型AXI验证模型(VIP)是Synopsys公司的商用模型，可配置，数据交易严格符合AXI协议，具备完整的协议检查功能。最重要的一点是，AXI-VIP提供与VMM平台的接口。实际上，这个VIP本身就实现了VMM平台的驱动部件(Driver)加监控部件(Monitor)的功能：向下层是与DUT通过端口相联，向上层则有基于vmm-cha

12、nnelvmm_xactor_callbacks的数据传输管道。如图2所示，除Test、Generator、和Scoreboard之外的部分，AXI-VIP都已实现。这个商用模型对开发进度的实际贡献，将取决于工程师能否快速上手。换言之，VIP的易用性决定了它的价值。有鉴于此，Synopsys公司提供一个基于AXI-VIP的VMM范例。其中，DUT部分以AXI Bus VIP替代，TB部分实现了如图2所示的分层架构。工程师作为用户，只需做如下修改，便能得到包含有简单数据交易、自检测、覆盖率统计等功能的验证平台：(1) 替换DUT，并修改接口信号名；(2) 改写测试例test_1的约束条件，得到自

13、己的测试例；(3) 增加对DUT的配置操作。上述工作于一天内完成，仿真输出结果有波形文件、Log文件、及覆盖率报告。4.2 AXI-VIP支持的类AXI VIP定义的类，都有相同的前缀名“dw_vip_axi”，它们构成vmm_env当中的大部分：这些类将例化产生主设备部件、从没备部件、监控部件、配置对象、数据对象、和数据传输管道等等。它们有着各自的变量、函数，提供了丰富的控制功能，涵盖所有类型的操作。功能的完备并未损害AXI-VIP的易用性，这点在项目中得到了印证。通过三天的培训与实做，工程师们能够通过“修改约束条件来随机产生测试向量”，按照芯片测试规范改写“自动比对机制”，添加“功能覆盖点

14、”，并利用AXI监控部件“自动检查协议”并收集与AXI协议相关的覆盖率。这当中，按照芯片测试规范改写“自动比对机制”没有现成的VMM基本类可用。我们是从Synopsys提供的简单范例人手，利用AX-I-VIP提供的回调函数集，获取数据交易信息，并实时地比对流出与流入数据。如同其他的验证系统，这部分工作是最多样化，也是最为核心的任务，所以占用三天当中的大部分时问，也在意料之中。我们在下一节中简单介绍本项目“自动比对机制”的实现。5基于VMM的Scoreboard实现本所验证组以VMM方法为指导，利用AXI-VIP提供的回调函数集，快速建立了该测试平台的自动比对机制。尽管还不能最终应用在十几个主从

15、设备的全系统中，但是，由于这部分代码封装在自定义的Scoreboard类当中，可重用，可扩展，并且符合VMM平台的接口要求，可以很方便地合入将来的系统中。该Scoreboard类的核心部分SystemVerilog代码由Synopsys提供，如图3所示。左端是主设备数据缓冲及比对，右端为从设备数据缓冲及比对，中间的1到N和N到1转换，实现数据比对任务的分配。N个从设备的比对代码，都扩展自相同的类。正因为这种设计它是可无限扩展的。基于本项目只有两个主设备的特点，我们对左边的结构做了大幅度简化。核心的比对部分之外，关键任务就是实时地获取各主从没备的数据流。这在AXI-VIP(也包括Synopsys

16、公司的其他VIP)中，已经有现成函数可用。本所工程师在两天时间内就学会使用，并结合实际完成了代码的开发与调试。AXI-VIP包括主设备、从设备、与监控设备。它们在数据交易的几个关键点将得到一次函数回调(callback)的机会，如表1所示。依据这些回调函数对应的数据交易阶段，我们选取主设备的post_input_channel_get、从设备的pre_output_channel_put两函数来获取交易数据。其他函数也可以用来获取数据，如监控设备的pre_activity_channel_put，就可以得到输入、输出两方面的数据。具体请参看AXI_VIP使用手册。另外，VMM回调函数还可以用于控制验证流程、插入错误数据等等，限于篇幅，本文不再展开。6 结语因为芯