采用OVM实现可重用的验证平台

在高级验证方法学(AVM)和通用可重用验证方法学(URM)的基础上，Mentor Graphics和Cadence共同推出了业界第一个通用、开放的验证方法学OVM；OVM为验证工程师提供了丰富的类库和高级验证技术，实现验证平台从模块级到系统级的重用，公司内外的重用，并且可以在多个厂家的仿真验证平台上运行。

可重用的验证平台

搭建一个高级的验证平台有很多要求，其中一个主要的要求就是要让验证平台可重用。验证平台的可重用性体现在以下几个方面：模块级验证到系统级验证的重用，同一个项目下不同测试环境的重用，在公司内部不同项目之间的重用，在不同公司之间的重用；从重用对象的角度来看，存在着验证组件的可重用、事务激励和产生算法的可重用等等。

OVM提供了事务交易级的架构，借助这些事务交易级的接口，可以搭建模块化，可重用的验证组件；它的类库可以帮助使用者创建约束随机的激励和序列，搜集和分析功能覆盖信息，包括断言在内的可配置和层次性管理的验证环境；其中基于Factory Pattern的对象生成方式，验证平台架构的动态构建，动态的参数配置，激励产生与验证架构分离和测试作为验证的顶层等高级技术使得可重用的验证平台更易实现。

验证平台架构的动态构建

在验证中经常遇到一个可重用性的难题就是需要及时调整特定的验证平台环境，对DUT应用一系列新的功能测试。通常，我们通过修改已有验证平台中特定的验证组件源代码，得到一个新的验证环境。例如，通过用一个注错功能的驱动器去替换通用的驱动器。这很容易就可以通过面向编程语言的技术，在例化原驱动器的位置上添加代码，例化一个注错功能的驱动器，从而扩展基类环境到一个新的环境。假如两个驱动器接口都是兼容的，那么验证环境的其他部分的代码便可以保持不变。

传统上，基于类的层次化对象产生创建是通过对象的构造函数new()来实现的。高层次的组件通过调用低层次组件的构造函数，创建低层次组件的对象。这种方法限制了创建对象的灵活性，因为对象的类型在编译的时候就已经确定了。另外，我们需要维护两个不同的验证环境，虽然我们可以通过面向编程技术使原有的代码得到重用，但是我们更加希望整个验证架构也能够重用；也就是说，我们希望可以不改动任何原有的代码，而调整其内容从而实现一个验证架构的重用。在OVM中我们可以通过 Factory Pattern 的方法来实现的。

Factory Pattern是一个很出名的面向对象的编程技巧，Factory是一个可以动态创建对象的类。它的主要好处是可以在特定的时刻创建特定的对象。Factory不是层次化验证架构中的一部分，而是处于层次化结构之外。OVM提供了一个Factory可以创建任何类型的事务交易或者任何验证组件，只要事前他们在Factory做过注册。Factory提供类型重写可以动态的改变所创建对象的类型。在OVM中我们通过ovm_factory来实现，见代码段1：

　　class my_env extends ovm_env;

　　 drv d1,d2;

　　…..

　　 function void build();

　　　　…… //build the rest of the environment

　　　　d1=new(“d1”,this); //explicit constructor:new()

assert($cast(d2,create_component(“drv”, “d2”))); // factory method: create_component //create an object of drv type

endfunction

　　…

　　endclass

我们从上面的代码可以看到d1和d2采用不同的例化和构造方式。d1这个对象是通过调用其构造函数来实现的，这限制了可重用性。相反，Factory的create_component()方法返回了一个drv类的对象并且赋给了d2。这两段代码都是一个drv的例化对象被创建，但是Factory提供了更大的灵活性，因为它可以在my_env类以外对其进行控制，也就是其上层的ovm_test例化中进行操作，从而可以从Factory中返回一个期望类型的组件给drvier的例化对象，如代码段2：

class err_test extends ovm_test;

my_env env;

function void build();

ovm_facotry::set_type_override(“drv”,“err_driv”); //factory type override meotod

env=new(“env”);

….

endfunction

…

endclass

set_type_override()方法告诉Factory：一旦验证环境通过create_component()要求一个drv基类对象的时候，请为其返回一个err_drv类的例化对象。在Factory中也可以针对特定的例化对象做类型修改。这个机制使得一个相同的验证环境类可以被例化到多个测试中，每一个测试都可能要求一个不同类型的driver的扩展，但是环境的代码没有改变。这个环境本身是一个可重用和上下文相关的(取决于测试如何控制Factory去生成相应类型的对象)。当在各个层次的build()阶段都采用这种的方式，每个上层的组件通过Factory去创建一个子组件的例化对象，那么任何一个组件就可以通过类似的方式来指定需要的类型。