時序優(yōu)化實例

1、時序優(yōu)化一例（一）注：全文摘自 Hoki EDNChina博客 一水寒整理學習時序也有一段時間了，一直也沒分享什么學習筆記。這次以時序優(yōu)化為例，檢驗一下這階段的學 習成果。關于時序方面的東西也看了、學了很多，就是練得很少，在平常自己的設計中很難找到非常針對的設計來練習，只能在今后的學習中慢慢發(fā)掘了。最近在整一個設計，在要求的指標下時序是滿足的，但 是為了拿它練手，故意將它的時鐘約束提高一倍：create_clock -name sysclk -period 4.000 -waveform 2.000 4.000 get_ports elk圖1約束到250M 了，發(fā)現建立時間不滿足，如圖 1所示

2、為10條違規(guī)路徑，可以發(fā)現主要都是FromNode : DC_Off模塊到To Node : estimator模塊的路徑，在此設計中不涉及 input、output的分析，因此 時序模型主要是針對reg-to-reg ，一般此情況下的時序違規(guī)主要是 data_path中的組合邏輯過長或者高扇 出導致的。下面通過 TimeQuest Timing Analyzer分析一下：Launch ClockLatchLatch ClockData ArrivalC loci1 Df 14N01 AMSlackRequiredClock Dei am時序波形圖如圖2所示，建立時間余量是通過 Data Re

3、quired Time減去Data Arrival Time得到的, 由于Data Path的時延過大，有 4.906ns，導致setup slack為負。Path SummaryStatisticsData PathLVaveformExtrm Fitter InforimationPropertyValueCountTotal Delay% of TotalMin1Setup Relationship斗ODOZClock Ske'A-0.0743Data Delay斗.9064Number of Lo口疋 Levels135E Physical Dela ys6Arrivai Pa

4、th73兀32.1Q5600.0009Cell31.394390.203r n-i Data% iIC142.32S470.000CellIS2.512510.010uToo10.06610.06614-Reouired PathT Chclc16rc3Z438720.00030.930270.147圖3由圖3可以發(fā)現時序違規(guī)的關鍵路徑上的Logic Levels達到13，這主要是在代碼中邏輯過于復雜和多層的ifelse、case導致的。通過 Locate Path至U Technology Map Viewer可以清晰得查看關鍵路 徑上的邏輯，如圖4所示，與開始的分析相符，主要是 DC_Of

5、f模塊和estimator模塊之間的路徑，其中包 含大量的加法器邏輯，導致時延過大。圖4 （看不清可另存查看）一般解決關鍵路徑過長問題達到時序收斂的方法，針對邏輯復雜的問題可以加入流水線級分割邏輯；而針對多層的ifelse、case則需要優(yōu)化代碼避免不必要的優(yōu)先級編碼，這需要的工作量稍大，在驗證階段一般的程序猿也沒心思去仔細得摳代碼了，因此相比于此方法，加入pipeline還是性價比高的解決辦法。在此設計中，修改代碼，在 DC_Off模塊和estimator模塊間加入了一級流水線寄存器，如圖5所示。入丁 ' *沖|»啤:可以發(fā)現圖5路徑中的邏輯是圖4路徑中邏輯的一部分，加入流

6、水線級后邏輯果然被分割了，然后看一下該路徑時序波形圖，如圖6所示，通過邏輯分割后這條路徑Data Path的時延減小到了 2.887ns，已達到時序收斂了Ldunrh ClackLaunchaonstLatch ClockArrival仙ta RequireTlm (tvs)圖6解決了原先的關鍵路徑，再次check 一下timing，發(fā)現還是沒有收斂，如圖7所示，setup slack還是負的，不過-0.381還是比原先的-1.070提高不少了，但是關鍵路徑不是原先那條了，而是主要集中在Div模塊內部。Div模塊只是例化了一個除法器IP核，難道官方提供的IP核有問題，翻閱了一下除法器的手冊，找

