隨著片上系統(SoC)設計向更大的復雜性進軍，包含數千行系統級驗證代碼的測試套件仍在繼續手工編寫，這是一種古老而低效的做法，違背了“盡可能自動化”的格言。在嵌入式開發中，對于在SoC的嵌入式處理器上運行以在制造之前驗證整個器件的C測試來說尤其如此。

在可能的情況下，自動化驗證測試組合已被證明可以提高SoC開發的許多階段的生產率。例如，在通用驗證方法(UVM)測試臺中，約束隨機技術利用針對特定場景的隨機測試向量來增加覆蓋率。雖然這些提高了硬件模塊級的驗證效率，但設計仍被視為一個黑盒，激勵、檢查和覆蓋代碼分別編寫，對于大型模塊而言，這仍是一項繁重且容易出錯的任務。

考慮到需要將處理器測試代碼與I/O事務結合起來，通常在仿真器或原型系統上執行，很難將這種方法擴展到系統級。為了正確驗證SoC，必須對處理器本身進行測試。UVM和其他約束隨機方法不考慮處理器上運行的代碼。事實上，為了在SoC上使用UVM，處理器通常被移除，并被SoC總線上的虛擬輸入和輸出所取代，從而允許子系統減去處理器進行驗證。

SoC驗證工程師認識到了受限隨機測試平臺的局限性，促使他們手寫C測試以在處理器上運行模擬和硬件仿真，即使他們在充分運用SoC設計方面受到限制。這些驗證平臺的性能不足以運行完整的操作系統(OS)，因此這些測試執行“裸機”，這大大增加了合成工作的開銷。在嵌入式開發中，手寫測試，尤其是在沒有操作系統服務幫助的情況下，在利用多線程的多核處理器上以協調的方式運行是不常見的。結果是SoC行為的各個方面，例如并發操作和一致性，得到了最低限度的驗證。

自動生成C測試

當然，自動生成的C測試會更有效地利用工程資源。它們也增加了覆蓋面。與手寫測試相比，生成的C測試用例可以測試更多的SoC功能，并且可以找出難以想象的復雜的極限情況。多線程、多處理器測試用例可以測試設計中的所有并行路徑，以驗證并發性。它們可以在內存段之間移動數據以強調一致性算法，并在數據應該發送到芯片的輸入或從其輸出讀取時與I/O事務協調。這樣做的總體效果是增加系統功能覆蓋率，通常高于90%,而數字通常要低得多。

測試生成軟件，被稱為測試套件合成，使用一個易于理解的、基于圖形的場景模型來捕獲預期的設計行為。這些模型可以使用Accellera可移植刺激標準使用本地C++編寫或可視化描述。場景模型由設計或驗證工程師創建，作為SoC開發的自然部分，因為它們類似于傳統的芯片數據流圖，可以在白板上繪制以解釋部分設計規范。

這些模型本質上包括激勵、檢查、覆蓋細節和調試信息，為生成器提供了生成高質量、自檢C測試用例所需的一切，這些測試用例強調了設計的每個方面。在嵌入式開發中，因為它們是分層的和模塊化的，所以在模塊級開發的任何測試都可以作為完整SoC模型的一部分完全重用，并且可以很容易地與不同的團隊和跨項目共享。最后，合成工具可以分解單個意圖模型，以提供跨線程和I/O端口的并發測試，所有測試都同步在一起。

優勢測試套件綜合

測試套件合成的一個顯著優勢是能夠在意圖模型上預先定義覆蓋目標。一旦指定了意圖，該工具就可以對其進行分析，以了解可能產生的測試數量以及將要實現的功能意圖的覆蓋范圍。

對于SoC來說，這可能需要數千次測試。然后，可以通過約束要測試的意圖并將工具集中在關鍵領域來設置覆蓋目標。這種能力避免了傳統方法中出現的痛苦的迭代循環，傳統方法是設置測試，運行驗證工具，理解實現的覆蓋范圍，然后一次又一次地重置測試。

在一個由著名半導體公司開發的大型SoC的典型項目中，驗證工程師將測試組合時間減少到以前需要手寫測試的20%。自動化技術產生了更嚴格的測試用例，覆蓋率從84%提高到97%。此外，這些型號便于攜帶。

在嵌入式開發中，單個模型可以為虛擬平臺、寄存器傳輸級(RTL)模擬、仿真、現場可編程門陣列(FPGA)原型或實驗室中正在進行硅后驗證的實際芯片生成測試用例。

調試是工程師的另一個時間陷阱，尤其是在SoC層面。如果一個測試用例發現了一個潛伏的設計錯誤，驗證工程師必須了解是哪個測試觸發了這個錯誤，從而追蹤到它的來源。測試用例失敗可能是由于場景模型中的一個錯誤，因此必須能夠將測試用例與捕獲設計意圖的圖相關聯。這個過程創建了高度模塊化和自包含的測試，這些測試很容易被分解，這樣就很容易看到為發現bug而執行的測試。

結論

就像約束隨機測試平臺消除了塊驗證的人工工作一樣，基于嵌入式處理器的SOC的綜合測試內容已被證明可以減少系統級驗證工作。此外，在嵌入式開發中，該解決方案目前正在塊級應用，并用于芯片后驗證。在這個例子中，自動化C測試用例應用了“盡可能自動化”的格言，顯著地提高了覆蓋率，同時縮短了驗證計劃。