應(yīng)對百萬門級系統(tǒng)級芯片驗證挑戰(zhàn)的可擴展解決方案

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

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

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

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

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

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

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

基于斷言的驗證

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

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

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

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

斷言可以嵌入設(shè)計之中，或者其規(guī)定內(nèi)容可以獨立于設(shè)計，并附加在設(shè)計中的各個點。是內(nèi)部還是外部則部分取決于誰在創(chuàng)建這一 斷言，比方說創(chuàng)建人員是設(shè)計人員還是獨立的驗證工程師。如果它們被嵌入設(shè)計之中，則主要驗證技術(shù)規(guī)范的實施。如果屬于外部開發(fā)，則將驗證技術(shù)規(guī)范的解釋， 或在某些情況下對技術(shù)規(guī)范本身進行驗證。因為嵌入式斷言實際上都是可執(zhí)行的注釋，因此它們可能放置在任何可以放置注釋的地方。

好處是注解現(xiàn)在變得更有價值，因為它們在發(fā)揮作用。注解包括期望行為的說明、設(shè)計人員作出的假設(shè)或針對期望用途作出的限制。它支持再利用，它提供有關(guān)設(shè)計的預(yù)期行為的所有各類信息，提供原設(shè)計人員的意圖。至少所有的第三方知識產(chǎn)權(quán)IP就應(yīng)該內(nèi)建接口上和用途方面的斷言。

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

本文小結(jié)

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