Browse > Home / 信息中心 / SNUG / 2004论文集 / VMT在AMBA部件验证中的应用

VMT在AMBA部件验证中的应用


Application of VMT in AMBA Component Verification

摘要：

AMBA（Advanced Microcontroller Bus Architecture）是当前SOC设计中的主流总线架构，AMBA部件验证是SOC验证的基础之一。Synopsys公司基于VMT（Verification Modeling Technology）开发了AMBA部件验证的一系列VIP（Verification IP），可以很好地满足这方面的验证需求。本文论述了如何使用VMT AMBA VIP来验证AMBA总线的各个部件，包括总线激励发送、结果采集、日志数据判读等，由此判断AMBA部件在接口上是否符合总线规范、功能上是否符合设计要求。

1 引言

1.1 项目概述

当前的通信ASIC设计有更多的芯片带有一个嵌入式ＣＰＵ，我们从事的３Ｇ的基带设计中面临着协议不断更新，芯片支持的功能不断的增强等问题，这就要求我们能够把一部分可能会经常升级的协议功能能够使用软件实现、比较固定的功能用逻辑实现。在以后的功能升级过程中只要现场升级嵌入式ＣＰＵ软件，即可实现３Ｇ通信系统的平滑过渡。我们实际上比较经常应用ＡＲＭ处理器作为我们嵌入式（ＥＣＳ）ＣＰＵ，但是在实际的ASIC设计中，ＣＰＵ的选型是一个非常慎重的事情，我们在选定ＡＲＭ处理器以后还会在不同家族不断的评估与实验最佳的体系结构和最佳性能价格比的处理器。

本芯片项目（以下称SDXXX）完成WCDMA下行物理信道编码与调制（包括HSDPA功能），我们的嵌入式系统与一般的逻辑实现分离设计，最后通过寄存器和RAM与逻辑部分实现交互 。我们已经选用：ARM926EJS作为我们片内的CPU、AMBA总线作为片上总线、外部的IP挂在AHB和APB总线上。

1.2 项目特点

本项目的ECS验证同其他的SOC项目一样，具有如下的特点：

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

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

（3） 验证的高度抽象性。例如我们的CPU可能是一个演进过程（ARM7–àARM9-àARM10），相对外围设备可能几乎没有变化，这样在更新CPU核过程中，外围设备需要重新验证；

（4） 验证的完整性没有手段保证。从方法论角度上，几个AMBA总线功能上的验证正确性不能保证AMBA总线全集的正确性；如何能够找到一个AMBA总线全集的激励源问题就解决；

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

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

1.3 项目分析与验证工具的选用

有以下几个原因不能用ARM核直接充当验证的激励源：

（1） CPU的获取是HARD CORE，只能直接进行版图综合，在整个ECS验证中缺少一个激励源；

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

我们要求能够有一家供应商能够提供如下的解决方案：

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

（2） 可观性。能够提供总线监视功能，能够把总线信号像逻辑分析仪一样能观察波形，也能够把总线事件以日志纪录下来后台观察；

（3） 可替代性。能够提供一种总线互联方案，在总线上能够挂上众多MASTER和SLAVE部件，该总线互联方案能够提供多MASTER的总裁方案，使得我们使用一层总线就能够替代设计中多层互联总线，而功能上同设计相一致；

（4） 随机性。支持随机验证。MASTER随机的发出激励，MONITOR能够把随即发生的AMBA总线事件全部记录下来，并能够在功能覆盖率分析，使测试者对测试的功能覆盖有一个量化指标；

基于以上的考虑，我们选用ＳＹＮＯＰＳＹＳ的ＶＭＴ（Verification Modeling Technology），该工具能够提供以下的解决方案：ＡＭＢＡ总线ＭＡＳＴＥＲ模型（ＡＲＭ　ＣＰＵ的总线行为模型）、ＳＬＡＶＥ模型、ＢＵＳ模型、ＭＯＮＩＴＯＲ模型，完全能够满足我们的要求，这样就给我们ＩＰ验证提供一个完整的解决方案。

