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

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

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

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

自動(dòng)生成C測試

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

測試生成軟件，被稱為測試套件合成，使用一個(gè)易于理解的、基于圖形的場景模型來捕獲預(yù)期的設(shè)計(jì)行為。這些模型可以使用Accellera可移植刺激標(biāo)準(zhǔn)使用本地C++編寫或可視化描述。場景模型由設(shè)計(jì)或驗(yàn)證工程師創(chuàng)建，作為SoC開發(fā)的自然部分，因?yàn)樗鼈冾愃朴趥鹘y(tǒng)的芯片數(shù)據(jù)流圖，可以在白板上繪制以解釋部分設(shè)計(jì)規(guī)范。

這些模型本質(zhì)上包括激勵(lì)、檢查、覆蓋細(xì)節(jié)和調(diào)試信息，為生成器提供了生成高質(zhì)量、自檢C測試用例所需的一切，這些測試用例強(qiáng)調(diào)了設(shè)計(jì)的每個(gè)方面。在嵌入式開發(fā)中，因?yàn)樗鼈兪欠謱拥暮湍K化的，所以在模塊級開發(fā)的任何測試都可以作為完整SoC模型的一部分完全重用，并且可以很容易地與不同的團(tuán)隊(duì)和跨項(xiàng)目共享。最后，合成工具可以分解單個(gè)意圖模型，以提供跨線程和I/O端口的并發(fā)測試，所有測試都同步在一起。

優(yōu)勢測試套件綜合

測試套件合成的一個(gè)顯著優(yōu)勢是能夠在意圖模型上預(yù)先定義覆蓋目標(biāo)。一旦指定了意圖，該工具就可以對其進(jìn)行分析，以了解可能產(chǎn)生的測試數(shù)量以及將要實(shí)現(xiàn)的功能意圖的覆蓋范圍。

對于SoC來說，這可能需要數(shù)千次測試。然后，可以通過約束要測試的意圖并將工具集中在關(guān)鍵領(lǐng)域來設(shè)置覆蓋目標(biāo)。這種能力避免了傳統(tǒng)方法中出現(xiàn)的痛苦的迭代循環(huán)，傳統(tǒng)方法是設(shè)置測試，運(yùn)行驗(yàn)證工具，理解實(shí)現(xiàn)的覆蓋范圍，然后一次又一次地重置測試。

在一個(gè)由著名半導(dǎo)體公司開發(fā)的大型SoC的典型項(xiàng)目中，驗(yàn)證工程師將測試組合時(shí)間減少到以前需要手寫測試的20%。自動(dòng)化技術(shù)產(chǎn)生了更嚴(yán)格的測試用例，覆蓋率從84%提高到97%。此外，這些型號便于攜帶。

在嵌入式開發(fā)中，單個(gè)模型可以為虛擬平臺、寄存器傳輸級(RTL)模擬、仿真、現(xiàn)場可編程門陣列(FPGA)原型或?qū)嶒?yàn)室中正在進(jìn)行硅后驗(yàn)證的實(shí)際芯片生成測試用例。

調(diào)試是工程師的另一個(gè)時(shí)間陷阱，尤其是在SoC層面。如果一個(gè)測試用例發(fā)現(xiàn)了一個(gè)潛伏的設(shè)計(jì)錯(cuò)誤，驗(yàn)證工程師必須了解是哪個(gè)測試觸發(fā)了這個(gè)錯(cuò)誤，從而追蹤到它的來源。測試用例失敗可能是由于場景模型中的一個(gè)錯(cuò)誤，因此必須能夠?qū)y試用例與捕獲設(shè)計(jì)意圖的圖相關(guān)聯(lián)。這個(gè)過程創(chuàng)建了高度模塊化和自包含的測試，這些測試很容易被分解，這樣就很容易看到為發(fā)現(xiàn)bug而執(zhí)行的測試。

結(jié)論

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