VMM验证平台

VMM验证平台（精选6篇）

VMM验证平台 第1篇

当前集成电路设计规模越来越大,复杂度也急剧增长。对验证提出了巨大挑战,验证已成为芯片设计的瓶颈,验证工作可占整个芯片设计70%的工作量。目前验证方法主要有仿真验证和 FPGA验证。FPGA验证在此不作讨论。仿真验证就是利用专门的EDA工具对用RTL描述的电路(DUT)施加各种激励,通过检查DUT的响应,来判断其功能的正确性。仿真验证可分为两个阶段:前仿和后仿。本文要讨论的是前仿,也称为功能仿真。目前业界大多采用的前仿真流程可分为单元仿真(UT),集成仿真(IT),系统仿真(ST)三个阶段。UT是指对单一模块内部功能的仿真;IT是对多个相关模块组成的子系统仿真;ST则是对整个芯片进行仿真。当前芯片设计规模的庞大,单元模块数动辙几十上百甚至上千,而且还嵌入了IP,同一模块也可能例化多个,因此决定各阶段搭建的平台必须具有可重用性,以减少大量的重复工作。芯片的各个UT环境作为IT环境的组件,各IT环境又作为整个ST环境的组件,这样层层复用的思想已被业界广泛应用。

1 VMM验证平台

VMM(Verification Methodology Manual)是一种基于 SystemVerilog的验证方法学,同时也是包含了搭建一个验证环境需要的基本类(class)所组成的类库的验证平台,包括激励、 事务(transaction)、通道(channel),记分板(scoreboard),基本环境等组件。这些组件都对应vmm.sv库中一个基本类。基于SystemVerilog具有面向对象的特点,在搭建验证环境时需要根据实际项目验证环境的需求调用VMM库中的基本类,然后作相应的扩展(extend)实现所需要的功能。

VMM类库中常用的基本类有vmm_data,vmm_channel,vmm_xactor,vmm_env等。vmm_data是所有事务描述符和数据模型的基础,提供仿真激励基本的操作。vmm_channel提供各种组件接口机制,可以在各个组件间传递扩展自vmm_data任意数据类型,在 VMM验证平台 <vmm_data>_channel操作可以直接实现各组件间传递数据激励。vmm_xactor是所有事务处理的基础,包括总线功能模型(BFM)、监视器、 发生器,提供了一套标准的控制机制。vmm_env是实现验证环境的基本类,采用九步顺序执行机制 gen_cfg、 build、 reset_dut、cfg_dut、 start、wait_for_end、 stop、cleanup、report,所有事务都在vmm_env生成例化并且将实例按照验证模型连接,在vmm_env框架中运行。本文所述的重用机制,vmm_subenv起重要作用,它扩展自vmm_env类,具有vmm_env类的属性,是环境组件化的基础,其实体可例化在上层环境中,以实现重用。

2 基于 VMM的验证架构

从图1可以看出VMM推荐的层次化验证平台从底至上被分成信号层、命令层、功能层、场景层以及测试层。其中的验证组件包括发生器、交易器、驱动器、监视器、检查器、记分板以及断言。

3 基于VMM可重用验证环境实例

本实例为接入交换机芯片。该芯片是基于存储转发原理实现,具有24个FE口和1个utopia level 2口作为接入口,上行具有2个支持1 G速率的GE口,支持Ethnet 与ADSL接入,支持以太网协议,PPP协议和vlan,其架构如图2。

本芯片为典型的SOC架构,主要分为两部分:业务处理子系统(SPS)和嵌入CPU子系统(ECS);其中ECS主要由ARM926核、AHB总线、APB外设(看门狗,UART,定时器),AHB总线与APB总线通过AHB2APB桥连接。SPS主要由包交换引擎(PSE)、各接口模块、缓存管理模块(BM),CBUS总线组成。PSE通过cbus2ahb桥连接,以便CPU对SPS中的寄存器和表项进行配置和管理。由于本芯片是基于存储转发原理,各端口进来的报文通过BM统一传送给DDR控制器(DDRC)再存入DDRAM。其中ECS内部各模块都为成熟IP,因此验证工作主要集中在SPS各模块。

3.1 UT环境搭建步骤和方法

为了重用,UT环境必须遵循以下原则。第一、各UT环境中各组件间传递的数据必须定义成统一的类;第二、UT环境做成subenv的形式。对于第一点,以utopia UT环境为例,伪代码如下:

这个统一的类就是top_pkt,本身只是个外壳,其内部例化各UT环境中用到的数据格式,以便使用同一种channal在各UT环境中进行无缝传输。各UT环境的搭建,伪代码如下:

c_utp_cfg配置类定义环境中各组件开关,可以根据实际需要开/关各验证组件。各组件和配置类在subenv中例化,c_utp_subenv类最终在UT环境中例化,总体架构如图3。

3.2 IT环境搭建步骤和方法

本例的IT环境以各UT环境为组件,各UT的subenv类都不需要改动而直接重用。IT环境要做的只需将各UT的subenv类例化,DUT有多个相同的模块也只要将同一个类例化多个,然后根据DUT内部各模块的连接关系将各UT的RM连接起来组成IT的RM。本例中分为两个IT,业务处理子系统(SPS),ARM子系统(ECS)。ARM子系统包括的ARM核和amba3.0总线是比较成熟的IP,不在IT中独立验证。SPS中具有 utp_subenv,fe_subenv,ge_subenv,pse_subenv,bm_subenv等组件。各subenv都在SPS环境中例化,其内部组件重新进行合理连接。SPS IT环境架构如图4。

如图4所示,IT中的generator,channel,interface,BFM,checker等组件都是重用自各UT相应组件,各UT的RM按实际芯片要求连接形成IT的RM,除此之外只需例化整个芯片顶层到IT环境中。