2 VMT工具的概述

2.1 VMT的基本含义

VMT是Verification Modeling Technology的缩写，在AMBA的VMT模型中，它包括四个模块：ＭＡＳＴＥＲ　模块、ＳＬＡＶＥ　模块、ＭＯＮＩＴＯＲ模块、ＢＵＳ模块。

2.2 VMT 的特性

（1）具有时钟周期精度的内核和时序可控的外壳，可以在只使用其功能模式，或者使用时序模式，也可以在Testbench通过命令，在仿真的过程中在两种模式之间动态的切换；

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

（3）可以使用多种语言来实现Testbench ，可以是VHDL，Verilog，C，VERA。

2.3 VMT 的运行机制

2.3.1 VMT 的命令流

上面的流程图包含如下的意义：

（1） 为测试的某个模型：例如AHB_MSTR，构造一个测试台，它包含一个或几个被测模型，其它主要是一系列的命令流组成；

（2） 在例化模型之后主要的工作对象是零周期的命令流和总线模型命令流组成；

（3） 命令流进入模型中可以分为：队列命令与非队列命令，队列命令进入“命令队列处理模块”进行处理，而非队列命令进入“命令执行引擎”中处理；

3 我们建立的验证环境

3.1 验证环境的搭建说明

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

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

（2）我们自行开发的一些比较通用的模块：例如watch dog 电路，这样的电路往往在我们的设计中有着非常重要作用，如果它出问题，可能我们的整个ECS会有致命的BUG。

这就要求我们必须选用一家比较好的AMBA 总线IP验证工具来接受IP，经过我们整个评估与验证实施，觉得SYNOPSYS的VMT是一个非常好的工具，下面我们会就我们的实际使用经验过程中谈谈我们对该工具的使用过程：

我们在整个IP的验证中构造一个如下的测试平台：

3.2 验证实施的说明

通过以上的平台我们作如下的一个实施过程：

（1）考虑功能的扩展的方便，我们对AHB总线与APB总线外挂IP模块的开放管理：

VMT 中AHB BUS 其实包括一系列的与总线功能相关的部件（如：arbiter 、default slave），并且主从部分都可以接15个器件，实际上我们的IP模块不会有如此之多，我们把不用的端口暂且保留起来为以后扩展使用；

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

4 实际的AHB+RAM测试方法

4.1 我们实际的测试对象

实际的测试对象我们为了简化分析问题的层次，我们首先把AHB总线上的模块和APB总线上的模块一定程度的划分，应用不同的层次进行分别验收，为了不失一般性，我们首先给出AHB总线上的MEMCTRL+MEMORY的测试方法：

4.2 实际上构建的验证环境

以上测试环境的建立完全遵从以上的可测性、可观性、可替代性、随机性，我们选用

ＭＡＳＴＥＲ模型作为ＡＨＢ的ＢＦＭ模型，我们普通以及随机激励的添加通过命令文件的方式，总线功能检测通过monitor。

4.3 测试台参数的设立

4.4 测试激励与监控

4.4.1 普通激励流程

4.4.2 随机业务

上图中，initiator用于生成总线上相关协议的随机激励，它受constraints约束（不同的model有不同的可约束属性），激励生成所需的payload可以随机生成也可从文件中读取。如果Responder用的也是VMT model，则其行为也可随机化。Notification是model预定义的一些事件，如发生总线读操作等，通过create_watchpoint函数可将其和某个watchpoint关联，通过watch_for函数可以检测这些事件。

CRT的特征依靠下面三种模型来表达：

● Initiator ：这个模型（通常是master）初始化随机业务；

● Responder：这个模型（通常是slave）接收业务并有时给master反馈，或者决定该业务是否有效；

● Monitor：这个模型记录业务和响应，有时在initiator或者在responder模型内部查看业务是否有效的情形；

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

随机业务产生

我们可以在测试台中使用以下三种类型CRT 对象来创建和定制随机约束：

