1、(*)題外話：TLM可能是UVM中最重要的概念，掌握了TLM，就可以開始嘗試編寫一些小程序了。翻譯這篇文章，也是為了鞏固加強對TLM的理解。(*)幾個名詞：transaction翻譯為事務或者交易；packet翻譯為封包，packet屬于transaction；monitor翻譯為監視器；driver翻譯為驅動器；scoreboard翻譯為記分牌；有些詞匯直接被運用到UVM源代碼上，所以有時候用英文更容易描述清楚。(*)語言的目的是為了交流，翻譯不是為了純粹的語言轉換，而是為了傳遞思想。4.6 UVM中事務級建模(TLM)20多年前，設計者從門級轉向RTL級。這次轉換來自于標準Verilog/

2、VHDL的RTL編碼風格，以及RTL綜合實現工具的推出。使用RTL最大的好處是讓設計者更多的專注于時序行為的設計以及功能的正確性，而很少考慮門級相關設計。TLM(事務級建模)同樣在抽象級別上更進了一步，在設計和驗證領域都有出現。通過TLM, 中心放在系統級別的各種事務流的建模，而更少關心時鐘級別的行為。TLM在測試向量中已經使用多年。通常，在產生激勵和覆蓋率檢查的時候使用事務而不是用時鐘級別建模，這種方式就是TLM. 為了驗證RTL級別的DUT(需要測試的模塊)，測試向量使用事務發生器(transactor)(有時也稱為總線功能模型(BFM)，將RTL級和事務級進行轉換。在UVM中，此事務發生

3、器也被叫做驅動(driver)或者收集器(collector)。TLM中，事務通過方法調用和類對象來建模。使用事務級而不是信號級別來建模有幾個顯著的好處：· TLM比RTL更簡潔，仿真速度快。        · TLM模型的抽象級別更高，更加契合驗證工程師或設計工程師對內部功能的考慮，從而使得建模更簡單，并且更容易被其他工程師理解。· TLM模型將不符合復用的部分移到模型之外，因此TLM很適合復用。并且，TLM使用面向對象的技術，比如繼承、實現和接口分離的技術。 TLM的采納依賴于標準的TLM建模技術的出現，就像R

4、TL綜合流程的采納歸功于標準RTL編碼風格的實現。幸運的是，近些年來，幾個重要的標準TLM應用程序接口(API)得到定義。在EDA和ESL領域，兩個最重要的標準是開放SystemC計劃（OSCI）的TLM1.0以及TLM2.0標準。OSCI TLM 1.0標準是一個簡單通用的TLM API, 用來建模消息傳遞。在消息傳遞時，對象(事務)在組件之間傳遞的方式和封包在網絡之間傳遞的方式類似。在發送封包的消息傳遞中，發送端和接收端之間沒有共享的狀態，他們之間的通訊訊息僅僅包含在消息中。The OSCI TLM 2.0標準能夠用來開發SystemC中的高速虛擬平臺模型。TLM2.0標準特別被用作片上存

5、儲映射的總線系統，包含許多能夠進行片上總線互聯的整合復用模塊.OSCI TLM 1.0和TLM 2.0是互相獨立的標準，滿足不同的需要。有人可能通過其命名方式認為TLM2.0優于TLM1.0，但是實際上并不是這樣。UVM提供的TLM 類和API是基于TLM1.0標準的。這是因為TLM通用消息傳遞語法很好的滿足了多種驗證組件的事務級建模。TLM1.0也適合多種語言之間的通信建模，比如SystemVerilog, SystemC以及e語言之間的建模。UVM中TLM1.0接口甚至可以用來和SystemC中的TLM2.0模型進行通訊。這一章節闡述了UVM中TLM的幾個重要概念，讓讀者理解如何使用TLM

6、來構造可復用的驗證組件。關于TLM各種類的更詳細說明請參閱UVM參考手冊。 4.6.1 UVM中TLM的關鍵概念4.6.1.1 對事務建模在UVM中, 從uvm_sequence_item繼承而來的任何類都是事務。用戶根據需要定義事務類的字段和方法，用來在驗證環境中不同組件之間進行信息交換。例如，一個簡單的包如下所示：1. class simple_packet extends uvm_sequence_item;2. rand int src_addr;3. rand int dst_addr;4. rand byte unsigned data;5. constrain

7、t addr_constraint src_addr != dst_addr; 6. .7. endclass事務通常包含足夠多的數據字段讓驅動器(driver)或者事務產生器能夠產生事務的真實信號級別的動作表示。事務也可以包含更多的數據字段，來控制數據的隨機產生，或者是驗證環境中的其他目的。可以通過繼承方式來增加更多的數據成員，方法以及約束。后續章節將會說明，如何通過繼承事務，從而花費最小的代價來完成特定的驗證任務。4.6.1.2 TLM調用端口(Ports)和實現端口(Exports)UVM中的TLM使用一系列特殊的方法調用來進行模型之間的事務通訊。在UVM中，一個port對象定義了一系列

8、可以被調用的方法，而export對象提供了對這些方法的實現。在構建驗證環境的時候，port和export通過connect()函數進行連接，之后，調用port端的TLM方法將會執行export中對此TLM方法的實現。實例4.7: 使用put方法將事務從生產者傳遞給消費者在UVM的TLM中，put接口能夠被用來將transaction從生產者發送給消費者。一個簡單的生產者示例如下：class producer extends uvm_component;   uvm_blocking_put_port #(simple_packet) put_p

9、ort;   function new(string name, uvm_component parent);     put_port = new("put_port", this);   endfunction   virtual task run();     simple_packet p = new();     . 

10、    put_port.put(p);   endtask endclass之前有提到，put port通過調用connect()函數連接到put export. 對上面的put方法的實現將由消費者組件來完成，如下：class consumer extends uvm_component;   uvm_blocking_put_imp #(simple_packet, consumer) put_export;   task put(simple_packet p);

11、60;    / consume the packet   endtask endclass將port連接到export之后，調用生產者的put方法將會觸發消費者的put方法實現得到執行，從而使得simple_packet對象從生產者傳遞到了消費者。TLM也引入了標準的圖形化示意來描述不同類型的通訊。put通訊流程的模塊圖如下： 圖4-2: 簡單的生產者/消費者的put通訊TLM接口定義了一些生產者和消費者都必須遵循的簡單規則，在這個示例中，對于put接口，規則如下：· put方法的實現在執行時有可能阻塞

12、，因此對put方法調用的對象必須負責確保在put方法阻塞的時候能夠正常工作。 · 生產者負責創建封包,而消費者不能修改封包（如果需要修改，必須先拷貝一份新的）滿足了上述規則，能夠很容易的將生產者或者消費者替換成其他的模型，只要這些模型滿足相同的TLM接口即可。TLM API提供了一個簡單的能夠互相操作的接口協議，類似硬件世界中的USB,以太網標準一樣。由于能夠容易的替換模型，UVM的TLM在滿足模型復用和驗證目標上發揮了關鍵性的作用，我們可以在后續章節進一步了解。上述示例，在生產者中存在單獨一個進程，當調用put方法時，控制流轉到消費者中的put方法中。put方法將事務沿著

13、方法調用控制流相同的方向進行傳送。在某些情況，由于消費者中包含一個需要事務數據的進程，希望將事務沿著TLM方法調用控制流相反的方向傳送。在這種情形下，生產者/消費者將使用get接口來實現，示例如下：1. class producer_2 extends uvm_component;2.   uvm_blocking_get_imp #(simple_packet, producer_2) get_export; 3.   task get(output simple_packet p);4.     si

14、mple_packet p_temp = new();5.     .6.     p = p_temp;7.   endtask8. endclass 9. class consumer_2 extends uvm_component;10.   uvm_blocking_get_port #(simple_packet) get_port; 11.   function new(string name, uvm_component parent);12.

15、60;   get_port = new("get_port", this);13.   endfunction 14.   virtual task run();15.     simple_packet p;16.     .17.     get_port.get(p);18.   endtask19. endclass在上面的put接口示例中，UVM對使用put接口的生產者和消費者設定了如下規則：· get方

16、法實現可能被阻塞。因此調用方必須確保當此方法阻塞的時候也能夠正確工作。 · get方法的實現必須創建并返回一個事務對象給get的調用方。get接口通訊的圖形化示意如下：     圖4-3: 消費者調用生產者中的get方法4.6.1.3 連接port和export上面例子中，port對export的連接是通過調用connect方法完成的。用戶需要在消費者/生產者的父組件中的connect回調函數仿真階段函數connect()中調用此connect方法:class parent_comp extends uvm_componen

17、t; producer producer_inst; consumer consumer_inst;   .   virtual function void connect();     producer_inst.put_port.connect(consumer_inst.put_export);   endfunction endclass連接port和export的通用準則是：子組件中port的connect方法以子組件export作為參數進行調用.

18、0;4.6.1.4 port和port的連接以及export和export的連接Verilog RTL中，模塊的端口(port)代表信號級別的界面。Verilog RTL模塊的內部也可以包含子模塊，子模塊也有各自的信號端口。然而，只有父模塊的端口代表整個模塊的接口，子模塊的接口被當作實現細節而被隱藏。同樣的，UVM的TLM中，組件的port和export代表了組件的TLM的對外接口。其子組件以及子組件的port和export被看作是實現細節而被隱藏。此種隱藏內部結構的方式加強了整個驗證環境的模塊化，能夠更加容易的復用以及被替換。但是，如果當需要子組件的port/export能夠被外部看到的時候

19、，該如何處理呢？這種情況下，需要通過將子組件的port連接到父組件的port上，將子組件的export連接到父組件的export上。實例4-8: 連接子組件的port到父組件的portclass parent_producer extends uvm_component;   uvm_blocking_put_port #(simple_packet) put_port;   producer child_producer_inst;   function new(string name, uvm_component par

20、ent);     put_port = new("put_port", this);     child_producer_inst = new("child_producer_inst", this);   endfunction   virtual function void connect();     child_producer_inst.put_port.connect(put_po

21、rt);   endfunction endclass通用的規則是：當連接子組件的port到父組件的時候，子組件port的connect函數被調用，其調用參數是父組件的port.實例4-9: 連接子組件的export到父組件的exportclass parent_consumer extends uvm_component;   uvm_blocking_put_export #(simple_packet) put_export;   consumer child_consumer_inst; 

