SystemVerilog通用驗證方法（UVM）是一種生成測試和檢查結果以進行功能驗證的有效方法，最適合用于塊級IC或FPGA或其他“小型”系統。在UVM測試臺中，大多數活動是通過編寫序列來生成的，這些序列是驗證程序的主力要素，會導致諸如刺激物產生和結果檢查之類的事情發生。所以序列是您應該集中精力的事情。UVM有許多運動部件。考慮序列時，您可以專注于完成工作的程序。

產生序列項

導致其他順序發生

管理其他音序器上的音序

產生亂序交易

我們還將向您展示如何編寫自我檢查序列的代碼，并介紹在嘗試更高級的用法之前構建和編寫基本序列的基礎。最后，這些技巧將幫助您更輕松地編碼和調試UVM序列。

創建和運行UVM序列

如前所述，UVM序列是SystemVerilog代碼的集合，該代碼導致事件在測試平臺內發生。它們通常用于創建事務，將其隨機化，將其發送到定序器，然后再發送給驅動程序。在驅動程序中，生成的事務通常會引起接口引腳上的某些活動。

例如，如圖1所示，write_read_sequence可以生成隨機寫事務并將其發送到定序器和驅動程序。驅動程序將解釋寫入事務有效負載，并導致使用指定的地址和數據進行寫入。

圖1這是一個執行中的序列。

UVM序列是一個SystemVerilog對象，可以從許多不同的地方構造它，但是通常，測試可以構造序列然后運行它們-它們體現了測試。

例如，測試可能被偽編碼為：

加載所有內存位置
讀取所有內存位置，然后
檢查預期的值是否匹配。

可能有一個順序將所有存儲位置從A寫入到B。另一個順序是將所有存儲位置從A讀取到B。或更簡單的方法是：write_read_sequence首先寫入所有存儲位置，然后讀取所有存儲位置。

下面的測試在fork / join_none內部創建一個序列。將有四個并行運行的序列。每個序列都設置了一個LIMIT變量，并在fork / join_none的末尾開始運行。一旦完成所有分支，測試就完成了。

在下面的代碼my_sequence中，它是一個簡單的序列，可創建事務并將其發送到定序器和驅動程序。body（）任務已實現。這是一個簡單的for循環，它會循環LIMIT次。LIMIT是可以從外部設置的序列中的變量。

在for循環中，通過調用new（）或使用工廠來構造事務對象。然后，調用start_item以開始與音序器的交互。此時，定序器將停止執行序列，直到驅動程序準備就緒為止。一旦驅動程序準備就緒，定序器將使start_item返回。一旦start_item返回，則該序列已被授予使用驅動程序的權限。Start_item實際上應該稱為request_to_send。現在，該序列具有使用驅動程序的權限，它可以使事務隨機化，或根據需要設置數據值。這就是所謂的后期隨機化，這是理想的功能。事務應盡可能接近執行隨機化，這樣它們可以捕獲任何約束中的最新狀態信息。

在將事務隨機化并設置了數據值之后，將其發送到驅動程序以使用finish_item進行處理。Finish_item實際上應該稱為execute_item。此時，驅動程序將獲取事務句柄并執行它。一旦驅動程序調用item_done（），然后finish_item將返回并且交易已執行。

執行驅動程序

驅動程序代碼相對簡單。它從uvm_driver派生并包含run_phase。run_phase是由UVM核心自動啟動的線程。run_phase被實現為永遠的開始-結束循環。在開始到結束塊中，驅動程序調用seq_item_port.get_next_item（t）。這是一個將導致在音序器中執行的任務-本質上是向音序器詢問應執行的下一個事務。可能是沒有可用的事務，在這種情況下，此調用將被阻塞，即不會返回，因為它正在“等待某事”。（注意：可以使用其他非阻塞調用，但它們不在本文討論范圍之內，而不是建議的用法）。當定序器有要執行的事務時，那么get_next_item調用將取消阻塞并返回任務參數列表中的事務句柄（在下面的示例中為變量“ t”）。現在，驅動程序可以執行交易了。

對于此示例，執行很簡單–它使用事務convert2string（）調用打印一條消息，并等待由事務持續時間類成員變量控制的時間。
一旦執行完成，將調用seq_item_port.item_done（）來發信號通知定序器，并依次返回序列，表明事務已被執行。

虛擬序列及相關序列

序列可以具有其他序列的句柄；畢竟，序列只是一個具有數據成員的類對象，以及一個將作為線程運行的任務body（）。

虛擬序列是一種序列，它可能不會生成序列項，而是在其他音序器上啟動序列。這是從一個控制點創建并行操作的便捷方法。虛擬序列僅具有其他序列和定序器的句柄。它啟動它們或以其他方式管理它們。虛擬序列可能已經通過從上方分配，使用配置數據庫查找或其他方式獲取了序列發生器句柄。它可能已經構造了序列對象，或者已經通過類似的其他方式獲取了它們。

虛擬序列就像一個木偶大師，控制著其他序列。虛擬序列可能如下所示：

