摘要

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

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

　　引言

　　泄漏功耗是固有的靜態(tài)功耗，與開關(guān)及內(nèi)部功耗 (定義為動態(tài)功耗) 共同構(gòu)成總體功耗。

　　泄漏功耗與應(yīng)用無關(guān)，主要是來自于：

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

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

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

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

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

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

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

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

　　方法描述

　　1.全流程概述

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

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

　　這種方法在完整的RTL至GDSII流程之后讓最終設(shè)計進入原始signoff環(huán)境，然后開始搜索那些能夠被交換到相應(yīng)的更高Vth而又不會影響設(shè)計性能的單元。

　　基本上，這意味著這種優(yōu)化將在設(shè)計的正Slack (時間裕量) 路徑上進行。

　　在優(yōu)化過程中，需檢查下列設(shè)計參數(shù)：

　　● 建立時間違反

　　● 設(shè)計規(guī)則，如最大傳輸時間 (max_transition) 違反和最大電容 (max_capacitance) 違反

　　● 由衰減受害者 (victims) 引起的串擾 (Crosstalk) 違反

　　● 時鐘網(wǎng)絡(luò) (Clock nets) 設(shè)計規(guī)則

　　● 不應(yīng)被接觸或改變的特殊單元和結(jié)構(gòu)

　　● 不同模式和邊角 (比如功能性/測試模式WC/BC 等)

　　泄漏減少流程的第一個階段 (即示意圖中的黃色矩形框) 是優(yōu)化流程中主要的耗時部分，并涉及利用PrimeTime“what-if”分析的搜索和交換策略。這一步驟會反復(fù)進行，直到找到所有適合交換的單元。

　　優(yōu)化流程的第二階段 (即示意圖中的褐色矩形框) 是后版圖設(shè)計 (ECO) 上的交換執(zhí)行，RC提取 (RC-Extraction) 和整個STA 運行，并重新運行全部signoff 環(huán)境。

　　優(yōu)化流程在這一階段對“what-if”分析與全部RC提取之比較后發(fā)現(xiàn)的違反錯誤進行修正。與PrimeTime的快速計算以及總體運行時間減小的的優(yōu)點相比，這些錯誤就相對不起眼了。因此，這一步驟的反復(fù)次數(shù)應(yīng)該較小。該階段的缺點是需要重新運行完整提取，從而增加總體運行時間。

　　在所有違反都得到修正 (第二階段) 之后，優(yōu)化設(shè)計的輸出在功能性上與原始的設(shè)計版圖相同，但大大減少了不必要的低/標準Vth單元，因此降低了功耗。

　　這種方法節(jié)省的總體功耗取決于RTL編碼以及RTL-to-GDS實現(xiàn)流程早期階段的泄漏意識。不過，利用這種流程可確保設(shè)計在Signoff要求方面得到最大限度的優(yōu)化。這個問題十分重要，因為實際實現(xiàn)和Signoff優(yōu)化之間總是存在差距，而在優(yōu)化流程之后，這一差距可被減小。

　　2.交換算法

　　這種方法的目的是盡可能找出非時序關(guān)鍵路徑 (即正Slack路徑) 上的低/標準Vth單元，并用高Vth單元來替代，同時不影響時序或任何其它設(shè)計要求。

　　這種算法的主要概念是根據(jù)其所影響的端點數(shù)目對標準/低Vth單元進行分類。

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

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

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

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

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

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

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

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

　　此外，假設(shè)在下列單元上交換到高Vth將導(dǎo)致：

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

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

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

　　現(xiàn)在，對這兩條路徑的泄漏優(yōu)化，我們有兩個選擇：

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

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

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

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

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

　　把產(chǎn)生違反的單元Swapping-back (換回) 到其原始形式的次數(shù)應(yīng)該盡量小。

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

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

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

　　且看下面的簡單例子：

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

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

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

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

　　此外，假設(shè)在下列單元上換回原始形式會導(dǎo)致：

　　● 單元D和B的單元延時將減少30 ps

　　● 單元C的單元延時將減少35 ps

　　● 單元A的單元延時將減少45 ps

　　很明顯，換回單元A就可以解決3個端點 (見圖2) 的違反問題，不必分別交換每個端點的單元 (D 和 B或C)。

　　結(jié)果

　　這種方法最初是在CEVA內(nèi)部開發(fā)的一款DSP產(chǎn)品CEVA-X1622 DSP內(nèi)核上執(zhí)行。

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

　　附錄

　　多模工作

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

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

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

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

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