[转]TimeQuest之delay_fall clock_fall傻傻分不清楚

这篇我想分享一个以前在用TimeQuest约束双边沿模块的input delay时犯得一个错误，有人看了可能会以为傻傻的，什么眼神，falling delay和 falling clk怎么会分不清呢，字面意思好区分，可要深究在约束里的具体含义，还得花点功夫，下面以ddio接收模块为例说明它们的含义以及碰到的一些问题。

ddio接收模块为双边沿工做模式，如图一所示，ddio_in接入DFFH和DFFL，时钟降低沿DFFL锁存DL，但不马上输出，直到时钟上升沿高电平使能latch时输出，同时DFFH在上升沿锁存输出DH，和DL拼接成输出数据，这样就实现了对双边沿输入数据的采样输出。

图一

其时序特性是，上升沿发送的数据降低沿采样，降低沿发送的上升沿采样，工做波形如图二所示，须要施加约束才能正确的双边沿采样。

图二

首先用create_clock建立输入时钟频率为100MHz的ddio_clk_s，而后用set input delay关联输入数据ddio_in和输入时钟ddio_clk_s，设置延迟为2ns，查看IO Timing，发现TimeQuest分析了两条路径如图三所示，一条是上升沿到降低沿，这是咱们想要的，另外一条是上升沿到上升沿，这不是咱们须要的，并且尚未降低沿到上升沿的路径，看来这种简单的约束方式明显存在问题。

图三

set input delay默认是基于时钟上升沿设置，TimeQuest不清楚用户的真实使用状况：上升沿发出的ddio_in数据究竟是被DFFH采样仍是被DFFL采样呢，因此默认源端上升沿发出的数据会同时被这两个D触发器采样，这就出现了上述rise to fall和rise to rise两条路径，第二条无关路径设置为伪路径后能够被去除。

降低沿到上升沿的路径如何设置呢？ 打开set input delay看看可否找到一些新的线索。

图四

如图四，首先映入我眼帘就是醒目的rise和fall的选项，既然set input delay默认是基于rise上升沿的，那勾选fall，应该就是基于降低沿了吧，这是我当时的第一反应。但是分析结果里仍是没有降低沿到上升沿的路径，又注意到这个fall选项是被划在input delay options里，按理fall应该是用来修辞input delay的，可是怎么个修辞法，当时并无细究，出于对曾今过了英语六级的那份自信，我仍然认为，fall表示数据是基于时钟降低沿输入的。当时也查了些前辈的博客，其中特权同窗很早以前的一篇 深刻剖析I/O 里也有对fall和rise的翻译如图五：

图五

特权同窗认为fall是时钟的降低沿延时，可是fall是用来修辞input delay的而不是clock，因此我并不承认这种翻译，此时我注意到表格里还有一个参数是-clock_fall，这个好像和我想找的意思相符，为了验证参数的具体含义，又继续搜索找到了altera关于set input delay的中参数的官方解释以下：

-clock_fall     Specifies that input delay is relative to the falling edge of the clock
-fall               Specifies the falling input delay at the port

此时我才大悟，-clock_fall才是我一直寻找的，它才是基于时钟降低沿的意思。勾选using falling clock edge后，降低沿到上升沿的路径终于千呼万唤始出来，不过同前述，也会多一条降低沿到降低沿到的路径，用伪路径能够轻松去之。

双边沿约束的问题解决了，但是官方对fall的解释 the falling input delay 是神马意思呢？都是四级的词汇，凑在一块儿，就不是很明了了，数据降低延迟？听起来总感受怪别扭的，跑去和同事一块儿讨论这个问题。一组输入数据变化时，哪有上升和降低之说？(数据从0010变为1001，你说是上升仍是降低呢?)，上升降低应该是针对某一根数据线的变化而言的(数据从0010变为1001，你能够说第0位上升了，第1位降低了)，可是TimeQuest真的想知道你每根数据线的上升降低延迟吗？no no no，回想下set input delay的本质是告诉Timequest最大输入延迟让其约束创建时间，和最小延迟约束保持时间，TimeQuest只想知道输入的最大最小延迟就能够了。源端发送数据的每一位的上升延迟和降低延迟可能会不同，也有一个大小之分，好比第0位上升延迟为0.4ns，降低延迟为0.8ns，第1位的上升延迟为0.5ns，降低延迟为0.9ns，TimeQuest会用其中相对较大的0.9ns去分析创建时间，相对小的0.4ns去分析保持时间，而不会去关心数据具体某位是如何变化的。既然TimeQuest只关心延迟的大小，那只要在set input delay里设置max min delay不就能够了吗，何须设置rise和fall呢？

测试后发现，若是不设置rise和fall，会致使约束不精准。举个例子：源端发出数据的输入上升延迟Tdelay_rise为0.5ns，降低延迟为Tdelay_fall为0.8ns，路径最大延迟为2ns，最小延迟为1ns，只设置set input delay的 max delay为2.8ns，min delay 为1.5ns，其中ddio_in[1]的路径延迟报告如图六所示。

图六

注意红色线标记，data path为2.129ns。

若是加上rise 和fall选项，设置 max  fall 为2.8ns，max rise 为2.5ns，min fall 为1.8ns，min rise 为1.5ns，ddio_in[1]的延迟报告如图七所示。

图七

看红色线标记处，data path为1.998ns，比前者少了0.131ns，这两种约束的最大和最小延迟相同，但结果却不一样，缘由在于FPGA的内部逻辑针对输入数据的上升Trise和降低Tfall的延迟也是不同的，假设Trise > Tfall，第一种约束方式的最大路径延迟是Trise + 2.8+ Tother，第二种方式指定了fall和rise后，TimeQuset知道了指定的最大输入延迟发生在数据降低时刻，因此分析的总体最大路径延迟会变为Tfall + 2.8 + Tother，这种约束方式更符合实际的应用，也更加精确。虽然两种约束方式的结果相差甚微，不会对普通应用形成影响，但对一些高速苛刻的应用，可就不能小视了。

set output delay同样也有rise  和 fall的选项，和set input delay做用相似，这里就再也不复述了。