在下面的代碼段中，有兩個序列，即ping和pong。他們每個人都有彼此相處的地方。它們旨在輪流使用。第一個發送五個事務，然后另一個發送，依此類推。有關完整代碼，請參見附錄。

首先構造手柄，并設置運行極限。

自檢和流量生成器序列

自檢序列是導致一些活動，然后檢查結果是否正常的序列。最簡單的自檢序列在一個地址處發出寫操作，然后從同一地址進行讀操作。現在將讀取的數據與寫入的數據進行比較。在某些方面，序列成為黃金模型。

可以編寫視頻流量生成器以生成背景流量流，該流模擬或建模視頻顯示可能需要的數據量。視頻有最低帶寬要求。該計算將隨接口或總線上的負載而變化，但是對于此示例而言，簡單的計算就足夠了。視頻流量將每秒生成60次數據屏幕。每個屏幕將具有1920×1024點。每個點由一個32位字表示。使用這些數字，流量生成器必須每秒創建471MB。

更加完善的流量生成器將根據當前條件調整到達率-隨著其他流量的上升或下降，應調整視頻流量的生成率。

同步序列

序列將用于同步其他序列（所謂的虛擬序列）。通常，兩個序列之間必須有正式的關系。例如，他們不能一起進入其關鍵區域-他們必須成為單一文件。否則，它們只能在一些常見的關鍵區域通過后才能運行。

下面的代碼聲明了兩個要同步的序列（synchro_A_h和sync_B_h）。它還聲明了一個同步器。這些類沒有什么特別的-它們只是同意使用某種技術進行同步。

同步器控制非常簡單。它只是說GO 20滴答聲和STOP 100滴答聲。

同步的序列開始。他們運行完成，然后只需重新啟動即可。他們永遠運行。

使用同步器的類只有在被告知執行后才能執行。

在仿真中，序列等待直到同步器處于GO狀態。進入GO狀態后，同步代碼將使用new生成事務，然后調用start_item / finish_item來執行該事務。在等待訪問驅動程序并執行之后，同步序列返回到循環頂部并檢查同步器狀態。它將再次運行或停止/等待（圖2）。

圖2仿真中的同步器等待GO狀態。

實現中斷服務程序

序列將用于提供中斷服務程序。中斷服務程序會一直休眠直到需要時為止。這是一種獨特的序列。在此示例實現中，它創建一個中斷服務事務并執行start_item和finish_item。這樣，它可以將該ISR事務句柄發送給驅動程序。然后，驅動程序將握住該句柄，直到發生中斷。

驅動程序將其作為處理SystemVerilog接口的整體工作的一部分來處理中斷。在這種情況下，處理中斷意味著將一些數據放入保留的句柄中，然后將該句柄標記為完成。同時，中斷服務序列一直在等待事務被標記為完成。用某種說法，這被稱為真正完成的項目。在UVM中，還有其他機制可以處理此類問題，但它們比這種解決方案更不可靠且更復雜。

實用程序庫

序列實用程序庫將被創建和使用。實用程序庫是一些簡單的代碼，可用于序列編寫器，輔助函數或驗證過程的其他抽象。

下面的open_door序列正如其名稱所暗示的那樣工作。它為音序器和驅動器打開了大門。現在可以使用序列對象句柄（例如seq.read（）和seq.write（））隨意進行外部調用。

打開open_door，然后使用常規方法啟動。然后，測試程序可以像下面的紅線一樣簡單地發出讀寫操作。

從序列中調用C代碼

從序列調用C代碼（使用DPI-C）很容易，但是有一些限制。DPI導入和導出語句不能放置在類內部，因此在文件，全局或包范圍內，它們必須在類之外。因此，它們沒有設計或類對象范圍。

DPI-C導出功能或任務只是使用export命令導出的SystemVerilog功能或任務。

DPI-C導入函數或任務是具有返回值的C函數。對于任務，返回值為“ int”（有關詳細信息，請參見SystemVerilog LRM）。對于函數，返回值應為返回值。

下面定義了簡單的void函數c_code_add（）。它有兩個輸入，并在指針* z中返回一個值。此C函數調用導出的SystemVerilog函數sv_code（）。

dpiheader.h是檢查DPI-C API的便捷方法。在此示例中，dpiheader.h（下圖）非常簡單。

這個序列沒有什么特別的特殊之處。它生成事務，但確實調用了C函數（下面的c_code_add紅線）。就編寫調用C代碼的序列而言，實際上沒有什么特別的事情要做。DPI-C代碼必須正確編寫，并且必須在適當的范圍內聲明。

順序和交易記錄

在本文討論的示例代碼中，每個序列并行運行-在單個定序器上同時運行。在下面的兩個屏幕截圖（圖3和圖4）中可以很容易地看到，每個序列是如何輪流發送并在驅動程序上執行事務的。

圖3此展開視圖顯示了每個序列如何輪流發送和執行事務。

圖4這是事務的放大視圖。

Rich Edelman是西門子Mentor的高級驗證方法學家。

編輯：hfy