3.3 验证过程及结果

UT验证阶段:本例三个接口模块FE/GE MAC,utopia和DDRC都是采用成熟的IP,在UT中不验证。UT重点验证PSE,BM模块。以BM为例,BM的UT环境和图3类似,编写激励BM_GEN,它与DUT(BM)有两个接口,一个申请缓存接口,另一个为释放接口;BM_GEN模拟生成大量的申请和释放请求,通过REQ_BFM和RLS_BFM转化为底层的时序信号来驱动DUT。需要重点验证的是申请的地址最终是否得到释放以及BM的带宽。这两点可通过编写一个CHECKER来实现,在CHECKER中有队列存储申请和释放的地址和长度,同时记录仿真时间,到仿真结束时比较两队列的数据,统计申请和释放的带宽。

IT验证阶段:由于PSE和BM在已在UT阶段中开发了subenv式的UT环境,在IT环境中可直接例化各组件,因此IT只需开发GE/FEMAC,utopia等接口模块的generator,rm,bfm及subenv,节省大量的工作量。各模块子环境按图4连接组成IT环境。各模块接口之间挂有monitor用来收集数据,将收集到数据和相应的RM输出数据比较便可方便的定位DUT的问题。本例代码行数统计见表1及表2。由统计数据可算出IT代码重用率达到54%。

4 结束语

本文在大规模集成电路设计中验证成为设计的瓶颈的背景下,以一款接入交换机芯片为例,提出了基于VMM subenv组件重用的验证方法,该方法在实际应用中表明,能够大幅减少工作量,提高验证效率。

参考文献

[1]Michael K,Pierre B.Reuse methodology manual for system on Chip designs.3rd ed.Boston:Kluwer Academic Publishers,2002:239—263

[2]Bergeron J,Cerny E,Hunter A,et al.Verification Methodology Manual for System Verilog.New York:Springer US,2005:231—254

[3]Spears C.System verilog for verification.New York:Springer US,2006:138—192

[4]徐英伟,刘佳.SoC功能验证的特点和方法.微处理机,2006,28(2):11—13

[5]杜宁,郑建宏.一种可重用的SOC验证平台.微计算机信息,2008,24(2):56—58

VMM验证平台 第2篇

航空发动机传感器故障诊断设计与验证综合仿真平台

针对航空发动机传感器故障诊断算法无法快速和高效地完成硬件在回路仿真问题;提出了基于虚拟仪器语言与快速原型化技术的航空发动机传感器故障诊断硬件在回路仿真方法,并研制了基于该方法的硬件在回路实时仿真平台;经过实验验证后,该平台不仅为发动机传感器故障诊断方法提供了实时仿真平台,同时为扩展本平台使之成为完全的半物理仿真平台奠定了基础,有一定的工程实用价值.

作 者：李睿 郭迎清 吴文斐 Li Rui Guo Yingqing Wu Wenfei 作者单位：西北工业大学,动力与能源学院,陕西,西安,710072刊 名：计算机测量与控制 ISTIC PKU英文刊名：COMPUTER MEASUREMENT & CONTROL年，卷(期)：201018(3)分类号：V233.7关键词：快速原型化 虚拟仪器 故障诊断 仿真平台 航空发动机 rapid prototyping virtual instrument fault diagnosis simulation platform aero-engine

探讨校园网统一验证平台的构建 第3篇

【关键词】中职校 校园网 统一验证平台

【中图分类号】G71 【文献标识码】A 【文章编号】2095-3089（2013）01-0221-02

我校是2009年启动数字化校园建设的，目前在学校中运行着多个应用系统，如办公自动化系统，教务管理系统，财务管理系统，招生管理系统等等。但笔者在日常工作中经常遇到教师因忘记自己的各类密码而要求管理员帮其重设密码和教师反应在多个系统间要多次登录比较麻烦的问题。此次示范校建设，我们通过构建统一校园网验证平台，即单点登录SSO的方法成功解决了上述问题。

一、统一验证平台的构建思想

SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的业务整合的解决方案之一。我们比较了多种方案后，最终采用了SSO方案，教师只需要登录一次系统平台，即通过一个应用中的安全验证后，再访问其他应用中受保护的资源时，不再需要重新登录验证。

二、统一验证平台的具体实现

以下是笔者所在学校各个系统间统一验证平台的构建的具体过程：

1.各应用系统介绍

笔者所在学校的校园网中布署的应用系统有：

（1）信息发布系统（学校网站）；

（2）资源管理系统（资源库）用于管理学校内部的资源（教案、课件、试题、教育教学论文、图片等资源）。未登录用户不能下载和打开相应的资源，只有合法登录的用户才能下载和打开；

（3）学校网络办公系统（OA系统）；

（4）教务管理系统（正方教务系统）；

（5）财务管理系统（国子管理系统）；

（6）招生管理系统（教师自己开发）。

2.配置表信息

在开发单点登录系统之前有些重要信息需要确定，然后写入配置信息表中。我校配置信息表中内容如下：

设置服务器的访问地址。主要是服务器的公共IP地址和站点域名。

设置可以访问的请求IP网段。主要记录该系统单点登录接口可以访问的IP来源。

设置系统模块标记。填写各个系统的编号，主要用于变节管理员查询到该请求来自哪个系统。

设置状态标记。填写True或False，主要方便管理员随时切断单点登录的功能。

3.配置表逻辑结构

4.系统单点登录原理

1）用户通过用户名和密码进入A系统；

2）A系统将配置表中状态为T标记的所有记录读取并打印到前台；

3）当用户点击任意系统后，A系统就会将该用户的编号，以及配置表中的A系统的参数一并通过http协议提交到目的系统中；

