首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >今日说“法”:TimeQuest之迷失的“delay_fall clock_fall”

今日说“法”:TimeQuest之迷失的“delay_fall clock_fall”

原创
作者头像
FPGA技术江湖
修改2021-04-16 17:47:52
3630
修改2021-04-16 17:47:52
举报
文章被收录于专栏:FPGA技术江湖FPGA技术江湖

今日说“法”:TimeQuest之迷失的“delay_fall clock_fall”

欢迎大侠来到FPGA技术江湖新栏目今日说“法”,当然,在这里我们肯定不是去研究讨论法律法规知识,那我们讨论什么呢,在这里我们讨论的是产品研发以及技术学习时一些小细节小方法等,欢迎大家一起学习交流,有好的灵感以及文章随笔,欢迎投稿,投稿请标明笔名以及相关文章,投稿接收邮箱:1033788863@qq.com。今天带来的是“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 cloc

-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作用类似,这里就不再复述了。

后续会持续更新,带来Vivado、 ISE、Quartus II 、candence等安装相关设计教程,学习资源、项目资源、好文推荐等,希望大侠持续关注。

江湖偌大,继续闯荡,愿大侠一切安好,有缘再见!

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 今日说“法”:TimeQuest之迷失的“delay_fall clock_fall”
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档