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

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

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

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

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

FPGA SoC 驗證的挑戰(zhàn)

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

圖 1：除了傳統(tǒng)的用戶可編程邏輯之外，當(dāng)今的 FPGA SoC 還包含多個處理器和標(biāo)準(zhǔn)接口。

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

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

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

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

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

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

來自非 FPGA SoC 領(lǐng)域的解決方案

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

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

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

這些測試用例旨在強調(diào) FPGA 設(shè)計，在多個處理器上并行運行多個線程以測試并發(fā)功能。由于某些測試用例將從 FPGA 輸入中提取數(shù)據(jù)或?qū)?shù)據(jù)發(fā)送到其輸出，因此這種方法在測試臺中包含一個運行時組件，用于協(xié)調(diào)處理器和 I/O 活動。驗證團隊可以輕松連接到標(biāo)準(zhǔn) UVM 驗證組件 （VC）。

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

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

審核編輯：郭婷