開發片上系統 （SoC） 需要管理設計的許多復雜方面。晶體管的絕對數量是壓倒性的，但復雜性不僅僅是數量。SoC 包含具有精確功能規范和一系列要求的高度復雜的特性。除了設計的復雜性之外，驗證每個功能和整個 SoC 是否滿足其規范和要求也是一個巨大的挑戰。

除了設計和驗證的復雜性之外，整個過程的項目管理也令人生畏。沒有一種解決方案可以解決 SoC 復雜性的所有方面，甚至大部分方面。然而，一些技術可以解決問題的特定部分，例如基于圖形的場景模型，這種形式可以直接降低驗證復雜性，同時為管理 SoC 設計和項目復雜性提供附帶好處。

SoC驗證

可以在示例數碼相機 SoC 設計的上下文中說明基于圖形的場景模型的作用（圖 1）。原始圖像由相機模塊從電荷耦合器件 （CCD） 陣列（正面或背面）捕獲。它可以顯示給用戶，由照片處理器操作，通過 USB 端口傳輸，或保存到 SD 卡。一系列此類圖像可被視為視頻流，并由視頻處理器和 SoC 中的其他知識產權 （IP） 塊進行類似處理。

圖 1：具有數碼相機功能的 SoC 的復雜設計。

SoC 具有相互交織的數據流并支持一些并行性。使用兩個嵌入式 CPU，可以同時對多個 IP 塊進行編程。此外，如果結構具有交叉開關功能，則多個數據流可以在不同的 IP 塊和內存之間并行運行，如果不需要內存緩沖區，則可以直接在 IP 塊之間運行。驗證要求在架構支持時并行執行所有這些可能的流程，以模仿相機中的實際最終用途。

如果要開發測試平臺環境，驗證團隊必須了解所有數據流和所有可能的交互。將 SoC 純粹視為黑匣子并不能提供足夠的驗證；在大型設計中，嚴格地通過操縱輸入來激發深層行為是很困難的。因此，SoC 驗證團隊幾乎總是開發在嵌入式處理器上運行的 C 語言測試，作為他們方法的一部分。當然，手寫測試也很困難，要對相互協調的多個處理器和測試臺進行手寫測試以充分發揮 SoC 的作用，幾乎是不可能的。

基于圖的場景模型

驗證團隊在理解芯片內所有可能的行為和數據流方面面臨挑戰。紙質規范很難消化，并且受制于自然語言的所有不精確性。由于描述的復雜性以及并非所有設計類型都適合聲明性語言這一事實，嘗試使用純形式化方法描述完整的 SoC 的嘗試沒有成功。

一種獲得認可的方法是基于圖形的場景模型。這樣的模型是一種形式主義——有向圖——但不需要形式語言。它可以使用標準 C/C++ 語言加上一些來自標準巴科斯-瑙爾形式 （BNF） 表示法的結構來描述。該圖顯示了 SoC 中 IP 塊之間的互連和合法數據流。場景模型類似于 SoC 架構師可能在板上繪制的數據流圖，不同之處在于它的左側是輸出和結果，右側是輸入。

如圖 2所示，可能的最終用戶場景包括：

從其中一個 CCD 陣列讀取并顯示在屏幕上、寫入 SD 卡或發送到 USB 端口的原始圖像

從其中一個 CCD 陣列讀取的原始圖像，由照片處理器編碼為 JPEG，然后寫入 SD 卡或發送到 USB 端口

從其中一個 CCD 陣列讀取的一系列原始圖像，由視頻處理器編碼為 MPEG，然后寫入 SD 卡或發送到 USB 端口

從 SD 卡或 USB 端口讀取并顯示在屏幕上的原始圖像，寫入 SD 卡或發送到 USB 端口

從 SD 卡或 USB 端口讀取的 JPEG 圖像，由照片處理器解碼并顯示在屏幕上，寫入 SD 卡或從 USB 端口發送

從 SD 卡或 USB 端口讀取的 MPEG 流，由視頻處理器解碼并顯示在屏幕上，寫入 SD 卡或從 USB 端口發送

