时序优化实例

1、时序优化一例（一）注：全文摘自 Hoki EDNChina博客 一水寒整理学习时序也有一段时间了，一直也没分享什么学习笔记。这次以时序优化为例，检验一下这阶段的学 习成果。关于时序方面的东西也看了、学了很多，就是练得很少，在平常自己的设计中很难找到非常针对的设计来练习，只能在今后的学习中慢慢发掘了。最近在整一个设计，在要求的指标下时序是满足的，但 是为了拿它练手，故意将它的时钟约束提高一倍：create_clock -name sysclk -period 4.000 -waveform 2.000 4.000 get_ports elk图1约束到250M 了，发现建立时间不满足，如图 1所示

2、为10条违规路径，可以发现主要都是FromNode : DC_Off模块到To Node : estimator模块的路径，在此设计中不涉及 input、output的分析，因此 时序模型主要是针对reg-to-reg ，一般此情况下的时序违规主要是 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可以发现时序违规的关键路径上的Logic Levels达到13，这主要是在代码中逻辑过于复杂和多层的ifelse、case导致的。通过 Locate Path至U Technology Map Viewer可以清晰得查看关键路 径上的逻辑，如图4所示，与开始的分析相符，主要是 DC_Of

5、f模块和estimator模块之间的路径，其中包 含大量的加法器逻辑，导致时延过大。图4 （看不清可另存查看）一般解决关键路径过长问题达到时序收敛的方法，针对逻辑复杂的问题可以加入流水线级分割逻辑；而针对多层的ifelse、case则需要优化代码避免不必要的优先级编码，这需要的工作量稍大，在验证阶段一般的程序猿也没心思去仔细得抠代码了，因此相比于此方法，加入pipeline还是性价比高的解决办法。在此设计中，修改代码，在 DC_Off模块和estimator模块间加入了一级流水线寄存器，如图5所示。入丁 ' *冲|»啤:可以发现图5路径中的逻辑是图4路径中逻辑的一部分，加入流

6、水线级后逻辑果然被分割了，然后看一下该路径时序波形图，如图6所示，通过逻辑分割后这条路径Data Path的时延减小到了 2.887ns，已达到时序收敛了Ldunrh ClackLaunchaonstLatch ClockArrival仙ta RequireTlm (tvs)图6解决了原先的关键路径，再次check 一下timing，发现还是没有收敛，如图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在这个例子中，现阶段时序虽还未收敛，但是还是优化了不少。从中自己也收获不少，学会了通 过TimeQuest Timing Analyzer分析，并且进行有针对性的优化，不会再像以前那样遇到时序问题时那么 盲目，不知从何下手。下一阶段，再试试用其它方法优化这个设计，不达到时序收敛誓不罢休！时序优化一例（二）在时序优化一例（一）中采用修改代码的方法优化了一实例，

9、通过加入一级流水线寄存器分割组合逻辑 达到该路径时序收敛，但是重新check 一下timing发现还有时序不满足，而且还是除法器IP核的时序未收敛，对于这官方提供的IP核那就没办法通过修改代码进行优化了。查了些资料，发现还可以通过物理综 合优化，在没有使能物理综合前，Quartusll软件只进行逻辑综合，逻辑综合中的时序仅限于综合后的门级电路或者器件内部的逻辑单元的时延信息，并没有包含布线时延信息，也就是说Synthesis与fitter并没有交互操作；而物理综合则在综合时考虑具体的布线时延信息，使获得不错的综合结果。Quartusll 提供 了几个选项，可以通过 Settings->C

10、ompilation 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 来

11、减少关键 路径的逻辑层数目，同时还会通过复制LUT解决扇出过大的问题，此选项只影响combinational logic，并不对register进行优化；Perform register retiming :关于register retiming的概念，主要是为了解决关键路径逻辑过长 的问题，通过在combinational logic中移动register，利用宽松路径的余量来补偿关键路径进行优化；Perform automatic asynchronous signal pipeline :该选项是在 fitter 时自动加入针对异步 clear或load信号的流水线级来优化性能，特别是在

12、recovery和removal slack未达到时序要求时可以使能这一选项；Perform register duplication :自动复制register优化高扇出的问题。111图2针对设计，通过查看关键路径，如图2所示，发现逻辑级数达到33，这与第一个选项：Performphysical synthesis for combinational logic所能解决的问题比较匹配，使能第一个选项，看一下优化结 果：Lfltch ClocKLatchData Required图3优化前Launch Clock L*jhc|Relitl *Lfltch ClockL*teh|SlackDat

13、j ReouiredT iw ,'ns)图4优化后如图4所示为经过优化后原先关键路径的时序波形图，发现该路径已达到收敛，Data Path的时延仅 3.464ns，留给建立时间 0.126ns 的余量。因此选项：Perform physical synthesis for combinationallogic确实达到了优化的目的，下面来查看一下软件是如何自动优化的：图5优化后如图5所示优化后的Technology Map图，发现逻辑级数还是很多，查看TimeQuest TimingAnalyzer中的统计，logic lever还是有32级，相比于优化前仅少了 1级，估计这1级也不是使

14、路径时序收敛 的关键，还需继续深入探究。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优化前 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优化后Data Path如图6、7所示，通过比较优化前和优化后的Data Path，根据上面分析，优化前 Data Path总时延为4

17、.335ns，而优化后仅为3.464ns，相差0.841ns，这足够使路径达到时序收敛。仔细比较优化前后的Data Path，发现共有两处差别：1.在逻辑中少了 1级，原先连接这级逻辑的路径时延发生了变化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)优化前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)优化后通过图8中优化前后的对比，优化后少了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)优化前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)优化后图

