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

测试作为验证的顶层

标准验证平台的结构中有一个顶层的模块(top)，在顶层模块中例化了DUT(alu)，DUT接口(alu_if)和一个顶层的类(test_env)；顶层的类(test_env)即验证环境中包含了验证平台的所有组件，可以在这个架构中应用的SystemVerilog技术例如约束随机数的产生和功能覆盖率。

图1 标准验证平台的顶层结构

在标准的验证架构中，如图1所示，顶层的对象是一个环境类，其中嵌入了激励产生器。这限制了添加和修改测试的灵活性。

将激励生成算法从验证平台的结构中分离出来，这样可以让我们将一个测试的类(test)作为顶层的对象而不是一个环境的类(env)。

图2 测试作为验证的顶层

如图2所示，test_MAC是我们的测试，它是一个类，其中包含四个成员：

1.一个sequence(MAC_sequence)，其可以生成一系列事务交易；在这个例子中，事务交易通过sequence生成，是一个实现了乘累加算法的激励序列。

2.一个验证环境(t_env)，其例化包含了各种验证组件。

3.Factory的重写，可以为MAC的测试动态地创建一个验证环境。

4.配置信息，可以为MAC的测试动态地配置验证环境。

相对于标准的验证平台，测试作为验证的顶层在添加和修改测试上提供了很大的灵活性。每个测试可以定义它自己特定的配置信息，在编译完所有的测试和验证组件之后，每个测试可以不用重新编译就能运行，因为每个测试在它运行的时候可以动态的创建和配置验证架构。

采用了这种方法，上述例子可以根据不同的应用被配置到特定的测试中，包括选择特定的记分板，给测试指定一个合适的衡量机制，选择一个特殊的事务处理器或者配置一个可预测的结果。在某些情况下，整个层次化的模块可能被代替，例如激励生成模块，分析模块和监视模块。从而，同一个验证环境(test_env)能够被不同的测试(test)多次重用，动态创建和配置。

激励产生与验证架构分离

图3 标准的激励产生模块

就如我们前面所说的激励产生、事务交易在验证平台中的验证组件――激励产生器中创建生成；如图3所示，在我们的例子中driver是一个事务处理器，可以接受ALU的事务交易，例如加、减操作，将其分解送入到ALU的管脚级的端口中。在DUT和事务处理器之间通过虚接口(virtual interface)来实现。

激励生成算法被嵌入在产生器的类中：stimulus_gen，这种接口限制了修改测试的灵活性。为了添加或者修改测试，产生器的对象需要被另外一个产生器代替，从而需要重新配置和重新编译。除了支持上述方法，OVM推荐了另外一种方法：把激励生成的算法模块从验证平台的结构中分离出来，从而在添加和修改测试上提供更大的灵活性。

图4 层次化的激励产生模块

在图4中，生成事务交易的算法包含在一个sequence对象中：MAC_sequence，这不是一个结构化的验证组件，而是存在于验证架构以外。OVM提供了sequence，在验证架构以外来生成事务交易。整个激励层次由一个sequence (MAC_sequence)，一个sequencer和一个事务交易器driver组成。sequencer同步了MAC_sequence和driver之间的通信。

作者：钟文枫

　　应用工程师

　　Mentor Graphics

　　ahan.mail@g mail.com