UVM UVM factory機制詳解

首先思考乙個問題：在uvm中我們是怎麼定義乙個class的呢？

在定義乙個類的時候，uvm強烈推薦使用`uvm_component_utils()或`uvm_object_ utils()巨集來把它們註冊。通過這兩個巨集，uvm就知道我們自己定義乙個類，這個類或是派生自uvm_component（使用`uvm_component_utils註冊），要麼就是派生自uvm_object（使用`uvm_object_utils註冊）。那麼註冊之後有什麼用處呢？

當採用上面的macro註冊過class之後，我們就可以用如下的方式來例化乙個class：

my_driver            my_driver_inst;
my_driver_inst = my_driver::type_id::create("my_driver_inst", this);

還記得uvm_component的建構函式（new()函式）中的兩個引數嗎？乙個是名字，另乙個是指向parent的指標。在這裡，create的兩個引數也是同樣的兩個引數。事實上，這個create會直接呼叫a的new函式。

假如我們沒有用`uvm_component_utils()或`uvm_object_ utils()巨集註冊，就不能用create的方式來進行例項化，只能採用systemverilog中的new函式進行。兩種例項化的方法，使用前者得到的例項，可以使用uvm中的眾多功能，而後者則不行。

假設我們自己定義了乙個my_driver，在跑80%的case的時候，這個driver是足夠使用的。但是在剩餘的20%的case中，我們需要對my_driver的行為作出某些改變，這時就可以用到override功能。如何使用override功能呢？

class new_driver extends my_driver;
…  `uvm_component_utils(new_driver)
endclass

class case_x extends base_test;
function void build_phase(uvm_phase phase);
…set_type_override_by_type(my_driver::get_type(), new_driver::get_type());
endfunction
endclass

經過上述過程之後，那麼在跑case_x的時候，系統中執行的my_driver就是new_driver型別的，其行為是new_driver的行為。不過這有乙個前提，那就是my_driver在它的agent中例項化的時候，要使用factory的方式例項化：

class my_agent;
my_driver drv;
function void build_phase(uvm_phase phase);
…drv = my_driver::type_id::create(「drv」, this);
endfunction
endclass

假如不是使用上面的寫法，而是使用drv = new(「drv」, this)的寫法進行例項化，那麼overide功能是不能實現的。所以這也就是uvm為什麼強烈推薦使用它獨有的那種古怪的例項化的方法的乙個原因。

回想一下uvm的**過程，當進入到run_test時，系統會根據輸入的+uvm_testname=name來建立乙個name的例項。這裡初看起來其實是挺容易的，但是仔細想一下，就會發現這裡面的技術難度很大。要通過乙個字串來建立這個字串所代表的類的乙個例項是相當相當困難的一件事情。但是uvm的factory機制實現了這種功能，它提供乙個稱為create_component_by_name()的函式，這個函式的輸入是乙個字串，通過此函式，可以根據類名來建立乙個類的例項。所以推薦大家派生類的時候，能夠用factory註冊就盡量用factory註冊，一方面是它提供了很強大的功能，另外一方面這也是整個驗證平台能夠執行起來的前提。

factory可以建立乙個新的類，在沒有factory之前，要建立乙個類的例項，只能使用new函式。

class a;
…endclass
a     a_inst;
a_inst = new();

但是有了factory之後，除了可以使用類名建立例項之外，還可以通過乙個代表類名字的字串來進行例項化。除此之外還可以進行override等功能。

所以，從本質上來看，factory機制其實是對systemverilog中new函式的過載。因為這個原始的new函式實在是太簡單了，功能太少了。經過factory機制的改良之後，進行例項化的方法多了很多。這也體現了uvm編寫的乙個原則，乙個好的庫應該提供更多方便實用的介面，這種介面一方面是庫自己寫出來並開放給使用者的，另外一方面就是把語言原始的介面給改良一下，使得更加方便使用者的使用。 factory的本質，就是重寫systemverilog的new函式。

UVM UVM factory機制詳解

通知機制和KVO機制

cookie機制和session機制

POW機制和DPOS機制

UVM UVM factory機制詳解

通知機制和KVO機制

cookie機制和session機制

POW機制和DPOS機制

相關推薦