4）目的系统则会根据配置表中的REQIP来判断该请求IP是否合法，若合法则继续执行，否则返回错误信息；

5）目标系统只需要到用户表中去寻找该编号对应的用户，并取出其权限，根据相应的权限执行可操作模块；

6）如此反复循环。

5.SSO模式的前提条件

SSO模式需要满足如下条件后才能部署：（1）所有的用户ID要么统一，要么设置匹配规则，我校选择使用教师工号；（2）所有系统必须在配置表中登记真实的信息；（3）所有的系统必须提供接口，用来接收和处理配置表信息的WebServer接口。

6.SSO模式优缺点

SSO模式有很多优点：实施简单，只有短短几行代码执行效率高；安全性高；无需笛卡儿积模式的维护，只要一张配置表即可；扩展性、维护性高；采用即插即用设计原则。同时也存在一些缺点，如对服务器安全性要求较高；旧系统必须有源代码更改权才可加入；目前只限于B/S模式。如何扬长避短需要开发人员不断摸索、不断实践。

7.提高安全性

安全是每个系统最首要的责任，我们采取以下安全措施保证单点登录的安全。

用户在客户端触发，提交到服务器中处理，所有信息都在服务中，非法窥视不到；

服务器之间的跳转也限制了IP，只能由指定的IP才可以访问；

客户端只提供触发功能的Ajax异步执行方法，主要代码在后台服务器上用户无法得知，前端的JavaScript代码只提供了访问服务器接口的功能和仅有的目的系统编号参数；

JS代码与html代码分离在两个文件中，并且服务器过滤了请求IP，非本地IP禁止下载JS文件，而且本地IP还要密钥才能访问，大大提高了安全性；

每个用户的权限都在相应的系统中分别设置，避免其中一个系统的管理员被攻击从而使整个架构陷于危难之中；

所有的共用信息都通过加密算法处理后再传输、存储的，避免管理员有意识的获取；

从系统到模块甚至到用户都有很便捷的开关功能，可以及时的切断危险源。

三、统一验证平台构建的思考

随着网络信息化技术在我国职业学校校园网络中的高速发展及应用，学校门户平台需要及时整合各类信息资源。笔者根据目前学校中电子校务实际运用中存在的信息孤岛问题，研究了单点登录技术的原理及实现方法。由于水平和时间的限制，以及随着对相关理论和开发的深入，还有待于继续努力。

通过此次开发，笔者所在的学校切实解决了教师以往要记住各个系统间的帐号与密码和各个系统要多次登录的问题。方便教师日常的教育、教學工作，进一步提高了教师的工作效率。实现了学校各个系统间用户的统一管理，减轻了系统管理员的工作负担。

参考文献：

[1]Web环境下的SSO实现模式的研究 张挺； 耿继秀 计算机仿真 2005-08-30

[2]基于RBAC的SSO统一权限管理方法 张世龙； 沈玉利 计算机工程与设计 2009-05-16

VMM验证平台 第4篇

现代集成电路芯片的设计规模越来越大,对其功能验证的要求也随之不断提高,原有的一些验证手段已不能满足日益复杂的芯片的验证需求。为了摆脱这个困境,EDA厂商相继推出一些新的验证手段和概念,如受限随机(constrainedrandom),断言(assertion),功能覆盖率(functional coverage)等等。本文以EMI模块验证环境的搭建为例,介绍了VMM验证组件和一些相关的验证技术,如Synopsys公司推出的基于VMM的寄存器抽象层验证技术和方案,简称RAL(Register Abstraction Layer)[1]。该技术是Synopsys针对芯片验证中如何简便、高效地完成寄存器/存储器相关的验证任务而开发的解决方案,可以在VMM的验证环境中非常方便地集成和重用。

在验证平台的搭建过程中,如何产生随机向量是工程师需要仔细考虑的问题。传统的方法是手工编写测试激励,这种方式工作量大而且不便于修改,难以达到覆盖率的要求。当前验证领域的主流是:采用基于事务的受限随机产生器来产生测试向量[2]。本文详细地介绍了如何基于VMM来搭建一个具有层次化、自动化、抽象化和可重用性的验证平台。

1 VMM验证方法学介绍

VMM验证方法学是一种基于事务的、层次化的验证方法学。它通过分层结构的思想把验证平台的搭建抽象到更高的层次,平台的层与层之间既相互联系又具有一定的独立性,使得验证平台在不同的项目之间使用时,即使改变某一层的功能也不会影响其他层的重用。这样极大地提高了验证的重用性。

VMM验证平台可分为5层。Signal Layer(信号层)主要处理验证平台与DUT的信号连接;Command Layer(命令层)主要是把数据驱动进DUT并检测从DUT出来的数据流;Functional Layer(功能层)主要负责协议的处理和对反馈数据的比较;Scenario Layer(场景层)主要是用来随机产生一系列的事务对象;Test Layer(测试层)主要是用户定义的test-case(测试案例),它用来启动和控制整个验证平台,定义激励的发生次数,协调不同事务之间的同步,以及直接测试例的构建等。

2 外部存储器接口

EMI模块的功能是为外部存储器提供读写接口,通过接收符合AHB总线规范的数据传输请求,完成地址译码,产生片选信号以及读、写控制信号,完成总线和外部存储器的数据传输。如图2所示,EMI分为两大子模块:HIU子模块(AHB总线接口单元)和MIU子模块(存贮器接口单元)。片外存储器包括:SRAM,SDRAM,NAND FLASH。

3 基于VMM的EMI模块级验证平台

3.1 EMI验证平台的架构

图3 EMI模块级的验证平台架构(参见下页)

图3为本文中EMI模块所采用的验证平台架构,它是图1中VMM层次化结构平台的具体实现。

下面将从寄存器验证和功能验证两个方面来解析整个验证平台的搭建,及各个组件的作用。

