語言屬性確保IC驗證


硬件驗證語言(HVL)已經度過了關鍵的早期采用者階段,現在正在積極進入主流。據估計,他們目前的滲透水平占整個Verilog和VHDL用戶市場的10%,年增長率超過50%。HVL市場目前由商業解決方案主導:Verisity Design Inc.的Specman Elite和Synopsys Inc.的Vera。其他商業解決方案包括Forte Design Systems的Rave和Co-Design Automation Inc.的新來者Superlog.開源解決方案,包括Cadence Design Systems Inc.的TestBuilder和Juniper Networks Inc.的Jeda。 C++ TCL或Perl,并通過自定義PLI接口與VHDL或Verilog集成。
如果您目前正在使用 Verilog 或 VHDL 來驗證您的設計,您是否應該考慮在下一個項目中切換到驗證語言,或者您是否可以使用現有工具完成相同的任務?隨著80年代后期設計復雜性的增加,設計界被迫放棄其可靠的原理圖捕獲工具,擁抱邏輯綜合革命,以保持有競爭力的生產力水平。功能復雜性的持續增加迫使核查界對核查方式進行類似的改變。此更改涉及的不僅僅是使用自檢事務級測試平臺。盡管這種方法是成功使用 HVL 的必要步驟,但僅實現當今一流的功能驗證方法還不夠。
HVL 的一個基本要求是支持高級數據類型、面向對象、并發控制和設計可觀測性。通常正是這個基本要求促使用戶切換到C或C++來實現測試平臺,因為Verilog和VHDL都沒有提供所有這些功能。Verilog沒有高級數據類型,VHDL沒有設計的直接可見性。這兩種語言都不是面向對象的,也沒有動態并發控制機制。C++與PLI接口相結合,可以輕松滿足這些要求。但這些基本要求只涉及編寫定向、自檢、事務級測試平臺的機制。它們沒有從根本上改變核查的實施方式。
為了在下一代數百萬門設計中具有競爭力,HVL必須提供三種互補工具,以實現新的、更高效的功能驗證方法:可約束的隨機生成、時間斷言和功能覆蓋。本文將討論這些工具。


隨著功能復雜性的增加,必須驗證的特征數量呈指數級增長。定向驗證方法,其中每個功能都使用單獨的手動編寫的測試用例單獨驗證,很快就會崩潰。需要編寫和調試的測試用例太多。在規定的上市時間窗口內編寫所有這些測試用例所需的人數是難以管理的,而且成本太高 - 假設您設法找到它們。為了解決這個問題,約束隨機生成已被證明是一種有效的工具,可以有效地生成行使設計特征所需的激勵。
HVL 提供的可約束隨機生成比 Verilog 提供的簡單隨機數生成器和分發任務或 VHDL 中常用的隨機生成包強大得多。為了高效且高效地創建大量不同且有趣的場景,HVL 可以輕松生成有效復雜數據結構的隨機實例。它們還可以輕松添加約束以將隨機生成定向到解決方案空間中特定有趣的區域,或者刪除約束以放寬某些條件以注入錯誤。圖 1 顯示了一個使用 OpenVera 語言編寫的編碼示例,該示例使用動態約束控制隨機生成 MAC 幀。
斷言語句
時態斷言是 HVL 的第二個要求。斷言是對屬性的陳述,該屬性必須始終為真。典型的軟件斷言是檢查指針的值是否為 NULL。使用 HDL 指定簡單斷言很容易。但是,在多個周期中具有多個替代方案的復雜、重疊的斷言更難表達、調試,更重要的是,更難信任。
HVL 包括一種強大的時態語言,可以使用簡潔的語法描述復雜的協議關系。動態生成并行執行線程、檢測差異和報告錯誤的日常功能都是內置的,使驗證工程師能夠專注于要驗證的實際功能,而不是檢測和報告機制。它們簡潔的語法和形式語義使它們非常適合通過形式驗證工具進行解釋,然后這些工具可能會嘗試在數學上證明或反駁該屬性。
盡管它們的力量很大,但時間斷言往往未被充分利用。這可能是由于它們的語法特征的聲明性和數學性質挑戰了我們傳統的程序思維模式。這就是為什么大多數時態斷言示例(包括下面的示例)通常很簡單,并給人的印象是,時間斷言不值得為學習如何使用它們而進行投資。但是一旦理解,它們被證明是確保設計功能質量不可或缺的工具。
在圖 2 中,使用 SuperLog 語言,斷言聲明請求后必須始終在 100 個時鐘周期內進行授權或重試,除非應用了重置,并且除非有請求,否則不得進行授權或重試。
HVL的最后一個基本要素是功能覆蓋。高級構造將幫助您更輕松地對數據及其轉換進行建模。受約束的隨機生成將有助于自動創建測試用例,臨時斷言將有助于檢測功能錯誤。但是,您如何知道您已經完全驗證了設計的功能呢?假設您的測試用例是隨機生成的,您如何知道是否已應用所有相關測試用例?這就是功能覆蓋的用武之地。

