原创 一种可重用的SOC验证平台

功能验证已经成为开发SOC的主要问题。SOC采用基于IP的设计方法学，加快了产品的面市时间，与此同时SOC也带来了更多的挑战。SOC验证问题是其中的挑战之一。验证在整个芯片设计中的投入是相当大的，大约占整个芯片设计的70%，实现高效的功能验证对芯片的一次流片成功起着至关重要的作用。
无论采用何种验证工具，其验证目的都是为了达到一定的功能覆盖，排除芯片设计中的错误，区别是开发的验证平台的可重用性以及可维护性等。便于维护、重用的验证平台可以节约宝贵时间，减少开发者在平台搭建过程中的工作量，加快SOC验证，有利于新产品的面市。本文介绍Synopsys的RVM验证方法学，是采用openvera硬件验证语言建立目标模型环境、激励自动生成、含错误指示的自核对式测试、覆盖状况分析能力[1]。
RVM验证方法学
Synopsys提供的RVM是在openvera基础上，结合随机验证和覆盖率驱动技术发展起来的一种基于事务的验证方法，适于对SOC某一模块的RTL级验证。显然可以直接利用openvera 来实现对SOC某一模块的RTL验证，但对于协议复杂的模块，其重用性可维护性大大降低。所谓事务是指被设计对象与事务处理器之间通过接口所做的一次数据或控制的传输[2]。事务可以是一次寄存器的读写这样的简单事务，也可以是具有一定比特个数且各比特间有一定关系的复杂事务。基于事务的思想把验证提高到更高的抽象层次——事务层，使验证不仅仅停留在信号级上，还提升到了事务级上，提高了验证效率。RVM采用分层的、模块的验证平台结构。RVM验证平台分为五层：测试层、激励产生层、功能层、控制层、信号层。其验证结构如图1[3]所示。
.          

                            
图1  RVM验证平台

信号层：提供与DUT（device under test被验证模块）外部物理接口信号连接的信号名，验证环境采用虚端口来代替真实的信号名，因此对DUT真实信号的改变不会影响到验证平台或者测试例。接口信号虽然可以被信号层以上的所有层访问，但应避免信号层以上的层直接访问信号层，除非特别需要。
控制层：包括驱动器和监控器，它们也是特殊的处理器。驱动器主要完成对接口信号的驱动以及监测；监控器主要监测需要监测的接口信号，把监测到的信息，以数据的形式组装并通过函数或者通道反馈给自检器。在这一层中事务被定义为在某一接口上的基本数据传输或者控制操作，例如一次DUT内部寄存器写，以太网帧传输。基本传输或者操作与声明的接口的独立时序有关。
功能层：包括事务处理器和自检器，处理应用级的事务。与物理层的基于接口的事务不同，功能层的事务与接口或物理层事务没有一一对应的相关性。功能层的事务是部分DUT或者整个DUT执行的，高于物理接口模型的更高级别的抽象。一个功能层事务可以使多个控制层事务在不同的接口被执行。事务处理器主要完成，组装DUT配置需要的数据对象，按照协议组装特定数据类型的数据对象，通过通道传送数据对象到下层模块驱动器。对于协议比较复杂的模块，事务处理器也非常复杂，尽可能将协议部分在事务处理器中实现，对协议的修改不会影响到下层模块，易于验证平台的维护。自检器：该模块实现数据自动对比，避免了看波形的费时费力，但看波形仍是十分必要的，通过看波形，分析DUT的信号时序，直接定位DUT的错误。
测试层：在整个验证平台的最高层，平台搭建完毕之后就可以开发测试例了, 测试例的开发对全面验证DUT的功能起至关重要的作用。测试例有正常、异常测试例；验证平台应该支持正常及异常测试例。通过限制产生器产生目标测试例。
激励产生层：产生器，随机产生需要的数据对象或者事务对象，根据实际需要产生符合需求的数据类型，用不同的属性来区分不同的数据对象。产生器是一个特殊的处理器，通过输出通道把被封装的数据或者事务传送到下层模块。整个验证过程中随机激励的产生是均匀分布的，也可以通过设置权重调整。这种测试的均匀分布对于随机测试是非常必要的，可以覆盖尽可能多的状况，其性能取决于设计规模、编译时间、连接时间、执行时间、存储器使用量以及测试向量的数目[4]。Vera特有的随机稳定[3]（random stability），可以使多次仿真运行产生相同的数据或者事务对象。在DUT设计有误然后被修改的情况下，随机稳定特性可以使产生器产生相同的事务，检查DUT错误之处是否被正确修改。
功能覆盖：功能覆盖与各个层次都有关，尤其与事务处理器、驱动器、自检器直接相关。对DUT的功能覆盖包括针对验证平台的激励功能覆盖、针对DUT的行为功能覆盖，理解DUT功能并制定详细合理的功能覆盖点，编写测试例，适当修改验证平台，达到预期功能覆盖率，全面验证DUT的功能。注意一些非法功能覆盖点是不能被覆盖到的。
RVM的分层结构使验证的抽象层次从信号层提升到事物层。因此验证工程师不必关心DUT内部的实现细节，只需根据设计工程师提供的详细设计文档，提取DUT工作需要的激励和输入输出端口信息，按照一定的时序关系就可以进行验证平台的搭建和验证代码的编写工作了。
RVM提供了方便验证平台搭建的基类库。主要包括构造事物对象的rvm_data类、构造事务对象的处理器(transactor)的rvm_xactor类、构造传输事务对象的通道(channel)的rvm_channel类、构造整个验证环境的rvm_env类、反馈信息的rvm_log类、事件通知rvm_notify类。验证工程师根据这些类根据不同的DUT灵活实现各个模块的设计，模块间的同步，搭建的验证平台易于调试、重用、维护。
RVM验证方法学在SD Memory Card验证平台搭建中的应用
SD功能简介：
SD Memory Card（secure digital memory card）是市场上通用的一种用于存储音视频等文件的卡，被广泛应用在电子产品中。SD是APB（advanced peripheral bus）总线的外挂设备，通过SD控制器与APB总线相连。控制器分别通过命令线、数据线负责向卡发送命令，从卡接收响应，向卡发送数据，接受来自卡的数据。通信过程中卡是被动的 ，在接收到控制器相关命令后进行相应的反馈。
根据SD卡协议，结合RVM验证方法搭建APB端验证平台，搭建卡的模型，如图2所示。图1中的DUT被这里的SD控制器代替。
              

                   
图2  SD控制器RTL级验证平台

