|
Mentor Graphics公司首席驗證科學(xué)家Harry Foster認為，今天的大多數設計經(jīng)理要依賴(lài)于某種驗證覆蓋的量度來(lái)回答三個(gè)重要問(wèn)題：我在哪里？去哪里？何時(shí)到？ 但覆蓋的量度有很多，它們來(lái)自各種工具，表示不同的事情。對設計經(jīng)理來(lái)說(shuō)，重要的是理解某個(gè)量度的真正含義。同等重要的是，經(jīng)理必須能夠將各種量度混合成為一幅圖像，它將能夠解答Foster的三個(gè)問(wèn)題。最重要的是，經(jīng)理必須正確回答第三個(gè)問(wèn)題的另一版本：何時(shí)該停止？作決策不僅需要不同量度的結合，而且有賴(lài)于一個(gè)詳盡的驗證計劃，這種計劃在架構設計的早期就已存在，并伴隨設計而成熟發(fā)展。 代碼覆蓋的概念（設計者從軟件驗證世界中借用的同一工具）很簡(jiǎn)單：當運行RTL（寄存器傳輸級）仿真時(shí)，只是維護一個(gè)1 bit寬的表，其表項是RTL源碼中的各個(gè)代碼行。一個(gè)仿真運行開(kāi)始時(shí)，將表中的各位清零。第一次執行某行時(shí)，表中的相應位設為1。仿真結束后，就獲得一個(gè)映像，它表示執行了哪些代碼行，哪些行沒(méi)有執行。如果某行沒(méi)有執行，就能可靠地說(shuō)你沒(méi)有驗證它。 專(zhuān)家把代碼覆蓋的概念推廣到基于設計RTL視圖的很多其它覆蓋的隱式量度。你可以設計出有關(guān)RTL公式、分支或寄存器切換等覆蓋的報告工具。并且，多數這類(lèi)報告都可從商用仿真工具中獲得，而無(wú)需設計專(zhuān)用的監控器。 代碼覆蓋量度的早期表現和易于使用的特點(diǎn)，使它們受到了大眾的歡迎。Foster稱(chēng)Mentor公司的調查數據表明，大約一半設計團隊在自己驗證流中的某個(gè)地方有代碼覆蓋量度。但代碼覆蓋也有嚴重的問(wèn)題。Synopsys公司研究員Janick Bergeron認為，主要問(wèn)題是“結構的覆蓋量度是必要的，但不足以決定驗證覆蓋”。Bergeron指出，代碼覆蓋中多數顯而易見(jiàn)的問(wèn)題是一種邏輯問(wèn)題。你執行了一行RTL，并不意味著(zhù)它做了你期望的事。 更精確地說(shuō)，問(wèn)題在于可觀(guān)察性與完備性。當你執行這行代碼時(shí)，它的結果是否傳送到了一個(gè)你在這個(gè)仿真中實(shí)際觀(guān)察的結點(diǎn)？如果不是這樣，那么你就不知道代碼是否做了你希望的事。Foster說(shuō)：“我們見(jiàn)過(guò)有100%代碼行覆蓋的設計，但事實(shí)上，在仿真中只觀(guān)察到70%代碼行的運行�！� 完備性是一個(gè)獨立的問(wèn)題。你執行了代碼行。但你是否在所有可能激活的情況下都執行了它？如果在它不工作的情況下會(huì )怎樣？ 功能量度 這些缺點(diǎn)使很多團隊采用功能驗證。人們會(huì )問(wèn)功能覆蓋，有多少設計中的功能做了你預期要做的事。由于這種直觀(guān)形式是經(jīng)理們用于量度驗證的最早方式，它也是很多團隊的支柱。 Alcatel-Lucent公司光學(xué)部硬件研發(fā)技術(shù)經(jīng)理Hans Sahm描述了這種基本方案的一個(gè)現代版。Sahm說(shuō)：“我們從一個(gè)需求文檔開(kāi)始，采用內部開(kāi)發(fā)的腳本，從需求生成一個(gè)驗證計劃電子表。這個(gè)表列出了功能需求，以英語(yǔ)表述，還有驗證團隊選來(lái)驗證每個(gè)需求的測試案例�！边@個(gè)電子表為驗證團隊提供了單一的文檔，他們可以在運行仿真時(shí)用該表檢查各種測試案例，因此就有了一個(gè)有關(guān)驗證過(guò)程的逐項功能檢查表。 這個(gè)概念構成了各種形式功能覆蓋量度的支架，但它也受到嚴重的挑戰。如Sahm指出的那樣，“在一個(gè)功能需求和需要驗證它的測試案例之間沒(méi)有自動(dòng)的鏈接�！币斫庖环N需求，并將其轉化為充分覆蓋該需求的測試，取決于驗證工程師的技能和經(jīng)驗。 Mentor公司的Foster稱(chēng)：“思想不存在自動(dòng)化。 ” Altera公司首席驗證架構師Jeff Fox表示：“在解譯需求文檔時(shí)總會(huì )存在一個(gè)問(wèn)題。不同工程師在閱讀相同文檔時(shí)，對于功能的表現方式會(huì )有完全不同的想法。這就是為什么我們試圖使自己的需求文檔盡可能貼近可執行代碼。它們必須是精確的�！� Synopsys公司的Bergeron也表示同意。他評論說(shuō)：“當你建立驗證一個(gè)功能的定向測試時(shí)，它是一個(gè)開(kāi)環(huán)過(guò)程。你永遠不能從結果去保證測試中不存在錯誤�！� 為了解決這種對人類(lèi)弱點(diǎn)的依賴(lài)性，最常用的技術(shù)是采用斷言（assertion）和約束隨機測試（constrained random test），這是Verisity公司（現在歸Cadence公司所有）最初倡議的。據Mentor公司的調查數據，只有大約40%的驗證團隊在使用約束隨機測試。相應地，大約40%團隊在使用功能覆蓋量度。從早期開(kāi)始，出現了許多用于書(shū)寫(xiě)斷言的專(zhuān)門(mén)語(yǔ)言，但業(yè)界現在似乎趨同于將System Verilog用于該目的。因此，我們正在看到一種新的形式：采用System Verilog的斷言，測試斷言的約束隨機測試，以及表述為斷言覆蓋的驗證量度。 對很多設計團隊來(lái)說(shuō)，這是個(gè)改良過(guò)程。Wipro Technologies公司半導體與解決方案業(yè)務(wù)部總經(jīng)理Giri Raju描述了他的設計團隊采用的路徑。他說(shuō)：“以前，我們只使用代碼覆蓋量度，跟蹤一個(gè)手工制作的交叉參考表來(lái)管理驗證工作。我們的目標只是100%的代碼覆蓋。我們已經(jīng)分階段地轉到功能驗證工具，并繼續用手工表跟蹤驗證過(guò)程�，F在，我們正轉向System Verilog和Open Verificaton方法�！� “現在仍需要大量工程技巧。驗證工程師要判斷驗證的覆蓋點(diǎn)，并與設計工程師一起復審，作為一次檢查。我們相信自己可以將這個(gè)過(guò)程的80% ~ 90%實(shí)現自動(dòng)化，但總會(huì )有某些情景下必須手動(dòng)完成工作。不過(guò)斷言覆蓋驗證量度確實(shí)對我們有幫助。我們的設計工程師現在已習慣在自己的代碼中插入斷言�！� 生成斷言覆蓋量度過(guò)程的一個(gè)最大便利之處是能用FPGA（現場(chǎng)可編程門(mén)陣列）在System Verilog環(huán)境中作邏輯驗證。較新的工具都允許驗證工程師生成約束的隨機激勵模式，然后工具會(huì )在覆蓋點(diǎn)跟蹤采樣數。Altera公司的Fox 說(shuō)，FPGA可以大大加速這一過(guò)程，它可以使團隊將設計與斷言綜合起來(lái)，并實(shí)時(shí)或接近實(shí)時(shí)地運行測試。這種方案可以使約束隨機測試的創(chuàng )建者涉及寬得多的網(wǎng)表，不僅能研究已知的案例，也包括未知的角落案例。 它還實(shí)現了事務(wù)級覆蓋的一種物理分類(lèi)。例如，通過(guò)FPGA手段，驗證工程師可以檢查一個(gè)接口的運行，只需簡(jiǎn)單地將FPGA連接到一個(gè)良好的外部設備上，觀(guān)察事務(wù)的情況。其想法是，如果接口能與其它芯片“良好地工作”，那么它就被100%覆蓋。 形式工具 通過(guò)代碼、功能和斷言覆蓋的量度，驗證經(jīng)理就擁有了很多數字，能給出驗證完成的程度。當然，所有這些都留下了一些不能解答的問(wèn)題。一些團隊越來(lái)越多地采用形式驗證工具，作為基于仿真技術(shù)的輔助方法。這些工具帶來(lái)了一些自己獨有的量度。 Alcatel-Lucent公司的Sahm稱(chēng)：“對那些最重要的模塊，我們正在使用特性檢查的形式工具。這種方法引入了特性覆蓋（property coverage）的概念。實(shí)際上，我們使用的工具有自身內部的完備性檢查能力，它會(huì )對特性覆蓋等作出量度，以及在一個(gè)給定場(chǎng)景下是否已確定了每個(gè)輸出狀態(tài)�！� 作為一種方法，形式工具給出了終極的保證。在運行結束時(shí)，你就擁有了以前違反所規定特性的全部反面實(shí)例。通過(guò)定義，可100% 地覆蓋各種特性。但也存在著(zhù)特性集如何完全覆蓋設計預期的問(wèn)題。于是就又回到了設計者的技能上，現在也許需求降低了，因為形式驗證工具的學(xué)習曲線(xiàn)是出了名的困難。 融合數據 你可以看到，驗證覆蓋不存在固定的答案。各個(gè)工具都可以告訴你如何完整地轉換 RTL代碼結構，或如何完全地檢查設計與驗證團隊編寫(xiě)的斷言，或證實(shí)由形式驗證專(zhuān)家定義的特性。但一個(gè)人工解析和創(chuàng )建的過(guò)程會(huì )將每個(gè)量度與設計預期分離開(kāi)來(lái)。因此，很多設計經(jīng)理會(huì )組合不同來(lái)源的覆蓋量度，從而構成自己對驗證過(guò)程的圖像。 Foster說(shuō)：“不同的團隊有將覆蓋數據組合為一個(gè)單一圖像的不同方式。做CPU的經(jīng)常只用功能覆蓋的量度，但他們有做這種工作的資源。沒(méi)有資源時(shí)，一些設計團隊仍然只用代碼行覆蓋。但你也可以結合不同種類(lèi)的數據�！� Foster建議一個(gè)團隊可以從功能覆蓋量度起步。當功能覆蓋接近100%時(shí)，團隊可以轉向代碼覆蓋作為一種對完備性的檢查。Altera公司Fox指出，這種方案可以使團隊準確地確定功能覆蓋中的漏洞。如果一塊代碼沒(méi)有得到執行，那么它或者是死代碼（設計團隊應能通過(guò)檢查確定），或者設計中的一些功能未得到覆蓋。Fox說(shuō)：“在這個(gè)地方，編寫(xiě)一些針對性測試�！� Fox強調了擁有不同來(lái)源數據的重要性。他說(shuō)：“比如，我們最近正在做一個(gè)接口IP塊。我們從三家供應商買(mǎi)進(jìn)了第三方驗證IP，讓兩個(gè)內部團隊做驗證過(guò)程。將他們在每個(gè)方案中發(fā)現的數據匯集起來(lái)做一些檢查�！� 尋找終點(diǎn) 即使像Fox這樣有經(jīng)驗的經(jīng)理，何時(shí)可以說(shuō)驗證完成了？可能有人會(huì )說(shuō)驗證永遠沒(méi)有盡頭。但也有人可能回應說(shuō)，當超過(guò)計劃日程后，驗證就完成了。不過(guò)，實(shí)用主義者的回答更加有趣。Bergeron說(shuō)：“你永遠不會(huì )結束。但可以在功能上達到一個(gè)商業(yè)成功需要的信心等級。這是一個(gè)風(fēng)險管理問(wèn)題�！� 因此，Bergeron和Foster都認為，有經(jīng)驗的驗證經(jīng)理會(huì )查看多個(gè)來(lái)源的覆蓋量度。商用工具可用于輔助這個(gè)過(guò)程，它按照結構塊或按功能來(lái)組織各種量度，這樣驗證工程師就可以從一個(gè)設計區域看到所有量度。并且現在還有減輕這些融合過(guò)程的努力（見(jiàn)附文《UCIS確�；ゲ僮餍浴罚�。這個(gè)水平上的差異通常指出了驗證計劃中的漏洞，團隊應用手工創(chuàng )建的專(zhuān)門(mén)測試加以彌補。 但經(jīng)理還應看問(wèn)題報告的頻率。如果當覆蓋量度接近100%時(shí)，問(wèn)題報告頻率在下滑，則一切正常。如果問(wèn)題以一種恒定速率（或更差）持續上升，那么就有一些麻煩了�？墒呛螘r(shí)停止呢？大多數經(jīng)理都同意下列觀(guān)點(diǎn)：當你實(shí)際上確定了一些關(guān)鍵塊時(shí)就能停止了。Sahm將“關(guān)鍵”定義為那些包括全新功能的塊；不能在軟件中簡(jiǎn)單處理的塊；以及設計者缺乏經(jīng)驗的塊。 Foster說(shuō)：“嘗試用覆蓋量度，將設計中的風(fēng)險限制在某些可修復塊內，這是一種非常合理的策略。這些塊可能有明顯的軟件工作區。它們可能有一堆不受約束的門(mén)，我們過(guò)去叫它們?yōu)椤鞓?lè )門(mén)’，設計者可以只用一些金屬層作一些修補�；蛘哌@些塊是實(shí)現新的算法，如果它們不工作，設計者只需簡(jiǎn)單地把它關(guān)掉�！� Foster總結說(shuō)：“覆蓋量度不能告訴你哪天完成工作。你可以看覆蓋曲線(xiàn)。如果它們在離100%不遠處走平，你可以改變自己的策略。如果覆蓋中有大的漏洞，可以針對它們做工作。如果有很多小漏洞，就可能需要全面改變自己的策略，并且嘗試形式方法，或針對分散區域的專(zhuān)門(mén)測試臺。但你從量度就能看出要去哪里，以及下一步應達目的地�！� 附文：UCIS確�；ゲ僮餍� Mentor Graphics公司首席驗證科學(xué)家Hany Foster說(shuō)，今天流行的驗證流程經(jīng)常會(huì )采用一組各異的驗證工具，從各種形式的仿真，到形式驗證甚至模擬。每個(gè)過(guò)程都可能生成多種覆蓋的量度，你用它們去測量一個(gè)過(guò)程的有效性，標記出那些可能需要注意的缺點(diǎn)。 今天流程的問(wèn)題在于，一個(gè)過(guò)程中的任何工具都可能生成不連貫、重疊的覆蓋量度，或者是一個(gè)不同工具可能生成一個(gè)量度的子集。此外，每個(gè)工具都以供應商確定的格式生成它的覆蓋數據。即使對最完備的項目團隊，要管理分析這些不同的覆蓋數據集也會(huì )是一場(chǎng)惡夢(mèng)。 圖A來(lái)自很多工具的覆蓋量度以及消費它們的幾種客戶(hù) Accellera公司建立了UCIS（統一覆蓋互操作標準），確保在多工具的異質(zhì)驗證流中收集、合并和解析覆蓋結果時(shí)的互操作性（圖A）。通過(guò)使用未來(lái)的Accellera UCIS API（應用編程接口）標準，多個(gè)驗證工具將能夠訪(fǎng)問(wèn)一個(gè)UCDB（統一覆蓋數據庫），概念上可以將其看作有全部覆蓋數據的單一存儲庫。 附文：UCIS確�；ゲ僮餍� 今天流行的驗證流程經(jīng)常會(huì )采用一組各異的驗證工具，從各種形式的仿真，到形式驗證甚至模擬。每個(gè)過(guò)程都可能生成多種覆蓋的量度，你用它們去測量一個(gè)過(guò)程的有效性，標記出那些可能需要注意的缺點(diǎn)。 今天流程的問(wèn)題在于，一個(gè)過(guò)程中的任何工具都可能生成不連貫、重疊的覆蓋量度，或者是一個(gè)不同工具可能生成一個(gè)量度的子集。此外，每個(gè)工具都以供應商確定的格式生成它的覆蓋數據。即使對最完備的項目團隊，要管理分析這些不同的覆蓋數據集也會(huì )是一場(chǎng)惡夢(mèng)。 Accellera公司建立了UCIS（統一覆蓋互操作標準），確保在多工具的異質(zhì)驗證流中收集、合并和解析覆蓋結果時(shí)的互操作性（圖A）。通過(guò)使用未來(lái)的Accellera UCIS API（應用編程接口）標準，多個(gè)驗證工具將能夠訪(fǎng)問(wèn)一個(gè)UCDB（統一覆蓋數據庫），概念上可以將其看作有全部覆蓋數據的單一存儲庫。 |