22、0; function new(string name, uvm_component parent);     put_export = new("put_export", this);     child_consumer_inst = new("child_consumer_inst", this); endfunction  virtual function void connect();     put_ex

23、port.connect(child_consumer_inst.put_export);   endfunction endclass通用的規則是：當連接子組件的export到父組件的export時，父組件export的connect函數被調用，其調用參數是子組件的export. 請注意此方式和上述的子組件port和父組件port的連接方式不同。4.6.1.5 使用uvm_tlm_fifo在最前面的生產者/消費者示例1中，在生產者中有一個進程，而消費者中沒有任何進程。消費者中的put方法在生產者的put方法被調用的時候執行。接下來的生產者/消費者的示例2中，消費

24、者中有一個進程，消費者有一個get port用來獲得封包。（生產者中沒有進程）我們有可能會遇到這種情況：需要將示例1中的生產者組件和示例2中的消費者組件相連接。如何做到這兩個組件相連接呢？一個非常常用的方法是使用UVM的uvm_tlm_fifo來完成。 uvm_tlm_fifo是一個參數化的FIFO(先進先出隊列)，此FIFO同時擁有put export和get export. uvm_tlm_fifo實例化的參數就是需要在此FIFO中存儲的數據對象類型。其構造函數的參數代表了此FIFO的最大深度(缺省值是1).實例4-10: uvm_tlm_fifo的使用class produce

