時鐘樹優(yōu)化與有用時鐘延遲在 “后端時序修正基本思路” 提到了時序優(yōu)化的基本步驟。其中，最關鍵的階段就是時鐘樹建立?；镜膬?yōu)化都優(yōu)先在數據路徑上進行，并且希望路徑盡量的短，最好在一個時鐘周期之內。當然，如果考慮輸入、輸出延遲，收斂悲觀因素，庫的建立時間，與時鐘不確定性，以及不同時鐘沿觸發(fā)等因素，這個要求還要進一步的壓縮，這些將在以后陸續(xù)進行討論。

通常，我們希望時鐘樹偏差(clock tree skew) 越小越好，目標為零。所以，在建立時鐘樹(CTS)之前，我們首先將時鐘設定為理想時鐘。這樣的好處是，優(yōu)化數據路徑時，不會對時鐘路徑有額外的修改。而且，因為排除了時鐘的影響，可以看到最終優(yōu)化的結果，是否能夠滿足時序的要求。如果不滿足，最要考慮的就是數據路徑組合邏輯是否太多，導致延遲過長。其他，可以估計一下RC延遲所占的比例，比如15%左右，過長時，檢查是否路徑邏輯單元之間是否間隔的太長等等。不過，本
文重點要討論的是，路徑過長時，如何通過增加有用時鐘延遲(useful skew) 來達到時序的滿足。

IC compiler 有這樣的命令 skew_opt ，還有其兩次流程（two pass）可供參考。

閱讀過本文后，我相信大家可以大致了解其工作的基本思路。

如果流程不正確，skew_opt 可能花費過長的運行時間，而且，不能達到預期的效果。如果我們清楚其中的原理，就可以更好，更自由的運用與發(fā)揮。

在不要考慮過多的情況下，如圖，在理想時鐘前提下，時序無法滿足，即slack 0 。原本我們可以做：

1，最短化數據路徑，

2，提前啟動時鐘路徑，

3，推遲捕獲時鐘路徑。

因為選項1，我無法壓縮它，現在我可以做的，就只有選項2和3了。

以選項3為例，目標為加長捕獲時鐘路徑：

set slack [get_attr [get_timing_path] slack]

set_clock_tree_exceptions

-float_pin_max_delay_rise $slack

-float_pin_min_delay_rise $slack

-float_pins $capture_clock_pin

以上是icc 命令的范例，大體上表達將小于零的slack 以時鐘特例的形式賦給捕獲時鐘路徑在寄存器的時鐘腳位。這樣，icc在進行時鐘樹綜合的時候，就會有意在捕獲路徑上增加多的延遲單元，起到人為的偏移，從而實現用戶的意圖。

當然, skew_opt 中，還有運用set_clock_latency和balance_group 來輔助時鐘樹平衡，以達到更好的效果。