uvm通信-UVC间可用的通信方法比较(以monitor和sb为例)

1.全局变量(以monitor与scoreboard的通信为例)

注1:class之外定义的变量称为全局变量(??);

(1)在monitor中对此全局变量进行赋值,在scoreboard中检测此全局变量值的改变;

(2)这种方法简单、直接,不过要避免使用全局变量,因为全局变量全局可见，出错后不易定位。此外，一旦定义了全局变量，则该变量会在整个仿真生命周期一直存在于服务器的内存之中，不会释放。若是在验证平台中大量使用全局变量，会降低内存的使用效率，进而降低仿真的效率。

2.public变量

(1) 在scoreboard中有一个变量,这个变量设置为外部可以直接访问的,即public类型的;

(2) 在monitor中对此变量赋值;

(3) monitor中要有一个指向scoreboard的指针, 否则虽然scoreboard把这个变量设置为非local的, monitor依然无法改变.

(4)这种方法的问题在于, 整个scoreboard的所有非local的变量对monitor都是可见的,可能会误改动scoreboard中的一些变量.

3.config机制

(1) 从uvm_object派生出一个参数类config_object, 在此类中有monitor要传给scoreboard的变量.

(2) 在base_test中,实例化这个config_object,并将其指针通过config_db#(config_object) :: set传递给scoreboard和monitor;

(3) 当monitor和scoreboard通信时, 只要把此config_object中相应变量的值改变即可.

(4) scoreboard中监测变量值的改变,监测到之后做相应动作.

缺点:需要引入一个专门的config_object类,并且需要base_test这个第三方的参与;

4.TLM机制(Transaction Level Modeling)

(1)阻塞操作:比如monitor向scoreboard传递数据时,一直等在那里,等到scoreboard处理完事情,接收新的数据;

(2)非阻塞操作:比如monitor向scoreboard传递数据时,不等待,直接返回;