7、到了它的性能指標，如圖8所示，在我的設計中 Device Family為Stratix IV，Input Data Width為32，Output Delay為16，估計fmax達到250M 還真是夠嗆啊。Tabte 18. LP嶄-DIVIDE Resource Ulilization and Perfoiniance 認血 aDevice familyInput data widthOutput latencylogic UsageS (MHZ)Adaptive Look-Up Table (AlUT)Dedicated Logic Register (DLR)Adaptive Logic

8、 Modale (ALMStrata in10 '11310701333054017063571644345|02623Stratlx IV105 |101S|064282641043470263448圖8在這個例子中，現階段時序雖還未收斂，但是還是優(yōu)化了不少。從中自己也收獲不少，學會了通 過TimeQuest Timing Analyzer分析，并且進行有針對性的優(yōu)化，不會再像以前那樣遇到時序問題時那么 盲目，不知從何下手。下一階段，再試試用其它方法優(yōu)化這個設計，不達到時序收斂誓不罷休！時序優(yōu)化一例（二）在時序優(yōu)化一例（一）中采用修改代碼的方法優(yōu)化了一實例，

9、通過加入一級流水線寄存器分割組合邏輯 達到該路徑時序收斂，但是重新check 一下timing發(fā)現還有時序不滿足，而且還是除法器IP核的時序未收斂，對于這官方提供的IP核那就沒辦法通過修改代碼進行優(yōu)化了。查了些資料，發(fā)現還可以通過物理綜 合優(yōu)化，在沒有使能物理綜合前，Quartusll軟件只進行邏輯綜合，邏輯綜合中的時序僅限于綜合后的門級電路或者器件內部的邏輯單元的時延信息，并沒有包含布線時延信息，也就是說Synthesis與fitter并沒有交互操作；而物理綜合則在綜合時考慮具體的布線時延信息，使獲得不錯的綜合結果。Quartusll 提供 了幾個選項，可以通過 Settings->C

10、ompilation Processing Settings->Physical Synthesis Optimization 打開，如圖 1 所示。圖1其中主要分為兩部分：1. Optimize for Performance :主要用于優(yōu)化性能2. Optimize for fitting :主要用于優(yōu)化 fitter與時序相關的就是第1部分（Optimize for Performance ）了，翻閱了官方手冊，找到了對應各選 項的解釋。Perform physical synthesis for combinational logic :通過交換 LEs 中 LUT port 來

11、減少關鍵 路徑的邏輯層數目，同時還會通過復制LUT解決扇出過大的問題，此選項只影響combinational logic，并不對register進行優(yōu)化；Perform register retiming :關于register retiming的概念，主要是為了解決關鍵路徑邏輯過長 的問題，通過在combinational logic中移動register，利用寬松路徑的余量來補償關鍵路徑進行優(yōu)化；Perform automatic asynchronous signal pipeline :該選項是在 fitter 時自動加入針對異步 clear或load信號的流水線級來優(yōu)化性能，特別是在

12、recovery和removal slack未達到時序要求時可以使能這一選項；Perform register duplication :自動復制register優(yōu)化高扇出的問題。111圖2針對設計，通過查看關鍵路徑，如圖2所示，發(fā)現邏輯級數達到33，這與第一個選項：Performphysical synthesis for combinational logic所能解決的問題比較匹配，使能第一個選項，看一下優(yōu)化結 果：Lfltch ClocKLatchData Required圖3優(yōu)化前Launch Clock L*jhc|Relitl *Lfltch ClockL*teh|SlackDat

13、j ReouiredT iw ,'ns)圖4優(yōu)化后如圖4所示為經過優(yōu)化后原先關鍵路徑的時序波形圖，發(fā)現該路徑已達到收斂，Data Path的時延僅 3.464ns，留給建立時間 0.126ns 的余量。因此選項：Perform physical synthesis for combinationallogic確實達到了優(yōu)化的目的，下面來查看一下軟件是如何自動優(yōu)化的：圖5優(yōu)化后如圖5所示優(yōu)化后的Technology Map圖，發(fā)現邏輯級數還是很多，查看TimeQuest TimingAnalyzer中的統(tǒng)計，logic lever還是有32級，相比于優(yōu)化前僅少了 1級，估計這1級也不是使

14、路徑時序收斂 的關鍵，還需繼續(xù)深入探究。F>T- iirrwf SMflEl擊.Eft恂lEtGTIMtAnZiWT»U益*： *檢 :? witM»Wim41<JIL.3MB.3« LIU :淖 A14II-13B.lJft «L：>ILW|l】 raw w 宿 .iR lL97i *崗I.X» 飢則 um i.w 亂網 犧 ».iw>.»晞巧<*;町即*!«.<?世碼喬51蠶3JH M %4?»94驚41»粧討靜汕須3：誹幷；乃恥"再吟丄|丄0

15、0旳 0 w 曲幻COlflQ.atas?器 sm 墟i- 丁1一匹一一 ultTIZitHlt樣"T*f殲片齊幵肝垢幵舛片聲”秤片。曲W MW 0» 0419 AM DOMoaia Qg MB 打妙 d.o» ocog w於 g妙 打 d o 打QQg fijjgoSTS w、PWi S«MoArrwal hlhA4Iru.1 -Jtf ? ! _»J Ml. L c-4-ca 4 £.r" s" -> 9 $ V 9 s t X x?.y.?a扳 lll藝二 港EB奩EEBE霍 £ 汐憶匯SKX

16、KS黑K脫闕 AancwbvggsAmmAgnr 4. s Fl L.- f c t- it Jr. t r- f. i. t s 1 1- -< i 1 J J J i 7圖6優(yōu)化前 Data PathTz W2#t 1 I L- 1羔覆:5爲嚮sxs 311 J . X 3 J J J s- ) X rT¥¥-¥v-¥TTf r V T f ri77 rSSNW耀 皿心F嚕啡aw T- .J 7 7 T 57圖7優(yōu)化后Data Path如圖6、7所示，通過比較優(yōu)化前和優(yōu)化后的Data Path，根據上面分析，優(yōu)化前 Data Path總時延為4

17、.335ns，而優(yōu)化后僅為3.464ns，相差0.841ns，這足夠使路徑達到時序收斂。仔細比較優(yōu)化前后的Data Path，發(fā)現共有兩處差別：1.在邏輯中少了 1級，原先連接這級邏輯的路徑時延發(fā)生了變化QullO0.409 CL 40Q.WQd3?H2OU1L4SCEH 百畀 m K3h?OiyGtPMDhNKnooncnt 3War«f a：DK kkdr dr-xjcr |sddmbISr-rsurt ntj 曙lYW 血rsM:常4$CEU 弭V55 N域QrvPL和OFK爐審審*5熹:帕帯y 祖kKTe<b»T«* 3dsub誡如 IT 也牛ceo

18、ax M» r$ hA©w功“MDrrtDEewftMSEWbUdhtridr陽e?idsub誕曲 ITEMZgl. 甲帶 h-14g OHFM D£WWWM-iuW 5W血0陽心 Cr時計*«A匱M 淪口Bml*KBmL期54 55 科 Wg OllPM DfilDE:rxmmtliwto <»用肘代乃，*比* I劇MlAg 1*13 cot(a)優(yōu)化前Dhr 0UR4 DMDE conGnrenthurl anrAtedi>v«dcr IdMifer twid sJb ISIriii%g &LPM DNDE f

19、rgWH臥曲 曲盛機貞 &“* 眩gl*K M 適如 13也 3 g &LF* DtrXE csrwwitiMtD orm* ：申gxkr kirdedAdd sub 晞k)Q(b)優(yōu)化后通過圖8中優(yōu)化前后的對比，優(yōu)化后少了Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|add_sub_16|op_19|這一級，減少 了布線延時，時延方面從0.310+0.801+0.440+0.000+0.055=1.606ns減少到 0.310+0.239+0.733=1.282ns，OJHFRcai_HL_mlakgll

