哈哈，转一篇非常不错的文章，在网上找了很久，很少有VMM实质有用的东西，个人感觉还是http://www.edacn.net/bbs/index.php上的资料更多一点，有兴趣的可以看看，哈哈这篇文章也不错，说不准下一个项目就用他喽～～
芯片验证越来越像是软件而不是硬件工作，这点已逐渐成为业界的共识。本文以软件工程的视角切入，分析中科院计算所某片上系统(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)、数据对象(data object)、数据传输管道(channel)、回调函数集(callback)、配置总集(dut_cfg与sys_cfg)、覆盖率统计部件，以及联接并集成以上所有部件的环境对象(environment object)，如图2中所示。
图2：在测试平台中使用验证IP可大为降低工作量。
VMM中各个部件的使用，可参看Synopsys与ARM共同出版的手册。
2. 评估标准
该研究所之前的验证工作均采用高级验证语言Vera，使用SystemVerilog则是第一次。VMM方法的引入，究竟能在多大程度上提高验证效率？该项目既是实际工作又是一次评估。
我们设定预期值，是基于以下几点考虑：
a. 建立一个范例平台(包含简单的数据交易、自检测、覆盖率统计)需要多长时间？
b. 可扩展性，即随机测试向量的约束条件更改、自动比对机制按需求定制、功能覆盖点的添加及AXI协议的监控是否完备。
c. 验证流程可控性，如在已有的九步骤中插入额外动作；通过系统配置的改变，来控制各步骤执行的顺序和次数(比如一次reset多次cfg_dut以实现在线重复测试)。
d. 易用性也应当考虑在内。毕竟，VMM方法涵盖的内容很广，工程师们要完全掌握仍有个过程。在无法知其所以然的时候，能不能很快地知其然，并开展工作，显得非常重要。
后文的叙述都将围绕着这几方面展开。
AXI-VIP的集成
如前所述，VMM方法具备抽象分层结构、有九个执行步骤等优点，但它只是一个通用的方法，能否符合前边提出的四点判定标准还成问题。举例来说，计算所的AXI主设备(master)仿真模型是以Verilog编写的，无法在短期内实现与VMM平台的互联；完整的AXI协议检测，对本所第一颗基于该总线的片上系统显得尤为重要；由于时间仓促，AXI仿真模型还有待修正。这些都是项目进程中无法回避的问题，而VMM方法本身又没有提供解决方法。
1. 商用验证模型
AXI验证模型(VIP)是Synopsys公司的商用模型，可配置、数据交易严格符合AXI协议，具备完整的协议检查功能。最重要的一点是，AXI-VIP提供与VMM平台的接口。实际上，这个VIP本身就实现了VMM平台的驱动部件(Driver)加监控部件(Monitor)的功能：向下层是与DUT通过端口相联，向上层则有基于vmm_channel/vmm_xactor_callbacks的数据传输管道。如图2所示，除Test、Generator和Scoreboard之外的部分，AXI-VIP都已实现。这个商用模型对开发进度的实际贡献将取决于工程师能否快速上手。换言之，VIP的易用性决定了它的价值。
有鉴于此，Synopsys公司提供一个基于AXI-VIP的VMM范例。其中，DUT部分以AXI Bus VIP替代，TB部分实现了如图2所示的分层架构。工程师作为用户只需做如下修改，便能得到包含有简单数据交易、自检测、覆盖率统计等功能的验证平台：替换DUT，并修改接口信号名；改写测试例test_1的约束条件，得到自己的测试例；增加对DUT的配置操作。上述工作于一天内完成，仿真输出结果有波形文件、Log文件及覆盖率报告。
2. AXI-VIP支持的类
AXI- VIP定义的类都有相同的前缀名“dw_vip_axi”，它们构成vmm_env当中的大部分：
a. dw_vip_axi_master_rvm；
b. dw_vip_axi_slave_rvm；
c. dw_vip_axi_monitor_rvm；
d. dw_vip_axi_master_transaction_scenario_gen；
e. dw_vip_axi_port_model_configuration；
f. dw_vip_axi_system_model_configuration；
g. dw_vip_axi_master_transaction_channel；
h. dw_vip_axi_slave_resp_transaction_channel；
i. dw_vip_axi_monitor_transaction_channel。
这些类将例化产生主设备部件、从设备部件、监控部件、配置对象、数据对象和数据传输管道等等。它们有着各自的变量、函数，提供了丰富的控制功能，涵盖所有类型的操作。
功能的完备并未损害AXI-VIP的易用性，这点在项目中得到了印证。通过三天的培训与实做，工程师们能够通过"修改约束条件来随机产生测试向量"，按照芯片测试规范改写"自动比对机制"，添加"功能覆盖点"，并利用AXI监控部件"自动检查协议"并收集与AXI协议相关的覆盖率。
这当中，按照芯片测试规范改写“自动比对机制”没有现成的VMM基本类可用。我们是从Synopsys提供的简单范例入手，利用AXI-VIP提供的回调函数集，获取数据交易信息，并实时地比对流出与流入数据。如同其他的验证系统，这部分工作是最多样化，也是最为核心的任务，所以占用三天当中的大部分时间，也在意料之中。
基于VMM的Scoreboard实现
本所验证组以VMM方法为指导，利用AXI-VIP提供的回调函数集，快速建立了该测试平台的自动比对机制。尽管还不能最终应用在十几个主/从设备的全系统中，但是，由于这部分代码封装在自定义的Scoreboard类当中，可重用、可扩展，并且符合VMM平台的接口要求，可以很方便地合入将来的系统中。该Scoreboard类的核心部分SystemVerilog代码由Synopsys提供，如图3所示。
图3：自检测单元的结构框图。
左端是主设备数据缓冲及比对，右端为从设备数据缓冲及比对，中间的1到N和N到1转换，实现数据比对任务的分配。N个从设备的比对代码，都扩展自相同的类。正因为这种设计它是可无限扩展的。基于本项目只有两个主设备的特点，我们对左边的结构做了大幅度简化。
核心的比对部分之外，关键任务就是实时地获取各主/从设备的数据流。这在AXI-VIP(也包括Synopsys公司的其他VIP)中，已经有现成函数可用。本所工程师在两天时间内就学会使用，并结合实际完成了代码的开发与调试。
AXI-VIP包括主设备、从设备与监控设备，它们在数据交易的几个关键点将得到一次函数回调的机会，如表1所示。
表1：回调函数与相应管道的对应关系表。
依据这些回调函数对应的数据交易阶段，我们选取主设备的post_input_channel_get，从设备的pre_output_channel_put两函数来获取交易数据。
其它函数也可以用来获取数据，如监控设备的pre_activity_channel_put，就可以得到输入、输出两方面的数据。具体请参看AXI-VIP使用手册。另外，VMM回调函数还可以用于控制验证流程、插入错误数据等等，限于篇幅，本文不再展开。
本文小结
因为芯片验证工作的趋势是需要更多的软件知识和技巧。本文以中科院计算所的SoC项目为例，讲解了如何充分利用专业的验证语言基本库和商用的仿真模型快速建立测试平台。文中详细介绍了各部件的使用和AXI-VIP对象如何纳入VMM框架，以及这样做的实际意义。
VMM方法基于SystemVerilog语言，提供了完整的函数库，而作为补充的AXI-VIP，功能完备且易用性强。基于这一新方法，本所验证组工程师在五个工作日内快速建立了一套可方便扩展的测试平台。建立新系统的过程中，发现一个设计的漏洞，充分体现了该方法的高效性。
张珩
中科院计算所
辜帆
Fan.Gu@synopsys.com
Synopsys公司
转自：http://www.eetchina.com/ART_8800464445_480301_TA_3efd022a.HTM
点击此处查看原文 >>
系统分类:
CPLD/FPGA | 用户分类:
| 来源:
整理