随机激励产生器：为了模拟对SD卡的读写操作，APB端可以抽象出2种数据类型，第一种是关于对SD卡的读写操作的数据类型，是APB端产生器传送给APB端事务处理器的数据apb_trans_1。第二种是APB端事务处理器传送给APB端驱动器的数据apb_trans_2。卡的模型端制定一种数据类型sd_trans。利用不同的传输通道传输不同的数据。
事务处理器：APB端事务处理器接收本端产生器通过通道传送来的数据apb_trans_1，然后按照SD卡协议通过输送通道把组装的事务apb_trans_2传给APB端驱动器，并从本端驱动器到事务处理器的输送通道中接收APB端驱动器反馈的数据；卡端事务处理器从接收通道中接收事务sd_trans，根据不同的属性组装相应的事务sd_trans，通过输送通道把事务传给卡端卡端驱动器，同时接收驱动器的反馈。
驱动器：从接收通道中接收数据并根据不同的数据属性执行不同的操作，此模块涉及对控制器外部接口信号的操作，可以对接口信号驱动或者采样。APB端驱动器的2个线程（同时进行的操作）：1）按照APB读写数据的协议对控制器进行读写操作；2）监测中断信号，中断到达后读取中断并把组装的数据通过通道传给APB端事务处理器。SD卡端驱动器的2个线程：1）按照一定的接口时钟监测数据线、命令线、把检测到的数据组装成卡端的数据类型，通过输送通道传给SD端事务处理器；2）等待从接收通道接收数据，根据数据的属性来判断是对数据线进行操作，还是对命令线进行操作，把数据驱动到数据线或者命令线上。对于相同总线功能模型的模块，该模块可以被重用。