20、x se H Mftv 01PM DNIDf cBirogntHtonrrifpdsub Wjon比*43一1怦 X$3 Y&* N簽Or dUM DJvZK cffpcrLt斗也 暉申rrnM * *曲軸 嚴軋吋5】專訂01碣dMWfrCMKu 嵌 心松如4*孰*油加力(a)優(yōu)化前C.XI R037MLAKS1 XWN&5 斗例 Kb： 如如3赧心 A 誌欣？ !*73lfcrWl”TM F:X ；C：；電 嚴#力a*=尸 靜貳苦仃也丁持彳®.3J RRCEU1禪Z T$2起料*6 otoh dMdtTLM OlYDe cwonentfcm du dr(b)優(yōu)化后圖

21、92.如圖9所示為第二處差別，此處具有相同的路徑，節(jié)點的扇出也相同，就是時延發(fā)生了變化,節(jié)點 Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|add_sub_16|op_173|sumout 到節(jié)點 Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|DFFStage142|sload的時延從 0.483ns 減少到了 0.114ns，這就很奇怪啊，查看Technology Map 肯定看不出什么區(qū)別了，因為它們路徑兩端的節(jié)點是相同的，那只能通過Chip Plan

22、ner查看底層是如何布線的了0 493ns0 000ns(a)優(yōu)化前0 000nsI 3fjQ114nsi«-（b）優(yōu)化后圖10通過對比圖10中（日）和（b），發(fā)現優(yōu)化前這一小段路徑橫跨了好幾個LAB，導致時延比較大,而優(yōu)化后該段路徑在一個 LAB就內部消化了，軟件自動對關鍵路徑的布線進行了優(yōu)化。t zJ 4 ftJi V 即 «#竽«益"瓷舅 f X- I I jr 1圖11經過以上優(yōu)化和分析，原先的關鍵路徑時序收斂了， 那整個設計的時序是否收斂了呢？那就重新 check 一下timing吧，很遺憾，還是不滿足，如圖 11所示，不過慶幸的是 setup

