就像芯片本身一樣，SoC上的CSR設計也沿用了層級設計的方法。從最底層往上，寄存器可以被分為以下幾個層級。

1. Reg Field
2. Reg
3. Reg Block
4. Memory Map

下面我們就來一一簡單介紹一下，它們是如何在設計里面實現的。

1. Reg Field:

為了提升設計的效率，一個寄存器往往包含著許多功能的控制或是模塊的狀態，所以一個寄存器往往可以再向下分出幾個更小的配置單元來達到不同的目的。比如說下圖就是一個被設計了五個不同域的寄存器，每個域都有它特定的功能。

CSR中的不同域

A Register Block

2.Reg & Reg Block：

那么Reg本身不用說就是最常見的CSR unit了。而Reg Block則是根據SoC上不同模塊的Reg Collection組成的一個寄存器塊。比如對于SoC Top層的寄存器有控制 Direct Memory Access（DMA） 的也有監視中斷狀態的寄存器。一個模塊的寄存器往往都擁有同一個 offset address 。如下圖所示。

3. Memory Map：

一個SoC上通常都有一個或多個processor cores，direct memory access（DMA），bus network interconnects和許多種 peripheral module 。而每個外設模塊都擁有一個它所有CSR的 Reg Block 。Memory Map就是這些所有Reg Block的頂層模塊，并為每個Reg Block定義了不同的地址范圍，每個Block都有它一個對應的 base address 。而且對于不同的 processor core ，這些地址范圍還可能不一樣，根據不同的 rocessor bus（Maybe AHB or AXI） 。

A Memory Map

第二部分：UVM中關于CSR的驗證方法學

在了解UVM Reg Model這一部分之前，讓我們先了解一下它的一些來源吧。

At the begining, UVM_RGM is not part of the Accellera standard, it is a user contribution from Cadence which is based on their use contribution from the OVM. UVM1.1 has a Register Abstaction as a part of the Accellera standard called UVM_REG. There is already multiple vendors that supprot generations producing UVM_REG descriptions

這是來自一個論壇上對于UVM_REG的介紹。大致意思就是UVM_REG的前身是 UVM_RGM ，在加入到Accellera標準之前，它其實是一個民間創建的package。所以我們可以簡單理解UVM_REG就是一個UVM的library。

UVM_REG重新定義了TB和設計中的寄存器，它提供了一種不同的驗證方法來簡化對芯片上的寄存器的仿真。那么它到底是如何簡化的呢？

就像設計中寄存器的層級結構，在搭建寄存器驗證環境的時候我們當然也想要一個能模仿DUT中CSR行為的結構，所以UVM Reg Model也提供了

1. UVM Reg Field Class
2. UVm Reg Class
3. UVM Reg Block Class

1. UVM Reg Field Class:

正如前面所提，UVM將設計中的CSR每一層都抽象成了一種class。對于Reg Field而言就是uvm_reg_field這個class了。一般它在Reg Class中被聲明成rand類型的變量。

2. UVM Reg Class:

對于Reg本身，UVM定義了uvm_reg這一class，就像所有的Reg field需要繼承自uvm_reg_field一樣，寄存器驗證環境中的每個寄存器都要繼承自uvm_reg。如下code所示，Reg Field被聲明成rand類型的變量便于我們有時候做一些特殊的case，后面會介紹到。

就像所有uvm的class一樣，我們需要將它實例化才能夠真正使用它。這里我們看到一個函數——‘configure（）‘這個configure（）函數十分重要，它決定了這個寄存器中每個寄存器域的屬性，決定了這個域的訪問權限，是否具有失憶性等等。這在后面的驗證過程中十分重要！！！

在一個uvm_reg中聲明不同rand類型的域

3. UVM Reg Block Class:

當我們在環境里面定義了所有需要被仿真的寄存器后，就需要將它們集合在一起方便做一些更高層級的操作，就像DUT中的CSR一樣。這個時候我們就用到了uvm_reg_block這個class了。以下是一段uvm block的code。

