CTS之后发现有些path即使postCTS可能也修不过去怎么办

CTS时候遇到了一个问题，就是在CTS时候有的path很难修，交给工具 post CTS也很难 修 过去还可能造成更多的违例，之后后是不是可以重新长一遍tree，但是每次长tree之前不是要删除已有的tree吗?还是在重新长tree的时候选择mode里告诉工具不要删除已有的tree，不然应该每次长的都一样啊

简单来说就是 cTS之后重新CTS对时序有没有好处?为什么

不懂為何要 CTS 之后再重新 CTS ? CTS 的目標就是 Balance skew 吧.
先搞懂所謂 timing path 很難修是不是 skew 不 balance 造成.
不了解設計只用 clock_opt 預設值去做讓我想起我剛入這行的前半年樣子.

通常不动tree，除非tree做的太烂，发个report看看， 是clk skew引起的么?

新人，同问一下，那正常情形下应该如何去做?是怎样一个思路?

在CTS之后怎么看长tree长的不好啊 ?在报告里看到的是slack是负的 ， 由于other end arrival time过大引起的 而且 data path 的endpoint是enclude pin
root 点既是时钟的startpoint 又是 data 的start point

图已发请教 为什么 hold 会有负值的情况

这个clock是从pad输入的么，贴个全path看看吧
感觉有点奇怪，为啥一开始arrival time就是9.9ns，和clock定义点有关系吧

第一个图的终点在reg 的 D pin 后一张图的终点在CK pin 上 ，路径上没有别的东西全是buffer 和 inv在 D pin 终点的前面还有两个ex 开头的inv 我问同事说是代表这是enclude pin 为什么在enclude pin 前面加inv 我也不明白，这个是不是就是说 因为data path上终点是enclude pin 所以不需要balance 而 root点是同一个 所以Required time要大于 arrival time ，而且requied time 计算的capture path 是在clock net 上 是fixed住的

in2reg的hold ignore也罢， 这个pad_pol1 是什么东西?

有人告诉我L什么的是clock net上的东西 ，这就是报告的第一条path 了 前面没东西了

可以用 report_clock_tree , report_clock_timing 去看你的 skew 有沒有 balance. 其他問題要請designer 幫你解決是不是 timing constraint 的問題.