监控器：APB端监控器按照DUT接口协议对需要监测的信号线采样，把需要对比（由自检器完成）的数据，例如当监测到是对控制器进行写操作并且是写入控制器FIFO（first in first out）中，或者是写入命令时就需要组装apb_trans2 并把这种数据通过通道或者函数传送给自检器，同样处理从控制器读取的需要对比的数据。SD卡的模型端也可以设置一个监控器，但卡端驱动器也对命令线以及数据线监测、驱动，因此可以直接复用此端驱动器，在驱动DUT之前把被驱动的需要反馈的数据通过通道或者函数传给自检器，把监测到的数据传给事务处理器 的同时，又传送给自检器。采用这种方式处理卡的模型端的平台，减少了模块数量，减轻了程序员的负担，仔细分析模块功能，重复利用各个模块中都能利用到的功能可以减少平台搭建的时间。
自检器：把APB端发送的数据以及命令，与SD卡的模型端接收的数据以及命令做比较；把APB端读出的数据以及命令的响应，与SD卡的模型端发送的数据以及命令的响应做比较。
测试例和功能覆盖：正常测试例包括对SD卡的读写操作、对卡的写保护、解锁卡。异常测试例，限于篇幅只做简单介绍，例如SD卡的模型端发送数据时结束比特出错时，控制器在结束比特错误中断使能的情况下，应该产生中断信号，这种测试例可以在测试例中限制产生器使其产生特定的测试例覆盖这种情况，如果利用大量的随机测试来覆盖这种情况，就太耗费时间了。SD控制器的激励功能覆盖点主要是控制SD卡的各种命令，例如单块读、写命令，多块读、写命令、擦除命令、解卡命令、锁卡命令等。行为功能覆盖点主要是DUT内部寄存器的状态。
测试结果
通过编写随机测试例、异常测试例，使DUT的代码覆盖率（由仿真工具自动统计）达到96.5%，功能覆盖率（功能覆盖点由验证工程师制定）达到100%。通过与设计工程师交流确定代码覆盖率达不到100%的原因，例如缺少测试例、设计中有冗余代码等原因。通过开发直接测试例，修改设计代码，使代码覆盖达到要求。验证中生成的.log文件中包含一些错误报警信息，假设数据的自动对比过程中存在错误，错误就会被打印出来，便于错误查找。同时仔细看仿真生成的波形，排除DUT时序错误的现象，也可以看到设计工程师定义的DUT内部信号，更快更准的定位DUT设计的错误。
SD验证模块在整个系统级验证中的应用
在系统级验证中，重点是各个模块的功能验证，各个模块的接口协议是否正确，整个芯片中各个设计模块间的通信是否正确[5]。我们可以将模块级验证平台的部分模块复用到系统级验证平台中，实现激励随机产生，输出结果对比等功能，减轻了验证工程师的工作量和提高了验证的效率。系统级验证时模块验证平台中的产生器、事务处理器、驱动器被实际的总线替代。如果驱动的功能是代替外设IP，在系统级验证时需要用实际的外设IP来代替，如果芯片的功能是产生芯片级管脚信号，此时驱动仍可以重用。在SD系统验证时，原来模块级验证平台的APB端产生器、APB端事务处理器、APB端驱动器被APB BRIDGE所替代，APB端的激励从ARM送出，而SD模块级验证平台的其它模块，被重用到系统级，起到模拟卡的操作和输入输出结果比对的功能。系统级验证的结构如图3所示
    

                           
图3  SD控制器系统级重用模型

本文作者创新观点
结合随机化验证和覆盖率驱动技术搭建的RVM验证平台，具有良好的层次性，可维护性、重用性，能更快捷全面地验证SOC模块的功能。而且模块级的部分验证平台可以重用到系统级，减少了系统级验证平台的搭建时间，加快产品的面市时间。
参考文献
1 孙海平，丁健．系统芯片(SoC)验证方法与技术[M]．北京：
电子工业出版社，2005
2 孟庆，何乐年等．基于事务的SoC验证策略．半导体技术
[J]，2002，27(6)：29--32
3 SYNOPSYS．Reference Verification  Methodology  User Guide．Version 8．5．11．December 2004
4 RASHINKAR P，PATERSON P，SINAGHL．系统芯片(SOC)验证方法与技术[M]．北京：电子工业出版社，2005．
5 陈辉，申敏，刘树军.结合覆盖率驱动技术的RVM验证方法学在SOC验证中的应用[J].微计算机信息，2006，9-2：115。
作者简介：杜宁（1983-），男，山东肥城人，硕士研究生，通信与信息系统专业，研究方向：第三代移动通信技术。郑建宏，男，重庆邮电大学通信学院教授，主要研究方向为第三代移动通信TD-SCDMA手机终端芯片的研发。
Biography：Du Ning(1983-),male,Feicheng city of Shandong province,postgraduate, major:telecommunication,research on technique of the third generation mobile communication. Zheng Jian-hong, male,professor ,department：college of communication ,Chongqing university of posts and telecommunications ,research on designing of the ASIC for the third generation mobile phone of TD-SCDMA.
通信地址：重庆邮电大学76信箱 邮编：400065  E-mail:duning1983@sohu.com