【轉】時序優化一例

時間 2019-12-10

標籤時序優化一例简体版

原文原文鏈接

【轉載文章用於學習】php

學習時序也有一段時間了，一直也沒分享什麼學習筆記。此次以時序優化爲例，檢驗一下這階段的學習成果。html

關於時序方面的東西也看了、學了不少，就是練得不多，在日常本身的設計中很難找到很是針對的設計來練習，只能在從此的學習中慢慢發掘了。最近在整一個設計，在要求的指標下時序是知足的，可是爲了拿它練手，故意將它的時鐘約束提升一倍：異步

create_clock -name {sysclk} -period 4.000 -waveform { 2.000 4.000 } [get_ports {clk}]async

圖1ide

約束到250M了，發現創建時間不知足，如圖1所示爲10條違規路徑，能夠發現主要都是From Node：DC_Off模塊到To Node：estimator模塊的路徑，在此設計中不涉及input、output的分析，所以時序模型主要是針對reg-to-reg，通常此狀況下的時序違規主要是data_path中的組合邏輯過長或者高扇出致使的。下面經過TimeQuest Timing Analyzer分析一下：佈局

圖2性能

時序波形圖如圖2所示，創建時間餘量是經過Data Required Time減去Data Arrival Time獲得的，因爲Data Path的時延過大，有4.906ns，致使setup slack爲負。學習

圖3優化

由圖3能夠發現時序違規的關鍵路徑上的Logic Levels達到13，這主要是在代碼中邏輯過於複雜和多層的if…else…、case致使的。經過Locate Path到Technology Map Viewer能夠清晰得查看關鍵路徑上的邏輯，如圖4所示，與開始的分析相符，主要是DC_Off模塊和estimator模塊之間的路徑，其中包含大量的加法器邏輯，致使時延過大。ui

圖4（看不清可另存查看）

通常解決關鍵路徑過長問題達到時序收斂的方法，針對邏輯複雜的問題能夠加入流水線級分割邏輯；而針對多層的if…else… 、case則須要優化代碼避免沒必要要的優先級編碼，這須要的工做量稍大，在驗證階段通常的程序猿也沒心思去仔細得摳代碼了，所以相比於此方法，加入pipeline仍是性價比高的解決辦法。在此設計中，修改代碼，在DC_Off模塊和estimator模塊間加入了一級流水線寄存器，如圖5所示。

圖5

能夠發現圖5路徑中的邏輯是圖4路徑中邏輯的一部分，加入流水線級後邏輯果真被分割了，而後看一下該路徑時序波形圖，如圖6所示，經過邏輯分割後這條路徑Data Path的時延減少到了2.887ns，已達到時序收斂了。

圖6

解決了原先的關鍵路徑，再次check一下timing，發現仍是沒有收斂，如圖7所示，setup slack仍是負的，不過-0.381仍是比原先的-1.070提升很多了，可是關鍵路徑不是原先那條了，而是主要集中在Div模塊內部。

圖7

Div模塊只是例化了一個除法器IP核，難道官方提供的IP核有問題，翻閱了一下除法器的手冊，找到了它的性能指標，如圖8所示，在個人設計中Device Family爲Stratix IV，Input Data Width爲32，Output Delay爲16，估計fmax達到250M還真是夠嗆啊。

圖8

在這個例子中，現階段時序雖還未收斂，可是仍是優化了很多。從中本身也收穫很多，學會了經過TimeQuest Timing Analyzer分析，而且進行有針對性的優化，不會再像之前那樣遇到時序問題時那麼盲目，不知從何下手。下一階段，再試試用其它方法優化這個設計，不達到時序收斂誓不罷休！

//*********************************************************************************************************************************

在《時序優化一例（一）》中採用修改代碼的方法優化了一實例，經過加入一級流水線寄存器分割組合邏輯達到該路徑時序收斂，可是從新check一下timing發現還有時序不知足，並且仍是除法器IP核的時序未收斂，對於這官方提供的IP核那就沒辦法經過修改代碼進行優化了。查了些資料，發現還能夠經過物理綜合優化，在沒有使能物理綜合前，QuartusII軟件只進行邏輯綜合，邏輯綜合中的時序僅限於綜合後的門級電路或者器件內部的邏輯單元的時延信息，並無包含佈線時延信息，也就是說Synthesis與fitter並無交互操做；而物理綜合則在綜合時考慮具體的佈線時延信息，使得到不錯的綜合結果。

QuartusII提供了幾個選項，能夠經過Settings->Compilation Processing Settings->Physical Synthesis Optimization打開，如圖1所示。

圖1

其中主要分爲兩部分：

1. Optimize for Performance：主要用於優化性能

2. Optimize for fitting：主要用於優化fitter

與時序相關的就是第1部分（Optimize for Performance）了，翻閱了官方手冊，找到了對應各選項的解釋。

Perform physical synthesis for combinational logic：經過交換LEs中LUT port來減小關鍵路徑的邏輯層數目，同時還會經過複製LUT解決扇出過大的問題，此選項隻影響combinational logic，並不對register進行優化；

Perform register retiming：關於register retiming的概念，主要是爲了解決關鍵路徑邏輯過長的問題，經過在combinational logic中移動register，利用寬鬆路徑的餘量來補償關鍵路徑進行優化；

Perform automatic asynchronous signal pipeline：該選項是在fitter時自動加入針對異步clear或load信號的流水線級來優化性能，特別是在recovery和removal slack未達到時序要求時可使能這一選項；