25、r_consumer_2 extends uvm_component;   producer producer_inst;   consumer_2 consumer2_inst;   uvm_tlm_fifo #(simple_packet) fifo_inst;   / fifo stores simple_packets   function new(string name, uvm_component parent);   &#

26、160; producer_inst = new("producer_inst", this);     consumer2_inst = new("consumer2_inst", this);     fifo_inst = new("fifo_inst", this, 16);  / set fifo depth to 16   endfunction   virtual function void

27、connect();     producer_inst.put_port.connect(fifo_inst.put_export);     consumer2_inst.get_port.connect(fifo_inst.get_export);   endfunction endclass運行此模塊時，生產者組件中的進程創建封包，同時將封包放入FIFO, 消費者組件在調用get方法的時候取出封包。由于FIFO的使用，這兩個進程的同步耦合關系被分開。每個進程的執行都可以任意延時

28、，使用FIFO以及阻塞性put/get調用可以確保沒有任何封包丟失。許多驗證環境建模時，對延時不敏感的特性以及確保事務(封包)能夠完好不丟失傳送的特性是非常需要的。UVM的TLM使得對此類系統建模非常容易。FIFO連接的圖形化示意如下： 圖4-4: 使用uvm_tlm_fifo 4.6.1.6 分析port和分析export（analysis port/analysis export)到目前為止，put/get port要求在仿真開始之前必須有且只有一個export與之相連接。如果port沒有連接，UVM會報告錯誤信息，要求你將之相連。有時候，我們需要構建類似監控

