CTS后理解clock latency的问题

想问的是，为什么CTS后，对于input paths，工具只能知道capture clock（FF2）的latency而不知道launch clock（FF1）的latency?我的理解是capture clock是指FF2，launch clock是指FF1，如果我的理解是错的，希望在评论里指正，感谢！

工具只能在端口标一个时钟长度（latency） 这个时钟是sdc里面约的 长度是根据做完cts后真实的始终长度
captrue和launch你理解是正确的

请问， 一般在CTS前用通过set_clock_latency先设置一个值来做place吗?为了更好的和CTS的情况接近，在place时

为啥我放的图没了。

我觉得没必要，我的理解:1. place的时候clock本就是ideal的
2. cts后出现的io violation有可能是假错，比如对于output port的setup，由于你做的block看不到外面的register，所以capture path的propagated delay是0，是ideal的，而launch path是有tree的，这差了一个tree的长度，可是从chip top上来看，它能看到你的capture path的register，所以capture path不是ideal的，只是可能tree并不平衡罢了，如果是完全平衡的，实际上是没有violation的。

我的意思是为了让place时的情况和CTS时的情况更 correlation,如果在place就标记一个CTS时得到的insert delay的平均值，那place时岂不是和CTS看到的timing差不多了，不知道对不对。您说的是IO timing ,但是regto reg呢?

reg to reg，只要tree长得好，与place相比，差异不大啊而且，不是还有postCTS嘛，总之我觉得没有必要。