23、 slack提高了些，到-0.240ns 了, 不然這優(yōu)化算是白費了?？偨Y：此次優(yōu)化是通過軟件自動進行的，通過查找問題使能了對應選項，這種針對性的優(yōu)化效果還是 很明顯的。在我嘗試其它選項進行優(yōu)化后發(fā)現幾乎沒有什么效果，甚至使問題更加惡化了，因此采用軟件 自動優(yōu)化時不能太盲目，認為將所有優(yōu)化選項都使能就是最佳的，必須根據設計本身的問題采取針對性的 優(yōu)化方案。革命尚未結束，咱還需繼續(xù)努力!時序優(yōu)化一例（三）在使用兩種方法（時序優(yōu)化一例（一），時序優(yōu)化一例（二）對設計進行時序優(yōu)化后，設計的建 立時間余量從-1.070優(yōu)化到-0.240，但是時序還未達到收斂，繼而嘗試了許多其它方法：（一）局部優(yōu)化在時

24、序優(yōu)化一例（二）中的物理綜合優(yōu)化是全局的，可能對關鍵路徑的優(yōu)化還不夠徹底。翻 閱了一些資料，發(fā)現可以針對一個模塊或者節(jié)點進行局部優(yōu)化，因此可以直接對關鍵路徑進行直接優(yōu)化。方法是在 Quartusll軟件中，打開 Assignments->Assignment Editor，如圖1所示，可以在其中加入需要優(yōu) 化的節(jié)點或者模塊，優(yōu)化選項與全局優(yōu)化選項類似，如圖2所示，在Assignment Name下拉菜單中可選擇不同的優(yōu)化策略。AflMfBWiHC I AlorIL5-3 OPI iMiZI/drYd*M9 IQ, MILbto Kdt itai Tidh wnhh©b nA擊

25、廣M.'Rn1hpkpiipri>wM Mb*b * m« «W! >>< UqHL 3i圖1Assignfnent NarneVdueErjbiedGMitrPerform Physcai Snlhesv fcr Cofttfarkofranal Logk flor Perfemana (Accepts wickdfd$AF<w”Perferrn Asrc衍cgs Signal Ppeining (AcceptsaPerform Loc to Kenwy Mappr>Q far Fit&ng (Accepts r.dca