3.2 寄存器级的验证

3.2.1 验证组件介绍

(1)RAL模型(RAL Model):封装了DUT中寄存器/存储器的一切描述信息,是DUT中的寄存器/存储器在验证环境中的映射,它为寄存器保存、维护镜像值。

(2)RAL处理器(RAL Transactor):负责把RAL Transaction转换为Command Layer Transaction并将其传递给Command Layer中的BFM。

(3)RAL访问管理器(RAL Access):负责管理RAL Mode与RAL Transactor之间的交互,它将RAL Model中的操作封装为一个RAL Transaction并传递给RAL Transactor,然后根据这个Transaction完成后的结果或状态,更新RAL Model中的数据信息。

(4)Master 1:是AHB VIP提供的主设备(Master),模拟了AHB总线上的主设备行为,通过设置约束条件,产生随机事务,把EMI的工作场景模拟了出来。

(5)BUS:是AHB VIP提供的总线模型,模拟AHB的总线,用于决定主设备的总线访问权,选择总线传输的从设备(Slave)。

(6)Monitor:是AHB VIP提供的监控器(Monitor),进行AHB协议的监控检查,自动检查总线协议,组件4、5、6均可在验证环境中配置。

3.2.2 验证流程介绍

测试案例对RAL Model进行的操作,最终会映射为对DUT内寄存器/存储器的操作。RAL Access把这种操作封装在RAL Transaction中,并将其传递给RAL Transactor;RAL Transactor又将这个Transaction翻译为Command Layer的Transaction,传递给BFM;BFM根据DUT的接口协议和时序,对这个Transaction进行解析并驱动DUT接口上的信号,从而实现对EMI内部寄存器/存储器的存取访问;RAL Access根据这个操作的结果和状态,维护RAL Mode中的数据信息。

3.3 EMI的功能验证

3.3.1 验证组件介绍

(1)基元产生器(Atomic generator):每次产生单独的一个受约束(constraint)的随机数据对象(data object)或者事务对象(transaction),可以通过使用VMM预定义的宏`vmm_atomic_gen来创建。

(2)场景产生器(Scenario generator):每次产生一串受约束的随机数据对象或事务对象,可以通过使用宏`vmm scenario_gen来创建。

(3)记分板(Scoreboard):实现输出值与期望值之间的自动比对,并给出了相关的比对信息,减轻了验证人员繁重的劳动。

(4)功能覆盖率模块(Coverage):定义了一系列的功能覆盖点,在运行验证平台时,功能覆盖模块会自动在这些点进行采样,并统计出一个覆盖率报告,使验证人员清楚哪些覆盖点还没有覆盖到,从而能不断完善验证环境和测试案例,以达到覆盖到所有覆盖点的目标。

(5)Master1、Master2、BUS和Monitor介绍同上。

3.3.2 验证流程介绍

在测试案例中,把事先经过约束的基元产生器事务和场景产生器事务分别装载到基元产生器和场景产生器中。然后基元产生器和场景产生器会对各自的事务进行随机化,并把产生的事务分别传给Master2和Master1,两个Master开始竞争总线,获得总线的Master把事务驱动到总线bus上,bus总线会根据EMI的协议,把总线事务解析成符合协议要求的信号去驱动EMI的引脚,并通过EMI完成与外设的交互。

4 验证结果

(1)发现AHB总线在对EMI作WRAPn写操作时,如果AHB总线上出现长时间的busy周期,EMI工作就会出现错误。后来设计人员对RTL代码进行了修正;

(2)如图4所示各项覆盖率均达到了100%。

(3)总的覆盖率达到了100%;

5 结束语

笔者在VMM验证方法学的指导下用较短的时间搭建了EMI模块级的验证平台,并采用基于VMM的寄存器抽象层验证技术,简便、高效地完成了对EMI模块寄存器存储器相关的验证,然后通过对基元发生器和场景发生器施加约束,产生受约束的随机化激励,对MEI进行了功能方面的验证,提高了验证的效率,缩短了项目的开发周期。

摘要：本文首先介绍了VMM层次化验证方法学的基本思想和方法,将其与传统的芯片验证技术进行了对比,并进一步对基于VMM(Verification Methodology Manual For System Verilog)方法学的验证平台结构和各个组成模块进行了详细的介绍。最后以外部存储接口(EMI)模块为例对VMM验证平台的搭建进行了具体说明,并给出了验证结果。

关键词：VMM,验证平台,验证组件

参考文献

[1]方颖立.基于VMM的寄存器抽象层验证[J].电子设计技术,2007(8):103-104,106-107.

[2]杨鑫,徐伟俊,陈先勇,等.SystemVerilog中的随机化激励[J].中国集成电路,2007,(7):58-62.

[3]Bergeron J,Cerny E,Hunter A,et al.Verification Methodology Manual for System Verilog[M].New York:Springer Science,2005.

[4]IEEE Std1800TM-2005IEEE Standard for System Verilog--Unified Hardware Design,Specification,and Verification Language[S].

[5](Verification Methodology Manual Tutoria1)2006.6Synopsys Inc

基于VMM实现的网络接口验证 第5篇

随着设计规模的不断扩大,设计的复杂度也呈指数级上升,从而验证工作的难度也越来越大。业界普遍认可当前验证工作已经占到了整个项目工作量的70%以上。与之相对应的,前期的RTL代码验证也愈来愈重要,对于大规模SoC设计如果在回片测试中发现重大缺陷意味着巨大的时间损失与金钱损失。大量的经验表明全面细致的RTL代码验证可以及早发现代码中隐藏的缺陷,极大缩短项目开发周期,降低项目开发的后期风险。

