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