在uvm_block中聲明所有這個block中的CSR

除了要聲明，實例化這些寄存器以外，也不要忘記使用configure（）定義這些寄存器的屬性，并將它們添加到default map當中。一個reg_block的對象就是一個Register model然后通過它可以訪問到里面所有的寄存器進行讀寫操作。

configure函數

第三部分：如何用UVM搭建CSR驗證環境

到目前為止，我們只知道了如何去構建一個類似于DUT中的寄存器仿真模型（有點reference model內味兒）。但如何讓環境中的寄存器模型“動起來”，like模擬DUT中CSR的讀寫操作還仍未知曉。

當然，這只是寄存器仿真環境的一部分，要想進行寄存器操作，我們還需要向bus發送bus transaction，就像直接通過普通的bus agent向外設寄存器配置接口發送讀寫的transaction一樣。

但在我們繼續這個環境的剩余部分之前我還需要向你們介紹UVM Reg中兩個重要的概念——Mirror Value和Desired Value。這兩個概念十分重要，對于理解后面UVM Reg內建的各種task和sequence幫助巨大！

Desired Value：

這個value可以理解成我們期望DUT寄存器中的值。寄存器模型中的這個變量其實就是我們預先設定好而后再更新同步到DUT中的寄存器里。如下圖：

CSR中的期望值

Mirrored Value：

而mirror value則是盡它最大的可能反應實際DUT中的值，每次我們通過寄存器模型發送讀寫操作到DUT中，對應寄存器的mirror value都會被更新。如下圖：

CSR中的鏡像值

實際上，整個寄存器環境一共有四個組成部分：

寄存器模型環境整體

1. Register Model
2. Agent
3. Adapter
4. Predictor

Register Model就是上文用了大量筆墨提到的一個組成部分。Agent也與其他常規驗證環境中的agent類似，依據不同的protocol將不同的transaction通過agent作為激勵送到DUT中。下面我們將重點介紹一下在寄存器環境中特有的兩個組成部分：Adapter和Predictor

Adapter：

由于寄存器模型中的seq有它特有的封裝方式，所以為了將寄存器模型類型的seq轉化成bus agent可識別的bus transaction，我們需要一個轉換器，同理來自bus agent的transaction也需要經過Adapter的轉換才能將來自DUT的信息同步到寄存器模型中。Adapter中最重要的兩個函數就是reg2bus() 和 bus2reg() 了，分別對應上述的兩個方向的transaction的轉化。

Predictor：

Predictor的作用也是用來同步寄存器模型中的值的。但經常，如果我們只通過寄存器模型里發起sequence，我們只擁有一個adpter就足夠同步寄存器模型里面的值通過寄存器模型built-in的task——read(),write()，因為這些內建的task中都有predict()函數，它的作用就是來將我們配置或從DUT收集來的值同步到寄存器模型中。但如果有一些配置DUT中寄存器的transaction來自于其他sequencer發送到bus agent的話，這個時候寄存器模型就不能實時的更新了，這有可能使我們最后的check mismatch。

所以predictor的main idea就是在環境中增添了一個連接agent中monitor的component來無時無刻監視著bus agent的動態，只要有任何write/read transaction經過，都會將其同步回寄存器模型中。

集成了predictor的寄存器模型環境

ok，現在我們已經具備了寄存器模型環境中的所有所需要的“磚頭”了，那么接下來就是如何將他們搭建成一個完整的房子了。如同其他所有驗證環境一樣，我們要在build phase將它們一個個實例化，然后在connect phase中再將它們銜接在一起。以下是一個簡易的寄存器模型環境的實例，僅供參考。

結語

寄存器雖然在整個芯片當中作為一個設計風險較小的組成部分，但在SoC驗證過程中是要優先完成驗證的部分。如果由于一個頂層寄存器的問題而導致一個芯片上大部分模塊無法正常工作是很耽誤驗證時效的。對于寄存器驗證來講，特別是一個有很多寄存器的芯片來講，如何通過UVM Reg進行高效，靈活的寄存器驗證十分重要！