當我們驗證片上系統（SoC）嵌入了具有多個數字外設的微處理器以及可能的模擬模塊時，我們希望檢查所有實現的功能和可能的極端情況，以最大限度地縮短驗證時間。多種技術和方法的混合用于改進功能驗證并提取覆蓋等級的度量：基于通用驗證方法（UVM）的形式驗證和隨機約束測試增加了發現錯誤的可能性。有時我們為RTL驗證創建一個完美有效的測試，但發現它不能在門級仿真期間重復使用，因為UVM監視器掛在內部SoC信號上，這些信號在實現階段后可能會消失或改變。

本文將描述創建有效的自檢模型是多么容易，這些測試既簡單又可以在門級模擬過程中重復使用。令人驚訝的是，通過改變數據流，我們可以為測試平臺帶來好處，降低記分板的復雜性，這也意味著更少的測試開發時間。

流程基于實例化UVM驗證用于檢查接口的組件，例如SPI，I 2 C，＆amp; UART，但它也可以擴展到更復雜的接口。

SoC驗證流程

最有效的SoC驗證是基于內部總線內部，特定內部模塊和主SoC接口上的多個UVM驗證組件（UVM VC）的實例化。這些UVM VC用作總線協議檢查器（例如，AMBA檢查器）;串行協議檢查器和主動主控器（例如，I 2 C，SPI，UART，JTAG，SATA，PCIe）。

基于UVM開發的測試應該是自檢的;必須通過檢查器驗證每個操作，激勵和事務，如果不匹配，會引發一個“標志”，停止模擬并發出模擬器控制臺上顯示的錯誤消息并寫入日志文件。

通信接口（例如，SPI）的驗證需要使用由在總線上獲取事務的收集器形成的UVM VC，用于檢查協議合規性的監視器以及生成的生成的總線功能模型（BFM）交易。 SoC和外部UVM VC之間交換的數據通過名為記分板的模塊進行驗證。

此記分板至少有兩個端口，其中添加的對象與第二個相匹配 - 參考。如果不匹配，則發出錯誤。在門級仿真期間必須重復使用這種檢查器以刺激關鍵路徑。圖1顯示了驗證測試平臺的簡單框圖，該平臺使用多個檢查器進行有效的驗證方法。

圖1：典型的UVM驗證測試平臺

黃色塊是UVM VC。總線監視器是一個只有監視器和檢查器的無源組件。

用于測試串行外設的通用數據流是將數據從UVM VC發送到微處理器并檢查數據是否有到達目的地（微處理器）。在第二步中，我們將數據從微處理器發送到UVM VC，檢查正確的數據是否已到達目的地（UVM VC）。

圖2顯示了數據記分板<的示例/i>用于全雙工同步通信（例如，SPI）。 UVM VC和外圍總線上的監視器（被動）用于將數據發送到記分板：UVM VC發送的數據被添加到記分板 TX路徑，當它們到達外圍設備時，將通過總線監視器發送到相同的記分板進行匹配。來自外圍設備的數據被添加到記分板 RX路徑中，并與UVM VC被動監視器接收的數據相匹配。

圖2：全雙工同步外設示例

此方法的主要缺點是門級仿真的可移植性。在實施階段，RTL中可用的內部信號可能會在優化的網表中消失，UVM VC模塊的綁定變得困難，有時甚至不可能（例如，在合成期間刪除未使用的端口）。

新的SoC驗證流程

新流程的基本概念是記分板中檢查的數據不應來自內部SoC節點上綁定的監視器（參見圖2）。因此，修改了測試平臺配置，以便僅使用UVM VC（主動和被動）進行頂層綁定的數據檢查。內部監視器（綁定在SoC內部節點上的監視器）僅用于RTL仿真，檢查總線的合規性并跟蹤覆蓋范圍。

此時，有必要更改數據在UVM VC和SoC外設之間交換數據包的流程。主要要求是：

數據隨機化

門級模擬的可移植性

易用性

由UVM VC生成并由外圍設備接收的隨機約束數據分組被SoC用于生成出站分組。為了增加隨機化，SoC中的微處理器計算接收數據的CRC并將結果用作要傳輸的數據。

記分板將從UVM獲取數據VC，在將它們添加到數據列表之前，它將計算CRC。從外圍設備返回的數據將直接添加到記分板以進行匹配過程。圖3顯示了這個新流程的一個示例。

圖3：數據檢查的新方法

