如何在后版圖網表上優化泄漏功率

　　比如，經過單元D、E 和 F終止于單個端點 (“端點1”和“端點4”) 的路徑，由于它們只影響一個端點，故標注為#1 (或“group_1”)。

　　同樣地，單元B和C屬于#2 (或“group_2”)，因為它們影響兩個端點 (“端點2”和“端點3”)，“group_2”……“group_n”以此類推。

　　對單元進行分類和標注之后，我們就可以從“group_1”開始，在一條正Slack路徑上執行單元的遞增式交換，然后是“group_2”…… “group_n”。在 PrimeTime中，利用“what-if analysis”來完成這一任務。

　　在任何兩個鄰近組“group_n”和“group_n+1”之間，算法都進行時序更新，以便在對“group_n+1”的任何單元進行交換之前，考慮到“group_n”上執行的交換。這是為了避免因虛假交換導致稍后必需修正 (重新交換)。

　　在進入“group_n+1”之前，對“group_n”中的所有可能單元都進行交換測試。這么做的目的是確保整個設計的最大交換次數。

　　舉一個簡單的例子來說明這種方法的原理：

　　路徑1：A --> D --> “端點 1”，正Slack +50 ps

　　路徑2: A -->B --> C -->“端點 2”，正Slack +70 ps

　　此外，假設在下列單元上交換到高Vth將導致：

　　● 單元D和B的單元延時將增加30 ps

　　● 單元C的單元延時將增加35 ps

　　● 單元A的單元延時將增加45 ps

　　現在，對這兩條路徑的泄漏優化，我們有兩個選擇：

　　● 選擇1：把單元A交換到高Vth;這將在路徑1上產生 +5 ps 的Slack，在路徑2上產生 +25ps Slack。不過，這并非最佳方法，因為它不利于交換更多的單元 (B、D和C)，節省的總體泄漏功耗較少。

　　● 選擇2：把單元D交換到高Vth，這將在路徑1上產生 +20 ps 的Slack;交換B和C將在路徑2上產生 +5ps Slack。這種方法是迄今最好的方法，節省的泄漏功耗較大 (假設單元B、C和D的總體泄漏功耗大于單元A的泄漏功耗。)

　　此外，在交換某個單元時，我們必須把影響相同端點的所有其他組單元排除在外。如上例，若我們現在在“group_2”中，并交換單元C，則我們就必需在下一次搜索中把“端點2”和“端點3”除去，直到時序更新完成。只有這樣，才能獲得路徑的正確時序，然后我們可以繼續檢查單元B的交換。否則，就可能導致虛假交換，而過多虛假交換也許會造成路徑出現負Slack。

　　3.重新交換違反者 (violators)

　　由于PrimeTime“what-if”分析的結果可能不同于執行ECO及運行整個Signoff的結果，在完整提取之后常常少有違反出現，同時沒有在Signoff 運行之前檢測。這是因為單元交換會造成單元電容的變化。在執行“what if”時，PrimeTime必需對這種變化進行“在線”重新計算，同時在整個Signoff下重新提取，以提高精度。顯然，PrimeTime的重新計算要快得多，并因此讓整個方案具有可行性。

　　把產生違反的單元Swapping-back (換回) 到其原始形式的次數應該盡量小。

　　因此，Swapping-back的情況與2.2節描述的過程相反。

　　一般而言，每一個被交換過的單元都被標注為“已交換的”，故在執行重新交換時，我們需要從違反端點沿路徑往回搜索，找到之前“已交換的”單元，就把它交換回原始形式。

　　為了有效完成這一工作，并盡量減少換回次數，我們首先換回那些影響端點數目最多的單元。

　　且看下面的簡單例子：

　　假設A、B、C和D是準備交換的單元，但在執行ECO、提取 (即Signoff) 之后，在“端點1”、“端點2”和“端點3”上存在建立時序違反，出現較小的負Slack：

　　路徑1: A --> D --> “端點1”，負 Slack -3 ps

　　路徑2: A -->B --> C --> “端點2”，負 Slack -5 ps

　　路徑2: A -->B --> C --> “端點3”，負 Slack -5 ps