摘要

　　隨著泄漏功耗成為待機模式下的主要能耗，降低泄漏功耗也成為客戶實現節能的主要途徑之一。故現有的實現流程中需要采用快捷的解決方案，不僅對設計收斂影響最小，還應盡可能地縮短執行的匯聚時間。

　　建議的方案適合于那些采用雙/三重 Vth (閾值電壓) 技術、無需對現有 RTL 至 GDS 流程做任何修改的設計。

　　引言

　　泄漏功耗是固有的靜態功耗，與開關及內部功耗 (定義為動態功耗) 共同構成總體功耗。

　　泄漏功耗與應用無關，主要是來自于：

　　● 源漏亞閾值 (sub-threshold) 電流，這是閾值電壓降低以致溝道不完全關斷的結果。

　　● 柵極到溝道的泄漏電流。

　　在多Vth技術中，亞閾值電流與Vth成指數關系，故低Vth單元的速度更快，但泄漏功耗也要大得多。

　　隨著工藝尺度的縮小，這種情況愈加嚴重，而且在90nm及以下工藝節點，對大多數移動應用而言，這一問題越來越顯著。

　　降低泄漏功耗是一項貫穿架構設計、VLSI設計、綜合、P&R (布局布線) 直至Signoff (完成) 的任務。

　　功率設計包括減少關鍵和次關鍵路徑的數量，以便在可能時讓更多的單元被映像到高Vth上。

　　智能綜合 (smart Synthesis) 與P&R的使用對設計的最終泄漏模式也有很大影響。

　　本文介紹的泄漏減少方法焦點在于流程實現的最后階段，而且，雖然它主要是針對PrimeTime編寫，卻并不局限于某個專用P&R/Signoff工具。

　　方法描述

　　1.全流程概述

　　這種泄漏功耗優化方法瞄準最后階段的后版圖設計工作。其概念是讓設計利用基于多個Vth的交換策略，提前一步實現最大泄漏的優化。

　　圖1是整個流程的模塊示意圖，其中黃色和褐色矩形框代表泄漏優化。這個用于驗證客戶設計的系統運行在PrimeTime/StarExtract原始signoff環境下。

　　這種方法在完整的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.交換算法

　　這種方法的目的是盡可能找出非時序關鍵路徑 (即正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。

　　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就可以解決3個端點 (見圖2) 的違反問題，不必分別交換每個端點的單元 (D 和 B或C)。

　　結果

　　這種方法最初是在CEVA內部開發的一款DSP產品CEVA-X1622 DSP內核上執行。

　　其設計規模在450,000門左右。流程主要部分的總體運行時間大約為12個小時 (即運行一個晚上) (見全流程概述圖2的黃色部分)，而使ECO結果與Signoff相符合的Signoff運行時間很少 (見全流程概述圖2的褐色部分)。

　　附錄

　　多模工作

　　當工作在一個以上的模式中時，必需針對每一個模式分別執行優化，且交換清單中不能包括其它模式的單元。

　　對于每一個模式，這種方法都生成ECO檔，并將之附加到包含了所有模式交換的全局文件中。然后，在后版圖設計中執行單個ECO，并對每一個模式執行一次完整的RC提取 + STA運行。

　　由于在某個模式中某些路徑可被視為“無約束路徑”(unconstrained paths)，故必需予以分離，但在其它模式中它們可能是時序約束的。這種情形可能導致虛假交換，增加修正這些違反所需的總體運行時間。

　　以左圖為例 (圖5);這是控制受約束路徑的Scan_enable信號。在功能性模式中，該信號具有恒定值，因此PrimeTime看不到掃描模式路徑 (紅色)。這時，PrimeTime會把紅色路徑上的所有單元交換到高Vth，從而可能造成max_transition違反，甚至建立違反。

　　把這些模式分離開來可以防止這種情況發生，并改善總體運行時間和真實交換數目。