模拟验证使用计算机软件模拟RTL级电路的运行,易于实现各种复杂的应用场景,并可生成精确的仿真波形,是各种验证方法中最直接、发现缺陷最快的,并且模拟验证还可以在代码编写阶段与设计人员配合实现迭代开发。尽管FPGA仿真验证与形式验证凭其优势已在验证工作中占有了一定的地位,但是模拟验证始终是验证工作中最重要的组成部分。同时业界也一直为提高模拟验证的效率进行着验证方法学的研究。

作者承担的验证工作是验证一款网络芯片中支持Utopia Level2[1],GMII[2],Posphy Level2三种网络接口协议与芯片私有特性的网络接口模块。网络侧接口是网络芯片中重要的组成部分,其对网络协议的支持直接决定了一个网络芯片的成功与否。网络协议一直在不断被更新,网络芯片也在不停随之升级。本文的工作正是基于以上前提实现了一个网络侧接口的验证环境,该验证环境的重用性强,不仅支持上述协议,还可以轻松地增加对新协议的支持或对同种协议的升级。在系列芯片开发中使用此验证环境可有效减少后续开发对网络侧接口验证的资源投入。

1 验证架构及实现

1.1 验证环境设计

VMM是Synopsys推出的基于SystemVerilog语言的验证方法学。VMM从以OpenVera语言为基础的RVM发展而来,它的优点是:代码的可重用性强,验证的自动化程度高,可以有效保证验证的质量。VMM验证方法学在当今SoC设计领域已有广泛应用,为ASIC产品项目进度的提升提供了很大的帮助[3]。VMM库包括一系列的标准基本类,主要有vmm_data,vmm_atomic_gen,vmm_xactor,vmm_xactor_callbacks,vmm_channel,vmm_env,vmm_log等。通过对这些基本类的继承与重载,可构造出灵活多样的验证环境。

本文使用VMM实现的验证环境由命令层与执行层两部分组成,如图1所示。

TestCase是命令层的主体,也是验证人员控制仿真如何进行的惟一接口。在TestCase中定义三部分内容:定义随机测试与直接测试,定义验证级别,定义验证方法。

随机测试与直接测试联合使用是一种高效的验证方法[4]。随机测试可以减少人为因素的干扰,能有效提高验证工作的效率和可靠性。随机测试对验证环境提出的要求是既要覆盖全面又要符合设计的规格特性。本文的验证环境使用VMM提供的数据基类(vmm_data)实现数据与事件的约束。下例是对网络协议类型选择的约束实现:

在这个简单的例子中当协议(Spec_Level)确定后,其他的变量都会根据类(Spec_Sel)中定义的约束(Constraint)进一步随机产生。但是此款芯片内部功能的配置参数却是彼此约束,没有一个是绝对独立的。因此简单的约束无法让仿真软件计算出结果,而会陷入死循环。本文的验证环境根据芯片的特性与应用场景定义了一个场景变量Situation_Mode作为强相关参数随机的基础,即根据应用场景确定部分参数,进而再产生所有的参数。随机测试关注是否覆盖到芯片的全部功能特性,而直接测试关注芯片特定功能的性能与设计风险。验证环境中直接测试的思想以传统的时序验证为基础,定义一个Timing_Define基类,这个基类实现时序的抽象描述,验证人员仅需要在TestCase中重载该基类并增加需要的时序段描述即可。这样的实现方式有效减少了验证人员花费在时序编写上的时间。

Command将命令层行为要求转译为执行层的行为实现,由全局配置类Env_cfg与各级行为控制类Env_tranxactor组成。Env_cfg是一个数据类,验证环境中的所有组件在例化时都会被传入这个类,从而在TestCase中实现对整个验证环境的行为控制。

执行层的功能包括激励产生,驱动DUT,监测DUT输出,收集覆盖率信息[5],产生参考数据,检查DUT输出并输出统计数据。执行层的验证方法主要有参考模型比对,断言检查与代码覆盖率统计。在设计代码尚不稳定时主要使用前两种方法,在代码稳定后则加入覆盖率统计并减少断言检查。这样的安排是出于验证效率的考虑,每一种验证方法的使用都需要消耗相应的资源(内存空间与时间)。合理利用有限资源也是验证工程师必须要考虑权衡的。

1.2 参考模型(RM)设计

参考模型是验证环境中最重要的组成部本。本文验证环境中的参考模型使用SystemVerilog实现。SystemVerilog语言简洁,类似于C++,从而可以从较高的抽象级别描述DUT的行为。使用面向对象编写的参考模型具有易封装,代码重用性高与抽象层次高的优点。编写参考模型需要验证人员对DUT的规格特性具备详尽深入的了解,在此基础上验证人员才可以制定出一个高效的验证策略。对于简单的算法与协议类设计可以采用黑盒测试,而对于较为复杂设计则需要采用灰盒测试。

一般的数字电路验证的内容主要为算法与协议。这类验证内容具有很强的可预见性,即已知输入数据与算法或协议便可以计算出DUT的输出。由此计算出的结果可以直接与DUT的输出数据进行一对一的比较,从而验证DUT的正确性。作者所验证的DUT并非一个纯粹的协议与算法电路,其设计规格中存在大量的时序强相关功能,并且这些特性直接影响DUT的稳定性,某些特定的时序条件会使存在缺陷的DUT异常挂死。因此本文的验证环境在参考模型中加入了时序考虑。

参考模型中的时序考虑有两种实现方式:全面覆盖与部分预估。

