|
第I章：介紹 物理設計中，時序收斂一直是個問題，解決這個問題的方法多式多樣。本文將探討幾種可幫助盡早檢測到可能要在非常晚期設計階段才會出現的問題以及降低正常P&R階段TNS（負余量總和）的方法。這些方法以Magma Talus現有功能為基礎，但功能的使用有經過進一步擴展或是重新考量。 第II章：繞障I/O密度地圖 隨著芯片規模的日益壯大，層次化設計正逐漸成為許多芯片設計的一種常用方法。在層次化設計中，最高層設計師（top level designer）會將整個芯片劃分為多個小塊。每個小塊作為一個獨立功能塊，將貫穿整個物理設計流程，最后再由最高層設計師將這些小塊集成為完整芯片。這樣一來，集成的時候塊邊界難免會有時序和布線問題。通常，這些問題的修復技術是要落實到功能塊上，將由塊設計師（block designers）應用以進行修復工作。 在一些案例中，功能塊設計師將發現很難在布線后晚期階段修復這些邊界問題，這會導致項目進度大大延遲。 圖1是一例這種問題。在功能塊左上角有個大型宏，它占用了許多布線層，在其周圍區域造成了非常高的擁塞情況。圖中加亮線是貫穿這個區域的一條路徑，中間插入了幾個緩沖區。有幾點應多加注意： 1.這條路徑是往下走的，因為在大型宏的北面沒有足夠空間用于緩沖區、沒有足夠導軌用于布線。 2.線路中間部分由于高度擁塞布線而呈割階狀態。 3.很難這個宏旁邊找個位置插入新的緩沖區以修復轉換和建立違規。 圖1 上述第1點和第2 點是導致最高層時序差的罪魁禍首，第3點則是導致這個問題難以修復的原因所在。布線后功能塊層中內部狀態對于時序和布線來說還是很不錯的；但當最高層設計師開始修復這個時序問題后，插入了許多單元，布線也發生了很大變化，這些均使得內部時序和布線變得更為糟糕且難以融合。 原因相當簡單：沒有足夠資源可留給最高層設計師來修復這個時序問題。但如何才能讓塊設計師知道他需要在哪里保留資源和保留多少資源呢？功能塊設計后內部時序和布局很不錯，這時要假設將會有問題時真得特別困難。 通過分析具有類似問題的一些功能塊后，我們發現了幾個能反映最高層設計潛在困難的指標，比如：邊界網路繞障嚴重程度。繞障（Detour）雖可在一定區域實現好的DRC（設計規則檢查）數目，但這好DRC背后卻隱藏著問題。對于擁塞嚴重的區域，時序水平一直在降低，新插入的單元先是會讓好的布線變差，然后還會變得不可布線。 為了評估邊界網路繞障嚴重程度，設計師首先要計算這些網路的密度，接著再以顏色直觀顯示其嚴重級別。這個過程分為5個步驟：
關鍵是第4步，它意味著最高層修復工作哪里將存在潛在困難。每個步驟的詳細內容如下所述： 步驟1 首先，你可將每個邊界分為多個小段；可基于個人喜好，設50um或100um作為一段長度。其次，計算出每小段中所有非PG（non-PG）引腳數量，基于每段中引腳數以不同顏色來加亮這些片段；為每小段選擇適當顏色閾值很重要，因為它直接影響到你對一個區域是否具有高引腳密度的印象。設計師可基于之前項目經驗來設置顏色。你需要將所有信號引腳層、類似模擬的特殊引腳層都計算在內，但電源引腳除外。可視部分可以通過命令“ui layout sketch line …”繪制，而所有其它部分則可通過自帶Tcl來完成。 圖2 步驟2 步驟2中顯示了在一些區域里I/O引腳密度高，那么我們需將存儲器從高密度區域（白色區域最高，紅色區域其次）移出。 步驟3 完成布線后，接下來是要找出所有連接I/O引腳的繞障網路。判斷一個網路是否是繞障網路，可通過對比網路線長與其所連接引腳的曼哈頓距離（Manhattan distance）來完成。設計師可依據個人需求來設置20%或30%作為閾值；當然若能設置最短長度就更好了，這樣就可忽略不計比它更短的網路；若沒有這個設置，設計師將會看到許多短的“繞障”網路，而實際上這些都是錯誤警報。 在測試功能塊中，1對1連接占了絕大部分。基于這點，作者假設忽略多連接網路不會對最終結果有任何影響，因此此次demo只計算了一個輸入一個輸出的網路，大大簡化了計算腳本編寫。當然，這種假設還需要經過其它設計的驗證。 這次計算將產生一張所有繞障I/O網路名單。不過，如果直接就加亮所有這些網路（如圖3），設計師幾乎說不出哪里布線真的很差，哪里還不錯可以繼續當前布線。 圖3中上區域看起來最為擁擠，但事實上，它既不是根源所在，也不是最關鍵區域。我們需要以另一種可直接反映問題所在的方式來提供信息。 圖3 步驟4 我們可對步驟1中加亮I/O密度的腳本進行修改，用于加亮繞障I/O密度。當將一個網路分為多個小段的進行計算時，首先要在已發現的繞障網路名單中進行過濾，且只計算名單中有的那些網路。由于過濾后引腳數將會大大降低，因此設計師需要調整每個分色的閾值。最終結果見圖4。 步驟5 圖4證明了白色區域具有最多繞障的I/O網路。這建議我們： 1.移動大型宏，這是塊設計師可執行的最直接動作。 2.最高層分配引腳時降低白色/紅色區域的引腳密度，這需要最高層設計師與功能塊設計協作進行。 通常，這些大型宏被設置在那個地方肯定有其原因存在，因此在一些實際項目中重新分布模型引腳這種方式要更為切實可行。 圖4 這只是“如何將我們的經驗轉換為可視化檢查”的一個例子。設計師不僅可對這種繞障I/O進行可視化處理來作為潛在問題預測指標，而且還可根據已經過證明的設計相關經驗，將其它因素加入到可視化檢查中來。 第III章：時鐘門控克隆階段選擇 一般來說，執行時鐘門控克隆一共有2個階段：fix cell（修復單元）和fix clock（修復時鐘）；設計師還可同時在兩個階段進行克隆。因此在此提出了3種組合： 1.只fix cell階段克隆 2.只fix clock階段克隆 3.兩個階段同時克隆 如果是只fix cell階段克隆，那么設計師可采用命令“run clock gate_clone”在第一次全局布局/布線后執行克隆；相關配置可通過“force clock gate_clone”命令來完成。不過完成克隆后，‘force clock gate_clone’設置的約束將變為無效；如再需要fix cell階段克隆，那么設計師還要重新應用這些設置。 作者以幾個功能塊為例，對這3種方法進行了一次測試，通過比較結果來找出適合其中多數功能塊的最佳方案。 表1 表1是測試結果，要點如下： 1.黃色數據是一個功能塊的最好TNS，綠色數據是最佳區域。 2.第2種方法帶來了適合大部分案例的最佳結果，包括最好TNS和最佳區域。 什么樣差異會導致這樣的結果？圖5是功能塊一個角點的時鐘門控單元分布： 圖5 粉色單元是門控單元；黃色單元是時鐘樹緩沖區；線是時鐘樹飛線。 3個圖片為： 左：第1和第3種方法的fix cell階段。 中：第3種方法中的fix clock階段。 右：第2種方法中的fix clock階段。 圖5顯示的是：無fix cell階段克隆，時鐘門控單元少了許多，但時鐘緩沖區卻多了許多。原因之一是：CTS將門控單元后時鐘樹往上移動，因此對克隆的需求也減更少發。 進一步研究我們又有了其它發現，這可能是對‘為什么第3種方法門控單元更少’的另一種解釋。見圖6： 圖6 圖6是2張fix cell volcano中門控單元分布連接圖。圖中所顯示的只有觸發器（flops），其它模式單元則是隱藏的。左圖無克隆，右圖有克隆。左圖中，所有連接資源都來自時鐘樹根；右圖中，功能塊有明顯克隆過的門控單元樹結構。 圖6顯示了一個有趣的地方：如沒有fix cell階段門控克隆，觸發器的布局會更為緊密些。這已是對許多案例觀察的結果。一種可能解釋 是：由相同原始門控單元所控制的觸發器在布線期間有直接連接，因此相比那些由于門控單元不同而中斷連接的克隆試驗，它們的布局更為緊密。 圖7是 fix clock volcano中時鐘門控單元分布圖： 圖7 與之前案例一樣，若無fix cell階段克隆，所需時鐘樹元素將更少。在這個案例中，出于觸發器布局更緊密的原因總負載更低，因此所需的門控單元/時鐘樹元素更少。 在那些測試案例中，第2種方法的門控單元數量要比第1和第3種方法少了30"50%。盡管第2種方法需要在門控單元后創建時鐘樹，但門控單元面積的降低是創建時鐘樹這種額外面積所無法比擬的，因此最后總面積的贏家是第2種方法。 從時序角度來看，如果觸發器間連接不太復雜，那么在第2種方法中觸發器布局更緊密的設置將有助于降低路徑上負載，進而在統計時獲得更好時序，這是實際設計中最常見情況。 通過比較這些方法來找到一個最好的時鐘門控克隆方式的想法源自于一個真實案例。在這個案例中，時鐘的時序非常棘手，帶有高度復雜的組合邏輯。上百個最高失效端點都是門控單元使能引腳，導致了“門控克隆需針對這個功能塊進行優化”的想法。這個功能塊的最佳結果是只fix cell階段克隆、無fix clock階段克隆。后布線優化圖可獲得超過50ps的更好結果。原因之一是fix cell階段克隆將會在這個階段更早期就暴露出使能引腳相關違規，那么Talus就可更早地對它進行優化。 第IV章：多輪Fix Cell 布局是一個融合過程。運行的布局輪次越多，可獲得融合度就越好，但這是以時間和磁盤空間為代價的。設計師不僅可嘗試多運行幾輪以獲得最佳結果，同時還可擁有有關“如何運行每輪fix Cell”的不同選項。本章將探討3種每輪fix cell運行的方式并比較時序和擁塞。選項有： 1.使用fix cell階段中‘-iteration #’選項 2.直接在之前fix cell數據庫上重新運行fix cell 3.采用之前fix cell網表，基于修復時間、修復計劃和修復單元開始重新運行。 第1種方法是最直接方法，易于運行。第2種方法需要明確大部分fix cell快照以便能在未來運行中跳過細節步驟。第3種方法需花更多時間和精力；但如果fix cell期間網表變化很大，那么第3種方法效果最好。 我們選擇了幾個功能塊來測試這些方法，表2是幾個功能塊的數據。從時序角度來看，結果并不傾向于中意其中任何一種方法；從擁塞角度來看，第2種方法在絕大部分案例中勝出。 表2 ‘擁塞’項目系指fix cell 數據庫中‘report congestion $m’的總數。第2種方法可更好處理擁塞熱點。請比較圖8中擁塞地圖，結果更一目了然： 圖8 在實際項目中，設計師需要權衡考慮每輪的運行時間及可獲得的改善。你嘗試得輪次越多，你可獲得的效果就越好，但設計進度毫無疑問會被延遲。對于容易功能塊，設計師可通過單輪fix cell摸索著運行每個步驟，不需要考慮時序/擁塞問題；對于關鍵功能塊，2"3輪的fix cell將可帶來明顯的擁塞和時序改善。 對于一些特殊案例，設計師可能要在全局布局后fix cell期間添加大量邏輯。而這些邏輯可能有糟糕的擁塞問題，第2輪的增量全局布局并不能很好地處理這個問題。在這種情況下，第3種方法是3種方法中唯一能起作用的方法。 如果采用第2種方法，設計師需要考慮‘需保留什么快照’‘需清除什么快照’；而且一些步驟可能只運行一次，在其它輪的fix cell中將不再運行。 當資源成本在可接受范圍內時，設計師應嘗試對設計進行多輪的fix cell，它可與新平面布局試驗同步進行；與調整平面布局對比，它所消耗的人力幾乎可以忽略不計。在這些方法中，從擁塞角度來看，我們建議你直接在之前數據庫上運行fix cell；若在特殊案例中，設計師應嘗試第3種方法。 第V章：采用線路延時解決多角點下時序沖突 在許多設計中，設計師常在一些時序路徑上設置大的建立容限和保持容限以避免意料之外情況下時序失效，但它可能會給時序收斂帶來麻煩，特別是在深亞微米工藝中更是如此。采用單元尺寸調整、緩沖區插入/去除等常規方法有時不能同時清理最佳情況（bc）角點中保持時序和最差情況（wc）角點中建立時序。這種沖突會反復發生，使得時序無法融合。 我們常規的時序修復方法主要針對的是標準單元。而在深亞微米工藝中，不同時序角點的標準單元延時有很大差異。表3顯示了測試電路的wc和bc角點中標準單元和金屬線路的延時差異比較： 表3 在一個真實案例中，路徑有這樣需求： 1.在最差情況（wc）中，路徑延時少于2.5ns(建立) 2.在最好情況（bc）中，路徑延時多于1ns(保持) 但實際延時是： 1.最差情況（wc）中延時為2.1ns。 2.最好情況（bc）中延時為0.8ns。 因此路徑滿足了建立需求，但卻造成了保持違規。 想象一下通過改變單元（減少尺寸、插入、交換）來修復保持違規，多數延時變化只發生在單元上。到時將發生以下情況： 1.將保持延時從0.8ns修正為1ns，測試案例中延時提高了0.2ns。 2.使用只針對單元（cell only）方法，如：插入緩沖區、減少尺寸。如表3所描述，它給最差情況中單元延時帶來的改變是3倍，即0.2ns * 3 =0.6ns. 3.最差情況中延時從2.1ns提高到2.7ns，造成建立違規 2個角點間單元延時變化很大，因此如果設計師只盯著單元，而靠路徑本身解決沖突根本不可能。 根據測試電路結果，線路延時在不同角點下延時差異更小，因此如果使用線路延時來修復保持違規，最差情況（wc）中延時的反彈也不會這么大。最好情況中0.2ns的線路延時增長將只會帶來最差情況中0.24ns延時，因此最差情況中總延時為2.1ns + 0.24 ns = 2.34ns。這種方法可兼顧建立和保持時序兩方面需求。 以下是一些有關‘如何使用線路延時優化來修復時序’的詳細內容。 以保持修復為例。第一步就是要識別一組帶有這類建立和保持沖突的時序路徑。這類路徑可通過初步時序優化或通過項目約束文件來獲取；然后我們就可分析這些候選路徑并選擇真正目標。 第二步就是進行詳細時序分析并開始時序修復，它包括： 1.插入延時單元并手動將它們設置在版圖中。 2.決定單元和模式和尺寸，確保無轉換違規。 3.評估線路延時。如布線形狀良好，那么實際延時與評估結果間差別將不會太大。 4.采用talus在布線后分析時序結果。如還有時序違規，嘗試使用有用偏斜來修復。 5.如它們不能通過有用偏斜修復，那么回到步驟1或2開始新一輪修復工作。 設計師可能需要幾輪的這類修復工作才可完成時序清理。融合速度取決于線路延時評估精確性和實際布線形狀。. 實施步驟雖簡單，但在實施過程中設計師可能仍會遭遇到一些問題。其中之一就是，實際線路延時值與原始評估值差異相當大。如果差異是由不好的布線形狀所造成，那么設計師可打開Talus volcano并以交互方式修復它們。通常，有兩種不好的布線形狀：jog（割階）和繞障（detour）。對于割階，它可通過Talus命令：“run route optimize jog …”或“run route refine model –type jog…”來去除。 對于繞障，它通常出現在資源不足的后布線階段一些線路布線的時候。一種解決方法是：先在一個已布局卻未布線的volcano中單獨進行這些線路的布線；接著將它們加載回到后布線volcano中。設計師可選擇性地設置這些線路為軟或硬的預布線，以便他們在布線引擎嘗試解決布線DRC時不會有太多的割階。此外，你還可設置首選層，這樣主要線路的布線工作可在資源豐富的層中完成。 另一個可能問題是：惡化的耦和時序。這通常發生在一群總線信號單元相互布局緊密的時候，它們擁有到同一個方向的相似連接。連接這些單元的線路布局非常緊密，有長距離地并行布線。這些線路中每一條都是到其它網路的一個聚集器，同時也是一個犧牲品。這會導致嚴重的耦和時序違規。解決這類問題的關鍵是在完成線路修復后盡可能早地輸入耦和問題，否則它會在設計后期將帶來非常大的麻煩。通過控制布線形狀可很輕松地避免耦和時序惡化，如：使用多間距、添加屏蔽或在不同層進行它們的布線。 如采用線路延時進行多輪修復后，時序沖突仍未解決，那么建議檢查一下原始約束是否合理，是否有緩和約束的空間。約束變更會有進度延時和項目失敗的風險，因此設計師必須確保在項目一開始就盡其所能地檢查出更多的潛在問題，建立合理約束。 總結 有挑戰性功能塊總是需要非同一般的方法才能讓其時序回歸正常。這些方法雖是利用了現有Magma Talus功能，但并不局限這些功能，對功能及功能的使用都進行進一步擴展。上文中這4種方法是雖然是要耗費些精力，但與后布線階段的時序修復所需耗費精力相比，還是值得的。 圖1是一例這種問題。在功能塊左上角有個大型宏，它占用了許多布線層，在其周圍區域造成了非常高的擁塞情況。圖中加亮線是貫穿這個區域的一條路徑，中間插入了幾個緩沖區。有幾點應多加注意： 1.這條路徑是往下走的，因為在大型宏的北面沒有足夠空間用于緩沖區、沒有足夠導軌用于布線。 2.線路中間部分由于高度擁塞布線而呈割階狀態。 3.很難這個宏旁邊找個位置插入新的緩沖區以修復轉換和建立違規。 |