計算CRC非常簡單;對于記分板，可以使用內置函數（偽方法），例如，可以使用 e 語言：

list_bytes 。crc_32（來自字節，字節數）

list_bytes 。crc_8（來自字節，字節數）

它逐字節讀取列表返回位或字節列表的CRC函數的整數值。可以計算CRC，定義起始字節（通過第一個參數 from byte ）和選定的字節數（通過第二個參數字節數）。

32位CRC的生成多項式為：

x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x +1

8位CRC的生成多項式為：

x 8 + x 2 + x + 1

類似的函數用于SoC中微處理器執行的 C 代碼：

POLY_GEN8為0x03。可以使用POLY_GEN32 = 0x2608EDB為CRC32擴展該功能。

使用此方法可以極大地簡化記分板上的數據管理;由于數據檢查是在串行接口上進行的，因此它與微處理器總線的數據大小無關，可以是8,16,32位或更多。以下是記分板的示例。

全雙工同步接口

如果是全雙工同步接口，例如SPI，我們可以有兩種可能的模式：外設是從機，或外設是主機。

當外設是從機時，事務由外部UVM VC啟動。全雙工模式意味著必須同時發送和接收數據。由于我們希望避免在SoC側生成數據（在 C 代碼上沒有有線數據），因此有效數據存在系統延遲。此延遲應在記分板上實現，以便正確比較交換的數據。

圖4：全雙工數據序列用于從模式

圖4顯示了在主（UVM VC）和從（外設）之間交換的數據序列的示例。由外圍設備發送的第一個符號對于記分板“不關心”，因此被釋放。微處理器需要一些時間從緩沖區獲取數據并計算CRC。一段時間后，數據準備就緒，交換繼續從UVM VC隨機生成和來自外圍側的偽隨機數據（在D x 上計算的CRC）。

我們可以通過使用傳統的“不關心”數據（例如，零）來進行自動符號同步。當然，這些數據不應由UVM VC生成。 SoC上的外設將發送零直到CRC數據準備就緒，并且UVM VC以足夠的零符號終止以完成記分板中的匹配。

當外圍設備是主設備時，事務通過微處理器自行啟動。

圖5：主模式的全雙工數據序列

數據流與奴隸模式的情況非常相似。圖5顯示了在主（外設）和從（UVM VC）之間交換的數據序列的示例。外圍設備發送的第一個符號對于記分板“不關心”。 UVM VC用隨機符號D x 回復，微處理器用它來計算外圍設備發送的偽隨機數據。如上所述，黃色突出顯示的符號是在記分板中比較的符號。

半雙工接口

如果是半雙工接口，例如I 2 C，我們可以有兩種可能的模式：外設是從機，或外設是主機。

外設是slave，事務由外部UVM VC啟動。半雙工模式基于通信協議，其中主設備發送命令請求數據作為回復或將數據發送到專用從設備。

對于全雙工模式，有必要定義良好的流程這樣可以避免 C 代碼中的數據（非隨機）并使數據檢查變得簡單：

通過發送write命令啟動事務。 UVM VC將開始發送數據包。在計算CRC之后，這些數據被添加到記分板中。

接收的數據被DUT用作“回復讀取”命令。微處理器計算接收數據的CRC并準備數據包以進行回復。

UVM VC發送讀命令。外圍設備開始發送先前準備的數據。這些數據將添加到記分板中以進行匹配。

圖6顯示了此數據握手的簡單圖表。

圖6：從模式的半雙工數據交換

主模式

當外圍設備是主設備時，事務通過微處理器自行啟動。

在這種情況下，為了利用UVM VC的隨機約束特性，協議必須

通過發送讀命令啟動事務。 UVM VC將開始作為回復發送數據包。在計算CRC之后，這些數據被添加到記分板中。

接收的數據被DUT用作“寫入數據”命令。微處理器計算接收數據的CRC并為下一步準備數據包。

外設發送寫命令，然后開始發送先前準備的數據。這些數據將添加到記分板中以進行匹配。

圖7顯示了此數據握手的簡單圖表。

圖7：主模式的半雙工數據交換

復雜協議

相同的方法可以也可用于USB或以太網等復雜協議。概念是相同的：對于全雙工通信，初始符號是“不關心”（空符號），然后DUT使用接收的樣本來計算CRC并將數據發回。

對于半雙工，數據交換由UVM VC啟動，然后DUT使用接收的數據包構建傳輸數據包。