icc cts 的问题

项目中大在cts阶段 ，clock_opt -only_cts后 congestion 还比计较好，skew 也能接受，DRC为0，接下来clock_opt -only_psyn，congestion就想到严重了，一片红色。set_false_path去掉一些不需要balance的clock 情况好了一点，但是还是比较严重。我就想那就不做clock_opt -only_psyn。只做 clock_opt -only_cts
report_constraint后 ，其中只有一条clock的transition的violation比较大，大概2.6，怎么也opt不掉 ,optimize_clock_tree -clock_tree [] 单独对那条clock做了cto ，psyopt -only_design_rule都用了，结果变化不大。占用率大概80%

第二个问题是 ：detail route后发现clock tree有transition的错，该怎么办?因为显示的dont touch了

感觉约束上还要好好debug下，哪些是同步需要blance的，哪些是没有timingcheck不需要blance的理清楚。感觉你的design可能时钟上是不是有dont touch或被设为idealnet的方检查下，clock_opt后congestion没有变化，就说明cts对design冲击不大，做onlypysn后很红说明你的你的时钟树可能有问题，需要blance得地方没有blance，这样工具看到很大的violation，然后拼命去优化，将cell的size称撑的很大就变红了，还有就是你的pysn的时候约束也有问题同样会导致这样的问题。

谢谢回复，如你所说，确实存在不需要balance的clock tree，大概20多条clock，相互之间不需要balance，set_false_path 没有写全，用set_clock_group 重新将clock 约束了一下。具体什么问题，我再debug一下另外是有一条clock，cts做完后transition的值很大，怎么也做不好，差的太多了，我怀疑是驱动clkbuf放的太小。怎么单独处理这个clock，求指点

标题clock_opt 的

标题8

单独报下那个点，看看是不是有dont touch 有的话看能不能remove掉，再在版图看是在什么位置，是不是前后级都很远。如果做树时有设transition和cap就不会有这样的问题，icc主要1是利用transition来驱动优化的

通常只会 fix hold会导致 utilization growth toomuch从而导致congestion的新增加，
不妨先不要set_fix_hold [all_clocks] ,psynopt 先修setup 先，
而且如上面所述，sdc约束肯定要搞清楚， false path，clk balance spec等也会影响的，
比如修一个根本是false的setup path，也有可能造成buffer插的太多

谢版大回复，没有fix hold ，现在是一个master clock 通过不同的分频器产生了很多clock，这些cock之间是不需要balance的。dc在每个分频器后面 create_clockmaster clock 在port端create_cock并且将master 和分频后的clock 也set_false_path 了。现在肯定是所有的clock之间都设成了异步的 。通过set_clcok_group -asynchronous
问题是分频后的clock总是做不好，总是其中一条的transition特别大。
因为only_cts后没有timing的问题。skew 也可以。所有就不想让工具去做only_psyn了,clocktransition 的violation 自己手动fix

谢谢回复第二个问题已经解决了，可以remove掉 ，现在是一个master clock 通过不同的分频器产生了很多clock，这些cock之间是不需要balance的。dc在每个分频器后面 create_clockmaster clock 在port端create_cock并且将master 和分频后的clock 也set_false_path 了。现在肯定是所有的clock之间都设成了异步的 。通过set_clcok_group -asynchronous
问题是分频后的clock总是做不好，总是其中一条的transition特别大。
因为only_cts后没有timing的问题。skew 也可以。所有就不想让工具去做only_psyn了,clocktransition 的violation 自己手动fix，不知道有没有其他好的办法