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

對於硬體有了解的讀者，都知道暫存器是模組之間互相交談的視窗。一方面可以通過讀出暫存器的狀態，獲取硬體當前的狀況，另外一方面也可以通過配置暫存器，使得暫存器工作在一定的模式下。而在驗證的過程中，暫存器的驗證也排在了驗證清單的前列，因為只有首先保證暫存器的功能正確，才會使得硬體與硬體之間的交談是“語義一致”，否則如果暫存器配置的結果與暫存器配置內容不同，那麼硬體無法工作在想要的模式下，同時暫存器也可能無法正確反映硬體的狀態。

本章我們關於UVM暫存器模型的介紹中，會將之前的設計MCDF中的暫存器模組簡化出來，通過硬體的暫存器模型、訪問的匯流排UVC以及暫存器模型之間建立一個小的驗證環境，以此貫穿本章的內容：

• 暫存器有關的工業流程。

• 暫存器模型的UVM類和類之間的關係。

• 如何將暫存器模型整合到現有環境，與匯流排UVC橋接，與DUT模型繫結。

• 暫存器模型的常用方法和預定義的sequence。

• 暫存器測試和功能覆蓋率的實際用例。

硬體中的各個功能模組都可以由處理器來配置功能以及訪問狀態，而與處理器的對話即是通過暫存器的讀寫來實現的。暫存器的硬體實現是通過觸發器，而每一個位元位的觸發器都相應代表了暫存器功能描述（function specification）表上的一位。一個暫存器一般由32個位元位構成，將單個暫存器拆分之後，又可以分為多個域（field），不同的域往往代表著某一項獨立的功能。單個的域可能由多個位元位構成，也可能由單一位元位構成，這取決於該域的功能模式可配置的數目。而不同的域，對於外部的讀寫而言，又大致可以分為WO（write-only，只寫），RO（read-only，只讀）和RW（read and write，讀寫），除過這些常見的操作屬性以外，還有一些特殊行為（quirky）的暫存器，例如寫後擦除模式（clean-on-read，RC），只寫一次模式（write-one-to-set，W1S）。我們在本章中主要講通用屬性的實現和使用，對於quirky屬性，讀者可以參考UVM cookbook。

MCDF中的暫存器模組描述如下：

地址0x00 通道1控制暫存器 32bits 讀寫暫存器

bit(0)：通道使能訊號。1為開啟，0位關閉。復位值為1。

bit(2:1)：優先順序。0為最高，3為最低。復位值為3。

bit(5:3)：資料包長度，解碼對應表為， 0對應長度4， 1對應長度8，2對應長度16，3對應長度32，其它數值（4-7）均暫時對應長度32。復位值為0。

bit(31:6)：保留位，無法寫入。復位值為0。

地址0x04 通道2控制暫存器 32bits 讀寫暫存器

同通道1控制暫存器描述。

地址0x08 通道3控制暫存器 32bits 讀寫暫存器

同通道1控制暫存器描述。

地址0x10 通道1狀態暫存器 32bits 只讀暫存器

bit(7:0)：上行資料從端FIFO的可寫餘量，同FIFO的資料餘量保持同步變化。復位值為FIFO的深度數。

bit(31:8)：保留位，復位值為0。

地址0x14 通道2狀態暫存器 32bits 只讀暫存器

同通道1狀態暫存器描述。

地址0x18 通道3狀態暫存器 32bits 只讀暫存器

同通道1狀態暫存器描述。

如果將它們用暫存器點陣圖來表示，那麼地址0x00和0x10的暫存器可以描述如下：

通常來將，一個暫存器有32位寬，暫存器按照地址索引的關係是按字對齊的（word-align），上圖中的暫存器有多個域，每個域的屬性也可以不相同，reserved域表示的是該域所包含的位元位暫時保留以作日後功能的擴充套件使用，而目前保留域的讀寫操作不起任何作為，即無法寫入而讀出值也是它的復位值。上面的這些暫存器按照地址排列，即可構成暫存器列表，我們稱之為暫存器塊（register block）。實際上，暫存器塊中除了包含暫存器，也可以包含儲存器，因為它們的屬性都近乎於讀寫功能，以及表示為同外界通訊的介面。我們如果將這些暫存器有機地組合在一起，那麼按照上面暫存器的地址描述，MCDF的暫存器功能模組即包含這樣一個register block：

在驗證MCDF暫存器模組的過程中，我們首先需要理清上面關於暫存器相關的概念，即一個暫存器，可以由多個域構成，而單個域可以包含多個位元位；一個功能模組中的多個暫存器和儲存可以組團構成一個暫存器模型（register model）。在上圖中讀者可以發現除了DUT中的暫存器模組（由硬體實現），還有屬於驗證環境的暫存器模型。從這兩個模組包含的暫存器資訊而言，是高度一致的，屬於驗證環境的暫存器模型也可以抽象出一個層次化的暫存器列表，該列表所包含的地址、域、屬性等資訊都與硬體一側的暫存器內容一致。而由軟體來建立的暫存器模型對於軟體開發和功能驗證都有幫助。對於功能驗證而言，可以通過將原本的匯流排級別的暫存器訪問方式抽象為由暫存器模型訪問的方式，這種方式使得暫存器後期的地址修改（例如基地址更改）或者域的新增都不會對已有的激勵構成影響，從而提高已有測試序列的複用程度。同時，暫存器模型在驗證過程中還有其它的優勢，我們將會在後面的《暫存器模型的常規方法》中重點介紹。