参考模型根据数据激励与条件约束产生一系列的参考结果保存在比较缓冲区中,比较器将DUT的输出数据与比较缓冲区中的参考结果依次比对,如图2所示。本验证环境使用全面覆盖的方法验证时序敏感元素较少的设计模块,实现这类电路的参考模型计算量较小,生成的参考结果也较少,从而比对的效率高。对于时序敏感元素较多的设计模块若使用全面覆盖的方式会使参考模型的算法复杂度呈指数级增加,需要验证人员为此投入大量的时间,并且生成的参考结果数量也非常庞大。所以本验证环境对于时序敏感元素较多的设计模块采用部分预估的方法实现其参考模型。参考模型仅预估致命性高、出现概率高的结果。这种方法是验证效率、资源消耗与缺陷命中率的折衷。部分预估法根据综合考量后的约束计算出部分参考结果,如果最终DUT的输出结果不在参考结果中则比较器会产生缺陷报告,进而验证人员根据缺陷报告为DUT另外设计直接测试的TestCase。使用部分预估减少了验证人员在编写参考模型时的时间投入,提高了验证效率。

1.3 重用性设计

验证环境的重用性体现在两个方面:一是不同电路设计间的重用;二是模块级到系统级验证的重用[6]。

对于电路设计间的重用本验证环境重点针对网络协议的升级进行了重用性设计,使用VMM层次化搭建验证环境的特性将大部分环境组件设计为完全重用。对于升级的协议或者特别的接口设计,验证环境仅需要对参考模型(RM)、驱动接口和激励生成器(Generator)进行修改,修改方式为从既有基本类派生新类或者通过环境组件中使用vmm_callback定义的task实现新功能的注入。原有的TestCase中除部分针对性的直接测试用例(如时序特性测试用例)外均可以完全重用。

对于模块级到系统级验证的重用,本验证环境从系统级到模块级都设计了统一的数据类型,各模块级的验证环境都采用相同的层次化结构,各模块级的参考模型设计有统一的对外数据通道用于在系统时实现模块级参考模型的级接。在进行系统级验证时只需要把各模块的验证环境例化在一个系统级验证环境内并按层次级联便实现了系统级验证环境。并且此验证环境可以同时支持RTL级仿真与网表级仿真,仅需要在执行方针时定义用于区分的参数即可。

2 验证结果

该验证环境采用覆盖率统计结果作为最终交付条件,其中DUT的行覆盖率达到100%,条件覆盖率达到98%,状态机覆盖率达到100%。

网络接口模块的验证工作包括模拟仿真验证与FPGA仿真测试。国内的验证技术尚不成熟,绝大多数国内公司都把FPGA测试作为产品设计必不可少的质量保证[7]。作者的验证工作结果为:FPGA仿真中发现的设计缺陷仅占所有已发现缺陷的3.4%;使用作者设计的验证环境后实际综合耗时相对于计划用时共节约21%,且所节约时间均为初期预留给FPGA测试所用。在FPGA测试发现的缺陷中仅有一个为规格不明确引入的功能设计缺陷,且可通过软件规避,而其余缺陷均为FPGA测试所使用的Memory模型引入的缺陷。由此可见模拟仿真在功能验证上完全可以取代FPGA仿真测试,节省不必要的时间与人力成本投入。

作者负责验证的网络芯片已经成功流片。在MPW样片测试中,网络接口模块达到零缺陷。另外在Pilot版本的芯片中网络接口模块新增约一倍的新规格,而使用本验证环境,仅使用4周就完成了模块新增特性的验证,之后仅两周就实现了缺陷的收敛。

3 结 语

介绍了基于VMM实现的一个网络侧接口模块的验证环境。该验证环境验实现了DUT的零缺陷交付,并且在后续升级版本中凭借其出色的重用性保证了Pilot版本芯片的交付,节约了宝贵的时间。此验证环境可以作为同类芯片的验证IP使用,对于设计同类系列化产品的团队,使用该验证环境可以有效提高产品的开发效率。

另外FPGA的逻辑单元数量有限,测试大规模SoC芯片需要耗费大量时间与硬件资源。而一个设计完善的模拟仿真验证环境完全可以取代FPGA在SoC芯片开发中的作用,有效提高开发效率,并节约成本。

参考文献

[1]ITU-T.ATM Bounding G.998.1[S].[S.l.]:ITU-T,2005.

[2]IEEE.Std802.3[S/OL].[2006-07-26].http://www.netyi.net/.

[3]BERGERON Janick.Writing testbench using system verilog[M].New York:Springer Science Business Media,Inc.Publishers,2006.

[4]KEAVENEY Martin,MCMAHON Anthony,O′KEEFFE Niall.The development of advanced verification[J].envi-ronment using system verilog,2008(6):47-51.

[5]WU Ying-pan,YU Li-xin,LAN Li-dong,et al.A cove-rage-driven constrant random-based functional verification method of memory controller[C].The19th IEEE/IFIP In-ternational Symposium on Rapid System Prototyping.[S.l.]:The ATM Technical Committee,1995.

[6]侯秋菊,沈海华.IP可重用的AMBA AXI总线验证平台设计与实现[J].计算机工程与设计,2008,29(7):1713-1715,1753.

[7]边计年.集成电路设计验证方法与技术[C]//第五届中国测试学术会议论文集.北京:[出版者不详],2008.

VMM验证平台 第6篇

VMM验证方法学是当今验证方法的趋势之一。它提供一种抽象的具有分层结构的验证平台, 平台中测试数据约束性随机产生, 自动化运行, 功能覆盖率可收集。

VIP是Synopsys公司基于VMT技术开发的验证IP, 用来模拟AMBA总线、USB主机等的通信行为, 它包含总线的BFM模型及monitor模型, 可帮助验证工程师快速构建验证环境。

本文基于VMM验证方法学, 利用AHB、USB VIP构建了USB IP的验证环境。验证平台功能覆盖全面、复用性强、测试用例编写简单, 全面验证USB传输的各种特性, 验证效率高。

1 USB设备控制器的结构