Perform register duplication：自動複製register優化高扇出的問題。

圖2

針對設計，經過查看關鍵路徑，如圖2所示，發現邏輯級數達到33，這與第一個選項：Perform physical synthesis for combinational logic所能解決的問題比較匹配，使能第一個選項，看一下優化結果：

圖3 優化前

如圖3所示爲優化前的時序波形圖，時序未收斂，關鍵路徑上Data Delay過大，達到4.335ns。

圖4 優化後

如圖4所示爲通過優化後原先關鍵路徑的時序波形圖，發現該路徑已達到收斂，Data Path的時延僅3.464ns，留給創建時間0.126ns的餘量。所以選項：Perform physical synthesis for combinational logic確實達到了優化的目的，下面來查看一下軟件是如何自動優化的：

圖5 優化後

如圖5所示優化後的Technology Map圖，發現邏輯級數仍是不少，查看TimeQuest Timing Analyzer中的統計，logic lever仍是有32級，相比於優化前僅少了1級，估計這1級也不是使路徑時序收斂的關鍵，還需繼續深刻探究。

圖6 優化前Data Path

圖7 優化後Data Path

如圖6、7所示，經過比較優化前和優化後的Data Path，根據上面分析，優化前Data Path總時延爲4.335ns，而優化後僅爲3.464ns，相差0.841ns，這足夠使路徑達到時序收斂。仔細比較優化先後的Data Path，發現共有兩處差異：

1. 在邏輯中少了1級，原先鏈接這級邏輯的路徑時延發生了變化

（a）優化前

（b）優化後

圖8

經過圖8中優化先後的對比，優化後少了Div_0|LPM_DIVIDE_component|auto_generat

（a）優化前

（b）優化後

圖9

der|DFFStage[142]|sload的時延從0.483ns減小到了0.114ns，這就很奇怪啊，查看Technology Map確定看不出什麼區別了，由於它們路徑兩端的節點是相同的，那隻能經過Chip Planner查看底層是如何佈線的了。

（a）優化前

（b）優化後

圖10

經過對比圖10中（a）和（b），發現優化前這一小段路徑橫跨了好幾個LAB，致使時延比較大，而優化後該段路徑在一個LAB就內部消化了，軟件自動對關鍵路徑的佈線進行了優化。

圖11

通過以上優化和分析，原先的關鍵路徑時序收斂了，那整個設計的時序是否收斂了呢？那就從新check一下timing吧，很遺憾，仍是不知足，如圖11所示，不過慶幸的是setup slack提升了些，到-0.240ns了，否則這優化算是白費了。

總結：這次優化是經過軟件自動進行的，經過查找問題使能了對應選項，這種針對性的優化效果仍是很明顯的。在我嘗試其它選項進行優化後發現幾乎沒有什麼效果，甚至使問題更加惡化了，所以採用軟件自動優化時不能太盲目，認爲將全部優化選項都使能就是最佳的，必須根據設計自己的問題採起針對性的優化方案。

革命還沒有結束，咱還需繼續努力！

//*********************************************************************************************************************************

在使用兩種方法（《時序優化一例（一）》，《時序優化一例（二）》）對設計進行時序優化後，設計的創建時間餘量從-1.070優化到-0.240，可是時序還未達到收斂，繼而嘗試了許多其它方法：

（一）局部優化

在《時序優化一例（二）》中的物理綜合優化是全局的，可能對關鍵路徑的優化還不夠完全。翻閱了一些資料，發現能夠針對一個模塊或者節點進行局部優化，所以能夠直接對關鍵路徑進行直接優化。方法是在QuartusII軟件中，打開Assignments->Assignment Editor，如圖1所示，能夠在其中加入須要優化的節點或者模塊，優化選項與全局優化選項相似，如圖2所示，在Assignment Name下拉菜單中可選擇不一樣的優化策略。

圖1

圖2

可是遺憾的是採用局部優化後，時序仍是沒有收斂！

（二）LogicLock

使用Logiclock能夠建立一個floorplan，用於將設計中的部分模塊邏輯的佈局佈線限制在模塊區域中。可是其主要用於增量編譯中，與design partition配合使用，將一個設計分區的佈局佈線限定在一個Logiclock區域中，若是分區的佈局佈線已達到要求，能夠設置保留該分區佈局的佈局佈線信息，那下次編譯時能夠跳過對該設計的佈局佈線過程，減小了編譯時間。

可是使用Logiclock對時序性能並無什麼好處，反而可能會起到反效果。由於fitter並不對Logiclock區域之間的佈線進行優化，而若是Logiclock區域劃分不合理，關鍵路徑正好處於跨區域中，那在以前對關鍵路徑所做的時序優化算是白費了。

在個人設計中，現階段關鍵路徑處於除法器IP內部，也沒別的什麼辦法去優化這個IP了，多是其它模塊的佈局佈線對除法器模塊產生了影響，那就「瞎貓碰死耗子」一把，試一試，萬一有小驚喜呢！使用Logiclock將除法器佈局佈線與其它模塊的佈局佈線隔離，將此除法器模塊單獨創建分區和建立Logiclock區域。分區如圖3所示，能夠看到Div模塊由於分區被單獨分離出來；Logiclock如圖4所示，div模塊的邏輯被限定在單獨的一個Logiclock區域中佈局佈線。