29、器(monitor)的組件，需要將一個port要么不連接，要么連接到一個或者多個組件上。這是因為監控器一般在整個驗證環境中是被動組件，他們不會影響仿真激勵的產生，也不會影響DUT(被測試模塊)的同步關系。監控器只是被動的收集事務數據，并將之發送給其他已經注冊的需要此數據的組件。分析port因此應運而生。分析port和其他TLM port類似，但是允許將其空接，也允許連接任意多個分析export。   圖4-5: 分析端口通訊對那些熟悉回調(callback)的人來說，分析port本質上就是結構化的回調函數（使用port連接的回調)每個分析port有一個void類型

30、的write()函數，其參數是一個transaction(事務)。每個分析port將維護一個與之相連接的分析export列表。當write方法以某個transaction作為參數被調用的時候，分析port將使用相同的transaction參數調用每個與之相連的分析port中的write函數。因為write方法是一個函數(function)，所以分析port的write函數將不會被阻塞，直接返回。另外，由于此write方法是一個void類型，在write函數返回后將不會傳遞任何狀態給組件。對包含分析port的組件的整體影響來說，可以不必去知道和關心與此分析port相連接的任何組件。實例4-11:

31、 使用分析port的監控器(Monitor)class packet_monitor extends uvm_component;   uvm_analysis_port #(simple_packet) analysis_port;   function new(string name, uvm_component parent);     analysis_port = new("analysis_port", this);   endfun

32、ction   virtual task run();     simple_packet p = new();     . / reassemble packet here from lower level protocol     analysis_port.write(p); / write the collected packet to the analysis port   endtask endclass實例4-1

33、2: 使用分析export的組件class packet_checker extends uvm_component;   uvm_analysis_imp #(simple_packet, packet_checker) analysis_export;   function new(string name, uvm_component parent);     analysis_export = new("analysis_export", this);

34、0;  endfunction   function void write (simple_packet p);     / check the packet here   endfunction endclass這兩個組件可以在父組件中被創建，然后使用UVM通用的TLM連接規則將分析port和分析exort相連接。上面提到，既然分析port允許多個分析export與之相連，可以例化多個具有分析export的組件，將他們連接到packet_monitor組件的分析port上。