補充保障
功能和代碼覆蓋率是互補的。后者測量代碼行,而前者測量數據模式、狀態序列及其與既定目標的組合。代碼覆蓋率將檢測遺漏錯誤(“測試平臺是否忘記執行這行代碼?”),而功能覆蓋率檢測委托錯誤(“設計是否在所有可能的數據值序列下工作?”)。代碼覆蓋率可以幫助檢測現有代碼中的錯誤,但功能覆蓋率可以幫助查找未實現函數中的錯誤。
功能覆蓋率可以幫助回答以下問題:“我是否使用所有可能的尋址模式執行了所有可能的操作數?“我是否向所有端口發送了所有重要長度的以太網數據包?”“我寫信給每個登記冊了嗎?”圖 3 顯示了一個編碼示例,該示例使用 Specman Elite 中的 e 語言來測量生成的 MAC 幀長度的功能覆蓋率。生成的報告的部分屏幕截圖使用戶能夠分析在設計驗證中還需要完成的工作。
本文 的 目的 是 說明 為什么 使用 專門 設計 用于 解決 功能 驗證 獨特 挑戰 的 語言 或 環境 比 以往 的 定向 測試 平臺 能 提供 更高 的 生產力 和 整體 質量。這些挑戰通過易于約束的隨機生成、時間斷言和功能覆蓋來解決。但是,重要的是要注意,盡管這些功能體現在 HVL 中,但僅使用 HVL 并不一定意味著充分利用這些功能。必須區分學習語言和學習如何正確使用它。前者很容易。后者需要幾個月的經驗或適當的高級方法培訓。
—
Janick Bergeron,Qualis Design Corp.(俄勒岡州奧斯威戈湖)的首席技術官,是驗證協會(http://janick.bergeron.com/guild/)的主持人。他擁有超過 15 年的功能驗證經驗,擁有滑鐵盧大學(安大略省滑鐵盧)的 MASc 學位和俄勒岡大學(尤金)的 MBA 學位。
責任編輯:David
【免責聲明】
1、本文內容、數據、圖表等來源于網絡引用或其他公開資料,版權歸屬原作者、原發表出處。若版權所有方對本文的引用持有異議,請聯系拍明芯城(marketing@iczoom.com),本方將及時處理。
2、本文的引用僅供讀者交流學習使用,不涉及商業目的。
3、本文內容僅代表作者觀點,拍明芯城不對內容的準確性、可靠性或完整性提供明示或暗示的保證。讀者閱讀本文后做出的決定或行為,是基于自主意愿和獨立判斷做出的,請讀者明確相關結果。
4、如需轉載本方擁有版權的文章,請聯系拍明芯城(marketing@iczoom.com)注明“轉載原因”。未經允許私自轉載拍明芯城將保留追究其法律責任的權利。
拍明芯城擁有對此聲明的最終解釋權。