發布日期：2022-07-14 點擊率：57
多年來,電子設計自動化(EDA)工具已經變得相當成熟。目前,它們在芯片制造各方面的設計和驗證中發揮著重要的作用,但設計約束(design constraint)的確認仍是其比較落后的一個領域。雖然芯片設計、功能驗證、時序驗證和制造已經高度自動化,但設計約束的編寫和驗證大部分還得依賴人工操作。
現在已經有軟件可以用來管理、驗證甚至創建設計約束,從而幫助設計師縮短設計周期,提高設計約束的質量。約束的改進意味著硅片可以達到更高質量,特別是在90nm及以下工藝尺寸的情況下(圖1)。
約束確認的擴展之一是異常生成(exception generation)。約束管理工具可以檢查網表,并發現功能故障路徑。工具必須使用經過驗證的形式引擎進行確認,以聲明它們是故障路徑。一旦被證實是故障路徑,它們就可以從成本等式以及綜合和實現工具的靜態時序分析中去除。這樣可以讓優化引擎集中資源處理實際路徑,有助于實現更小尺寸、更高性能和更低功耗的設計。當向更復雜的設計和更精細的幾何尺寸發展時,自動化約束管理將成為主流,并引領設計自動化的新時代。為了充分利用這一功能,下面專門針對約束產生提出一些建議:
建議
? 創建的約束要覆蓋設計環境的所有方面,例如所有時鐘、生成的時鐘、接口時序和負載能力以及諸如故障路徑等時序異常等。通常約束文件是從一個項目到另一個項目這樣傳下來的。這樣,每個約束必須匹配設計規范或新項目的系統級約束。因此,必須復查該規范,并添加遺漏的約束。
? 利用約束確認工具驗證約束的正確性和質量。質量檢查應包括SDC語法檢查,語法上正確但存在像錯誤睡眠模式等問題的SDC構造,以及約束或異常的覆蓋。同時,應和所有參與該項目的設計師一起去推定被工具標示的約束問題帶來的影響。
? 當使用自底向上的綜合和/或實現流程時,需要特別注意分層約束(hierarchical constraints)。在頂層定義的任何故障路徑、案例分析、多次循環路徑等也必須在模塊級反映出來。設計師必須對諸如被聲明為芯片級故障路徑而在模塊級卻不是同一路徑等約束不一致性進行檢查。當具有時鐘定義的頂層引腳在只有一條create-clock語句描述的模塊端口的扇入中時還會發生另外一個常見的問題。該問題通常是遺漏set_case_analysis語句引起的。在有成百上千行SDC代碼的大型設計中,這種遺漏現象很容易發生。而約束管理工具可以在相對人工方法短很多的時間內發現這種情況。
?.要注意,更改名稱可導致約束文件和設計RTL或網表的失配。這些問題有一些(但不是全部)可以被綜合和布局布線工具標示出來,但設計師不得不在報告文件中逐頁搜索警告項。這又是一個極耗人工的過程。而目前的約束驗證工具可以使這一過程自動化,并向設計師提供以彩色標示、通過或沒通過規則檢查的反饋信息。
? 使用不僅能閱讀和創建SDC約束同時還能閱讀和創建PSL斷言的工具,以便架起仿真和形式約束確認之間的連接橋梁。
? 開發形式驅動的異常生成以提高硅片質量。一些工具可以從綜合、實現或靜態時序分析工具讀取關鍵故障路徑(CFP)來減少需要處理的時序路徑數量。這叫做CFP生成。
? 考慮使用集成現有形式技術(如等效檢查、低功率和時鐘域驗證)的工具。這樣可以使其在設計團隊內部更容易被采納和學習。一些工具還提供到現有的允許自動腳本生成和交叉檢測分析的實現工具的鏈接。
不建議
? 在創建諸如錯誤路徑等時序異常時使用帶通配符的松散條件。通配符在擴展時可能會導致綜合和實現工具的速度極其緩慢。能夠屏蔽真正功能路徑的通配符將會造成意料之外的故障路徑。由于這些路徑在設計過程中沒有被考慮到,在設計流片前問題不會暴露出來,因此有可能導致成本高昂的重新流片。而約束管理工具可以擴展和通過形式確認由通配符造成的異常。
? 低估對已驗證的形式引擎的需求。必須經過形式校驗的確認才允許綜合或實現工具從成本等式中刪除生成的故障路徑。“黃金約束”或許只是對設計規范的快速解釋。
?. 試圖在報告文件的上千行代碼中查找約束警告。因為現代約束管理工具已能提供完善的圖形化環境來識別約束問題,并提供反例(當確認失敗時)和簡便的調試功能。
? 在重復或重疊約束的情況下,假想最后一次應用是正確的。要與設計師或系統架構師一起進行檢查并找出真實的意圖。約束管理工具可以標示出沖突,但只有用戶自己才能核實哪條語句反映了芯片或環境的目標行為。在有疑問時,一定要仔細檢查!
作者:Jason Ware
Cadence公司
下一篇： PLC、DCS、FCS三大控
上一篇： MEMS加速計校準提升工