圖 2：數碼相機 SoC 的高級場景模型。

因為場景模型是分層的，所以圖 2中的每個圖形節點（目標）都可以展開以顯示相應 IP 塊設計的詳細信息。該模型可以由 SoC 團隊自上而下開發，也可由 IP 開發人員自下而上開發。自上而下的開發更為常見，因為項目通常開始使用場景模型來解決全芯片 SoC 驗證問題。這可能需要 IP 開發人員的一些參與來填寫較低級別的詳細信息。如果一個項目完全采用該方法，那么場景模型也用于驗證單個 IP 塊，然后組合成一個全芯片模型。

場景模型提供了對 SoC 設計和芯片制造前必須覆蓋的驗證空間的洞察。這通過幫助定義測試計劃來解決驗證的復雜性。場景模型還有助于解決設計復雜性，因為它很像芯片架構師可能繪制的數據流圖的擴展版本來解釋設計的工作原理。因此，該圖成為架構師、設計師、驗證工程師、嵌入式程序員和啟動團隊之間可以使用的通用模型。這也降低了項目管理的復雜性，無論是在單個項目中，還是在共享設計部分的多個項目中。

場景模型自動化

圖形場景模型的最大價值可能在于它可用于生成 C 測試用例，以在仿真、在線仿真 （ICE）、現場可編程門陣列 （FPGA） 原型或 SoC 芯片中的嵌入式處理器上運行在培養實驗室。生成器從左到右遍歷圖表，從期望的結果到輸入，組裝一系列步驟，這些步驟返回到產生特定結果所需的輸入值集。圖形決策點和數據值是隨機的，因此每個演練都會產生一個獨特的測試用例。這種自動化消除了在 SoC 項目的任何階段（從模擬一直到實驗室）手寫測試的需要。用戶報告說，他們可以使用以前用于手寫測試的 20% 的團隊來獲得更好的自動化結果，

可以將約束添加到圖形中以阻止根據規范非法的路徑，隔離尚未準備好驗證的設計部分，或將測試用例生成偏向某些方向。例如，圖 2所示的圖表允許從 SD 卡讀取原始圖像，由照片處理器處理，然后顯示在屏幕上的場景。這是一個不必要的步驟，因為可以直接顯示原始圖像；用戶可以很容易地添加一個約束，即只有 JPEG 編碼的圖像被發送到照片處理器，以消除不必要的測試。

生成的測試用例是多線程和多處理器的，具有跨線程、處理器和內置測試臺的所有通信。目標是在允許的最大流量和并行度下對 SoC 進行壓力測試。在相機 SoC 中，可能會在從 SD 卡讀取前一個圖像并顯示在屏幕上的同時將相機圖像寫入 USB端口。這種級別的活動不太可能發生在手寫 C 測試或傳統的仿真測試平臺中，因此可以提供更完整的設計驗證。

把它們放在一起

與任何自動測試生成方法一樣，SoC 團隊需要一種方法來評估驗證的徹底性并確定何時流片。除了捕獲設計和驗證空間外，場景模型還用作系統級覆蓋模型。由于遍歷圖表的確定性，驗證工程師在測試用例生成時準確地知道圖表中的最終用戶場景（路徑）和目標已被覆蓋。他們不需要收集和整合運行時覆蓋來評估驗證進度。更重要的是，他們可以避免花費數周時間運行額外的模擬測試，這些測試對覆蓋結果幾乎沒有任何影響。

場景模型和自動測試用例生成形成閉環覆蓋系統。驗證工程師可以指向任何未發現的路徑或目標，生成器將生成一個覆蓋它的測試用例。這同樣適用于跨覆蓋路徑或目標。Breker 的 TrekSoC 系列產品提供閉環覆蓋和場景模型的其他優勢。

基于圖的場景模型捕獲關鍵的設計和驗證知識，通過通用模型實現 SoC 項目團隊成員之間更好的溝通，減少流程中多個點的人工工作，加快進度，更完整地驗證設計以增加獲得第一名的機會- 硅成功。

審核編輯：郭婷