这个实例我们来看看如何对设计进行时序优化，假设设计的顶层框图如图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[ 0] ^ last_data[ 1];

插入流水后，将parity赋值语句放在进程里面并使用阻塞赋值，如下所示：

parity0  <= last_data[ 0] ^ last_data[ 1] ^ last_data[ 2];

通过以上修改并重新编译设计，那么奇偶校验寄存器现在都满足了时序要求。如图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时钟域所有时序问题都得到了解决。