VMT在AMBA部件验证中的应用

2004年08月15日

高级微控制器总线架构(AMBA)是当前SoC设计中的主流总线架构,AMBA部件验证是SoC验证的基础之一。Synopsys公司基于验证模型技术(VMT)开发了AMBA部件验证的一系列验证IP(VIP),可以很好地满足这方面的验证需求。本文论述了如何使用VMT AMBA VIP来验证AMBA总线的各个部件,包括总线激励发送、结果采集、日志数据判读等,由此判断AMBA部件在接口上是否符合总线规范、功能上是否符合设计要求。

当前的通信ASIC设计有更多的芯片带有一个嵌入式CPU,在我们从事的3G基带设计中面临着协议不断更新和芯片支持的功能不断增强等问题,这就要求把一部分可能会经常升级的协议功能使用软件来实现,而比较固定的功能用逻辑实现。在以后的功能升级过程中只要现场升级嵌入式(ECS)CPU软件,即可实现3G通信系统的平滑过渡。我们常用ARM处理器作为嵌入式CPU,但是在实际的ASIC设计中,CPU选型是一个非常慎重的事情,在选定ARM处理器以后还会在不同系列中不断评估和实验最佳体系结构和最佳性价比的处理器。

本文所涉及芯片项目的嵌入式系统与一般逻辑实现分离设计,最后通过寄存器和RAM与逻辑部分实现交互。我们选用ARM9构架作为片内的CPU,AMBA总线作为片上总线,外部的IP挂在AHB和AMBA外设总线(APB)上。实际的片内AMBA总线的体系结构如图1所示。

项目概述

本项目的ECS验证同其它的SoC项目一样,具有如下的特点:

1. 嵌入式系统比较复杂,片内总线上的各个部件同通常的逻辑有着很大不同,而且得遵从AMBA总线协议；

2. 构筑验证平台、模拟实际运行状况困难重重,例如需要在软硬件协同验证过程才能获得CPU对各个部件的激励,构筑这样一个平台需要大量人力、物力和时间；

3. 验证的高度抽象性,例如CPU可能是一个演进过程(ARM7-->ARM9-->ARM10),相对外围设备可能几乎没有变化,这样在更新CPU核过程中,外围设备需要重新验证；

4. 验证的完整性没有手段保证,从方法论角度上,几个AMBA总线功能上的验证正确性不能保证AMBA总线全集的正确性,找到一个AMBA总线全集的激励源就可以解决这个问题；

5. 验证过程中缺少可控性和可观测性手段。如何有效控制激励源,使其发出遵从AMBA总线协议的激励关系到验证效率的提高,如果自己用VERA或C开发出一组测试台代价很大,而且在验证过程中经常会碰到不符合AMBA总线协议的事件,把这样的事件用日志文件形式记录下来作为下次改进参考是一件理想的事情,实际上通过仿真器来观察效率太低,因为我们需要的是一个事件,而仿真器只提供时钟周期级的波形；

6. 激励源是否支持随机方式发出激励也是验证难点,实际上大量的验证问题是随机发现的,如果激励源发出随机进行测试,可以早点发现问题。

项目分析及验证工具选择准则

基于以下几个原因,不能用ARM核直接充当验证的激励源:

1.由于CPU是硬核,只能直接进行版图综合,在整个ECS验证中缺少一个激励源；

2. 即使ARM公司提供ARM仿真模型,它也需要包括底层软件在内的软件支持,软硬件联合验证太复杂,在部件验证中使用该方法成本很高。

我们要求供应商能够提供如下的解决方案:

可控性。有一个能够发出AMBA总线全集的激励源,该激励源应该具有:标准AMBA总线的主(master)接口快速接入ECS中；非常容易控制的激励函数,不需要同软件联合工作。

1. 可观察性能够提供总线监视功能,能够像逻辑分析仪一样观察总线信号波形,也能够把总线事件以日志记录下来在后台观察。

2. 可替代性能够提供一种总线互联方案,在总线上能够挂上众多主、从部件,该总线互联方案能够提供多主的仲裁方案,使得我们使用一层总线就能够替代设计中多层互联总线,而功能上同设计相一致。

4. 支持随机验证主部件随机地发出激励,监测器能够把随即发生的AMBA总线事件全部记录下来,并能够进行功能覆盖率分析,使测试者对测试的功能覆盖有一个量化指标。

