在之前簡單介紹了uvm_reg_predic是怎么實現(xiàn)顯示預(yù)測的，連上map，連上adapter，連上bus_in即可，下面我們要詳細的解釋原因
先解釋uvm_reg_predict中重要變量的作用

uvm_reg_map map : 從bus總線上上采樣到addr信息之后，有map根據(jù)addr尋找到RAL中相關(guān)寄存器句柄 uvm_reg_adapter adapter:從bus總線上上采樣到addr信息之后，調(diào)用adapter.bust2reg實現(xiàn)transaction 轉(zhuǎn)換 uvm_analysis_imp#(BUSTYPE,uvm_reg_predict#(BUSTYPE)) bus_in :TLM 端口

核心方法write()，下面總結(jié)了這個方法具體做的事情

(1) 判斷adapter是否為null (2) 應(yīng)該增加判斷map是否為null(雖然UVM源碼中沒有實現(xiàn)，嚴(yán)謹(jǐn)?shù)慕嵌葢?yīng)該判斷)//注意這里掛載的map的必須是root_map。 (3) adapter.bus2reg// transaction轉(zhuǎn)換 (4) map.get_reg_by_offset //獲取RAL中reg句柄 (5) 獲取reg所在local_map的map_info//獲取reg的直連map的map_info信息 (6) 根據(jù)map_info信息調(diào)用uvm_reg::do_predict//實現(xiàn)預(yù)測,包的括多地址的處理情況

上面即為實現(xiàn)顯示預(yù)測的全步驟
下面介紹一下當(dāng)register 位寬大于bus_width的時候，uvm_reg_predict是如何處理的
這種情況比較特殊，具體看下面的流程。

（1）基本流程和上面相似，下面說一下不同之處 （2）比如register 位寬是64bit，bus_width是32bit，均以小端模式來說 （3）首先uvm_reg_prdictor采樣到了monitor發(fā)送來的寄存器低地址（比如00），這個時候 將采樣的地址暫時保存起來 （4）接著uvm_reg_prdictor采樣到了monitor發(fā)送來的寄存器低地址（04）這個時候?qū)?采樣的數(shù)據(jù)也保存到同樣的地方 （5）判斷發(fā)現(xiàn)現(xiàn)在暫時的空間中已經(jīng)有2個32bit的數(shù)據(jù)了，與之前map_info中存儲的地址的個數(shù)一樣，2個地址（mp_info中存放了該寄存器的低地址和高地址），這個時候才會調(diào)用 uvm_reg::do_predictor去update mirror value

所有不管是哪種模式，uvm_reg_predict必須采樣到一個寄存器的的完整數(shù)據(jù)才會去做predict 工作。
同時在做predict的時候uvm_reg_predictor默認是打開寄存器的byte_en使能，所有的byte均可以update，因此我們在adapter中重載bus2reg時如果有相關(guān)方面的需求，是無法實現(xiàn)的，我們可以去重載uvm_reg_predictor::write方法來實現(xiàn)。
在uvm_reg_predict還有一個變量 uvm_analysis_port #(uvm_reg_item) reg_an

這個TLM 端口的作用是在進行預(yù)測完之后，將相關(guān)的uvm_reg_item transaction發(fā)送出去，有時候我們可能有這方面的需求，

總結(jié)：

（1）掛載的map必須是root_map,這樣才能對全局所有寄存器可見
（2）掛載的adapter可以是local_adapter或者root_adapter
（3）byte_en默認是全打開的
（4）所有不管是哪種模式，uvm_reg_predict必須采樣到一個寄存器的的完整數(shù)據(jù)才會去做predict 工作。
(5)根據(jù)需要可以對write方法進行重載

總結(jié)

以上是生活随笔為你收集整理的UVM RAL 中的显示预测 uvm_reg_predictor的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。