从TimeQuest角度看set_max_delay

今天开始看特权大大的《实战演练之时序收敛》,看到set_max_delay时跟着做了一下,设置了最大延时为3ns,然后report timing突然自动飘红了,很意外,于是看了看瓢红的路径的waveform,意外的发现set_max_delay中设置的值成了latch edge time,由于E文不好google了半天也没找到原因,于是再次祭法宝(从TimeQuest方向进行猜测)。由于report timing飘红让我这种初学者心里有压力,于是先将set_max_delay设置为5ns,然后果然不飘红了。开始找原因吧,先去data require path看看,果然latch edge time变成了5ns,也就是说latch edge time就是设置的最大延时。

再看一下data arrive path

发现上图中的所有的时钟延时为负的都是由PLL产生的,我理解是因为PLL自动对时钟相位进行了负的偏移来修正走线以及其他的的延时。

再看一下Technology Map Viewer中的视图:

从上面的图中我们可以看到其实在这两个节点上所谓的setup slack分析其实无非就是想说明从clk的时钟信号经过锁相环的变换到sr_clk输出共花费了3.045ns,也就是说clk+走线延时+逻辑延时-(PLL修正的延时的绝对值)就是clk到sr_clk之间的输出延时。那么为什么set_max_delay的值为什么变为latch edge time了呢,下面再看一下waveform,如图:

新建

这下都清晰了,其实TimeQuest是借用了register to register的setup slack的分析模型来检查,布局布线后的延时是否大于我们set_max_delay中设置的延时。由图可以看到,clk经过变换达到引脚sr_clk(包含PLL的相位偏移修正)共是3.045ns,这点也可以从data arrive path上看出,然后将latch edge time设置为set_max_delay的值这样就可以检测set_max_delay 的值是否大于clk到sr_clk的延时,也就是说其实这里仅仅巧妙的借用了setup slack的分析模型来检测布线延时是否满足要示。最后,一切均为猜测,没有官方依据,如有不对请大家指出哈!

发表评论

ninety one − eighty seven =