摘要
隨著洩漏功耗成為待機模式下的主要能耗，降低洩漏功耗也成為客戶實現節能的主要途徑之一。故現有的實現流程中需要採用快捷的解決方案，不僅對設計收斂影響最小，還應盡可能地縮短執行的彙聚時間。
建議的方案適合於那些採用雙/三重Vth(臨界電壓)技術、無需對現有RTL至GDS流程做任何修改的設計。
1.0引言
洩漏功耗是固有的靜態功耗，與開關及內部功耗(定義為動態功耗)共同構成總體功耗。
洩漏功耗與應用無關，主要是來自於：
* 源汲極次臨界(sub-threshold)電流，這是臨界電壓降低以致溝道不完全關斷的結果。
* 閘極到溝道的洩漏電流。
在多Vth技術中，次臨界電流與Vth成指數關係，故低Vth單元的速度更快，但洩漏功耗也要大得多。
隨著製程尺度的縮小，這種情況愈加嚴重，而且在90nm及以下製程節點，對大多數行動應用而言，這一問題越來越顯著。
降低洩漏功耗是一項貫穿架構設計、VLSI設計、合成、P&R(佈局佈線)直至Signoff(簽核完成)的任務。
功率設計包括減少關鍵和次關鍵路徑的數量，以便在可能時讓更多的單元被映射到高Vth上。此外，智慧合成(smart Synthesis)與P&R的使用對設計的最終洩漏模式也有很大影響。
本文介紹的洩漏減少方法焦點在於流程實現的最後階段，而且，雖然它主要是針對PrimeTime編寫，卻並不局限於某個專用P&R/Signoff工具。
本文2.0節描述了整個流程圖，並對演算法進行剖析；3.0節呈現了利用這種方法獲得的部分結果；4.0節則包括普通主題和代碼實例。
2.0 方法描述
2.1全流程概述
這種洩漏功耗最佳化方法瞄準最後階段的佈局後設計工作。其概念是讓設計利用基於多個Vth的交換策略，提前一步實現最大洩漏的最佳化。
圖2-1是整個流程的模組示意圖，其中黃色和褐色矩形框代表洩漏最佳化。這個用於驗證客戶設計的系統運行在PrimeTime/StarExtract原始signoff環境下。
圖2-1：洩漏功耗減少方案流程示意圖
這種方法在完整的RTL至GDSII流程之後讓最終設計進入原始signoff環境，然後開始搜索那些能夠被交換到相應的更高Vth而又不會影響設計性能的單元。
基本上，這意味著這種最佳化將在設計的正Slack(時間裕量)路徑上進行。
在最佳化過程中，需檢查下列設計參數：
* 建立時間違反
* 設計規則，如最大傳輸時間(max_transition)違反和最大電容 (max_capacitance)違反
* 由衰減受害者(victims)引起的串音(Crosstalk)違反
* 時鐘網路(Clock nets)設計規則
* 不應被接觸或改變的特殊單元和結構
* 不同模式和邊角(比如功能性/測試模式WC/BC等)
洩漏減少流程的第一個階段(即示意圖中的黃色矩形框)是最佳化流程中主要的耗時部分，並涉及利用PrimeTime“what-if”分析的搜索和交換策略。這一步驟會反覆進行，直到找到所有適合交換的單元。
最佳化流程的第二階段(即示意圖中的褐色矩形框)是佈局後設計(ECO)上的交換執行，RC提取(RC-Extraction)和整個STA運行，並重新運行全部signoff環境。
最佳化流程在這一階段對“what-if”分析與全部RC提取之比較後發現的違反錯誤進行修正。與PrimeTime的快速計算以及總體運行時間減小的的優點相比，這些錯誤就相對不起眼了。因此，這一步驟的反覆次數應該較小。該階段的缺點是需要重新運行完整提取，從而增加總體運行時間。
在所有違反都得到修正(第二階段)之後，最佳化設計的輸出在功能性上與原始的設計佈局相同，但大大減少了不必要的低/標準Vth單元，因此降低了功耗。
這種方法節省的總體功耗取決於RTL編碼以及RTL-to-GDS實現流程早期階段的洩漏意識。不過，利用這種流程可確保設計在Signoff要求方面得到最大限度的最佳化。這個問題十分重要，因為實際實現和Signoff最佳化之間總是存在差距，而在最佳化流程之後，這一差距可被減小。
2.2 交換演算法
這種方法的目的是盡可能找出非時序關鍵路徑(即正Slack路徑)上的低/標準Vth單元，並用高Vth單元來替代，同時不影響時序或任何其他設計要求。
這種演算法的主要概念是根據其所影響的端點數目對標準/低Vth單元進行分類。
比如，經過單元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。
2.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
此外，假設在下列單元上換回原始形式會導致：
* 單元D和B的單元延時將減少30 ps
* 單元C的單元延時將減少35 ps
* 單元A的單元延時將減少45 ps
很明顯，換回單元A就可以解決三個端點 的違反問題，不必分別交換每個端點的單元(D和B或C)。
3.0 結果
這種方法最初是在CEVA內部開發的一款DSP產品CEVA-X1622 DSP內核上執行。
其設計規模在450,000閘左右。流程主要部分的總體運行時間大約為12個小時(即運行一個晚上)(見全流程概述圖2-2的黃色部分)，而使ECO結果與Signoff相符合的Signoff運行時間很少(見全流程概述圖2-2的褐色部分)。
4.0 附錄
4.1 多模工作
當工作在一個以上的模式中時，必需針對每一個模式分別執行最佳化，且交換列表中不能包括其他模式的單元。
對於每一個模式，這種方法都生成ECO文件，並將之附加到包含了所有模式交換的全局文件中。然後，在佈局後設計中執行單個ECO，並對每一個模式執行一次完整的RC提取+ STA運行。
由於在某個模式中某些路徑可被視為“無約束路徑”(unconstrained paths)，故必需予以分離，但在其他模式中它們可能是時序約束的。這種情形可能導致虛假交換，增加修正這些違反所需的總體運行時間。
以下圖為例(圖4-1)；這是控制受約束路徑的Scan_enable信號。在功能性模式中，該信號具有恒定值，因此PrimeTime看不到掃描模式路徑(紅色)。這時，PrimeTime會把紅色路徑上的所有單元交換到高Vth，從而可能造成max_transition違反，甚至建立違反。
把這些模式分離開來可以防止這種情況發生，並改善總體運行時間和真實交換數目。
隨著洩漏功耗成為待機模式下的主要能耗，降低洩漏功耗也成為客戶實現節能的主要途徑之一。故現有的實現流程中需要採用快捷的解決方案，不僅對設計收斂影響最小，還應盡可能地縮短執行的彙聚時間。
建議的方案適合於那些採用雙/三重Vth(臨界電壓)技術、無需對現有RTL至GDS流程做任何修改的設計。
1.0引言
洩漏功耗是固有的靜態功耗，與開關及內部功耗(定義為動態功耗)共同構成總體功耗。
洩漏功耗與應用無關，主要是來自於：
* 源汲極次臨界(sub-threshold)電流，這是臨界電壓降低以致溝道不完全關斷的結果。
* 閘極到溝道的洩漏電流。
在多Vth技術中，次臨界電流與Vth成指數關係，故低Vth單元的速度更快，但洩漏功耗也要大得多。
隨著製程尺度的縮小，這種情況愈加嚴重，而且在90nm及以下製程節點，對大多數行動應用而言，這一問題越來越顯著。
降低洩漏功耗是一項貫穿架構設計、VLSI設計、合成、P&R(佈局佈線)直至Signoff(簽核完成)的任務。
功率設計包括減少關鍵和次關鍵路徑的數量，以便在可能時讓更多的單元被映射到高Vth上。此外，智慧合成(smart Synthesis)與P&R的使用對設計的最終洩漏模式也有很大影響。
本文介紹的洩漏減少方法焦點在於流程實現的最後階段，而且，雖然它主要是針對PrimeTime編寫，卻並不局限於某個專用P&R/Signoff工具。
本文2.0節描述了整個流程圖，並對演算法進行剖析；3.0節呈現了利用這種方法獲得的部分結果；4.0節則包括普通主題和代碼實例。
2.0 方法描述
2.1全流程概述
這種洩漏功耗最佳化方法瞄準最後階段的佈局後設計工作。其概念是讓設計利用基於多個Vth的交換策略，提前一步實現最大洩漏的最佳化。
圖2-1是整個流程的模組示意圖，其中黃色和褐色矩形框代表洩漏最佳化。這個用於驗證客戶設計的系統運行在PrimeTime/StarExtract原始signoff環境下。
圖2-1：洩漏功耗減少方案流程示意圖
這種方法在完整的RTL至GDSII流程之後讓最終設計進入原始signoff環境，然後開始搜索那些能夠被交換到相應的更高Vth而又不會影響設計性能的單元。
基本上，這意味著這種最佳化將在設計的正Slack(時間裕量)路徑上進行。
在最佳化過程中，需檢查下列設計參數：
* 建立時間違反
* 設計規則，如最大傳輸時間(max_transition)違反和最大電容 (max_capacitance)違反
* 由衰減受害者(victims)引起的串音(Crosstalk)違反
* 時鐘網路(Clock nets)設計規則
* 不應被接觸或改變的特殊單元和結構
* 不同模式和邊角(比如功能性/測試模式WC/BC等)
洩漏減少流程的第一個階段(即示意圖中的黃色矩形框)是最佳化流程中主要的耗時部分，並涉及利用PrimeTime“what-if”分析的搜索和交換策略。這一步驟會反覆進行，直到找到所有適合交換的單元。
最佳化流程的第二階段(即示意圖中的褐色矩形框)是佈局後設計(ECO)上的交換執行，RC提取(RC-Extraction)和整個STA運行，並重新運行全部signoff環境。
最佳化流程在這一階段對“what-if”分析與全部RC提取之比較後發現的違反錯誤進行修正。與PrimeTime的快速計算以及總體運行時間減小的的優點相比，這些錯誤就相對不起眼了。因此，這一步驟的反覆次數應該較小。該階段的缺點是需要重新運行完整提取，從而增加總體運行時間。
在所有違反都得到修正(第二階段)之後，最佳化設計的輸出在功能性上與原始的設計佈局相同，但大大減少了不必要的低/標準Vth單元，因此降低了功耗。
這種方法節省的總體功耗取決於RTL編碼以及RTL-to-GDS實現流程早期階段的洩漏意識。不過，利用這種流程可確保設計在Signoff要求方面得到最大限度的最佳化。這個問題十分重要，因為實際實現和Signoff最佳化之間總是存在差距，而在最佳化流程之後，這一差距可被減小。
2.2 交換演算法
這種方法的目的是盡可能找出非時序關鍵路徑(即正Slack路徑)上的低/標準Vth單元，並用高Vth單元來替代，同時不影響時序或任何其他設計要求。
這種演算法的主要概念是根據其所影響的端點數目對標準/低Vth單元進行分類。
比如，經過單元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。
2.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
此外，假設在下列單元上換回原始形式會導致：
* 單元D和B的單元延時將減少30 ps
* 單元C的單元延時將減少35 ps
* 單元A的單元延時將減少45 ps
很明顯，換回單元A就可以解決三個端點 的違反問題，不必分別交換每個端點的單元(D和B或C)。
3.0 結果
這種方法最初是在CEVA內部開發的一款DSP產品CEVA-X1622 DSP內核上執行。
其設計規模在450,000閘左右。流程主要部分的總體運行時間大約為12個小時(即運行一個晚上)(見全流程概述圖2-2的黃色部分)，而使ECO結果與Signoff相符合的Signoff運行時間很少(見全流程概述圖2-2的褐色部分)。
4.0 附錄
4.1 多模工作
當工作在一個以上的模式中時，必需針對每一個模式分別執行最佳化，且交換列表中不能包括其他模式的單元。
對於每一個模式，這種方法都生成ECO文件，並將之附加到包含了所有模式交換的全局文件中。然後，在佈局後設計中執行單個ECO，並對每一個模式執行一次完整的RC提取+ STA運行。
由於在某個模式中某些路徑可被視為“無約束路徑”(unconstrained paths)，故必需予以分離，但在其他模式中它們可能是時序約束的。這種情形可能導致虛假交換，增加修正這些違反所需的總體運行時間。
以下圖為例(圖4-1)；這是控制受約束路徑的Scan_enable信號。在功能性模式中，該信號具有恒定值，因此PrimeTime看不到掃描模式路徑(紅色)。這時，PrimeTime會把紅色路徑上的所有單元交換到高Vth，從而可能造成max_transition違反，甚至建立違反。
把這些模式分離開來可以防止這種情況發生，並改善總體運行時間和真實交換數目。
