聲明：本人所有權屬路科驗證，本人僅為個人學習方便將文章整理至此。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
有了UVM的世界觀，知道這座城市的建築設計理念，也跟着碼師們（實在不忍心用碼農……）一起修建了各成獨立環境的組件群落。讀者們在經過一番實踐，經過上一章講的組件之間的通信方式，開辟了各個建築之間的道路、橋梁和河道以后，就可以進入緊張繁忙的物流期了。如果城市里面沒有交通，那么顯然不會有多熱鬧。
在本章中，我們將主要圍繞下面幾個核心詞來闡述它們的作用、主要分類以及之間的互動關系：
-
sequence item
-
sequence
-
sequencer
-
driver
如果按照交通道路的車流來打比方，sequence就是道路，sequence item是道路上行駛的貨車，sequencer是目的地的關卡，而driver便是最終目的地卸貨的地方。從軟件實施的層面來講，這里的貨車是從sequence一端出發的，再經過了sequencer，最終抵達了driver，經過driver的卸貨，每一輛的貨車也就完成了它的使命。而driver對每一件到站的貨物，經過它的掃面處理，將它分解為更小的信息量，提供給DUT。在這個過程中，不同的角色中有下面的這些軟件互動：
- sequence對象自身會產生目標數量的sequence item對象。借助於SV的隨機化和sequence item對隨機化的支持，使得產生的每個sequence item對象中的數據內容都不相同。
- 產生的sequence item會經過sequencer再流向driver。
- driver得到了每一個sequence item，經過數據解析，再將數據按照與DUT的物理接口協議寫入到接口上，對DUT形成有效激勵。
- 如果有必要的時候，driver在每解析並且消化完一個sequence item，它也會將最后的狀態信息同sequence item對象本身再度返回給sequencer，最終抵達sequence對象一側。這么做的目的在於，有的時候sequence需要得知driver與DUT互動的狀態，這就需要driver仍然有一個回路再將處理了的sequence item對象和狀態信息寫回到sequence一側。
貫穿本章的幾個重要概念，在上面的互動中可以看到，sequence item是每一次driver與DUT互動的最小粒度內容。例如，DUT如果是一個slave端，driver扮演master去訪問DUT的寄存器，那么sequence item的需要定義的數據信息至少包括訪問地址、命令碼、數據和狀態值，這樣的信息在driver取得以后，會用時序的方式在interface一側激勵送給DUT。按照一般總線做寄存器訪問的方式，這樣的訪問在時序上大致會保持幾個時鍾周期，直至數據傳送完畢，而由driver再准備發起下一次的操作。用戶除了可以在聲明sequence item時，添加必要的成員變量，也可以添加對這些成員變量進行操作的成員方法。這些添加了的成員變量，需要充分考慮在通過sequencer傳遞到driver前是否需要隨機化，例如上面提到的例子中的訪問地址和數據等等，都應該通過SV關鍵詞rand聲明為可以隨機化的變量，以便后期進行隨機化處理。
那么對於一個sequence而言，它會產生多個sequence item，也可以產生多個sequence。從產生層次來看，sequence item是最小粒度，它可以由sequence生成，而相關sequence也可以進一步組織和實現層次化，最終由更上層的sequence進行調度。這么看來，sequence可以看做是產生激勵內容的載體。
在sequence與driver之間起到橋梁作用的是sequencer。由於sequencer與driver均是component組件，它們之間的通信也是通過TLM端口實現的。
在上一章中提到過，TLM端口在例化中需要對通信參數進行指定，這里的通信參數即sequence item種類。由於這一限制，使得sequencer到driver的傳輸數據類型不能改變，同時與sequencer掛接的sequence內創建的sequence item類型也應為指定類型。這就跟一個投幣機的原理有一些類似，如果顧客投遞的是1塊錢，那么它會被識別到相應的儲幣區域，而如果顧客投遞的是5毛錢，那么它肯定會被區別對待的。
在激勵驅動鏈的最后一道關卡是driver。這個家伙胃口還蠻挑剔的。它就跟投幣機一樣只認了同一個類型的“鋼鏰兒”。對於常見的用法，driver往往是一個sequence item消化完，報告給sequencer和sequence，同時再請求消化下一個sequence item。所以，driver看起來永遠喂不飽，同時還又對食物很挑剔。在消化每一個sequence item之前，該item中的數據是已經隨機化好的，所以每個item一般都是各不相同的。driver自己並不會輕易修改item中的值，它會把item中的數據按照與DUT連接接口的物理協議按照時序關系驅動到端口上面。例如對於一個標准的寫操作，driver不但需要按照時序依次驅動地址總線、命令碼總線和數據總線，還應該等待從端的返回信號和狀態值，這樣才算完成了一次數據寫傳輸。又如果是一個讀操作，driver還應該在驅動完地址總線和命令碼總線之后，等待返回信號、狀態值和讀出的數據，並且在有需要的情況下，將讀出的數據再寫回到sequence item中，通過sequencer最后返回給sequence。
從類的繼承性來看，uvm_sequence_item和uvm_sequence是基於uvm_object，這不同於uvm_component可以在build階段作為UVM環境的“不動產”創建和配置，而是可以在任何的階段創建。這種類的繼承帶來的UVM應用區別在於：
- 由於無法判定環境在run階段運行什么時間點會創建sequence和掛載（attach）到sequencer上面，所以無法通過簡單的UVM結構來識別sequence的運行階段。
- 正是由於uvm_object獨立於build階段之外，這使得用戶可以有選擇地、動態地在合適的時間點掛載想要的sequence和item。
- 考慮到uvm_sequence和uvm_sequence_item並不處於UVM結構當中，所以頂層在做配置時，無法按照層次關系直接配置到sequence中。而如果sequence一旦活動起來，那么它必須掛載到一個sequencer上，這樣sequence可以依賴於sequencer的結構關系，間接通過sequencer來獲取頂層的配置和更多的頂層信息。
在本文的最后，需要額外提出的一點是，從常規的認知方式來看，用戶可能更願意將時序控制的權利賦予sequence。這種從sequence產生item，繼而將item通過sequencer推送給driver的方式，實際上有一些“越俎代庖”的嫌疑。畢竟如果按照責任明確划分的話，sequence應該是只負責生成item的內容，而不應該控制item消化的方式和時序，而驅動激勵的時序這一任務應當由driver來完成。讀到這里，也許一些讀者可能會困惑，畢竟實際應用中，我們可以添加一些實用的時間延遲或者事件觸發來控制item的生成和傳送，但是請注意，item的生成和傳送，並不是直接表示了最終的驅動時序，決定這一點的還包括sequencer和driver。
sequencer之所以作為一個“路由”管道，停在sequence和driver之間，看重的是它的兩個特點：
-
sequencer作為一個組件，它可以通過TLM端口與driver傳送item對象。
-
sequencer在面向多個並行sequence時，它有充分的仲裁機制來實現合理分配item傳送來模擬並行item數據傳送至driver的測試場景。
那么是否sequencer應該從sequence一側得到item數據，再推送給driver呢？或者，在sequence、sequencer與driver之間發生的數據傳送請求應由誰首先發出？而數據流向又是從誰到誰呢？關於這一個具體的TLM傳輸機制，我們將會在其后的《sequencer和driver》中詳細介紹。而在這里，希望讀者首先認清的是，數據傳送機制采用的是get模式，而不是put模式。我們在TLM傳輸中為讀者們就介紹過典型的兩種數據傳送場景，如果是put模式，那么應該是sequencer將數據put到driver，而如果是get模式，那么應當是driver從sequencer獲取item。之所以選擇get模式，UVM是基於下面的考慮：
-
如果是get模式，那么當item從sequence產生，穿過sequencer到達driver時，我們就可以結束該傳輸（假如不需要返回值的話）。而如果是put模式，則必須是sequencer將item傳送至driver，同時必須收到返回值才可以發起下一次的傳輸。這從效率上看，是有差別的。
-
如果需要讓sequencer擁有仲裁特性，可以使得多個sequence同時掛載到sequencer上面，那么get模式更符合“工學設計”。這是因為driver作為initiator，一旦發出get請求，它會先通過sequencer，繼而獲得仲裁后的item。
如果讀者對於究竟應該采用get模式還是put模式有疑問的話，不妨想象一個極端的情況，sequence的職責如果僅僅是個“水池”，那么用水的權利應該交給終端的driver，還是交給作為調度站的sequencer呢？
作為一個開着item，或者坐到sequence中瀏覽觀光的新手，讀者們可以伴隨路桑在下一節《sequence和item》中欣賞這兩個對象之間各種悱惻纏綿的關系。
謝謝你對路科驗證的關注，也歡迎你分享和轉發真正的技術價值，你的支持是我們保持前行的動力。