應對百萬(wàn)門(mén)級系統級芯片驗證挑戰的可擴展解決方案

在系統層次上，由于抽象層次混雜，系統內部存在的不同語(yǔ)義，因此糾錯工作變得更加復雜。在異類(lèi)環(huán)境，比如硬件和軟件或數字 和模擬環(huán)境中，挑戰就會(huì )更為嚴峻。因此，信息不僅必須可用，而且必須在正確的語(yǔ)義背景下可用。同樣，利用多層次抽象，信息也必須在必需的抽象層次上可用。

例如，對軟件糾錯時(shí)，有關(guān)軟件程序執行的所有信息都包含在硬件記憶體中，但沒(méi)有任何東西是隨時(shí)可用的。了解變量放置在何處 正是解決方案的發(fā)端。它還必須確定信息保存在哪個(gè)芯片之中以及芯片中的相對位置，假定它并非緩存或寄存器。在許多情況下，即使在這種時(shí)候，數據還可能因為 數據或地址交叉原因而未按邏輯排序。因此，獲得變量值就可能非常復雜。

為了化解這些挑戰，新的糾錯方法正在不斷推廣。例如斷言或檢查器，盡管其用途并未得到完全理解。另一個(gè)容易引起混淆的問(wèn)題 則涉及覆蓋率問(wèn)題。許多工程師并未認識到，滿(mǎn)足代碼覆蓋率標準并不意味著(zhù)系統已經(jīng)得到適當驗證。同樣，我們還必須使用功能覆蓋率或斷言覆蓋率等其它標準來(lái) 確認該設計已經(jīng)得到完全驗證。

今天，絕大多數工程師都在創(chuàng )建激勵源，并將其饋送進(jìn)入執行引擎之中，這樣他們就可以對產(chǎn)生的響應進(jìn)行分析(圖4)。在許多 情況下，他們對照參照模型對該設計的某項實(shí)施的波形進(jìn)行比較，尋找不同之處。這是一種單調乏味且毫無(wú)把握的糾錯途徑，也正是眾多錯誤不被發(fā)現的原因所在。 我們很容易將注意力集中在手邊的問(wèn)題，同時(shí)錯過(guò)這樣一個(gè)事實(shí)，即有些地方已經(jīng)出錯，或目前的測試平臺無(wú)法反映新的問(wèn)題。

設計人員必須擺脫當前的絕大多數糾錯方法，因為就本質(zhì)而言它們都是單調的、重復的且不可能行得通。在設計流程的稍后階段，等效性檢查可能是一項非常強大的工具。等效性檢查可用于對照參考模型測試實(shí)施情況，但它采用形式驗證的方法，而不是試圖通過(guò)模擬比較兩套波形。

最近，其它一些測試平臺組件已經(jīng)臻于成熟達到可用程度，比如生成器、預測器和檢查器等。它們允許自動(dòng)生成測試預案，并對照期 望行為檢查響應成果。其中最成熟的當屬檢查器，也即斷言?，F有兩種類(lèi)型斷言，即依賴(lài)測試內容的斷言和不依賴(lài)測試內容的斷言。依賴(lài)測試內容可以輕松插入現有 驗證方法中，無(wú)需其它工具支持；不依賴(lài)測試內容的斷言則與生成器聯(lián)系，需要其它工具并改進(jìn)驗證方法。

故事并不止于此，因為目前還有一些尚未精確定義的測試平臺組件，比如功能覆蓋率、測試計劃以及驗證管理等。盡管這種測試平 臺轉換尚需幾年時(shí)間才能完成，但一旦完成，人們夢(mèng)寐以求的可執行計劃規范就將實(shí)現，不過(guò)其方式已經(jīng)迥異于業(yè)界最初的預測。它不會(huì )用于自動(dòng)執行設計流程，但 將應用于自動(dòng)執行驗證流程。

基于斷言的驗證

如前所述，測試平臺受到兩大獨立因素的制約：可控制性和可觀(guān)察性?？煽刂菩钥傻韧诩钤床迦牒鬁y試平臺激活設計中存在問(wèn)題的能力。它與代碼覆蓋率存在非常密切的關(guān)系，也正是我們在運用代碼覆蓋率時(shí)必須小心謹慎的原因所在，因為它并未考慮測試平臺的其它方面因素。