26、rdsoups)Perform Phywaf Syntheses for ComtxnatBnal Logtc fv Httnfl (Accepts widcAfds/groups)Ptfforrn Ptif-sca; 5vnth«.5 for CombtnaiKjnafl L旳c 2 Performaxe (AtxeDts wrdcardi/groups)Perform 呵莊曲 Dtptjon fiw PerformAftte (Accepts 畀紀cards.Pcrrrt Reviser Rebmng fef Perferrrjnce Accepts viidcards/youp

27、sPerform WYSIWYG PTrnttve Resynthesis圖2但是遺憾的是采用局部優(yōu)化后，時序還是沒有收斂！（二）LogicLock使用Logiclock可以創(chuàng)建一個floorplan，用于將設計中的部分模塊邏輯的布局布線限制在模塊區(qū) 域中。但是其主要用于增量編譯中，與design partition配合使用，將一個設計分區(qū)的布局布線限定在一個Logiclock區(qū)域中，如果分區(qū)的布局布線已達到要求，可以設置保留該分區(qū)布局的布局布線信息，那下次編 譯時可以跳過對該設計的布局布線過程，減少了編譯時間。但是使用Logiclock對時序性能并沒有什么好處，反而可能會起到反效果。因為fi

28、tter并不對Logiclock區(qū)域之間的布線進行優(yōu)化，而如果 Logiclock區(qū)域劃分不合理，關鍵路徑正好處于跨區(qū)域中，那 在之前對關鍵路徑所作的時序優(yōu)化算是白費了。在我的設計中，現階段關鍵路徑處于除法器IP內部，也沒別的什么辦法去優(yōu)化這個IP 了，可能是其它模塊的布局布線對除法器模塊產生了影響，那就“瞎貓碰死耗子” 一把，試一試，萬一有小驚喜呢！使用Logiclock將除法器布局布線與其它模塊的布局布線隔離，將此除法器模塊單獨建立分區(qū)和創(chuàng)建Logiclock區(qū)域。分區(qū)如圖3所示，可以看到 Div模塊因為分區(qū)被單獨分離出來；Logiclock如圖4所示，div模塊的邏輯被限定在單獨的一個L

29、ogiclock區(qū)域中布局布線。圖3divOiDiv.圖4然后來check 一下timing，值得欣慰的是，時序好了一些，如圖 5所示，建立時間余量減小到-0.224ns 了，關鍵路徑還在除法器內部。通過分區(qū)邏輯隔離、創(chuàng)建Logiclock區(qū)域進行布局布線隔離還是起到了意想不到的效果，盡管這效果很小。圖5在嘗試了多種優(yōu)化方案后，設計的時序還未達到收斂，但我卻已黔驢技窮了。冥思苦想了幾天，我決定重新分析一下問題，將這段時間的優(yōu)化過程回顧了一下，忽然間發(fā)現曾在時序優(yōu)化一例（一）中分析過除法器IP的問題，查詢過這IP核的性能，初步估計可能達不到250MHz，是不是這IP核本身真就不行呢？其實在 時序

30、優(yōu)化一例（三）中已經可以驗證了，因為通過分區(qū)和創(chuàng)建Logiclock區(qū)域將除法器與其它模塊在synthesis和fitter過程中分離開來了，此時時序分析后的關鍵路徑還停留在除法器內部，為了充 分驗證其性能，單獨對此除法器建了個工程，頂層原理圖如圖1所示，其它的邏輯完全不加，并且時鐘約束到250MHz。薊« H 圖1然后對此模塊采用時序優(yōu)化一例（二）中相同的物理綜合優(yōu)化，如圖2所示，使能Performphysical synthesis for combination logic 選項，并且 Effort level 設置成 Extra圖2通過TimeQuest Timing Analyzer分析一下時序，果然未收斂，如圖3所示，建立余量達到-0.226ns，與時序優(yōu)化一例（三）中優(yōu)化后的結果-0.224ns幾乎相同，看來前面分析的正確，是除法器IP真就不行！這個問題只能通過自己重新編寫除法器程序解決了，可以不采用altera官方的IP核，而此階段的時序優(yōu)化任務算是告一段落了！BadkL卜命聞iw |QF*MArS axilI口跚*少卻砂餅*31 - -Ts 31* u *flb Jhrvto* 一k1 1i1h- rt&q