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

动态的配置机制

传统的基于类的层次化验证环境中使用构造函数的参数来配置验证平台。例如验证平台的架构，参数设置(数组的大小和常数)，操作模式(错误注入和调试)是可以通过这个方法来配置的；但是在层次复杂的结构中，这种方法使用起来变得困难而且很难添加新的参数。

OVM支持内置动态的配置机制，来实现结构化属性和运行时参数的配置，从而避免通过构造函数的参数来传递信息。一个高层次的组件可以设置配置信息，这些信息被对应的低层组件的获取后使用。每个可配置的组件负责在合法的时刻去获取自己的配置信息：结构化配置信息，例如多少个子模块可以被例化，可以通过build()这个阶段来控制；运行时的信息，例如在总线周期之间需要等待多少个状态才注错，可以通过组件的build()或者configure()阶段来实现，他们也可以在run()这个阶段来实现。OVM提供了一个API来实现这个配置信息的设置和获取的过程。如代码段3：

class drv extends ovm_threaded_component;

　　local int delay;

　　virtual function void build();

　　 if(get_config_int(“numdly”,numdly)) //get the configuration from the global table

set_delay_length(numdly);

　　endfunction

　　virtual task run();

　　…

case(state)

　　 DONE:begin

　　 if(get_config_int(“numdly”,numdly))

　　 if(numdly<=10)

　　 set_delay_length(numdly);

　　 else ovm_report_error(“Driver”,”ILLEGAL length sepcification”);

　　 state=IDLE;

　　 IDLE:begin

　　 if(delay==0)

　　 state=GO;

　　 …

　　　endcase

….

endtask

　　endclass

配置信息可以通过高层的组件来指定，而常常由顶层的验证环境或者顶层的测试来决定；通过set_config_*()，配置也可以对一个特定例化上实现；配置信息可以直接的被制定为整数或者字符串的值，但是有些比较复杂的需要封装在一个ovm_object的对象中通过使用set_config_object()方法来实现。代码段4是一个例子，测试将配置driver中的延迟时间：

代码段4：

　　class dly_test extends ovm_test;

　　 virtual function void build()

　　 set_config_int(“env.d1”,”numdly”,5);

　　 …..

　　 endfunction

　　…

　　endclass

在OVM中这些配置是通过一个全局的查找表来实现的，其为验证平台提供了可重用性。第一，对组件的配置信息独立于自身的构造函数，这使得测试可以更灵活的根据其他配置信息或者随机地去为还未被例化组件配置信息。使用者还可以通过使用通配符来在多个组件中对多个参数做配置。组件自主获取其配置信息可以让组件保证无论在那种情况下都要被合法的配置。如果其中有不匹配的地方，组件作为一个仲裁者，会要求恰当的配置。