問(wèn)題的另一半則是可觀(guān)察性。故障一旦出現，兩件事情必須發(fā)生。首先是這一故障所產(chǎn)生的效應必須傳播至主要輸出，隨后故障必須 被發(fā)現。對大多數測試平臺來(lái)說(shuō)，接受驗證的主要輸出的數量非常少，因此我們會(huì )對許多問(wèn)題視而不見(jiàn)。這正是斷言之所以強大的原因所在。斷言對可觀(guān)察性造成積 極影響，提供多項好處。它們能夠明確除錯的主要原因DD而非次要或第三位原因DD糾錯工作變得更為輕松和快速。這是因為它們能夠分散在整個(gè)設計之中，產(chǎn)生 實(shí)際的主要輸出，后者則自動(dòng)檢查驗證對象的行為好壞。

這樣，測試平臺就不必再將這些錯誤效應傳播至實(shí)際的主要輸出，使得測試平臺的開(kāi)發(fā)變得更加容易。另外，我們還可以對大量數 據進(jìn)行驗證，否則的話(huà)它們將被忽略。斷言還開(kāi)展數據檢查，使得測試平臺更加有效。某項斷言一旦設計完成并被置入設計中，那么它就總是處在運行狀態(tài)。在許多 情況下，斷言檢查的東西并非測試的主要內容，因此它們將會(huì )發(fā)現非預期故障。例如，在模塊測試階段插入的斷言在集成階段乃至系統層次測試中都會(huì )執行其檢查功 能，這樣就可以提供更為廣闊的驗證覆蓋面。

最后，斷言使得測試的范圍更為寬廣。運用基于斷言的驗證技術(shù)的工程師經(jīng)常發(fā)現，其檢錯速度遠遠超過(guò)非斷言技術(shù)。這樣就可以 抵消編寫(xiě)和放置斷言造成的總體開(kāi)銷(xiāo)DD約占3%總開(kāi)銷(xiāo)時(shí)間以及10%總運行開(kāi)銷(xiāo)時(shí)間。運用斷言的公司報告稱(chēng)，在其所有程序錯誤中，大部分是通過(guò)斷言來(lái)發(fā)現 的，其糾錯時(shí)間也縮短了80%之多。

斷言可以嵌入設計之中，或者其規定內容可以獨立于設計，并附加在設計中的各個(gè)點(diǎn)。是內部還是外部則部分取決于誰(shuí)在創(chuàng )建這一 斷言，比方說(shuō)創(chuàng )建人員是設計人員還是獨立的驗證工程師。如果它們被嵌入設計之中，則主要驗證技術(shù)規范的實(shí)施。如果屬于外部開(kāi)發(fā)，則將驗證技術(shù)規范的解釋?zhuān)?或在某些情況下對技術(shù)規范本身進(jìn)行驗證。因為嵌入式斷言實(shí)際上都是可執行的注釋?zhuān)虼怂鼈兛赡芊胖迷谌魏慰梢苑胖米⑨尩牡胤健?p>好處是注解現在變得更有價(jià)值，因為它們在發(fā)揮作用。注解包括期望行為的說(shuō)明、設計人員作出的假設或針對期望用途作出的限制。它支持再利用，它提供有關(guān)設計的預期行為的所有各類(lèi)信息，提供原設計人員的意圖。至少所有的第三方知識產(chǎn)權IP就應該內建接口上和用途方面的斷言。

目前，人們對斷言的主要興趣是如何進(jìn)行模擬斷言，但這并非斷言的所有功能。斷言的基礎是一些名為屬性的更為基礎的東西。屬性 可以用于斷言、功能覆蓋標準、形式檢查器以及用于偽隨機刺激生成的約束生成器。屬性既可為模擬器也可為形式分析工具所用，它能夠將靜態(tài)和動(dòng)態(tài)驗證技術(shù)融入 一種方法中。隨著(zhù)這一領(lǐng)域中標準的來(lái)臨，在今后數年中，運用屬性的工具預計將會(huì )迅速增長(cháng)。

本文小結

設計團隊需要運用那些能夠在設計復雜性和多層次抽象之間擴展的工具改進(jìn)現有方法?？蓴U展解決方案能夠幫助工程師開(kāi)展他們目前能夠開(kāi)展的工作，而且在相同時(shí)間范圍內只會(huì )變得更好、更快且效率更高。它使得驗證工具對用戶(hù)更為友好，并能夠在設計過(guò)程中推入更多測試向量。