被测模块 (简称DUT) 是一款通用的USB2.0设备控制器, 具有AHB总线接口和UTMI接口。它支持全速、高速传输;除控制端点外, 其它的端点数量可配置, 且每个端点支持批量、中断、同步三种传输方式;支持DMA读写控制;支持测试模式;支持挂起和远程唤醒功能。其结构如下图:

该USB控制器模块实现了两层的功能: (1) 在信号层通过UTMI接口与USB主机互连, 接收和发送USB数据; (2) 在逻辑设备层对总线接口与各端点之间的数据路由, 并将数据及相关端点信息存入寄存器中, 供上一层即功能设备层使用。USB的功能层则由软件来实现, CPU通过AHB总线读写操作端点寄存器及设备寄存器控制USB设备枚举及功能数据流的通信。

2 基于VMM的验证环境

2.1 VMM验证环境简介

VMM验证平台是一个层次化验证平台。一般说来, 从底至上被分为信号层、命令层、功能层、场景层以及测试层。如图2所示。

驱动器 (driver) 将从命令层收到的事务转化为信号激励输入到DUT, 同时收集DUT的输出信号。监视器 (monitor) 用来侦测信号变化, 并转化成事务传给检查器。事务处理器 (transactor) 将场景层定义的抽象的事务转成驱动器能解析的命令。如将一次中断处理分解成读、写寄存器等总线操作。记分板 (scoreboard) 从事务处理器中接收事务, 实现某种算法或做一些处理, 然后将结果存入到检查器中。检查器 (checker) 将从监视器中得到的结果和记分板中的结果做比较, 以检验DUT的功能是否正确。场景层的产生器 (generator) 用来生成具有一定关系的随机列序。最上层是测试层, 用来定义不同的约束条件, 配置各种测试用例。

2.2 AHB、USB VIP介绍

AHB验证模型 (AHB VIP) 是一个能够配置AHB总线系统、数据传输完全符合AMBA2.0 AHB总线协议的模型。在该模型中, 存在主机、从机、总线模型三个角色。主机负责发起传输, 从机负责响应主机。总线模型则是由仲裁器、多路选择器、解码器等互联组成。用于在系统中连接主机和从机。AHB VIP具有兼容VMM平台的接口, 它在VMM平台中起驱动器和监视器的作用。即向下与DUT通过信号接口相联, 驱动总线或响应主机;向上通过通道 (channel) 与事务处理器相连, 接收上层传递的抽象命令, 并转换成总线读写命令。

AHB VIP的使用, 节省了验证工程师编写AHB BFM的时间, 且VIP是经过完全验证的可靠的模型, 正确性有了保证。

USB VIP是Synopsys公司的另一个商用模型。它也是可配置的符合USB协议的验证模型。该模型支持主机、设备两种工作角色, 发起或回应USB总线请求;支持三种工作速度 (低速、全速、高速) ;支持serial/UTMI/ULPI等接口方式;及支持两种时序模式:正常工作模型、仿真工作模式。该VIP可发送协议层 (transaction) 、信号层 (packet) 等不同抽象级别的数据流, 还可在数据流中随机注入错误包以模拟错误通信。此外, 该VIP自带多个回调函数 (callbacks) , 用户可应用这些callback控制数据流向、收集数据等。

USB是分层协议, 它的通信机制较AHB更复杂, VIP的使用可以让验证工程师可以放心地构建测试用例, 调试验证流程, 而不必在通信模型上放更多的精力。

另外, VIP是从VMM基类中扩展的, 它能快速地“融入”到VMM验证平台中。而且, VIP有自己的monitor, 可用来监测总线行为;一旦总线出现违反协议的行为, VIP会报错, 这对我们仿真、调试的帮助很大。因此AHB、USB VIP的使用缩短了验证周期, 提高了验证效率。

3 验证平台的实现

3.1 基于VMM的USB验证平台结构

基于VMM的USB控制器验证平台如图3所示。从下往上看, 被测试模块既是AHB总线上的从机, 也是USB总线上的设备端。一方面, 我们使用AHB VIP master, 通过总线互联与DUT的AHB接口相联, 另一方面, 利用USB VIP作为USB主机, 与DUT通过UTMI接口互联。AHB master与USB host都处于命令层, 直接驱动信号进出DUT。

为了模拟CPU操作AHB总线读写寄存器, 我们需要创建ahb_manager。它起到承上启下的作用:接收产生器下传的随机包, 解析此包, 产生并组织一系列的读写操作, 然后将这些操作顺序下传到AHB master VIP中。为了指挥USB HOST VIP复位DUT、总线枚举及发起传输, 我们还需要创建usb_manager:它解析上层传递的随机包, 将这些抽象的包“翻译”成一系列的传输事务, 顺序下发到USB HOST VIP中。

由于被测模块没有算法操作, 在验证环境中不需要复杂的记分板, 只需比较双方传输的数据是否正确。在本环境, 我们在ahb_manager、usb_manger提取传输的数据, 并通过callback方式传入到记分板中, 做自动比较。

在场景层, 我们需要创建多个场景来测试DUT在全速/高速下, 控制传输、批量传输、中断传输和同步传输以及DUT支持的各种内部操作方式。因此, 我们创建两个产生器:一个用来产生USB配置信息, 配置DUT的工作速度、传输类型、内部操作模式等;另一个用来产生USB HOST发出的传输包:IN、OUT、SETUP、SOF等。两个产生器又相互约束。

Tb_cfg是对配置文件, 用来配置VIP的参数。

3.2 双产生器的设计思想

