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

mem與reg的聯絡和差別

UVM暫存器模型也可以用來對儲存建模。uvm_mem類可以用來模擬RW（讀寫）、RO（只讀）和WO（只寫）型別的儲存，並且可以配置其模型的資料寬度和地址範圍。而uvm_mem不同於uvm_reg的地方在於，考慮到物理儲存一旦對映到uvm_mem會帶來更大的資源消耗，因此uvm_mem並不支援預測和影子儲存（shadow storage）功能，即沒有預期值和期望值。uvm_mem可以提供的功能就是利用自帶的儲存訪問方法去訪問硬體儲存，相比於直接利用硬體匯流排UVC進行訪問，這麼做的好處在於：

• 類似於暫存器模型訪問暫存器，利用儲存模型訪問硬體儲存便於維護和複用。

• 在訪問過程中，可以利用模型的地址範圍來測試硬體的地址範圍是否全部覆蓋。

• 由於uvm_mem也同時提供前門訪問和後門訪問，這使得儲存測試可以考慮現在先期通過後門訪問預先載入儲存內容，而後通過前門訪問讀取儲存內容，繼而做資料比對，這樣做不但節省時間，同時也在測試方式上保持了前後一致性（即只需要選擇後門訪問還是前門訪問）。這種方式與傳統的測試方式，即利用系統函式或者模擬器函式實現儲存載入，要在UVM的測試框架中更為統一。

與uvm_reg相比，uvm_mem不但擁有常規的訪問方法read()、write()、peek()和poke()，也提供了burst_read()和burst_write()。之所以額外提供這兩種方法，不但是為了更高速地通過物理匯流排BURST方式連續方法儲存，也是為了儘可能貼合實際訪問儲存中的場景。要實現BURST訪問形式，需要考慮下面這些因素：

• 目前掛載的匯流排UVC是否支援BURST形式訪問，例如APB不能支援BURST訪問模式。

• 與read()、write()方法相比，burst_read()和burst_write()的引數列表中的一項uvm_reg_data_t value[]採用的是陣列形式，不再是單一變數，即表示使用者可以傳遞多個數據。而在後臺，這些資料首先需要裝載到uvm_reg_item物件中，裝載時value陣列可以直接寫入，另外兩個成員需要分別指定為element_kind = UVM_MEM，kind = UVM_BURST_READ。

• 在adapter實現中，也需要考慮到儲存模型BURST訪問的情形，即需要考慮到四種訪問型別（uvm_access_e）下的轉換，即UVM_READ、UVM_WRITE、UVM_BURST_READ和UVM_BURST_WRITE。對於UVM_READ和UVM_WRITE的橋接，已經在暫存器模型訪問中實現，而UVM_BURST_READ和UVM_BURST_WRITE的轉換，往往需要考慮寫入的資料長度和，例如長度是否是4、8、16或者其它。譬如AHB匯流排，支援連續4個、8個、16個數據的讀寫（INCR4、INCR8、INCR16），但是如果資料長度不是這些固定長度時，adapter還需要自己處理來實現INCR的連續訪問方式。

• 此外，還需要考慮不同匯流排的其它控制引數，例如AHB支援WRAP模式，AXI支援out-of-order模式等，如果想要將更多的匯流排控制封裝在adapter的橋接功能裡，需要將更多的配置作為擴充套件配置，在呼叫訪問方法時，一併傳入到引數uvm_object extension。待傳入後，adapter將可以在橋接方法中抽取出額外的配置，作為選擇更準確的協議訪問的限定依據。

• 對於更為複雜的BURST形式，如果需要實現更多的協議配置要求，那麼路桑推薦直接在匯流排UVC層面去驅動。這樣做的靈活性更大，且更能充分全面的測試儲存介面的協議層完備性。因此，verifier在為儲存模型訪問實現adapter方法時，需要考慮的是，uvm_mem層面的方法應該儘量便捷、必要的引數少，以便於使用和維護；而另外一方面，如果要首先測試儲存介面，則應該在匯流排UVC的層面上更充分的完成驗證。

內建（built-in）sequences

不少有經驗的UVM使用者可能會忽略UVM針對暫存器模型內建的一些sequence，實際上如果可以將這些自建的序列作為驗證專案一開始的健康檢查必選項的話，這對於整個專案的平穩執行會有不小的貢獻。這是因為在專案一開始的階段，設計內部的邏輯還不穩定，對於verifier而言，如果想要同步跟上設計的進度，可以展開驗證的部分無外乎是系統控制訊號（時鐘、復位、電源）和暫存器的驗證。在早期時，暫存器模型的驗證可以為後期各個功能點驗證打下良好的基礎。比如，通過內建的暫存器或者儲存序列可以實現完善的暫存器復位值檢查，又比如檢查讀寫暫存器的讀寫功能是否正常等。

不過有一些暫存器即便可以測試，也建議將其作為例外而過濾出去，例如一些重要的系統控制訊號（時鐘、復位、電源），當寫入某些值以後，會使得系統全部或者區域性復位、時鐘也可能被關閉，這就可能阻礙暫存器的下一步檢查。所以UVM提供了一些特殊域，用來禁止一些sequence檢查這些暫存器或者儲存。接下來，我們來瀏覽整理出來的暫存器和儲存相關的自建sequence。

暫存器模型內建序列

儲存模型內建序列

接下來我們給出一段例碼，繼之前MCDF測試暫存器的例子，用來演示如何利用內建序列完成暫存器測試一開始的健康檢查。下面的例碼分別添加了uvm_reg_hw_reset_seq、uvm_reg_bit_bash_seq和uvm_reg_access_seq來測試暫存器模型，從程式碼的整潔性來看，使用者並不需要額外再新增什麼，這種使用方式非常方便，且又能完成暫存器的大規模整合測試。

對於一些暫存器，如果像將其排除在某些內建序列測試範圍之外，使用者可以額外新增上面列表中提到的“禁止域名”。由於uvm_reg_block和uvm_reg均是uvm_object類而不是uvm_component類，所以可以使用uvm_resource_db來配置“禁止域名”。下面的程式碼摘自mcdf_rgm::build()方法，這相當於暫存器模型在自己的建立階段設定了一些屬性，當然，uvm_resource_db的配置也可以在更高層指定，只不過考慮到uvm_resource_db不具備層次化的覆蓋屬性，我們建議只在一個地方進行“禁止域名”的配置。