标签: 多周期
相关博文
-
-
TimeQuest 之 multicycle paths 王敏志 （现在发现字数会莫名其妙超出） 实际应用实例 图 6 是本人实际工作中设计的一个工程部分示意框图，在全编译之后主要是图中的三个 PLL 的输出时钟有报告时序问题，在不进行时序约束的时候上板调试是没有遇到什么问题的，只是这么多时序违约报告不知道长时间运行是否稳定，所以有必要仔细分析每一个违约时序报告。 图 6 这个工程只是对于 CLKIN （外部 100MHz 时钟）和 PLL 的输出进行约束，如下所示 create_clock -period 10.000 -name refclk -waveform {0 5} create_clock -period 10.000 -name clkin -waveform {0 5} derive_pll_clocks 全编译之后查看 TimeQuest 的报告图 7 所示， *pll*clk 、 *pll*clk 和 *pll*clk 分 图 7 别是图 6 中的 100MHz 、 250MHz 和 62.5MHz 三个时钟我们发现这三个时钟都有报告时序违约，而且 250MHz 的 Fmax 报告才不到 94MHz 。打开 TimeQuest 分别对这三个时钟的红色报告执行 report timing 命令并进行分析，图 8 显示了对于 100MHz 时钟执行 Report Timing 后的结果，产生违约的路径的 Launch clock 是 62.5MHz ， Latch clock 是 100MHz ，也就是说这些违约路径都是跨时钟域的路径，再分析源代码发现这些路径都是跨时钟传递数据，逻辑设计保证在传递数据的时候能安全传递，即通过握手控制信号保证数据稳定传输，所以这些路径可以认为是 false paths 。针对这些路径加入 false paths 约束如下 set_false_path -from }]\ -to }] 再重新编译工程，发现 100MHz 的时序违约没有了，如图 9 所示。 图 8 、对 100MHz 时序违约路径执行 Report Timing 命令结果 图 9 、解决 *pll|clk 即 100MHz 时序违约 重新打开 TimeQuest ，依照从易到难原则，这次解决 *pll|clk 即 62.5MHz 时钟时序违约问题。同样执行 Report Timing 命令我们得到类似图 8 的报告界面，如图 10 所示。 图 10 、对 62.5MHz 时序违约路径执行 Report Timing 命令结果 产生违约的路径的 Launch clock 是 100MHz ， Latch clock 是 62.5MHz ，也就是说这些违约路径同样都是跨时钟域的路径，再分析源代码发现这些路径都是跨时钟传递的控制信号（图 6 框图所示），这些 100MHz 时钟域的控制信号和 62.5MHz 时钟域被控制的模块是完全异步的关系，所以这些路径可以认为是 false paths 。针对这些路径加入 false paths 约束如下 set_false_path -from }]\ -to }] 上述 false paths 命令其实就是前面 false paths 命令的反向操作，即这两条 false paths 命令分别“ cut ”了 100MHz 和 62.5MHz 这两个时钟域之间路径的时序分析。再重新编译工程，发现 62.5MHz 的时序违约没有了，如图 11 所示。 图 9 、解决 *pll|clk 即 62.5MHz 时序违约 还剩最后一个，总的 slack 到 -10.586ns ，打开 TimeQuest 并对此违约路径执行 Report Timing 命令，报告结果如图 12 所示。 图 12 、对 250MHz 时序违约路径执行 Report Timing 命令结果 由于负 slack 量很大，所以时序违约也许不止一种情况（实际情况也确实如此），图 12 所示的报告默认只报告最差的 10 条。仔细分析图 12 已经报告出来的这些违约路径，发现跟图 8 和图 10 报告的违约路径类似，也都是一些跨时钟域的路径，这里的 Launch clock 是 100MHz ， Latch clock 是 250MHz 。也就是说可以把这些路径当作 false paths 处理，由于本文是论述多周期，所以我想是不是可以通过加入多周期约束来解决这个问题呢？尽管 100MHz 与 250MHz 不是整数倍的关系，但是图 12 时序图看出可以加入一个 4 周期的 end 建立多周期约束，同时加入一个 3 周期的保持多周期来解决这个问题。命令如下所示： set_multicycle_path -from }] -to }] -end -setup 4 set_multicycle_path -from }] -to }] -end -hold 3 ( 注：本人不确定多周期是否必须两个时钟必须要是整数倍关系，但根据这个例子似乎不是也可行啊！ ) 重新编译工程，发现 250MHz 还是有时序违约，但是负的 slack 减少了，如图 13 所示 图 13 打开 TimeQuest 针对违约路径执行 Report Timing 命令，得到的报告结果如图 14 所示 图 14 仔细分析图 14 报告的违约路径，以及时序图，这些违约路径的 Launch clock 和 Latch clock 为同一时钟，即 250MHz 时钟。研究这些违约路径的原始代码发现 from node 其实是一个计数器的输出，而此计数器的计数频率虽然是 250MHz ，但是有条件的计数，所以这些路径更适合加多周期约束，这里先使用 false paths 约束，最后再把图 12 和图 14 所示的违约路径分别改成 false paths 和多周期路径约束。这里先加入的 false paths 如下所示 set_false_path -from }] -to }] 重新编译工程，发现 250MHz 的时序违约没有了，而它的 Fmax 也提高到 250MHz 以上了，如图 15 所示（注意和图 7 比较）。 图 15 附 1 前面有提到图 12 所示的违约路径应该 false paths 约束，而图 14 所示的违约路径应该加多周期路径约束。那么首先将图 12 所示的违约路径修改成 false paths 约束，约束命令如下，也即 Launch clock 是 100MHz ，而 Latch clock 是 250MHz 时钟。 set_false_path -from }] -to }] 重新编译后的结果如图 16 所示。 图 16 上图显示修改成 false paths 约束后似乎也能解决时序违约问题，对比图 15 ， Fmax 似乎跑的更高一些。而图 14 所示的时序违约路径的约束修改为多周期路径约束并没有成功，不管我如何加多周期约束在 FIT 的时候都是通不过，提示“ Critical Warning (332008): Read_sdc failed due to errors in the SDC file ”，也许是多周期语法有错？下面列出我尝试过的命令格式： 第一条： set_multicycle_path -end -setup –to }] 3 第二条： set_multicycle_path -end -setup –to }] 3 第三条：加上 –from 即从时钟到上述 PINs 也不行。 第四条：将“ get_pins” 改成“ get_cells ”以及“ get_registers ”也不行。 所以对于图 14 显示的违约路径还是加 false paths 来处理。最终工程的时序报告如图 16 所示。
-
TimeQuest 之 multicycle paths 王敏志 概述 Multicycle paths 即多周期路径， 指的是两个寄存器之间数据要经过多个时钟才能稳定的路径，一般出现于组合逻辑较大的那些路径。在实际工程中，除了乘除法器等少数比较特殊的电路，一般应该尽量避免采用多周期路径电路。即使有所使用，也应该通过约束在综合工具中指出该路径，使得综合工具在计算 Fmax 的时候忽略这条路径，避免用大量的时间对该路径进行优化。 对多周期路径可加一下约束： set_multicycle_path -from D_reg -to S_reg 。 本文成文之前参考了网上《 DC 概论之多周期路径》，并使用其中一些例子，这里对作者的辛勤劳作表示感谢。《 DC 概论之多周期路径》网上链接众多，本人不负责辨认何处为原创，这里只是给出其中一个链接： http://bbs.ednchina.com/BLOG_ARTICLE_214699.HTM 另外，这里有一个疑似原创出处： http://www.cnblogs.com/liuokay/category/291986.html 关于何时何处使用 Multicycle Path 上述《概论》论述的是 IC 设计的时候的多周期路径，那么对于 FPGA 设计特别是 ALTERA 的 FPGA 设计的时候何时何处会用到多周期约束呢？其实简单点说就是设计者如何知道自己的设计中哪里需要进行多周期设计的问题。 在设计中很多地方都有涉及多周期路径，当个两个触发器之间的逻辑如果一个周期执行不完的话一般有两个解决方案： 1 、插入流水线使得组合逻辑打散 ； 2 、使用使能信号控制，几个周期读取一次数据。 这里面 2 所使用的方法就需要设定 multi-cycle path ，方法 2 和 1 之间是有区别的。方法 1 数据的吞吐量更大，方法 2 牺牲了数据吞吐量，但是设计中有的地方对吞吐量没有要求是可以使用这种方法的。 举个简单的例子，某个设计大部分逻辑可以跑 1G ，但有个乘法器只能跑 100M ， 所以你就把 multi-cycle 设成 10T ， 但是 design 也要修改， 就是每 10T 才采集一次乘法器的结果。 在《概论》里详细介绍了所谓的“快采慢”和“慢采快”的两种情况，可以很好理解两个不同寄存器的采样时钟频率不一样时的情形。 多周期的分类 这里有必要交待一下多周期的分类，说到这个分类，有两种。一种就是上述《概论》里提到的快采慢和慢采快，另外一种是 Setup 多周期和 Hold 多周期。 ALTERA 其实对于第一种分类是这样描述的，即分为 Destination 和 Source 。 Destination 是基于目标时钟沿，向后移动 Latch 时钟沿来放松建立保持时间。而 Source 约束是基于源时钟沿，通过向前移动 Launch 时钟沿来放松建立保持时间。 Start 和 end 说明多周期路径依赖于 start clock 还是依赖于 end clock 。 ALTERA 关于第二种分法的描述是这样的，即 Setup 多周期是增加建立时间分析的周期数，默认情况下是 1 个周期。 Hold 多周期是增加保持时间分析周期数，默认情况下是 0 。 Setup 和 Hold 说明多周期路径是用在建立时间检查还是用在保持时间检查。 具体什么是多周期路径约束呢？ 时序分析器会分析除了定义为 false path 的所有路径。所有的路径都是在最近的沿分析 setup ，在最近的沿的前一个沿分析 hold 。 设置为 multicycle 的 path 会改变分析方法， 比如 muticycle 2 就是说会在最近的沿的下一个沿分析 setup ，分析 setup 的沿的前一个沿分析 hold 。 具体的多周期路径约束语法如下所示： set_multicycle_path value -start ：选择源（ source ）多周期 -end ：选择目标（ destination ）多周期（默认） -setup|hold ：指定建立或者保持多周期 value ：扩展分析的周期数目 其他基本和 false path 命令基本相同。下面通过几个例子来具体说明如何理解多周期。 1、 标准单周期寄存器传输 图 1 2、 双周期 setup ，单周期 hold 传输 图 2 那么图 2 所示的多周期路径约束如下所示： Set_multicycle_path –from –to –end –setup 2 3、 实际应用中经常遇到的乘法器多周期例子 图 3 前面有介绍，在多周期设置中， Setup 的周期是 X ，那么设置的 Hold 周期为 X-1 。所谓的快采慢如图 4 所示，请注意《概论》中的默认情况和 ALTERA 的 TQ 工具里默认情况的异同。概论里提到的工具如果命令没有指明 Start 和 end ，那么默认情况下 Setup 是参照 end ，而 Hold 参照 start 。而 ALTERA 似乎均默认为 end 。 图 4 假设已经知道 3*clk1delay2*clk1 ，这时候多周期约束为 set_multicycle_path -setup 3 -end -from clk1 -to clk2 set_multicycle_path -hold 2 -end -from clk1 -to clk2 再来看看“慢采快”，如图 5 所示 图 5 假设已经知道 3*clk1delay2*clk1 ，这时候多周期约束为 set_multicycle_path -setup 3 -start -from clk1 -to clk2 set_multicycle_path -hold 2 -start -from clk1 -to clk2 最后再来一个“慢采快”的例子， 100MHz 时钟分频得到一个 50MHz 的时钟，那么为从 100MHz 到 50MHz 时钟域所有路径加一个源多周期为 2 ，保持多周期为 1 的约束如下所示： create_clock -period 10.000 -name CLK create_generated_clock -divide_by 2 -source -name CLKDIV2 set_multicycle_path -start -setup -from -to 2 set_multicycle_path -start -hold -from -to 1