21、92.如图9所示为第二处差别，此处具有相同的路径，节点的扇出也相同，就是时延发生了变化,节点 Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|add_sub_16|op_173|sumout 到节点 Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|DFFStage142|sload的时延从 0.483ns 减少到了 0.114ns，这就很奇怪啊，查看Technology Map 肯定看不出什么区别了，因为它们路径两端的节点是相同的，那只能通过Chip Plan

22、ner查看底层是如何布线的了0 493ns0 000ns(a)优化前0 000nsI 3fjQ114nsi«-（b）优化后图10通过对比图10中（日）和（b），发现优化前这一小段路径横跨了好几个LAB，导致时延比较大,而优化后该段路径在一个 LAB就内部消化了，软件自动对关键路径的布线进行了优化。t zJ 4 ftJi V 即 «#竽«益"瓷舅 f X- I I jr 1图11经过以上优化和分析，原先的关键路径时序收敛了， 那整个设计的时序是否收敛了呢？那就重新 check 一下timing吧，很遗憾，还是不满足，如图 11所示，不过庆幸的是 setup

23、 slack提高了些，到-0.240ns 了, 不然这优化算是白费了。总结：此次优化是通过软件自动进行的，通过查找问题使能了对应选项，这种针对性的优化效果还是 很明显的。在我尝试其它选项进行优化后发现几乎没有什么效果，甚至使问题更加恶化了，因此采用软件 自动优化时不能太盲目，认为将所有优化选项都使能就是最佳的，必须根据设计本身的问题采取针对性的 优化方案。革命尚未结束，咱还需继续努力!时序优化一例（三）在使用两种方法（时序优化一例（一），时序优化一例（二）对设计进行时序优化后，设计的建 立时间余量从-1.070优化到-0.240，但是时序还未达到收敛，继而尝试了许多其它方法：（一）局部优化在时

24、序优化一例（二）中的物理综合优化是全局的，可能对关键路径的优化还不够彻底。翻 阅了一些资料，发现可以针对一个模块或者节点进行局部优化，因此可以直接对关键路径进行直接优化。方法是在 Quartusll软件中，打开 Assignments->Assignment Editor，如图1所示，可以在其中加入需要优 化的节点或者模块，优化选项与全局优化选项类似，如图2所示，在Assignment Name下拉菜单中可选择不同的优化策略。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但是遗憾的是采用局部优化后，时序还是没有收敛！（二）LogicLock使用Logiclock可以创建一个floorplan，用于将设计中的部分模块逻辑的布局布线限制在模块区 域中。但是其主要用于增量编译中，与design partition配合使用，将一个设计分区的布局布线限定在一个Logiclock区域中，如果分区的布局布线已达到要求，可以设置保留该分区布局的布局布线信息，那下次编 译时可以跳过对该设计的布局布线过程，减少了编译时间。但是使用Logiclock对时序性能并没有什么好处，反而可能会起到反效果。因为fi

28、tter并不对Logiclock区域之间的布线进行优化，而如果 Logiclock区域划分不合理，关键路径正好处于跨区域中，那 在之前对关键路径所作的时序优化算是白费了。在我的设计中，现阶段关键路径处于除法器IP内部，也没别的什么办法去优化这个IP 了，可能是其它模块的布局布线对除法器模块产生了影响，那就“瞎猫碰死耗子” 一把，试一试，万一有小惊喜呢！使用Logiclock将除法器布局布线与其它模块的布局布线隔离，将此除法器模块单独建立分区和创建Logiclock区域。分区如图3所示，可以看到 Div模块因为分区被单独分离出来；Logiclock如图4所示，div模块的逻辑被限定在单独的一个L

29、ogiclock区域中布局布线。图3divOiDiv.图4然后来check 一下timing，值得欣慰的是，时序好了一些，如图 5所示，建立时间余量减小到-0.224ns 了，关键路径还在除法器内部。通过分区逻辑隔离、创建Logiclock区域进行布局布线隔离还是起到了意想不到的效果，尽管这效果很小。图5在尝试了多种优化方案后，设计的时序还未达到收敛，但我却已黔驴技穷了。冥思苦想了几天，我决定重新分析一下问题，将这段时间的优化过程回顾了一下，忽然间发现曾在时序优化一例（一）中分析过除法器IP的问题，查询过这IP核的性能，初步估计可能达不到250MHz，是不是这IP核本身真就不行呢？其实在 时序

30、优化一例（三）中已经可以验证了，因为通过分区和创建Logiclock区域将除法器与其它模块在synthesis和fitter过程中分离开来了，此时时序分析后的关键路径还停留在除法器内部，为了充 分验证其性能，单独对此除法器建了个工程，顶层原理图如图1所示，其它的逻辑完全不加，并且时钟约束到250MHz。蓟« H 图1然后对此模块采用时序优化一例（二）中相同的物理综合优化，如图2所示，使能Performphysical synthesis for combination logic 选项，并且 Effort level 设置成 Extra图2通过TimeQuest Timing Analyzer分析一下时序，果然未收敛，如图3所示，建立余量达到-0.226ns，与时序优化一例（三）中优化后的结果-0.224ns几乎相同，看来前面分析的正确，是除法器IP真就不行！这个问题只能通过自己重新编写除法器程序解决了，可以不采用altera官方的IP核，而此阶段的时序优化任务算是告一段落了！BadkL卜命闻iw |QF*MArS axilI口跚*少却砂饼*31 - -Ts 31* u *flb Jhrvto* 一k1 1i1h- rt&q