时序优化实例.pdf

时序优化一例（一） 注：全文摘自Hoki EDNChina博客 一水寒整理 学习时序也有一段时间了，一直也没分享什么学习笔记。这次以时序优化为例，检验一下这阶段的学 习成果。 关于时序方面的东西也看了、学了很多，就是练得很少，在平常自己的设计中很难找到非常针对 的设计来练习，只能在今后的学习中慢慢发掘了。最近在整一个设计，在要求的指标下时序是满足的，但 是为了拿它练手，故意将它的时钟约束提高一倍： create_clock -name {sysclk} -period 4.000 -waveform { 2.000 4.000 } [get_ports {clk}] create_clock -name {sysclk} -period 4.000 -waveform { 2.000 4.000 } [get_ports {clk}] ccrreeaattee__cclloocckk--nnaammee{{ssyyssccllkk}}--ppeerriioodd44..000000 --wwaavveeffoorrmm{{22..000000 }}[[ggeett__ppoorrttss {{ccllkk}}]] 图1 约束到250M了，发现建立时间不满足，如图1所示为10条违规路径，可以发现主要都是From Node：DC_Off 模块到To Node：estimator模块的路径，在此设计中不涉及input、output的分析，因此 reg-to-reg reg-to-reg 时序模型主要是针对rreegg--ttoo--rreegg，一般此情况下的时序违规主要是data_path 中的组合逻辑过长或者高扇 出导致的。下面通过TimeQuest TimingAnalyzer 分析一下： 图2 时序波形图如图2所示，建立时间余量是通过Data RequiredTime减去DataArrivalTime得到的， 由于Data Path的时延过大，有4.906ns，导致setup slack为负。 图3 由图3可以发现时序违规的关键路径上的LogicLevels达到13，这主要是在代码中逻辑过于复杂 和多层的if…else… 、case导致的。通过LocatePath 到Technology Map Viewer 可以清晰得查看关键路 径上的逻辑，如图4所示，与开始的分析相符，主要是DC_Off 模块和estimator 模块之间的路径，其中包 含大量的加法器逻辑，导致时延过大。 图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