基于以上的考虑,我们选用Synopsys的VMT,该工具能够提供以下的解决方案:AMBA总线主模型(ARM CPU的总线行为模型)、从模型、总线模型、监测器模型。该工具完全能够满足我们的要求,为我们IP验证提供一个完整的解决方案。

VMT工具概述

在AMBA的VMT模型中,它包括四个模块:主模块、从模块、监测器模块、总线模块。

1. VMT的特性

a. 具有时钟周期精度的内核和时序可控的外壳,可以只使用其功能模式或时序模式,也可以通过测试评台命令在仿真的过程中在两种模式之间动态的切换；

b. 提供多种控制机制,可以用事件调整模型行为,也可以同步不同的命令进程,还可以使用单一的命令流同时控制多个模型；

c. 可以使用多种语言来实现测试平台,如VHDL、Verilog、C和VERA。

2. 验证环境的搭建

IP模块是有如下的两种情形:

a. 生产厂家提供的标准模块,在系统集成的过程中需要对其验收,验证它是否符合AMBA总线规范和功能上是否达到我设计需求；

b. 我们自行开发的一些比较通用的模块:例如看门狗电路,这样的电路往往在我们的设计中有着非常重要作用,如果它出问题,可能整个ECS会有致命的bug。

因此,必须选用一家比较好的AMBA总线IP验证工具来接受IP。经过整个评估与验证实施,我们选择Synopsys的VMT工具。

验证实施过程

考虑功能扩展方便,我们对AHB总线与APB总线外挂IP模块开放管理:VMT中AHB总线其实包括一系列与总线功能相关的部件(如仲裁器、默认从部件),并且主从部分都可以接15个器件,实际上我们的IP模块不会有如此之多,我们把不用的端口暂且保留起来为以后扩展使用。

2.保持对设计验证的一定程度透明,更好监督设计。在应用ARM处理器核和其它主器件(DMAC)过程中,设计可能会用到多层总线；VMT中总线已经包含多处理器的仲裁算法,验证只需把对应主、从器件挂在总线上即可,这样就用VMT单层总线结构就可监督多层总线设计的正确与否,可以为验证节省大量时间。

实际的AHB+RAM测试方法

为了简化分析问题的层次,我们首先把AHB总线上的模块和APB总线上的模块进行一定程度划分,应用不同的层次进行分别验收,为了不失一般性,我们首先给出AHB总线上的MEMCTRL+存储器的测试方法,AHB系统中测试框图如图2所示。

在图3中,Initiator起始器用于生成总线上相关协议的随机激励,它受约束条件的制约(不同的模型有不同的可约束属性),激励生成所需的净载荷可以随机生成也可从文件中读取。如果Responder用的也是VMT模型,则其行为也可随机化。 "告示"是模型预定义的一些事件,如发生总线读操作等,通过create_watchpoint函数可将其和某个watchpoint关联,通过watch_for函数可以检测这些事件。

约束随机测试(CRT)的特征依靠下面三种模型来表达:

Initiator:这个模型(通常是主模型)初始化随机业务；

Responder:这个模型(通常是从模型)接收业务并有时给主模型反馈,或者决定该业务是否有效；

Monitor:这个模型记录业务和响应,有时在Initiator或者在Responder模型内部查看业务是否有效的情形。

测试台的创建者建立了施加给Initiator的约束用来指导随机业务的发生。每一个Initiator模型必须预定义有能够被约束的特征。当业务发生时,一个Initiator模型从一个或多个常见净载荷对象中取出数据。如果净载荷被删除,业务产生即被中止。当任何净载荷被删除的消息被提交,测试台能够通过必要的消息观测点获得这些消息。你可以选择随机业务发生器中的某种业务来发出通知,从一个Initiator发出的通知单包括即将被执行的业务信息和同业务相关联的数据信息。通过写通知单的句柄,你能够执行数据检查或其它行为。

随机业务产生

我们可以在测试台中使用以下三种类型CRT 对象来创建和定制随机约束:协议处理发生器(PTG)、处理序列发生器(TSG)和处理选择发生器(TCG)。

在开发CRT过程中主要的工作就是定义业务的约束和权值。既然约束能够被定义控制单点业务(业务组),我们可以对约束值进行修改、组合、重用。约束有以下几个方面功能:

1. 限制传输类型、传输数据值或特征值。例如:你能够在一个部分地址范围、部分猝发类型测试业务或执行一定比例读写业务。

