item指的是uvm_sequence_item， Sequence Item具備UVM核心基類所必要的數據操作方法，對于激勵的生成和場景控制，是由sequence來編織的，item應該有什么用途的數據成員被定義在item中呢？文章進行了劃分。

無論是自駕item，穿過sequencer交通站，通往終點driver，還是坐上sequence的大巴，一路沿途觀光，最終跟隨導游停靠到風景點driver，在介紹如何駕駛item和sequence，遵守什么交規，最終可以有序地穿過sequencer抵達driver之前，讀者又必要首先認識sequence與item之間的關系。這里的sequence值的是類uvm_sequence，而item指的是uvm_sequence_item，為了文章的簡潔，我們稱之為sequence和item。對于激勵的生成和場景控制，是由sequence來編織的，而對于激勵所需要的具體數據和控制要求，則是從item中的成員數據得來的。

Sequence Item

我們已經提出item是基于uvm_object，這表明了它具備UVM核心基類所必要的數據操作方法，例如copy、clone、compare、record等，這里我們不再做贅述。讀者需要了解到的是，通常對于一個item，應該有什么用途的數據成員被定義在item中呢？我們可以將它們劃分下如下幾類：

控制類。譬如總線協議上的讀寫類型、數據長度、傳送模式等。

負載類。一般即數據總線上的數據包。

配置類。這往往是用來控制driver的驅動行為，例如命令driver的發送間隔或者有無錯誤插入。

調試類。用來標記一些額外的信息，用來方便調試，例如該對象的實例序號、創建時間、被driver解析的時間始末等。

下面的例碼是一段item的定義，從這段代碼中讀者可以看到上面提到的各種用途的數據使用情況：

輸出結果：

上面的這段代碼中，不但給出了一個較為典型的item定義，同時也伴有一些item使用時的特點：

如果數據域屬于將來需要用來做驅動，那么用戶應考慮定義為rand類型，同時按照驅動協議給出合適的constraint。

由于item本身的數據屬性，為了充分利用UVM域聲明的特性，我們建議將必要的數據成員都通過`uvm_field_xxx宏來聲明，以便日后的基本函數操作，例如上面的print（）函數。

讀者也注意到了一點，上面的例子中，t1沒有隨機化而t2隨機化了，這種差別在item通往sequencer之前是很明顯的。因為UVM要求item的創建和隨機化都應該發生在sequence的body（）任務中，而不是在sequencer或者driver中。

如果按照item對象的生命周期來區分，它的生命應該開始于sequence中的創建，而后經歷了隨機化和穿越sequencer最終到達driver，直到被driver消化之后，它的生命周期一般來講才算壽終正寢。之所以要突出這一點，是因為一些用戶在實際中，會不恰當地直接操作item對象，直接修改其中的數據，或者將它的句柄發送給其它組件使用，這就無形中修改了item的基因，或者延長了一個item對象的壽命。這種不合適的對象操作方式是用戶需要注意的，可以取代的方式則是合理利用copy和clone等方法。

接下來我們需要理清item和sequence，以及sequence群落之間的關系。從簡而言，一個sequence包含了一些有序組織起來的item實例，考慮到item在創建后需要被隨機化，sequence在聲明時也需要預留一些可供外部隨機化的變量，這些隨機變量一部分是用來通過層級傳遞來控制item對象中的變量的，一部分也是用來對item對象之間加以組織和時序控制的。為了加以區分幾種常見的sequence定義方式，我們在介紹后續的sequence之前，首先將sequence可以分類為：

扁平類（flat sequence）。這一類中往往只用來組織更細小的粒度，即item示例的組織。

層次類（hierarchical sequence）。這一類則是由更高層的sequence用來組織底層的sequence，進而讓這些sequence或者按照順序的方式，或者按照并行的方式，掛載到同一個sequencer上。

虛擬類（virtual sequence）。這一類則是最終控制整個測試場景的方式，鑒于整個環境中往往存在不同種類的sequencer和其對應的sequence，我們需要一個虛擬的sequence來協調頂層的測試場景。之所以稱這個方式為virtual sequence，是因為該序列本省并不固定掛載于某一種sequencer類型上，而是它會將其內部的各種不同類型的sequence最終掛載到不同的目標sequencer上面。這也是最大的不同于hierarchical sequence的一點。