功能验证已经成为开发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的功能。注意一些非法功能覆盖点是不能被覆盖到的。