2. 规定几种协议业务类型或业务序列。例如:我们可以产生大量16拍读脉冲串、少量单拍写入、甚至更少量读-修改-写业务。每一种协议业务或者业务序列能够被设定不同的权值。

3. 对不同业务应用普通特征值、甚至完全应用随机特征值。例如:在一个读-修改-写序列中,需要往同一个地址执行读写业务。

功能覆盖率的检查与整个验证结果发现的问题

AHB监测器使用VERA覆盖对象函数来实现覆盖。默认的方式就是进行覆盖统计,通过设置参数来设定、清除、开始、结束覆盖。覆盖报告在仿真结束时产生,在监测器定义所有的覆盖目标都在报告中产生,各种覆盖报告有专门的命名方法。

本验证中发现以下问题:在AHB_MASTER连续发生读写激励(中间不插入IDLE态),RAM模型不能作到正确响应；在进行字节、半字、字交替操作时出现较长时间数据相应错误或出现不定态。经过分析,发现问题分别如下:

1. 在连续发生读写信号(特别是先写立即读)任何存储器在读写数据都需要有一个时钟周期时间来缓冲,这就要求存储器控制器能够有效缓冲这种紧张时序,经定位是控制器的bug；

2. 分别进行字节、字操作读不会出现问题,如果加入半字操作就会出现问题。经定位,也是存储器支持半字操作过程中字节使能有问题；

通过以上测试VMT验证工具大大加速我们发现问题的进程。

实际的APB+TIMER测试方法

1. TIMER验证框架的确定

APB+TIMER的验证框架如图4所示。

2. TIMER验证方法

a. 基本测试点

TIMER寄存器读、写:BFM单次遍历读、写TIMER内部寄存器,并比较结果,同时APB监测器实时监测APB总线信号是否符合APB规范；BFM burst读、写TIMER内部寄存器,并比较结果,同时APB实时监测APB总线信号是否符合APB规范；BFM back-to-back读、写TIMER内部寄存器,并比较结果,同时APB监测器实时监测APB总线信号是否符合APB规范。

TIMER控制功能测试:遍历设置不同预分频时,检测TIMER是否按正常的时钟频率计数；设置控制寄存器的使能位,检测TIMER是否可正常开、关。

TIMER计数功能测试:设置计数器工作在自由运行模式,1/1的预分频设置,计数初值分别为1、2、0x4000、0xFFFF时,当前计数值寄存器指示是否正常、是否按自由模式计数、是否正常产生中断；设置计数器工作在周期运行模式,1/1的预分频设置,计数初值分别为1、2、0x4000、0xFFFF时,当前计数值寄存器指示是否正常、是否按自由模式计数、是否正常产生中断。

中断清除功能测试:设置TIMER工作在自由运行模式,1/1的预分频设置,计数值分别位1、0xFFFF时,产生计数中断后写中断清除寄存器可正常清除中断输出。

b. 问题的发现与解决

本模块是我们项目组自行设计的模块,可能会有比较多的bug,需要我们仔细验证。根据设计特点,可能本模块由于是挂在APB总线,接口时序可能比较简单,但内部功能相对复杂,应该重点跟踪。

问题描述:设置计数器工作在周期运行模式,1/1的预分频设置,计数初值为0xFFFF时,不能正确产生中断；

问题解决:我们通过AHB MASTER模型激励定时器进行计数,在计数器的初始值为0XFFFF观察中断是否发生,经定位发现计数器在初始值寄存中有bug。

本文总结

本项目是华为一个非常重要的SoC项目,快速保证ECS部件的设计收敛、各个部件对AMBA总线规范的兼容性与完整性是整个嵌入式设计中非常重要的问题。我们选用Synopsys的Designware中的VMT,能够充分满足我们的以下几个方面需求:

1. 快速的AMBA总线的建模能力。由于该工具提供了货架式模块,我们只花费了2人周就可以搭建包括AHB和APB部件在内的所有的部件验证框架,只需要在命令文件中发出激励即可仿真进行；

丰富、易用Master激励函数模型,为构造各种类型激励提供可能,我们建立了面向事件的函数封装库(例如,只需要一个函数,整个系统就可以发起读写操作并给出比对的结果)；

完整、严密的AMBA总线规范的监视能力,并能够形成报告文件,可读性好；在CRT测试中我们最大可能让总线发起各种操作,最后观察到在某种极限情况下部件的bug的出现。

作者:方茂元

ASIC验证工程师