新闻中心

EEPW首页 > 测试测量 > 设计应用 > VMM验证方法在AXI总线系统中的实现

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

作者:时间:2012-06-29来源:网络收藏

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

本文引用地址:http://www.eepw.com.cn/article/193663.htm

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

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

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

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

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

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

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

的应用

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

11.jpg

图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中所示。

22.jpg

图2:在测试平台中使用验证IP可大为降低工作量。

VMM中各个部件的使用,可参看Synopsys与ARM共同出版的手册。

2. 评估标准

该研究所之前的验证工作均采用高级验证语言Vera,使用SystemVerilog则是第一次。VMM方法的引入,究竟能在多大程度上提高验证效率?该项目既是实际工作又是一次评估。

我们设定预期值,是基于以下几点考虑:

a. 建立一个范例平台(包含简单的数据交易、自检测、覆盖率统计)需要多长时间?

b. 可扩展性,即随机测试向量的约束条件更改、自动比对机制按需求定制、功能覆盖点的添加及协议的监控是否完备。

c. 验证流程可控性,如在已有的九步骤中插入额外动作;通过系统配置的改变,来控制各步骤执行的顺序和次数(比如一次reset多次cfg_dut以实现在线重复测试)。

d. 易用性也应当考虑在内。毕竟,VMM方法涵盖的内容很广,工程师们要完全掌握仍有个过程。在无法知其所以然的时候,能不能很快地知其然,并开展工作,显得非常重要。


上一页 1 2 3 下一页

评论


相关推荐

技术专区

关闭