多年來，電子設計自動化(EDA)工具已經變得相當成熟。它們在晶片製造各方面的設計和驗證中發揮重要的作用。但目前仍然落後的領域是設計約束的確認。雖然晶片設計、功能驗證、時序驗證和製造已經高度自動化，但設計約束的編寫和驗證大部份還是繁複的人工作業。

目前，已經有軟體可用來管理、驗證甚至製作設計約束，協助設計師縮短設計週期，提高設計約束的品質。約束的改進意味著更高品質的矽晶片，特別是在90nm及更小的幾何製程中(圖1)。

約束確認的擴展之一是例外的產生。約束管理工具可以檢查網表，並發現功能故障路徑。工具必須用經驗證的形式引擎確定這些路徑，以證明這些路徑可以被聲明為故障路徑。一旦這些路徑被證實是故障路徑，它們就可以從成本等式以及合成和實現工具的靜態時序分析中去除。這樣可以讓最佳化引擎集中資源處理實際路徑，帶來更小、更快的設計。

當向更複雜的設計和更精細的幾何尺寸發展時，自動化約束管理將成為主流，並引導設計自動化的新時代。為了充分利用這一功能，本文針對約束產生提出了一些建議。

圖：今天的約束管理工具可對設計流程的所有階段確認並產生約束。

建議的方法

‧製作的約束要覆蓋設計環境的所有方面，如所有時脈、產生的時脈、介面時序和負載能力，以及像故障路徑等時序例外等。通常約束文件是一個專案一個專案傳下來的。如果確實是這種情況，每個約束必須匹配設計規格或新專案的系統級約束。該規格也必須被檢查，並補充任何遺漏的約束。

‧利用約束確認工具驗證約束的正確性和品質。品質檢查應包括SDC語法檢查、語法上正確但存在如錯誤睡眠模式等問題的SDC構造，以及約束或例外的重疊。與參與該專案的所有設計師共同瞭解被工具標示出來的任何約束問題，及其所帶來的影響。

‧當使用自底向上的合成和/或實現流程時，需特別注意層次性約束。在頂層定義的任何故障路徑、案例分析、多次迴圈路徑等也必須在模組級反映出來。設計師必須對諸如同一路徑在晶片級聲明為故障路徑但在模組級不是故障路徑等約束檢查其一致性。當具有時脈定義的頂層接腳，在只有一條create-clock語句描述之模組埠的扇入中還會產生另一個常見的問題。該問題通常是遺漏set_case_analysis語句引起的。在有上百甚至上千行SDC程式碼的大型設計中，這種遺漏現象很容易發生。相對於手動方法，約束管理工具可以在很短的時間內發現這種問題。

‧瞭解名稱更改可能導致約束文件和設計RTL或網表的失配。這些問題有一些(但不是全部)可以被合成和佈局佈線工具標示出來，但設計師不得不在報告文件中逐頁搜索警告條目。這又是一項極耗人工的過程。而目前的約束驗證工具可以使這一過程自動化，並向設計師提供彩色標註、通過或沒通過等規則檢查的反饋資訊。

‧使用除了能閱讀和製作SDC約束外還能閱讀和製作PSL聲明的工具，以便架構模擬和形式約束確認之間的連橋接樑。

‧開發形式驅動的例外產生工具以提高矽晶片品質。一些工具可以從合成、實現或靜態時序分析工具讀取關鍵故障路徑，以減少需要處理的時序路徑數量。這稱為關鍵故障路徑(CFP)產生。

‧考慮使用與現有形式技術(如等效性檢查、低功率和時脈域驗證)整合的工具。這將使採納和學習在設計團隊中變得更容易。一些工具還提供到現有實現工具的鏈結，允許自動腳本產生和交叉檢測分析。

不建議的方法

‧在製作如錯誤路徑等時序例外時使用具有萬用字元的鬆散條件。萬用字元在展開時可能導致合成和實現工具速度極其緩慢。由萬用字元設立的意外故障路徑可能遮蔽真正的功能路徑。由於這些路徑在設計過程中沒有被考慮到，在設計投片前問題不會暴露出來，因此有可能導致成本高昂的重新投片。約束管理工具可對萬用字元產生的例外進行擴展和形式確認。

‧低估對已驗證的形式引擎需求。產生的故障路徑在允許合成或實現工具從成本等式中刪除之前，必須被形式驗證工具確認。‘黃金約束’可能只是對設計規格的快速解釋。

‧費力地在報告文件的上千行程式碼中查找約束警告。現代約束管理工具提供了成熟的圖形化環境來識別約束問題，並提供反例(當確認失敗時)和方便的除錯功能。

‧在重複或重疊約束情況下，假設最後一次應用是正確的。要與設計師或系統架構師一起進行檢查並找出真實的意圖。約束管理工具可以標示出衝突，但只有靠用戶自己才能驗證哪條語句反映了晶片或環境的目標行為。在有疑問時，一定要仔細檢查！