从TimeQuest角度看create_generated_clock

最近在学SDRAM,听说SDRAM涉及到静态时序分析,那还说什么呢学吧。

在看到create_clock与create_generated_clock时我彻底疑惑了, 即然有了create_clock何必还要create_generated_clock呢,google一翻后得到一个结论,create_generated_clock是用于衍生时钟,TimeQuest作STA分析时会自动计算source clock 到generated_clock之间的skew.我又不明白了即然TimeQuest可以计算时钟偏斜,那直接对source clock进行create_clock不就行了,TimeQuest不就会自动对其衍生时钟偏斜进行分析了么。可能这个问题太低级了,大牛觉得太显然对此一略而过,也可能是我理解能力太差,大牛写了我没领会到,不管怎么样我是百思不得其解,早晨醒来就有了一个猜想。TimeQuest号称STA工具,那么他应该不会理解衍生时钟的逻辑功能,只能单纯的根据uTco、clock skew、data path等时间值对setup time、hold time、removal time、recoveral time的余量进行分析。也就是说TimeQuest只会对内部逻辑延时进行计算不进行逻辑分析,实际上TimeQuest并不知道你的衍生时钟与源时钟之间的关系。因此需要create_generated_clock对衍生时钟进行说明,下面用图来说明一下。

假设使用逻辑衍生出的理想时序如下图:

图中clock为源时钟,invert_clock为衍生时钟,与源时钟相移180度,如果仅使用create_clock来对clock时行约束,那么,TimeQuest在进行STA时对invert_clock的时钟所理解的波形应该如下图:

在上图中,clock skew仅仅是由时钟衍生逻辑产生的延时,不包括逻辑产生的相移,也就是说TimeQuest无法理解clock进行一块逻辑后出来的具体时钟与源时钟的真正关系,仅能靠一些路径延迟与DFF或LUT的参数来计算时钟延时。

而如果我们使用create_generated_clock对invert_clock进行约束后,TimeQuest在进行STA时对invert_clock的时钟所理解应该如下图:

也就是说只有对衍生时钟进行create_generated_clock约束,TimeQuest才能正确的理解波形,换句话说,一些走线延时、LUT、DFF的参数产生的问题由TimeQuest来自动搞定,如果是由于我们自己用逻辑产生的影响(如上图相位偏移),我们必须报告给TimeQuest,TimeQuest才正在静态时序分析时进行正确的计算。由于上面的TimeQuest所有过程均为我猜测得出,所以有不对的地方,请大家拍砖。

从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的分析模型来检测布线延时是否满足要示。最后,一切均为猜测,没有官方依据,如有不对请大家指出哈!