标签: 时序优化

          这个实例我们来看看如何对设计进行时序优化，假设设计的顶层框图如图1所示， 该设计在两个系统之间实现了一个POS-PHY第三层链路。       图1：POS-PHY顶层设计框图          如图所示在POS-PHY第三层接收器模块收到包之后，包检测模块分析一个包里的数据，以确保数据是正确的，比如确保包的长度是1K字，ERR标志没有被置位。接着包将会送到FFT以及一系列FIFO，外部的FIFO是为了增加系统存储能力。最后，数据包由POS-PHY第三层发送器模块发送到其它器件。            该设计总共有三个时钟域，一个是外部100MHz时钟域，一个是200MHz内部时钟域，最后一个是读写外部FIFO的133MHz时钟域。           下面我们利用这个设计来具体实践怎么发现设计中的时序问题，以及如何来解决这些时序问题。假设设计已经完成，我们下面按步骤一步一步来介绍。            由于事先我们已经将工程建立好了，我们直接对工程进行编译，然后在编译报告里找到TimeQuest时序报告，如图2所示，SCLK时钟域存在时序违规。   图2：工程编译后查看时序报告          为了查看SCLK详细时序违约情况，可以通过鼠标右击图2中第一行，从弹出的菜单里选择“Report Timing…”，如图3所示。 图3：通过报告时序命令查看时序分析细节          选择图3所示的命令后，在弹出的命令对话框中输入一下信息，然后点击“Report Timing”，如图4所示。 图4：报告SCLK时序          可以看到报告显示非常多的红色时序违规，很多时候面对这类时序问题，设计者往往会手足无措，因为不知道从哪里下手来解决这些问题。大家可以按照一些提示来进行分析：   l  找到From和To下节点，分析其类型。可以结合两个节点来分析，常常可以帮助我们理解到底哪里出了问题。比如，这两个节点是位于两个模块之间的接口还是位于一堆组合逻辑之中呢。有时候，我只需解决少量有时序问题路径，就可以同时解决一堆其它路径的时序问题。 l  找到From和To节点中你认识的节点。通过这些节点，你可以知道那些源代码或逻辑结构出现了问题。这样比较容易理解出问题的逻辑是什么以及如何来解决时序问题。 l  前面提到，当你解决某个路径的时序问题的时候，可能会不经意间解决了其它路径上的时序问题。因为编译器总是试图对所有路径进行优化，假如能通过修改代码或约束来解决某个路径的问题，那么就有利于释放编译器将更多精力放在其它有时序问题的路径上。   回到最初的时序报告，根据上述提示，不管有多少时序失败的红色路径，我首先来分析前面几行时序问题，最前面几行是时序最差的路径，如图5所示。 图5：时序最差几条路径          我们看到前面7条内容差不多，那么我们来分析第一条，鼠标右击第一行任何地方，选择“Report Worst-Case Path”来观察和分析这条路径。在Statistic页面查看这条路径的上数据到达路径上的逻辑层级，当然也可以在Data Path页面下通过该路径上CELL和IC的计数也能得知该路径上的逻辑层级，如图6所示，结果是17级。 图6：查看数据到达路径上逻辑层级          鼠标右击图6中到达路径任何单元，选择“Locate Path”，然后在弹出的对话框里选择“Technology Map Viewer”，单击OK。那么我会看到如图7所示的逻辑结构。   图7：寄存器之间逻辑层级过多          如图7所示在寄存器last_data和parity_error之间总共有17级逻辑，很好地表明了这个时序应该是由过多逻辑层级造成。            回到TimeQuest，我们再次使用“Locate Path”命令，这次选择使用Chip Planner来查看路径。在Chip Planner底部的Locate History窗口里双击定位的路径，根据需要可以使用放大镜调整放大倍数，我们可以看到这条路径布局布线结果如图8所示。   图8：布局布线结果          图8中连线的延时信息，需要从View菜单里执行“Show Delays”来使能已经高亮的路径。可以看到该路径上所有节点只分布在相邻的两个LAB中，而且LAB之间仅有少数几根连线，这表明这是一个很好的布局，再次证明该路径时序问题是由逻辑层级过多造成。            为了解决这个路径上的时序问题，可以 插入流水寄存器的方法。如果代码是你本人写的，那么这个方法是一个可行的办法。因为你会知道，发生这种奇偶校验错误时，并一定需要立即得到处理，几个时钟周期的滞后对于设计来说还是可以容忍的。所以我们可以通过修改代码来对该路径进行优化。            插入流水之前，奇偶校验是这样实现的： assign parity0  = last_data ^ last_data ; 插入流水后，将parity赋值语句放在进程里面并使用阻塞赋值，如下所示： parity0  = last_data ^ last_data ^ last_data ; 通过以上修改并重新编译设计，那么奇偶校验寄存器现在都满足了时序要求。如图9所示，剩下时序问题负的slack小于1了。 图9：剩下的有时序问题路径          从图9可以看出，时序问题仍然是SCLK时钟域，可以再次使用报告时序来对其进行分析。从报告窗口里继续使用“Report Worst-Case Path”命令来查看第一条出现时序问题的路径sop_error的更多细节。   图10：出现时序问题路径细节          如图10所示，很多出错路径的To节点都是sop_error（即包错误标志开始）信号，这些路径都是从接收模块的FIFO地址寄存器到此标志信号。这就意味着，我们可以一次性解决所有这些问题。            根据前面的经验，我首先来查看这条路径的逻辑层级，使用相同的方法，但是这次我们发现路径上逻辑层级很少，所以也许问题不是因为层级太多，但是为了验证我们的猜测，可以使用图形观察工具进行确认。使用“Locate Path”到“Technology Map Viewer”中进行观察，如图11所示。   图11：观察路径逻辑层级          从图11可以看到，不像之前那条路径，这条路径上只有一个RAM块和3级逻辑，所以证明这个时序问题不是因为路径上有过多的逻辑层级。但是可以看到RAM的输出路径是组合逻辑，这意味着整体寄存器到寄存器延时就包括RAM块以及三级组合逻辑单元的延时。这是否是造成时序违规的原因呢？            我们返回到TimeQuest中观察路径详细信息的slack报告界面，在Data Arrival Path片段，我们重点看第六行（时钟路径和数据路径已经展开，行号应该是2，因为数据路径展开在时钟路径之后）。如图12所示。 图12：详细观察数据到达路径          我们需要图12中，注意“Type”列为CELL延时，这行显示经过器件的cell给该路径增加的延时。“Location”和“Element”显示的是该CELL实际上是一个M9K存储块，那么经过这个存储块增加了多少延时呢，可以在“Incr”列看到。因此，尽管这条路径上只有少数几级逻辑，但是此路径上的时序问题还是属于逻辑层级过多造成的时序失败，因为路径经过的存储块带来过多的延时。那么我们应该如何来解决这种问题呢？通过使用M9K块输出寄存器来手动插入流水似乎是不可能的，因为该RAM是POS-PHY函数的一部分。通过多周期路径约束应该可以解决这个问题，但是多周期路径约束会增加处理延时。            这个问题，可以使用物理综合里的寄存器重定时选项来进行优化。寄存器重定时将移动关键路径上的寄存器位置来提升路径时序性能。虽然这个优化选项将会增加编译时间，但是它有可能会同时解决设计中其它的时序问题。            使能寄存器重定时，可以在Quartus II软件的Assignments菜单下选择Settings，在弹出的窗口找到物理综合优化，使能寄存器重定时优化选项，同时将其“Effort level”设置为“Extra”，点击OK后重新编译工程。       编译结束后，SCLK时钟域所有时序问题都得到了解决。

           学习时序也有一段时间了，一直也没分享什么学习笔记。这次以时序优化为例，检验一下这阶段的学习成果。          关于时序方面的东西也看了、学了很多，就是练得很少，在平常自己的设计中很难找到非常针对的设计来练习，只能在今后的学习中慢慢发掘了。最近在整一个设计，在要求的指标下时序是满足的，但是为了拿它练手，故意将它的时钟约束提高一倍： create_clock -name {sysclk} -period 4.000 -waveform { 2.000 4.000 } 图 1          约束到 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 模块之间的路径，其中包含大量的加法器逻辑，导致时延过大。 图 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 ，估计 f max 达到 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 ed|divider|divider|add_sub_16|op_1~9| 这一级，减少了布线延时，时延方面从 0.310+0.801+0.440+0.000+0.055=1.606ns 减少到 0.310+0.239+0.733=1.282ns ， （ a ）优化前 （ b ）优化后 图 9          2. 如图 9 所示为第二处差别，此处具有相同的路径，节点的扇出也相同，就是时延发生了变化，节点 Div_0|LPM_DIVIDE_component|auto_generated|divider|divider|add_sub _16|op_1~73|sumout 到节点 Div_0|LPM_DIVIDE_component|auto_generated|divider|divi der|DFFStage |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 区域中布局布线。 图 3 图 4          然后来 check 一下 timing ，值得欣慰的是，时序好了一些，如图 5 所示，建立时间余量减小到 -0.224ns 了，关键路径还在除法器内部。通过分区逻辑隔离、创建 Logiclock 区域进行布局布线隔离还是起到了意想不到的效果，尽管这效果很小。 图 5

         在尝试了多种优化方案后，设计的时序还未达到收敛，但我却已黔驴技穷了。冥思苦想了几天，我决定重新分析一下问题，将这段时间的优化过程回顾了一下，忽然间发现曾在 《时序优化一例（一）》 中分析过除法器 IP 的问题，查询过这 IP 核的性能，初步估计可能达不到 250MHz ，是不是这 IP 核本身真就不行呢？其实在 《 时序 优化一例（三）》 中已经可以验证了，因为通过分区和创建 Logiclock 区域将除法器与其它模块在 synthesis 和 fitter 过程中分离开来了，此时时序分析后的关键路径还停留在除法器内部，为了充分验证其性能，单独对此除法器建了个工程，顶层原理图如图 1 所示，其它的逻辑完全不加，并且时钟约束到 250MHz 。 图 1          然后对此模块采用 《时序优化一例（二）》 中相同的物理综合优化，如图 2 所示，使能 Perform physical synthesis for combination logic 选项，并且 Effort level 设置成 Extra 图 2          通过 TimeQuest Timing Analyzer 分析一下时序，果然未收敛，如图 3 所示，建立余量达到 -0.226ns ，与 《 时序 优化一例（三）》 中优化后的结果 -0.224ns 几乎相同，看来前面分析的正确，是除法器 IP 真就不行！这个问题只能通过自己重新编写除法器程序解决了，可以不采用 altera 官方的 IP 核，而此阶段的时序优化任务算是告一段落了！ 图 3 总结：          还是对这阶段时间时序优化的实践做一个总结吧！通过边实践边记录的方式学习，发现学习效率提高了不少，需要记录就有了解决问题的动力，在解决问题的过程中就将理论知识结合起来了，以前两个月对时序方面理论知识的学习为基础，因此可以对实践中发现的问题可以找到合理的解释。 在 《时序优化一例（一）》 中通过修改代码的方法优化了关键路径，效果还是很明显的，在以后的时序优化过程中，应该将此方法作为首选，因为代码是时序不理想的根源。首先需要通过时序分析工具（ TimeQuest Timing Analyzer ）找到关键路径，分析关键路径，可能是由于路径中逻辑过长或者节点扇出过大，然后根据关键路径修改对应的代码，可以加入流水线级或优化逻辑代码来优化时序。 在 《时序优化一例（二）》 中通过物理综合优化时序，在无法使用修改代码方法优化时序时，可以采用此方法。这部分优化是软件自动进行的，包括优化逻辑、优化布局布线等。 在 《 时序 优化一例（三）》 中为了分析时序问题，采用了 Design Partition 和 Logiclock 方法。其实这两个工具的主要用处就是分析， Design Partition 可能主要用于增量编译；而 Logiclock 将逻辑的布局布线限定在一个区域中，更易于对时序路径进行分析。 通过这阶段的学习实践，巩固了时序方面的理论知识，掌握了几种时序优化的方法，当然还有许多其它方法，需要继续学习提高。