在此验证平台, 我们设计了两个产生器:usb_cfg_generator用来产生DUT的配置信息, 包括当前DUT工作的速度、工作模式、传输次数、寄存器设置等, 相当于主机和设备在通信之前的约定;usb_tran_generator用来产生USB传输包, 如IN/OUT/SETUP/SOF等, 即在当前约定好的配置下, 总线上传输的包。工作流程如下:ahb_manager和usb_manager在usb_cfg_generator中取得当前的配置信息后:ahb_manager初始化寄存器, 确定DUT当前工作的速度、DUT端点的类型, 端点的存储空间大小等;usb_manager在此配置的约束下, 设置VIP参数, 约束USB主机工作的速度、发包的类型、传输延迟等。然后两者在usb_tran_generator中分别获取USB传输包序列, 并依次处理各包。usb_tran_generator是场景产生器 (scenario generator) , 生成的传输包序列可以是完全随机的序列也可以是有相互关系的序列。例如, 可约束生成一个具有前后顺序的序列:{SET_ADDRESS, SET_CONFIGURATION, EP1_OUT, EP2_IN};序列中每个成员的传输类型、速度、包长度要受到配置信息包的约束。在完成一定次数的传输后, 两个manager结束当前的传输, 系统复位;之后两个manager再从usb_cfg_generator中获取下一次配置信息, 并重新初始寄存器、约束参数, 开始下一次的通信。双产生器的设计使验证平台实现了测试激励分层解析、分层约束, 充分发挥VMM约束性随机的特点。验证平台同时支持批量、同步、中断、控制四种传输模式, 最大限度的实现了重用, 且测试用例编写简单、代码量少。

3.3 激励的封装与实现

协调并操作好VIP, 才能更“逼真”地模拟DUT通信。当双方manager在usb_cfg_generator获取系统配置信息后, 紧接着在usb_tran_generator中获取随机序列, 准备通信。如何实现两端的同步, 成为两个manager首要考虑的问题。

一般来说, 为了使双方manager同步, 我们将产生器中的随机包通过broadcast方式同时传递到ahb_manager和usb_manager中, 双方都完成各自的处理后, 再从产生器中获取下一个随机包, 从而实现同步。这个随机包可以是单独的packet, 也可以是某一transaction, 还可以是更高层次的抽象。如果以packet为单位, manager的工作效率低下:usb_manger向命令层发送一个包后, 需等待产生器产生下一个包;而产生器只有在双方都完成工作后, 才产生下一包, 这就造成双方发一包, 等一段时间, 工作效率极低且不符合USB实际通信。如果以transaction为单位, 虽然解决了包间延时过长的问题, 但会存在边界测试未覆盖的情况。例如, 一个transaction最大可以传输1024个字节, 双方会在传完此transaction后等待, 以实现同步。传输的字节越多, AHB总线操作时间越长, 这就造成transaction与transaction之间的延时过长, 无法覆盖大量数据连续冲击DUT的功能点。为了解决上述方案存在的缺陷, 我们定义更抽象的随机数据包:它是一系列传输的组合, 完成某一具体任务。例如, 定义某一包为SET_ADDR, 它包含SETUP传输, IN传输;定义某一包为OUT, 它包含若干对PING传输和OUT传输。如图4所示。这种层次化的激励的设计, “逼真”的模拟了实际USB与AHB端的通信, 解决了数据流连续发送与broadcast接收方同步等待的矛盾, 全面覆盖了传输过程中可能出现的各种情况。

3.4 USB验证模块重用

在USB端口这一侧, usb_tran_generator产生抽象的随机序列, 决定USB主机将要发起何种操作;usb_manager将抽象的序列转化成一系列传输包, 组织主机与DUT之间的数据传输, 控制传输的进度;USB HOST VIP把这些传输包转换成USB总线信号, 驱动到DUT接口上。这三者协同合作, 充分“扮演”主机的角色。当被测模块被集成到系统中, 模块与模块之间的连通、系统与外部的通信仍需要USB主机这个角色, 且测试激励无需变动。因此, 我们把这三者封装到次一级的验证环境中, 我们称之为subenv。Subenv解决了代码重用性的问题, 系统级环境和模块级环境可以同时开发, 从而减少了验证周期, 提高了验证效率。

3.5 VIP callback应用

USB VIP提供回调函数 (callback function) 供用户扩展使用。图5所示, 在VIP的IN、OUT、Response通道与VIP主体连接处分别设有三个回调点:post_transaction_input_channel_get, pre_transaction_output_channel_put和post_transaction_response_channel_get。用户可在此处自行添加代码, 从而实现某些特定功能的测试。例如, 用户在主机发出包后, 修改当前传输的参数 (如包间延时、总线超时时间等) , 再发至DUT, 可以测试DUT延时检查功能是否符合协议;或者主机在发出握手包后, 用户在回调点丢掉此包, 可导致DUT接收超时, 从而验证DUT超时处理是否正确。另外, USB VIP本身支持异常测试, 即VIP HOST会随机产生错误包或错误参数, 然后不定时注入到发出的包或传输中。用户可以通过这些回调点, 获取错误信息, 并针对这些错误包做出处理:如不放入记分板比较, 提前中止数据流处理等。这样, 在同一个平台上, 实现了异常传输与正常流程“分流”, 平台统一, 功能强大。

4 结语

本文提出了一种基于VMM验证方法学的USB控制器的验证方案, 文中使用了Synopsys的AHB总线验证IP和USB验证主机IP以加速验证平台的搭建。在验证平台的实现中, 本文提出了一些解决方法, 如双产生器的设计思想、激励的层次化、USB端口重用及VIP callback使用心得等, 本验证平台全面验证了USB控制器IP, 且功能覆盖全面, 重用性强, 测试用例约束性随机产生, 编写代码简单易用, 具有较高的工作效率。

参考文献

[1]Verification Methodology Manual for SystemVerilog.ByJanick Bergeron Eduard Cerny Alan Hunter Andrew Night-ingale