1. 程式人生 > >UVM暫存器篇之三:暫存器模型的整合(上)

UVM暫存器篇之三:暫存器模型的整合(上)

本文轉自:http://www.eetop.cn/blog/html/28/1561828-6266220.html

我們在上一節大致瞭解了與暫存器相關的流程,包括暫存器描述檔案和UVM暫存器模型生成。從上節給的暫存器模型流程圖中我們可以看到,接下來需要考慮選擇與DUT暫存器介面一致的匯流排UVC,該UVC會提供硬體級別的訪問方式。要完成一次硬體級別的匯流排傳輸,往往需要考慮給出地址、資料佇列、訪問方式等,而暫存器模型可以使得硬體級別的抽象級可以上升到暫存器級別。由此帶來的最直觀的好處在於,以往寫的由具體地址來指定的暫存器,將由暫存器名稱來替代,同時暫存器模型封裝的一些函式使得可以對域做直接操作,這一升級使得轉變後的測試序列更易讀。而當伴隨著專案變化,無論暫存器基地址如何變化,以暫存器級別實現的配置序列都要比以硬體級別的序列可維護性更好。

 

那麼如何將暫存器模型與匯流排UVC實現橋接呢?下圖中添加了更多的細節來表示暫存器橋接(adapter)的作用。

  • 從激勵的流向來看,暫存器序列(而不是匯流排序列)會將帶有目標暫存器的相關資訊存放到uvm_reg_item例項中,送往adapter。

  • adapter在接收到uvm_reg_item之後,需要從中抽取出匯流排UVC所需的資訊,同時生成匯流排UVC需要的bus_seq_item型別。在完成了資料內容抽取和二次寫入之後,bus_seq_item由adapter送往了匯流排UVC。

  • 匯流排UVC從bus_seq_item獲取了地址、資料、操作模式等資訊之後會發起匯流排的讀寫訪問。對於寫訪問而言,如果總線上有反饋訊號來標示訪問是否成功,則該標示應當由匯流排sequencer按照item response的路徑返回至adapter,adapter也應對該反饋訊號做出處理。這一反饋路徑在讀訪問時也會將匯流排讀回的資料返回至adapter,並最終交回到與暫存器操作有關的方法返回值。

 

對於暫存器模型而言,它生成之時並不會有adapter伴隨。實際上adapter的上層UVM暫存器包是一個標準包,但下層即各個匯流排UVC,考慮到匯流排協議的不同帶來的匯流排sequence item的不同、以及不同公司、團隊開發的同一種匯流排UVC也存在不小差異,因此adapter開發的責任就落到了匯流排UVC本身。而實際情況是,目前大多數商業匯流排UVC並沒有自帶暫存器adapter,而多數自研的匯流排UVC也並未顧及到adapter的開發。這裡,路桑提倡匯流排UVC的開發也應當將adapter一併囊括進去,這樣就將暫存器模型與匯流排UVC整合時的各自邊界劃分的很清晰,否則只能由TB構建者來實現不同匯流排的adapter,這無疑增加了額外的TB構建開銷。

 

但有的時候,事實如此,讀者現階段如果要整合暫存器模型,恐怕仍然需要掌握實現adapter的一些基本技巧,同時理解adapter充當抽象層轉化的原理。我們貫穿本章的材料依然是MCDF暫存器模組,以及接下來的較為簡單的訪問暫存器的匯流排UVC和對應的adapter實現。希望通過本節內容,讀者可以懂得依靠adapter來實現的前門(front-door)訪問和後門(back-door)訪問兩種方式。

 

匯流排UVC實現

MCDF訪問暫存器的匯流排介面時序較為簡單。控制暫存器介面上首先需要在每一個時鐘解析cmd,當cmd為寫指令時,即需要把資料cmd_data_in寫入到cmd_addr對應的暫存器中;當cmd為讀指令時,即需要從cmd_addr對應的暫存器中讀取資料,在下一個週期,cmd_addr對應的暫存器資料被輸送至cmd_data_out介面。

 

按照上面的時序,我們接下來給出一段8位地址線,32位資料線的匯流排UVC實現程式碼。

 

 

 

上面給出的程式碼囊括了mdf_bus_agent的所有元件:sequence item、sequencer、driver、monitor和agent。我們這些程式碼的部分實現給出解釋:

  • mcdf_bus_trans包括了可隨機化的資料成員cmd、addr、wdata和不可隨機化的rdata。rdata之所以沒有宣告為rand型別,是因為它應從匯流排讀入或者觀察,不應隨機化。

  • mcdf_bus_monitor會觀測匯流排,其後通過analysis port寫出到目標analysis元件,在本節中它稍後將連線到uvm_reg_predictor。

  • mcdf_bus_driver主要實現了匯流排驅動和復位功能,通過模組化的方法reset_listener()、drive_bus()、drive_write()、drive_read()和drive_idle()可以解析mcdf_bus_trans中的三種命令模式IDLE、WRITE和READ,並且在READ模式下,將讀回的資料通過item_done(rsp)寫回到sequencer和sequence一側。建議讀者在通過clone()命令建立RSP物件後,通過set_sequence_id()和set_transaction_id()兩個函式保證REQ和RSP的中保留的ID資訊一致。