|
功能驗證正成為IP驗證的瓶頸，并影響到整個設計團隊。設計工程師想方設法提高驗證效率，以實現整個芯片設計的最佳利益。在這里，我們提供10個簡單技巧，顯著提升您的IP驗證效率。 1. 參與驗證計劃審核 良好的開端是成功的一半！在驗證計劃上的投入是非常重要的。很多時候，沒有明確的微架構文檔的驗證計劃（從白盒驗證的觀點）是不完整的。前期的投入可以減少很多執行中的障礙。你需要根據設計開發計劃確定優先順序。您還需要對驗證計劃的完整性有所投入。此外，如果您的驗證團隊正計劃采購第三方驗證的IP，請確保它符合DUT的特殊定制需求。 2. 以文檔的形式記錄接口信號、寄存器和數據流 文檔是一種奢侈品！許多設計工程師奉行“代碼就是文檔”的理念。這是可以理解的，因為你在與時間作戰。然而，有關測試器件與測試平臺之間的接口的基礎文檔和基礎數據流信息對提高驗證效率大有益處。在整個調試過程中這些文檔能夠充當參考從而避免混淆。 3. 在系統整合前就完成DUT的頂層編譯 為了早點把RTL交付給驗證團隊，工程師常常跳過DUT的RTL頂層編譯。你可千萬別忽略這一步。每個新寫的測試平臺都會有自己的問題。而引用未成熟的DUT只會將問題復雜化。因此，最好能給驗證團隊提供一個沒有錯誤的DUT頂層的RTL編碼作為參考。 4. 避免DUT頂層出現dangle信號 dangle信號是內部模塊之間的連接信號。然而,由于缺少連接，這些dangle信號最終會被放到頂層的端口上。這破壞了測試平臺頂層編譯從而導致混亂。你需要在內部把它們連接起來，然后按照規格要求，參照預定義的端口列表交付DUT頂層。 5. 為關鍵性的假設和接口信號添加必要的斷言 隨著斷言的日益普及，如果你可以多花些精力，添加必要的斷言，肯定是有百利而無一害的。這可以是簡單的內部FIFO空滿斷言，也可以基于任何輸入激勵或任何可能出現的異常的假設的復雜的斷言。針對DUT上的接口信號的斷言可以提供及時的信息，以判斷驗證工程師是否正確整合DUT。這些早期的斷言可以為后期的調試節省大量的時間。 6. 繞過冗長的初始化序列 許多接口協議規范都列舉了很長的初始化序列，以提供配置的靈活性。一些初步的測試過后，驗證的焦點會轉移到其他環節。大多數的測試是為了驗證初始化序列以外的特性，所以你應該提供方法繞過這些長期的初始化序列。 7. 設置可變的計時器時長 設計通常都會使用定時器以避免出現掛起的情況。這些定時器要么符合標準的規范要么由內部定義。通常，這些計時器都設定有非常長的值以防止超時。不過，要測試那些很長的值需要消耗大量的仿真時間。一些值甚至是仿真測試無法實現的。所以，你需要讓計時器具有可伸縮性，以確保定時器可以毫不費力地進行縮放。同時，你也應該調整其他相關的配置，總之一定要讓計時器順利進行仿真。 8. 一致性驗證 這一步是 “錦上添花”！隨著形式驗證工具的日益普及，設計師可以做一些一致性驗證而無需在測試平臺上大量投入。對設計（或設計的主要模塊）進行一些非�；镜臏y試，將大大節省時間，從而加速啟動全面驗證。 9. 在DUT頂層使用System Verilog接口 設計師鐘愛Verilog，但是當今世界大多數的驗證都是通過System Verilog實現的。你應該逐漸發掘System Verilog的“設計友好型”的特點。為DUT頂層提供System Verilog接口，而不是 Verilog的端口列表。這會是一個良好的開端，它可以減少集成時間，也可為接口斷言提供合適的場所。此外，這將有助于轉變設計思維過程，從單純的Verilog到System Verilog – 從長遠看，這無疑是有益之舉。 10. 參與功能覆蓋率收斂 你可以說，“我已經處理了代碼覆蓋率收斂。功能覆蓋率收斂不關我的事 �！睕]錯。然而，從長遠來看，延遲的驗證收斂必定讓你耗費更多的努力。在時序關鍵設計領域的后期修復的bug會導致時序收斂的返工（非常痛苦的過程）。因此，你最好能全程參與和指導功能覆蓋收斂，尤其是關鍵或薄弱環節。 |
