建構驗證環境的内經

一、環境建構的四要素

在發送測試序列之前，首先需要建立一個結構化的環境，将環境建立的核心要素拆解開來，可以分為四個部分：

• 單元元件的自閉性
• 回歸建立
• 通信端口連接配接
• 頂層配置

二、單元元件的自閉性

自閉性指的是單元元件(例如

uvm_agent

或者

uvm_env

)自身可以成為獨立行為、不依賴于其它并行的元件。舉例來說，

driver

同

sequencer

之間，雖然

driver

需要擷取

sequencer

的

transaction item

，但是它本身可以獨立例化，而它們之間的通信也是基于TLM端對端的連接配接實作的。這種單元元件的自閉性為之後的元件複用提供了良好的基礎，各個子環境也可以獨立內建于頂層環境，互相也不需要額外的通信連接配接。

三、回歸建立

通過回歸建立這種方式，上一級的元件在例化自身(執行

new()

函數)之後，會執行各個phase階段，通過

build_phase

可以進一步建立子元件，而這些子元件也通過一樣的過程去建立下一級元件。

回歸建立之是以可以實作，這要依賴于自頂向下執行順序的

build_phase

。通過

build_phase

這種結構化執行順序可以保證父元件必先于子元件建立，而建立過程還包括：

• 在定義成員變量時賦予預設值，或者在

  new()

  函數賦予初始值。
• 結構配置變量用來決定元件的條件生成，例如

  uvm_agent

  依靠

  is_active

  變量來判斷是否需要例化

  uvm_sequencer

  和

  uvm_driver

  。
• 模式配置變量用來決定各個子元件的工作模式。
• 子元件按照自頂向下、從前到後的順序依次生成。

四、通信端口連接配接

在完成了整個環境建立以後，各個元件會通過通信端口的連接配接進行資料通信，常見的端口通信用途包括：

• driver

  的端口連接配接到

  sequencer

  ，并且對

  sequencer

  采取

  blocking pull

  的形式擷取

  transaction item

  。

• monitor

  的端口連接配接到

  scoreboard

  内部的

  analysis fifo

  ，将監測的資料寫入其中。

五、頂層配置

正式由于單元元件的自閉性，UVM結構不建議通過引用子環境句柄，繼而索引更深層次的變量進行頂層配置，是以會增加頂層環境同子環境的粘性，無法做到更好的分離。

是以更好的方式是通過配置化對象，作為綁定于頂層環境的部分傳遞到子環境，而子環境的各個元件又可以從結構化配置對象中擷取自身的配置參數，進而在

build_phase

、

connect_phase

以及

run_phase

中來決定它們的結構和運作模式。

頂層配置對象可以在子環境沒有例化時就将其配置到将來會建立的子環境當中，無需考慮頂層配置對象會先于子環境生成，這也為UVM驗證結構提供了安全的配置方式：

• 無論在哪一層使用配置，應該盡量将所有配置都置于子元件建立之前，保證配置已經完成。
• 配置的作用域應該隻關注目前層次及以下，而不涉及更高的層次。
• 配置的對象結構應該盡量獨立，最好同環境結構一樣形成一個樹狀結構。這樣獨立的配置對象會對應獨立的子環境，如果将獨立的配置合并為一個樹狀頂層配置結構，那麼頂層配置對象更便于使用和維護。
• 由于

  config_db

  的配置特性使得高層的配置會覆寫底層的配置，這也使得在

  uvm_test

  層次做出的配置可以控制整體的結構和模式。

頂層配置框圖

六、環境元素分類

将

uvm_test

層作為比

uvm_env

更高的層次繪制出來，這是因為

uvm_test

層會有一些配置的部分傳遞給子環境。包括構成環境的元件

uvm_component

在内，環境元素可以分為以下部分：

• 成員變量：一般變量、結構變量、模式變量。
• 子元件：固定元件、條件元件、引用元件。
• 子對象：自生對象、克隆對象、引用對象。

成員變量

• 一般變量用于對象内部的操作，或者為外部通路提供狀态值。
• 結構變量則用來決定内部子元件是否需要建立和連接配接，例如頂層的is_active變量即用作該目的。
• 模式變量用來控制元件的行為，例如

  driver

  變量經過模式配置，可以在

  run_phase

  做出不同的激勵行為。
• 對于結構變量和模式變量，一般由

  int

  或者

  enum

  類型定義，可以在

  uvm_test

  層通過

  uvm_config_db

  的配置方法直接設定，也可以通過結構化的配置對象來進行系統配置。對于複雜的驗證環境，配置對象的方式會容易操作和維護。

子元件

• 環境必須建立的元件稱之為固定元件，例如

  agent

  中的

  monitor

  無論對于

  active

  模式或者

  passive

  模式，都需要建立，又或者頂層環境中的

  scoreboard

  ，也需要建立來比較資料。
• 條件元件則是通過結構變量的配置來決定是否需要建立，例如

  sequencer

  和

  driver

  隻允許在

  active

  模式下建立。
• 引用元件是内部聲明一個類型句柄，同時通過自頂向下的句柄傳遞，使得該句柄可以指向外部的一個對象。例如在

  uvm_test

  一層，首先例化了一個寄存器模型

  rgm

  (固定元件)，其後将該模型的句柄通過配置傳遞到

  reg_env

  層中的

  rgm

  句柄(引用元件)。利用引用元件的方式，使得環境各個層次在需要的情況下，都可以共享一個元件。

子對象

• 在某一層中首先會建立一個對象，該對象可以稱之為自生對象。
• 對象傳遞過程中，該對象經過克隆進而生成一個成員數值相同的對象，稱之為克隆對象。
• 如果對象經過了端口傳遞，到達另一個元件，而該元件對其未經過克隆而直接進行操作的話，稱之為引用對象的操作。例如在

  virtual sequence

  會生成送往

  reg_master_agent

  和

  reg_slave_agent

  的

  transaction item

  ，分别是

  mst_t

  和

  slv_t

  ，這些連續發送的

  mst_t

  和

  slv_t

  通過

  uvm_sequencer

  ，最終到達

  uvm_driver

  。

  uvm_driver

  拿到這些transaction對象之後，如果首先進行克隆，而後利用克隆資料對象進行激勵是一種方式；

  uvm_driver

  也可以不克隆資料對象而直接對這些對象(引用對象)進行操作。