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