那麼，上面提到的軟體建立的暫存器模型如何可以保證與硬體實現的暫存器內容屬性保持精確一致呢？這離不開一份中心化管理的暫存器描述檔案，很多公司目前在使用XML格式的暫存器描述檔案，也有的一些公司在使用Excel（CSV）或者DOC等格式來儲存暫存器的描述。為什麼暫存器描述應該被中心化管理呢？這種管理也被稱之為唯一源方式（single-source mode）管理，與之相似的是我們在設計驗證流程剛開始的環節中就介紹到設計人員與驗證人員都應該與功能描述文件為唯一的功能實現及測試標準。這兩者之間相同的地方時都採用了唯一源的管理方式來儘量降低出現實現分歧的可能，只不過與功能描述文件不同的是，暫存器描述文件從根本上有條件可以使用更加結構化的文件描述方式，這也是為什麼可以通過XML或者Excel（CSV）等資料結構化的方式來實現暫存器的功能描述。

通過資料結構化的儲存方式，暫存器描述文件可以在硬體和軟體開發過程中被多次以不同方式來使用：

• 系統工程師會撰寫並維護暫存器描述檔案，而後歸置到中心化儲存路徑供其他工程師開發使用。

• 硬體工程師會利用暫存器描述檔案生成暫存器硬體模組（包含各個暫存器的硬體實現和匯流排訪問模組）。

• 驗證工程師會利用暫存器描述檔案來生成基於UVM的暫存器模型，以供驗證過程中的激勵使用、暫存器測試和功能覆蓋率收集。

• 軟體工程師會利用該檔案生成用於軟體開發的暫存器配置的標頭檔案（header file），從而提高軟體開發的可維護性。

• 暫存器描述檔案也可以用來生成文件，用可讀性更好的方式來方便閱讀。

驗證工程師需要的基於UVM的暫存器模型，既可以手寫，也可以由指令碼實現轉換。路桑推薦讀者找到合適自己的一種自動轉換的流程，原因很簡單因為手動轉換會有潛在的錯誤，而且暫存器越多出現錯誤的可能性越大，這樣會使得後期除錯的難度更大，因為verifier首先需要定位暫存器模型的錯誤時來自於轉換過程還是硬體自身。除此之外，路桑推薦一個暫存器生成器（指令碼）的原因還包括：

• 一個廣義的暫存器生成器（register generator），應該依據統一格式的暫存器描述檔案，來生成UVM暫存器模型（為驗證），或者硬體暫存器模組（被整合到設計中），或者生成標頭檔案（C語言）用來開發軟體等。

• 一個穩定的暫存器不但可以保證從文字資訊到暫存器模型的無錯誤轉換，還可以在轉換過程中通過語義檢查發現暫存器描述檔案違規的情況幫助修正暫存器描述檔案內容。

• 如果暫存器描述檔案內容有更新，暫存器生成器可以再次生成需要的暫存器相關格式，這對於流程化作業非常方便。

• 對於驗證所需的暫存器模型而言，一個更有效的做法是可以通過封裝已有的暫存器生成器，使得可以通過指定多個暫存器和其對應基地址（base address），繼而生成一個層次化的top register block，包含多個child register block。通過這種方式可以將更大的子系統或者系統級的暫存器模型歸納在一起，便於系統化的操作管理。

目前現有的EDA廠商都提供各自的暫存器生成器，例如MentorGraphics的Register Assistant、Synopsys VCS工具自帶的暫存器模型生成指令碼ralgen等。這些商業工具一般都需要一個統一的暫存器描述格式，而目前工業中主要推廣的格式當屬IP-XACT（IEEE-1685）。

http://www.accellera.org/downloads/standards/ip-xact/

關於IP-XACT，實際上它不單可以用來描述暫存器，任何結構化的內容都可以用它來描述，而這種XML格式的資料內容可以用來開發、實現和驗證電子系統。任何與IP-XACT類似的硬體描述結構化的資料方式都是為了便於生成器（generator）來快速構建一個準確的、靈活的硬體和軟體開發環境。而在IP-XACT還沒有成為IEEE標準之前，大公司和小公司都有各自資料格式化的方法，也許他們採用了基於XML而不同於IP-XACT規範的資料格式、也許採用了Excel(CSV)、DOC或者其它方式，那麼對於目前行業中依然沒有采用IP-XACT規範的開發流程，路桑給出幾點建議來幫助接下里實現指令碼自動化生成UVM暫存器模型的方法：

• 實現從公司自有資料正規化到IP-XACT規範的指令碼轉換，繼而可以在完成格式抓換之後通過現有的商業工具生成暫存器模型。

• 通過指令碼解析自有的資料正規化，並對映到對應的UVM暫存器模型上，通過自開發指令碼實現公司內部流程的開發閉環，繼而生成暫存器模型。

• 如果是初創公司，可以考慮採用IP-XACT資料結構，避免後期為了接入商業工具而因此二次開發的維護成本。