● Protocol Transaction Generator（PTG）

● Transaction Sequence Generator（TSG）

● Transaction Choice Generator（TCG）

4.4.3 CRT（Constraint Random Test ）

在开发CRT过程中主要就是定义业务的约束和权值。既然约束能够被定义控制单点业务（业务组），我们可以对约束值进行修改、组合、重用。

约束有以下几个方面功能：

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

● 规定几种协议业务类型或业务序列。例如：我们可以产生大量16-beat read bursts、少量single-beat writes、甚至更少量read-modify-write业务。每一种协议业务或者业务序列能够被设定不同的权值。

● 对不同业务应用普通特征值、甚至完全应用随机特征值。例如：在一个read-modify-write序列中，你需要往同一个地址执行读写业务。

4.4.4 本用例中的约束方法

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

4.5.1 功能覆盖率检查

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

4.5.2 本验证发现的问题与定位分析

（1） 在VMT连续发生读写激励（中间不插入IDLE态），RAM模型不能作到正确相应；

（2） 在进行字节、半字、字交替操作时出现较长时间数据相应错误或出现不定态；

经过分析，发现问题分别如下：

（1） 在连续发生读写信号（特别是先写立即读）任何memory在读写数据读需要有一个cycle时间来缓冲，这就要求memory控制器能够有效缓冲这种紧张时序；经定位是控制器的bug；

（2） 分别进行字节、字操作读不会出现问题，如果加入半字操作就会出现问题，经定位，也是memory支持半字操作过程中字节使能有点问题；

通过以上测试VMT验证工具大大的加速我们发现文体的进程；

4.5.3 实际应用到VMT的工具

5 实际的APB+TIMER测试方法

5.1 TIMER 验证框架的确定

5.2 TIMER 验证方法

5.2.1 基本测试点

TIMER寄存器读、写

● BFM单次遍历读、写TIMER内部寄存器，并比较结果。同时APB monitor实时监测APB总线信号是否符合APB规范。

● BFM burst读、写TIMER内部寄存器，并比较结果。同时APB monitor实时监测APB总线信号是否符合APB规范。

● BFM back-to-back读、写TIMER内部寄存器，并比较结果。同时APB monitor实时监测APB总线信号是否符合APB规范。

TIMER控制功能测试

● 遍历设置不同pre-scale时，检测TIMER是否按正常的时钟频率计数；

● 设置控制寄存器的使能位，检测TIMER是否可正常开、关；

TIMER计数功能测试

● 设置计数器工作在自由运行模式，1/1的pre-scale设置，计数初值分别为1、2、0×4000、0xFFFF时，当前计数值寄存器指示是否正常，是否按自由模式计数，是否正常产生中断。

● 设置计数器工作在周期运行模式，1/1的pre-scale设置，计数初值分别为1、2、0×4000、0xFFFF时，当前计数值寄存器指示是否正常，是否按自由模式计数，是否正常产生中断。

中断清除功能测试

● 设置TIMER工作在自由运行模式，1/1 的pre-scale设置，计数值分别位1、0xFFFF时，产生计数中断后写中断清除寄存器可正常清除中断输出。

5.2.2 问题的发现与解决

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

问题描述：设置计数器工作在周期运行模式，1/1的pre-scale设置，计数初值为0xFFFF时，不能正确产生中断；

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

5.2.3 VMT 的使用方法

6 总结

本项目是我司无线基站套片中一个非常重要的SOC项目，快速保证ＥＣＳ部件的设计收敛、各个部件对AMBA总线规范的兼容性与完整性是整个嵌入式设计中非常重要的问题。我们选用SYNOPSYS的DESIGNWARE中的VMT，能够充分满足我们的以下几个方面需求：

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

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

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

笔者在ＡＭＢＡ总线部件级验证取得一些比较好的经验，在下一个ＳＯＣ项目中我们也会继承以上的验证思想，选用ＶＭＴ工具（或其升级版）作为部件级验证平台。