沒有人說過 FPGA 設計很容易。然而，與開發 ASIC 和定制芯片的同行相比，可編程設備的設計人員長期以來在驗證方面具有主要優勢。當然，這種優勢在于可以修復在 FPGA 驗證過程中遺漏的設計錯誤，而無需重新制造芯片。不久前，很多FPGA設計者根本沒有進行驗證；他們可以直接“吹氣就走”到培養實驗室。

在實驗室中，FPGA 被直接插入到最終系統的原型中。該團隊專注于產品驗證，在產品最終應用的上下文中提出硬件和軟件（如果需要）。在實驗室中發現任何漏掉的設計錯誤都可能很乏味。一旦找到一個，重新編程 FPGA 并繼續啟動是一件簡單的事情。只要錯誤的數量保持相當小，這個串行過程就可以很好地工作。

隨著可編程芯片變得越來越大和越來越復雜，實驗室中發現的錯誤數量和發現它們所需的時間都顯著增加。為了保持合理的啟動計劃，FPGA 開發團隊意識到他們必須在進入實驗室之前更好地驗證他們的設計。作為回應，FPGA 驗證團隊應運而生，并開始看起來很像他們的 ASIC 表親。

寄存器傳輸級 （RTL） 仿真仍然是所有芯片驗證的核心，FPGA 團隊從簡單的手寫矢量文件轉移到仿真中更加自動化的測試臺。一些采用了通用驗證方法 （UVM） 標準的約束隨機功能。用于檢查時鐘域和低功耗結構的靜態分析工具開始出現，一些高級 FPGA 團隊甚至開始使用形式分析。

更復雜的驗證方法變得越來越普遍，以減少在啟動實驗室中花費的時間并加快最終產品的上市時間。然而，FPGA 設計人員仍然擁有能夠重新編程設備以修復通過驗證并在實驗室中發現的錯誤的后備位置。隨著 FPGA 片上系統 （SoC） 設計的出現，即使這種轉義機制也越來越不可用。

FPGA SoC 驗證的挑戰

圖 1 顯示了一個具有代表性的 FPGA SoC，基于多個供應商公開發布的框圖。芯片的很大一部分仍然是可用于最終產品及其應用的傳統可編程邏輯。但是，包含一個硬核處理器子系統以提供 SoC 級電源。該子系統通常包括至少兩個嵌入式處理器、片上存儲器以及各種內部和外部接口。

圖 1：除了傳統的用戶可編程邏輯之外，當今的 FPGA SoC 還包含多個處理器和標準接口。

FPGA 團隊在使用此類復雜芯片進入 SoC 時代時遇到驗證障礙的原因有三個。首先是重新編譯和重新編程巨大的 FPGA 的時間。一旦發現錯誤并更改源 RTL 代碼，在高端個人計算機上創建新圖像的過程可能需要一整天。然后必須將圖像下載到 FPGA，這可能需要幾個小時。

其次，實驗室調試過程也是使 FPGA 設計功能正確所需時間的一個重要因素。一旦將芯片安裝到真正的目標系統中，就很難操縱輸入或讀取輸出。協議分析儀可用于標準總線，但幾乎總是有帶有自定義或 ad hoc 接口的 FPGA 端口。一個團隊在實驗室中花費數天甚至數周的時間試圖追蹤一個難以捉摸的錯誤的來源并不罕見。

根據 FPGA 架構，團隊可能必須進行多次編譯/程序傳遞，以帶出內部信號以進行調試。一旦發現錯誤，在驗證錯誤是否已得到解決之前，可能需要更多的編譯/程序通過來嘗試可能的修復。通常，團隊會在重新編程之前驗證錯誤并在模擬中測試修復。這是一個聰明的舉動，但會增加調試周期的時間。

問題的第三個方面在于 FPGA SoC 本身的架構。根據定義，SoC 至少有一個嵌入式處理器。它可能有幾個或許多同質或異構處理器。SoC 的關鍵在于處理器負責控制許多功能塊、存儲器和 I/O 端口之間的數據流。如果沒有在其嵌入式處理器上運行的軟件，SoC 只能做很少的事情。

這樣做的主要結果是，必須有某種形式的軟件才能在啟動實驗室的 FPGA SoC 處理器上運行。在設計 FPGA 時，最終產品軟件通常還沒有準備好，因此開發團隊經常不得不創建特殊的診斷軟件來測試設備。這給項目增加了資源負擔，因為該軟件必須與硬件設計并行開發。

手寫診斷代碼的開發既耗時又昂貴，難以維護，并且功能有限。人類不擅長并行思考，因此診斷很少會在設計中強調并發性、跨多個線程或多個處理器進行協調，或者將塊串在一起形成現實的最終用戶應用程序。結果是設計錯誤可能潛伏在 FPGA 中，直到在最終系統集成時發現，甚至被客戶發現。

來自非 FPGA SoC 領域的解決方案

為了解決診斷軟件代碼的困境，FPGA SoC 開發人員必須從 ASIC 和定制芯片驗證這本書中翻開新的一頁。他們可以從自動生成多線程、多處理器、自我驗證 C 測試的方法中受益，這些測試強調 SoC 中的系統級行為。這些測試可以加載到嵌入式處理器中并在模擬或硬件加速中運行。圖 2 顯示了此方法的工作原理。

圖 2：多線程、多處理器、自驗證 C 測試用例可以從基于圖形的 SoC 場景模型自動生成。

測試用例生成器的來源是一個基于圖形的場景模型，它捕獲了預期的芯片行為和驗證計劃。生成器分析圖表以確定設計的功能，然后生成一組測試用例，使用嵌入式處理器驗證這些功能。C 代碼被編譯并下載到處理器中，并在模擬或模擬加速中運行，就像任何其他軟件一樣。

這些測試用例旨在強調 FPGA 設計，在多個處理器上并行運行多個線程以測試并發功能。由于某些測試用例將從 FPGA 輸入中提取數據或將數據發送到其輸出，因此這種方法在測試臺中包含一個運行時組件，用于協調處理器和 I/O 活動。驗證團隊可以輕松連接到標準 UVM 驗證組件 （VC）。

創建場景模型很簡單，因為它們反映了設計中的數據流并且類似于 SoC 框圖。這種初始投資能夠生成幾乎無限的測試用例以在模擬中運行。如果有合適的 I/O 引腳連接可用，甚至可以在編程的 FPGA 上運行這些測試用例。

這種生成方法為 FPGA 開發人員提供了對傳統“燒毀和攪動”重新編程周期的巨大改進，因為在實驗室中一個一個地發現了錯誤。自動化測試用例可以節省開發時間、提供更徹底的驗證并節省資源，因為嵌入式程序員不必開發一次性診斷。結果是更快、更可預測的 FPGA 開發計劃，即使是最復雜的 SoC 設計也是如此。

審核編輯：郭婷