SOC 驗證有什么用？

這篇文章的標題聽起來像是上世紀90年代電視劇里的玩笑，但它實際上是一個嚴肅的問題。很多人不明白，是什么讓一個系統(tǒng)級芯片（SoC）與其他半導體器件不同。許多公司，尤其是在電子設(shè)計自動化（EDA）行業(yè)中，圍繞術(shù)語“SOC”進行了眾多討論，但卻沒有定義它，或者解釋它為什么是這樣一個重要的概念。

Soc驗證的含義

從“SoC”的定義開始討論，應該是最合適的地方。正如其名稱所暗示的那樣，“系統(tǒng)級芯片”，是存在于單個封裝的完整系統(tǒng)，通常都處于單個die，盡管3-D集成電路建立在多個die上的情況也正變得越來越普遍。

本質(zhì)上，SoC就是將分布在多個芯片甚至是離散設(shè)備上的功能集成到一個芯片中?，F(xiàn)在已經(jīng)很難找到不含某種處理器的系統(tǒng)了，所以在實際的定義中，在SoC必須包括至少一個處理器。

最常見的SoC架構(gòu)包括一個或多個嵌入式處理器，部分片上存儲器，附加的功能單元，標準總線接口以及可能的片外存儲器。某種類型的片上總線，總線結(jié)構(gòu)，或網(wǎng)絡芯片將所有的單元連接在一起。

與其他芯片驗證不同的原因是什么？

由于需要在嵌入式處理器上運行的軟件，完整的SoC實際是芯片加上在這些在處理器上運行的代碼。有些系統(tǒng)級芯片具有在多個不同的處理器，CPU，DSP，圖像處理器等，——所有的運行代碼都是針對單獨功能定制的。

處理器的存在是使得SoC驗證與其他芯片驗證不同的關(guān)鍵。更小，沒那么復雜的芯片，以及許多在SoC內(nèi)部的模塊，可以使用仿真測試平臺有效的進行驗證。提供數(shù)據(jù)到芯片的輸入，檢查芯片上的輸出數(shù)據(jù)。

傳統(tǒng)測試平臺可簡化為一個框架，允許用戶提供一系列的二進制輸入，并使用波形查看器查看輸出結(jié)果。當然，如此的手動設(shè)置僅僅能夠驗證復雜設(shè)計很少的預期功能。

現(xiàn)代的基于測試平臺的驗證環(huán)境會為芯片輸入自動生成隨機的stimulus，這種隨機同時處于用戶指定的約束條件（規(guī)則）下，并會自動檢查每個測試的結(jié)果。這比基于傳統(tǒng)測試平臺手工編寫單獨的測試更有效率。

有約束的隨機測試平臺

一些驗證方法已經(jīng)建立，流行的標準是有約束的隨機測試平臺，并允許有限復用測試平臺的組件。這些驗證方法中，最有名的是標準組織Accellera定義的通用驗證方法學（UVM）。

帶約束的隨機測試平臺在一定程度上工作正常，但不能就此擴展到full-SoC驗證上。僅僅從芯片的輸入來驗證其所有功能，是一件太過困難的工程。

此外，雖然在SoC的嵌入式處理器通常有能力在仿真中運行代碼，但對所有協(xié)調(diào)處理器與測試平臺的活動，UVM都不提供任何指導。事實上，在SoC級運行的任何UVM-based仿真，通常用總線功能模型（BFMS）去替代嵌入式處理器。

以上的這些限制導致許多SoC團隊在full-chip級僅僅做最少的驗證。他們僅僅驗證模塊是否已正確連接，并可能運行一些簡單的測試來驗證各主要模塊運行正常。

對SoC運行中，模塊串接的真實情形，他們卻很少運行測試。這種“stitch and ship”方法帶來高風險，因為它從從未測試模塊間復雜相互作用的情況，而其恰恰極可能暴露設(shè)計bug或證實性能的缺陷。

模塊級驗證

在模塊級驗證中，很難發(fā)現(xiàn)諸如存儲器沖突，總線飽和，等在SoC多模塊共享資源時才發(fā)生的問題。

考慮到SoC功能在很大程度上取決于其嵌入式處理器，意料之中，一個純粹的測試平臺是不足夠的。有些驗證團隊認識到這一點，他們用人工設(shè)計測試在嵌入式處理器上運行。這些測試通常不連接到測試平臺也未很好集成到整個驗證工作中。

此外，要人工設(shè)計對SoC并行功能多任務（multi-threaded）測試簡直比登天還難。當然，我們所需要的就是考慮這些corner-case bugs和性能問題。

充分有效的SoC驗證

SoC驗證要充分有效，就必須包括在嵌入式處理器上運行自動化測試。軟件可以在仿真中生成在多處理器多線程情況下的測試case。

為了對SoC有足夠的壓力測試，測試case需要刺激和協(xié)調(diào)處理器和測試平臺內(nèi)的并發(fā)活動。測試case必須能夠?qū)﹄S機生成的輸入數(shù)據(jù)進行自動驗證，計算輸入的預期結(jié)果，并檢查芯片的輸出符合預期的結(jié)果。

通常來說，我們需要提供SoC的功能信息給測試case生成器，這些case才能恰當?shù)尿炞C其功能性并檢驗結(jié)果。描述SoC設(shè)計功能的最好方法就是一系列可視方案模型。

圖像能夠捕獲芯片的數(shù)據(jù)流路徑并記錄如何配置模塊來運行所有SoC設(shè)計功能。圖像引導的生成器約束保證其不會對非預期行為生成test case。

來自Breker驗證系統(tǒng)中的TrekSoC產(chǎn)品

這個軟件工具能自動生成在SoC的嵌入式處理器上運行并能夠自驗證的C語言test case，而且該軟件不需要操作系統(tǒng)或者其他產(chǎn)品軟件的支持。

這些test case都是多線程的，因此能并行檢驗SoC的多個部位，在tapeout之前進行足夠的壓力測試。生成器中成熟的scheduler能夠跟蹤多個并行運行的現(xiàn)實情況，并從線程中移動它們以盡可能多的對SoC進行測試。

因為一些C-based測試會從芯片輸入讀取數(shù)據(jù)，或者發(fā)送數(shù)據(jù)到芯片輸出，“TrekBox”組件連接現(xiàn)有的總線功能模型（BFMS）在測試平臺中，并協(xié)調(diào)處理器和測試平臺間的活動。

當每個C-based測試準備接收或生成數(shù)據(jù)時，會通知TrekBox處理實際的數(shù)據(jù)傳輸。源數(shù)據(jù)也可以被加載到存儲器，并且存儲器檢查可以在不干擾的SoC的情況下進行。

這個基于圖形的場景模型描述了能夠在SoC中產(chǎn)生無限數(shù)量的多線程測試case的所有信息。

總結(jié)

總之，SoCs使得半導體產(chǎn)業(yè)能繼續(xù)實現(xiàn)其，更好，體積更小，更快芯片的目標。它們與其它類型的芯片不同，所以SoC的驗證也必然是不同的。

開發(fā)團隊必須認識到，在SoC時代，存在嚴重bugs風險或者毫無競爭力的去生產(chǎn)芯片的情況，使得他們的世界已經(jīng)不同。

自動生成多線程，自我驗證C測試case是一個相當新，但是很好的驗證方法?！癝oC驗證”團隊采取這種方式會有著更快產(chǎn)生更好的，更小的芯片的優(yōu)勢。
編輯：lyn