|
眾所周知，功能驗證在芯片的整個設計周期中占用的時間最多。盡管目前有許多技術可用于減少驗證時間，但最終應當如何選擇？答案并不簡單明了，而且經常令人迷惑并要付出高昂的代價。 一個項目中需要使用的工具和技術必須在設計周期的初期就確定下來，以便獲得新驗證方法費用預算的準確信息。經常有公司因為錯誤估計了運轉這些新型工具和技術所需的設計和技術的復雜性而浪費大量的資金和資源。 產品的抽象級越高，越容易設計；同樣的，抽象級越高，越容易犯嚴重的錯誤。一個架構上的缺陷可能會導致整個芯片的損害，而在門級網表中的連線錯誤可以通過重制解決。 例如，Verilog為設計者提供了一種相對容易的接口，以便他們在相當抽象的層次上進行設計。當設計曾經作為制約性的瓶頸時，Verilog 為設計生產率帶來了指數增長，并且大大推動了復雜芯片的發展。但是如果設計者不了解在復雜的設計周期中語言上的細微差別，就很容易犯錯。在驗證成為瓶頸的今天，同樣的觀點也適用于許多驗證技術和語言。 本文將對時下流行的驗證技術(形式驗證、隨機、定向、有約束的隨機、斷言、屬性檢驗)與語言(SystemC、C/C++、SystemVerilog、Open-VERA、E等)進行全面評述，還將分析在傳統的數字ASIC設計流程中應當在何時采用何種驗證技術和語言。 1 驗證瓶頸 盡管事實表明如今設計生產率的增長速度仍然低于芯片復雜度的增長速度，然而現在需要面對的瓶頸已不再是設計時間，而是驗證時間。最近的統計數據表明，對一個復雜邏輯芯片而言，整個產品周期中 60_70% 的時間都用于驗證工作。如何使用新的工具和技術對設計中的復雜功能進行驗證已經成為縮短總體的產品時間所需要面對的挑戰。 由于以下原因，可以說驗證瓶頸在某種程度上是設計抽象級逐步提高造成的結果： 1) 在較高的抽象水平上進行設計，易于構建高度復雜的產品功能。設計復雜度的提高造成驗證工作的成倍增加； 2) 在設計、轉換以及映射到最終產品的過程中，應用更高的抽象級進行設計會帶來信息損失和解釋錯誤的問題。例如，采用HDL級設計并將其轉換到門級的綜合過程，需要進行驗證以確保轉換的正確性以及使設計意圖完全得到體現。提高抽象級還帶來了代碼解釋問題，在仿真時要通過這些代碼對設計進行描述，以確保所寫的代碼真實反映了功能規范。 其它影響驗證問題的因素還包括： 1) 由于設計中硬件與軟件、模擬與數字等共存而造成的功能復雜度增加； 2) 對系統可靠性的要求增高，使得對驗證工作的要求也增加，以確保在系統環境下，芯片功能可以順利執行。 統計數據表明，驗證問題現實存在，而且讓公司付出了高昂的成本： 1)由于設計錯誤造成的芯片缺陷：在需要進行重制的芯片中，有82%是由于邏輯與功能缺陷設計錯誤。這意味著驗證過程沒有覆蓋邊角情況，缺陷一直隱藏在設計過程中直到流片。 2)由于規范錯誤造成的芯片缺陷：在需要進行重制的芯片中，有47%是由于邏輯與功能規范不正確或不完整，有32%是由于規范發生了改變。 3)重用IP和外來IP的問題：所有失敗的芯片中，有14%是由于在重用或外來的IP中存在錯誤。 4)重制的后果：重制費會高達10萬美元，還會延誤產品的推出，由于使用這些有缺陷的芯片而導致的系統失敗也會增加成本。 為了提高驗證生產率，EDA行業提出了一個與解決設計瓶頸類似的解決方案——抽象化的理念。諸如 Verilog 和 VHDL 等高層次的語言被用于驗證芯片，這些語言包括各種指令如任務指令和線程指令(fork/join 語句)，以及控制結構(while語句)。這提供了更強的數據控制力，以便對所有邊角設計進行充分驗證。然而，這些指令不能被綜合，因此不會被用作實際設計代碼的一部分。 隨著復雜度與日俱增，能夠驗證具有不同抽象級的復雜設計的新語言被創建出來，支持這些新的驗證語言的技術和工具也隨之誕生。 所有這一切意味著芯片廠商必須對新的工具作出評估，必須針對這些新的工具和技術對工程師進行培訓，在公司的研發費用成本結構中必須包括新的工具和資源，公司在總體上必須在短時間內克服學習曲線問題，另外，還需要對這些工具進行風險評估，以及考慮新工具與已有技術的集成和協同工作的能力。 2 驗證與確認(Validation) 除了驗證問題之外，芯片公司還要面對確認時間問題。Kropf將“確認”定義為“通過檢查實現行為以獲得對規范的信心的過程”。在驗證和確認之間，有一種觀點認為，“確認能夠確保這是正確的設計，而驗證則是確保這個設計是正確的”；另外一種觀點認為，“驗證指硅片成為成品之前的測試(Verilog/VHDL 仿真等)，確認指硅片成為成品之后的測試(在實驗室里測試電路板上的芯片)”。 無論是確認還是驗證，若要保證硅片滿足規范要求，要完成以下兩個步驟：1)通過文件或建模，芯片規范得到了正確的解釋；2)以上解釋得到了正確的理解與實現(一般是通過 HDL)，綜合入硅片，并封裝成為芯片。 本文認為第二步是驗證，第一步是確認。目前業界流行的設計流程如圖1所示，此流程可保證以上兩個步驟的要求得以滿足。根據待實現功能的復雜程度不同，可以跳過一些步驟或者增加一些步驟。例如，如果某一項設計是純粹面向硬件的，不涉及驅動或軟件，那么可以從抽象級3直接跳到抽象級1，鎖相環設計即為一例。 當設計按照抽象級逐步推進時，要注意必須一直保持等效性，以確保最低層的抽象級能滿足系統規范的要求。例如： 1)當 C 模型被置于一個系統環境并能夠滿足規范中所描述的所有系統要求時，芯片規范(一般是一個文本文件)與其 C 模型之間就達到了等效。這在實質上是功能等效。 2)通過比較 C 模型與HDL 實現的輸出，可以在規范的C 模型與其 HDL 實現之間建立等效關系。在沒有 C 模型的情況下，可使用“期望數據模型”。這在實質上也是功能等效。 3)HDL實現與門級(綜合后的)之間通過應用“邏輯等效性檢驗”可以建立等效關系。這時，由于設計采取的形式是純粹的邏輯門，而且功能能夠被表示為邏輯表達式，因此，這在實質上是邏輯等效。 3 現有驗證技術及發展趨勢 目前可使用的驗證方法及技術如圖2所示。 3.1 動態功能驗證 使用最為廣泛的功能驗證方法是動態的，之所以被稱為動態是因為輸入圖形/激勵信號是在一段時間(幾個時鐘周期)內生成并應用于設計的，相應結果會被用于與參考/黃金模型進行比較，以檢驗其與規范之間的一致性。 仿真器通常用于計算所有的信號值，并將其與指定的期望值進行比較。目前，有兩類可供選擇的仿真器： 1)基于周期的仿真器：這類仿真器不管在時鐘周期內發生了什么事情，它只是在每個周期內對單脈沖信號進行一次求值，由于執行時間很短這類仿真器的速度通常很快。 2)基于事件的仿真器：這類仿真器在時鐘周期內或者在時鐘邊界捕獲事件，并在設計中傳播這些事件，直到系統達到穩態。 3.2 隨機/定向功能驗證 在一個有時間限制的仿真過程中，動態仿真器只能驗證芯片的典型行為，而不能驗證所有可能的行為，這是動態仿真的主要缺陷。出現這個問題的主要原因是對芯片的定向測試是針對已知的測試空間，而不是未知的測試空間進行的。即使是僅對已知測試空間的測試也要花費很長時間。例如，假設推出每個運算數需要一個時鐘，為了驗證一個能對兩個 32 位操作數進行加和運算的簡單加法器的測試空間就需要 232x232個時鐘周期。隨著邏輯運算越來越復雜，驗證空間也會相應增加。因此出現了隨機動態仿真，通過為設計提供隨機激勵信號來增加驗證的測試空間，這樣能夠使驗證覆蓋的功能空間最大化。但當設計規模很大且非常復雜時，隨機測試空間會變得無限。為了解決這個問題，更高級的驗證語言，如 Open-VERA、E 與SVL (SystemC 驗證庫)被推出。這些語言引入了諸如約束隨機激勵信號、隨機激勵信號分配與電抗性測試平臺等概念。伴隨著這些語言的運用，出現了一些用于對其進行解釋的工具，如VERA、Specman與 OSCI 內核( Concentric System Studio ，CCSS)。 除了引入隨機化功能以外，新的驗證語言和工具還通過減少公司在構建不同測試場合/方案所花費的時間，來提高生產率。例如，測試方案可以采用最高的抽象級來編寫，并能夠通過采用功能強大的面向對象型結構而擴展至任何較低的抽象級。 當應用動態驗證時，通常需要估計所覆蓋的、可以量化的功能空間，包括：經過驗證的代碼行數(行覆蓋率)，經過測試的邏輯表達式個數(表達式覆蓋率)，一個 FSM 設計中能夠達到的狀態數(FSM 覆蓋率)，在一個仿真運行中可以雙向變換的端口及寄存器數目(變換覆蓋率)，以及設計代碼中覆蓋的邏輯通道數目(通道覆蓋率)。以上可以使用 Code Coverage 及 Lint 工具來實現。 3.3 斷言 設計者將斷言用作一個占位符，用來描述與設計相關聯的假設及工作特性(包括暫時的特性)。如果設計滿足或未滿足規范或假設，則斷言將會在一個動態仿真過程中被觸發。斷言還可在形式/靜態功能驗證環境中使用。 3.4 混合功能驗證 在該方法中通常執行動態仿真，仿真結果被用作靜態驗證的輸入。在靜態驗證過程中，在設計中傳播的是邏輯方程式/符號，而不象在動態仿真中那樣傳遞數值。這種方法雖然不像形式驗證詳盡周全，但卻具有比純動態仿真更高的效率。 3.5 靜態功能驗證 在靜態功能驗證中，不向設計施加輸入激勵，而是將設計映射在一個圖形結構中，用雙擇判決圖(BDD)或其他數學表示方法來描述所有時間周期內的設計功能。利用這種圖形結構來證實或反駁屬性可以驗證這些數學表達式，這是通過順著或逆著信號流來傳遞數值，以確定數學結構中的矛盾式來完成的。 現有的工具通過以下兩種方式來滿足靜態驗證市場的需求： 1) 使用斷言：這是在模型/設計當中規范并公式化的設計約束(使用SystemVerilog、Open-VERA、Verilog和VHDL等設計/驗證語言)。 2) 使用屬性：這允許使用屬性語言(如PSL和Sugar)對屬性進行規范。 3.6 等效性驗證 為了確認門級表示法與HDL實現是相同的，需要實施等效性檢驗，使用匹配點并比較這些匹配點之間的邏輯。檢驗中會生成一個數據結構并比較在相同的輸入模式下得出的輸出數值模式，如果這些輸出數值模式不相同，那么表示法(這里指門級和RTL級)就不是等效的。當表示法中的一個經過了某種類型的變換時，等效性檢驗有時會在兩個門級網表或兩個RTL級實現之間進行。 造成設計表達式差異的一些實際原因包括： 1) 綜合算法／探索式方法：根據對綜合工具的約束條件(區域、時間、功率)不同，綜合工具會對邏輯運算進行優化，以得到適當的門級表式。為此，綜合工具將采用探索式方法和邏輯最小化算法。 2) 抽象級：在采用HDL來實現設計時，由于語言的局限性或是缺乏(不具備)對綜合工具如何解釋特定語言結構并將其變換為門級表式的預測能力，因此，HDL實現有可能與設計者意圖存在一定的差異。 4 影響驗證技術的趨勢和力量 4.1 技術視角 設計錯誤可能出現在模塊接口處或是在模塊內部，它們最終會集成在一起形成芯片。舉例而言，那些在模塊級沒有被發現的缺陷在應用動態仿真時會在子系統或系統級上顯露出來。使用靜態功能驗證，模塊開發的每一步都會得到詳盡的驗證，從而確保子系統/系統質量和可靠性從根本上得到提高。有人認為，使用靜態/形式功能驗證，能夠更快地找到更多的缺陷。 另一方面，使用靜態功能驗證也存在以下缺陷： 1)現有的工具只能在模塊級運行； 2)通常不能處理大型設計(一般只能處理100~150K的門電路)； 3)不能處理高度復雜的設計； 4)現有的形式驗證工具有時會出現時間無限的問題(這主要是因為它們往往是基于一套探索程序，而不是任一算法)。這意味著形式功能驗證在一些情況下可能會比動態仿真花費更長的時間； 5)設計必須被寫為可綜合的RTL形式。 除了上述技術上的挑戰外，基于斷言的形式功能驗證的兩個競爭標準(PSL對SystemVerilog)也帶來了額外的問題。目前傾向于將靜態功能驗證方法用于驗證足夠成熟以備綜合的模塊，動態驗證(隨機和定向)用于嚴格驗證集成前的模塊。 目前，動態仿真還將繼續主宰功能驗證領域，直到形式驗證工具提供一種更成熟的方法。 4.2 語言視角 可以觀察到這樣一個趨勢，就是將設計和驗證語言結合在一起。這將極大地促進生產率，改進系統可靠性以及提高設計質量，因為使用多種工具和語言引發的不明確和誤解問題將得到消除。 在這一結合實現之前，公司要繼續依賴現有的高級設計語言(Verilog和VHDL)，并選擇是使用專有驗證語言(Open-VERA、E等)，還是過去流行的Verilog和VHDL 。 SystemC與其他高級設計描述語言在設計流程中扮演著重要角色，其中涉及硬／軟件折衷以及在硬件上運行軟件的設計(如SoC)。另外，它們也可用于架構建模及確認，當可以為應用事務模型的驗證使用架構模型組件時，也可以使用 SystemC。 5 選擇正確的驗證方法的標準 在當前縮短上市時間和迫切要求低成本的環境下，工程師正在設法解決設計復雜性問題。那些在新技術上投入更多研發精力的公司，其研發費用的使用更有效率，產品上市時間更短，公司成長更快，盈利更高。另外，公司必須在其特有需求與核心價值的基礎上評估方法和技術。在將新技術引進其工具流程時，它們應當考慮以下問題，并做出適當的權衡。 1)在某個生產線中，公司是市場領先者還是追隨者？ 2)基礎設施、工具和方法是集中式的還是分布式的？ 3)新驗證技術的評估是針對第一代產品進行的嗎？ 4)新驗證技術對成本和產品上市時間有何直接和間接影響？ 5)新的工具能否處理不同的設計能力？ 6)工具的易用性如何？ 7)可為新的工具提供什么水平的文檔和支持？ 8)新的工具和方法與公司內部現有的工具和方法之間是否具有互操作性？ 9)新工具的投資回報率(ROI)如何？(包括在服務、培訓、咨詢、計算和人力資源方面的投資) 10)新的工具是否能夠支持處于多個不同地理位置的設計？ 11)公司需要考慮的問題中，最為重要的問題之一可能是：我們雇用的設計師和驗證工程師是否對新的工具抱有成見？(即設計師不愿意學習和接受新的技術) 公司在做出關于工具、語言和方法的決策時可以采用以下介紹的簡單權衡方法。 5.1 產品視角 主要從事存儲器芯片或存儲器密集型(相對于邏輯密集型而言)芯片生產的公司訝SRAM和DRAM公司可能根本不需要進行大量的邏輯驗證。這些芯片大多是定制的。雖然這些產品中有些規模會很大，但它們的邏輯復雜性并不高，因而不支持在公司內部配備大量邏輯驗證工具的計劃。不過，存儲器密集型設計在其他方面提出了挑戰，例如布線、工藝變化以及功率等。 那些制造純ASIC芯片，在芯片上不運行任何軟件的公司可能無須在硬件或是軟件實現上進行權衡或是實施測試以捕獲運行于硬件之上的軟件。例如，只具有硬件的SERDES芯片所要求的驗證和建模方法與同時具有硬件和軟件的SoC是不同的。 對于擁有多種產品線的大公司來說，驗證方法必須滿足各種產品的不同要求。 5.2 系統視角 過去，邏輯芯片供應商不負責對芯片是否滿足參考系統的功能和性能要求進行驗證，而如今的系統廠商在批量訂貨之前都要求芯片供應商實施系統參考驗證。這就要求芯片公司在一個它們不熟悉的附加抽象級上對芯片進行建模和驗證，這需要架構模型、參考模型、復雜應用級的測試以及精細的測試平臺配置。面對這些不同類型的挑戰，公司有兩種選擇，一是采用現有的語言、技術和方法，這將耗費大量的時間和精力；另一種就是采用新技術(如VERA、Specman等)。此外，芯片供應商還必須確保所使用的參考模型和驗證套件是在一個與客戶的相應模型和套件兼容的環境中完成的，例如，應用客戶的軟件開發套件(SDK)和仿真器也能夠進行同樣的測試。 5.3 方法學視角 在芯片集成之前，可以將靜態功能驗證與動態仿真結合起來，在一個高置信度水平上驗證模塊級的功能。通過確認動態仿真正在持續驗證功能空間的主要邊角，可以有效地實施系統級驗證。 首先執行隨機仿真可以在驗證的初始階段發現大量的缺陷，然后對隨機模擬加以約束以確定測試空間已經被完全覆蓋的做法或許相對容易一些。應考慮在功能覆蓋度量上對約束驅動型驗證進行細化。功能覆蓋率這一術語被用于描述對被覆蓋的功能空間進行量化的參數，相反地，代碼覆蓋率則被用于量化一個給定的測試套件對已實現的設計進行覆蓋的程度。定向仿真隨后可被用于在驗證周期末期覆蓋邊角測試空間。 斷言和屬性可在靜態功能驗證期間起作用(在模塊級上)，并可在動態仿真環境中被重用(在模塊級和系統級上)。如果模塊轉變為IP，那么斷言和屬性也是有用的，因為斷言將在IP被重用時持續不斷地檢查其屬性。 6 結語 隨著時間的推移，具有更小特征尺寸(90nm 和 65nm)的器件將投產。目前，公司正在致力于解決諸如布線、串擾和軟錯誤的設計問題。一旦這些設計瓶頸得到了解決且隨著芯片廠商在越來越小的芯片上封裝越來越多的邏輯，驗證問題的出現就是意料中的事了。新型工具和方法的不斷引進提高了設計生產率。提高設計(SystemC和SystemVerilog)和驗證(Open-VERA、E 和 SystemC)的抽象化程度以滿足日益增長的復雜度要求是不可避免的。目前從SystemVerilog 的推出能夠看到設計和驗證語言的融合趨勢。 驗證持續扮演著重要角色，它能夠提高產品質量，使硅芯片一次成功，從而間接影響總體的產品時間。SystemC 和建模語言將繼續為邏輯密集型產品提供架構驗證。通過使用屬性、斷言以及推出形式驗證工具，生產率得到了進一步提高。但目前工程師仍舊依賴并信任動態仿真，因為它能夠驗證大型和高度復雜的設計。最終的趨勢可能是：形式驗證占據主要地位，動態仿真仍用于完整性檢查。 |