35、有時候，通過分析port傳送的交易不能夠馬上被與之相連的下游組件處理，這些交易需要存儲一段時間之后才能夠被消耗處理掉。比如，當記分牌組件需要將DUT產生的真實封包和參考模型產生的封包進行比較的情形。在這種情況下，由于DUT需要延時，從參考模型產生的封包需要存儲下來。uvm_tlm_fifo能夠在需要的時候存儲封包，似乎可以很好的解決上述問題。然而，uvm_tlm_fifo并沒有一個分析export，所以不能直接將它連接到分析port上去。一個重要的原因是：在分析export中對write方法的實現要求傳遞transaction之后馬上返回，但是如果FIFO是有限的固定深度，就不是總能夠滿足這一

36、點。UVM使用uvm_tlm_analysis_fifo來解決此問題。uvm_tlm_analysis_port擁有一個分析export，因此可以直接和分析port相連，并且它的FIFO具有無限深度，所以write方法調用可以立即成功返回。 4.6.1.7 uvm_*_imp_decl宏有些情形，組件需要對相同的接口擁有多種實現。例如一個記分牌類需要對多個接口(比如兩個input和一個output)進行監測。在這種情況下，必須提供處理多個接口的方法。有3種潛在的解決方案：· 為每個特定的接口創建一個組件來實現. · 如果每個接口的交易類型相同，可以使用一

37、個實現；這個需要交易對象提供一個可以區分其來源的機制. · 對每個port創建_imp類型，每個_imp類型調用不同的功能實現函數.在UVM中，由于使用了uvm_*_imp_decl宏，使得第3種方式最簡單。這些宏用來創建新的實現類型，用來轉到不同的實現函數。比如，使用uvm_analysis_imp_decl(_1)，將會得到一個uvm_analysis_imp_1 #(type T)的類實現，此類中實現了對函數write_1的實現。小技巧: uvm_*_imp_decl宏的使用準則:· 由于此宏創建了新的類定義，最好將此宏放到一個共享的作用域，比如s

38、ystemverilog包. · 當組件確實需要對同一接口進行多種實現的時候，使用這些新類（類似標準的記分牌組件） · 使用通用的有意義的后綴。例如，后綴_inport1和_outport1就比較合理，因為它們提供了一些連接實現相關的信息 · 后綴以下劃線'_'開頭，讓實現函數名能夠通過下劃線分隔（比如write_inport1)實例4-13: uvm_*_imp_decl宏以下是使用宏的記分牌(scoreboard)的簡單示例.1. package my_analysis_imps_pkg;2.  

39、; import uvm_pkg:*;3.   include "uvm_macros.svh"4.   uvm_analysis_imp_decl(_inport1)5.   uvm_analysis_imp_decl(_inport2)6.   uvm_analysis_imp_decl(_outport2)7.   uvm_analysis_imp_decl(_outport2)8. endpackage: my_analysis_imps_pkg 9. package

40、 scoreboard_pkg:10.   import uvm_pkg:*;11.   include "uvm_macros.svh"12.   import my_analysis_imps_pkg:*;13.   import mytx_pkg:*;14.   mytx q1$, q2$;15.   class myscoreboard extends uvm_component;16.     uvm_analysis_imp_inport1#(my_tx, mys

41、coreboard) in_export_1;17.     uvm_analysis_imp_inport2#(my_tx, myscoreboard) in_export_2;18.     uvm_analysis_imp_outport1#(my_tx, myscoreboard) out_export_1;19.    uvm_analysis_imp_outport2#(my_tx, myscoreboard) out_export_2;20.   &#

42、160; function new(string name, uvm_component parent);21.        super.new(name,parent);22.        in_export_1 = new("in_export_1", this);23.        in_export_2 = new("in_export_2", this);24.        out_export_1 = new("out_export_1", this);25.        out_export_2 = new("out_export_2", this);26.     endfunction27.  &#