當我開始使用 UVM RAL 時，我無法理解 UVM 基類庫對更新所需值和鏡像值寄存器的值有什么看法。我還認為，所使用的術語沒有準確反映其意圖。花了一些時間后，我想出了一個表，幫助我了解寄存器模型 API 的行為，以及如何最好地調用它們。

在介紹該表之前，讓我們看一下創建寄存器模型的過程：

創建寄存器格式規范

將規范轉換為 UVM 寄存器模型

使用寄存器模型

創建寄存器格式規范：有許多寄存器格式可用于描述設計人員的寄存器規范。您可能熟悉廣泛使用的 Synopsys RALF 格式。下圖說明了使用 Synopsys Ralgen 工具將 RALF 格式轉換為寄存器模型的流程。虛線表示您可以為不同的方法生成寄存器模型：

使用寄存器模型：寄存器模型具有一組用于所需寄存器值和鏡像寄存器值的變量。該文檔使用術語“所需”和“鏡像”，但為了避免混淆，我在下面將它們稱為“主”和“鏡像”。鏡像變量的目的是始終保存或表示 RTL 的值，以便它可以用作記分板。有一堆 API 可用于對這些變量進行操作。這里的目的是闡明在模擬期間調用任何這些 API 時主變量和鏡像變量會發生什么情況。

讓我們看一下可用的 API。我將它們分為三類：主動、被動和間接。

積極：物理事務在總線上執行讀取和寫入操作。Read（）、write（）、update（） 和 mirror（） 是使用物理接口在 DUT 上運行的活動 API。您可以選擇使用后門機制，在這種情況下，它不會消耗模擬周期。您可以期待與使用前門訪問時發生的相同的 RTL 寄存器行為.

被動：僅使用寄存器模型運行。set（）、get（） 和 predict（） 是直接在模型上運行的被動 API。我也稱 peek（） 為被動，因為這不會在讀取過程中更改寄存器值。例如，讀取以清除寄存器 – 在執行 peek（） 時不會被清除。

間接：有一組API間接地在DUT上運行，它們是peek（）和poke（）。請注意，peek（） 和 poke（） API 只是后門訪問。雖然 poke 可以更新 RTL 寄存器，但它無法模擬物理讀取期間可能發生的實際寄存器行為。例如，寫一個要清除。

讓我們簡要介紹一下廣泛使用的 API 定義。您可以在 UVM 類參考指南中找到更多詳細信息。

讀取（）：使用前門或后門訪問從 DUT 寄存器讀取值。

寫（）：使用前門或后門訪問更新 DUT 寄存器。

更新（）：如果使用 set（） 更改了主寄存器變量中的任何值，則可以使用此方法（批量更新）在 DUT 中寫入所有這些寄存器。您可以調用單獨的 write（） 方法來獲得相同的結果。

鏡像（）： 鏡像維護 DUT 寄存器值的副本。Mirror（） 方法讀取寄存器，如果啟用了檢查，則可以選擇將讀回值與當前鏡像值進行比較。 鏡像可以使用物理接口（前門）或 peek（）（后門）機制執行。

躲貓貓（）：使用后門訪問機制從 DUT 寄存器讀取值。

Poke（）：使用后門訪問機制將 DUT 寄存器寫入指定值。

預測（）： 可以使用此方法將鏡像變量值更改為預期值。

我運行了一些實驗，下表顯示了從測試臺執行任何這些 API 時寄存器模型和 DUT 中會發生什么。

縮寫
UMV – 更新主變量， UMrV – 更新鏡像變量， AP – 自動預測
RDR – 讀取 DUT 寄存器， UDR – 更新 DUT 寄存器， RMV – 讀取主變量
FD – 前門， BD – 后門， * – 檢查是否使用了UVM_CHEK， NA – 不適用

要記住的幾點

我沒想到 peek（） 和 poke（） 方法會無條件更新鏡像值。在查看了 UVM 源代碼后，我發現 do_predit（） 方法在 peek（） 和 poke（） 方法中被無條件調用。我還注意到，使用后門機制的 write（） 和 read（） 方法會在調用 do_predict（） 時更新鏡像寄存器，而無需檢查此 get_auto_predict（） 方法的輸出。我看到唯一有條件調用的地方是具有前門訪問權限的 write （） 和 read（） 方法。

在與專家討論后，我了解到預期功能是確保鏡像變量具有最新的寄存器值。類似地，使用后門訪問的read（）/write（）更新鏡像寄存器 — 這也是有意為之的。由于使用了后門程序，因此物理接口上不會觀察到（當自動預測關閉時）來更新寄存器模型。因此，在所有情況下都必須對其進行更新。

審核編輯：郭婷