接口的强大功能:一是简化模块之间的连接;二是实现类和模块之间的通信。可以说接口的功能固然强大,但是问题又来了:
首先,因为事务交易处理器中的方法采用了层次化应用的方式去访问对应端口的信号,所以我们只能为两个相同功能的接口分别编写两个几乎一样的事务交易处理器,为什么呢?因为采用的是层次化的应用,假如设计中的某个引脚名字需要修改,我们只能修改驱动这个端口的方法!这样还是有点繁琐,那么sv中有了虚接口的概念,事情就会变得更加简单了!
到底是如何操作的呢?
虚接口和对应的通用方法可以把设计和验证平台分隔开来,保证其不受设计改动的影响。当我们对一个设计的引脚名字进行改动的时候,我们无须改动驱动这个接口的方法,而是只需要在例化该事务交易处理器的时候,给虚接口绑定对应连接的实体接口即可。以此来实现事务交易处理器的更大重用性。
虚接口的定义:
virtual interface_type variable;
虚接口可以定义为类的一个成员,可以通过构造函数的参数或者过程进行初始化。
虚接口应用的具体步骤:
到此,我们就可以在事务交易处理器中,编写针对该接口的通用方法(如request和wait_for_bus),只要针对虚接口进行操作就可以,而该虚接口不针对特定的具体器件,只有在事务交易处理器的对象例化创建时,根据具体传递给他参数确定。
在UVM中,同步的不再只局限于同一个对象中的各个线程,而是还有各个组件之间的同步问题。一旦发生同步的要求发生在各个组件之间,这就要求组件之间通过某种可以同步的方法来实现。而考虑到UVM各个组件的封闭性原则,我们并不推荐通过层次索引的形式在组件中来索引公共的event或者semaphore。UVM为了解决封闭性的问题,定义了如下的类来满足组件之间的同步:
uvm_event,uvm_event_pool,uvm_event_callback,uvm_barrier, uvm_barrier_pool
uvm_event类与event相比,它有下面的几个重要特性:
不同的组件可以共享同一个uvm_event,这不是通过跨层次传递uvm_event对象句柄来实现共享的,因为这并不符合组件环境封闭的原则。这种共享同一个uvm_event对象是通过uvm_event_pool这一全局资源池来实现的。这个资源池类是uvm_object_string_pool #(T)的子类,它可以生成和获取通过字符串来索引的uvm_event对象。通过全局资源池对象(唯一的),在环境中任何一个地方的组件都可以从资源池中获取共同的对象,这就避免了组件之间的互相依赖。