请教cts之后如何修setup违例

请教两个关于时序的问题
(1) cts后，place阶段留下来的几个setup违例还是怎么修(group_path -weight，psynopt，clock_opt -only_psyn ,optimize_clock_tree)也
修不干净，只能稍微减小一些
其中一条timing path如下，slack为-0.08

发现 U2481这个 buffer的延时比较大，因为其扇出比较大，如何手动优化一下它呢
(2) design中的critical path是发生在ICG上的path，这个很可能是因为ICG距reg比较远而离clockroot比较近造成的 这个该如何优化呢；
看到论坛上有人提到用move bound结合set_clock_gate_latency? 再用move bound时，如何提前知道某个ICG是和哪些reg相连呢
?

1）调整clocktree吧， 把endpoint 拖后，
2） place_opt -optimize_icg看看，

小编首先多谢你的关注1）把clocktree的endpoint 拖后?这个用什么命令来实现呢?
2） place_opt -optimize_icg看看?看了下09和13版本的place_opt和clock_opt都没有这个-optimize_icg选项

1) 手工insert_buffer ,
2) 13.12 才有这个选项，

哈哈 ，确实昨晚搞了好久，也发现手动插入buffer可以解决问题，并且插入buufer的时候，有几点要注意：
(1) 要插入低驱动能力的buffer，如1x的；插入大驱动的话，只会使slack更差

(2) 如果要在某个cell的输出pin之后插入buffer，那么一定要选择那些只出现在clock path上的cell，否则时序不会改善

(3) 在clock path上插入buffer后，setup问题解决后；要注意查看是否有hold的违例，如果有可以用 psynopt -only_hold_time，这个命令

在修hold的同时，不大会使setup变坏

哦，原来这样，那我有时间再去下个13.12的

多谢小编

(1) 要插入低驱动能力的buffer，如1x的；插入大驱动的话，只会使slack更差
---注意在时钟树上的buffer限制: 注意类型是否是CTS专用的，注意驱动是否是合法的

建议用合法的最小驱动的buffer，不满足的话，多插一些

恩 多谢小编 用的就是最小驱动的buffer ，1x的！

时钟树上不能用这么小的buffer，否则ocv覆盖不了，一般至少用x4以上，而且不到万不得已最好不要动时钟树

我觉得，时钟树建好之后，它的质量优时钟树的skew和transtion决定，如果修改之后(插入buffer)之后，这两项还依然满足你的要求
那就应该没有太大问题的；插入大驱动buffer的话，比如4x的，我试过，这样会使clock path上的延时减小，从而使slack变得更差；

当然也可以在data path上将小驱动的buffer(比如1x 2x)替换为大驱动(比如4x 8x)，不知道你说的是这个意思不?

你再好好看看6#,7#,9#的意思
clock path用的cell比普通data path范围要小得多的——工艺上的要求。

你再好好看看6#,7#,9#的意思
clock path用的cell比普通data path范围要小得多的——工艺上的要求。

范围小得多这个是什么意思?小编，我的理解很简单，就是cts的时候用的buffer和inv与普通的buffer和inv不一样，
cts用的buffer和inv是单独为cts准备的，因为这些buffer和inv的rise/fall的transition比较一致，这样长出来的树比较balance

我说的插入buffer也是插入这些buffer和inv，比如CKBUFFX1 CKBUFFX2，不是插入BUFFX1 BUFFX2

不知道小编说的范围小 是什么意思

即使是CKBUFFX1 CKBUFFX2，很多时候工艺厂商也是不建议用的（或者特殊场合才可以用），看看manual有没有这种信息

恩，先谢谢小编！
目前我只知道不用驱动能力很小的CKBUFF的一个原因，小编知道厂商为什么一般不同意用较小驱动能力的吗?

1.小的buf/inv在ff和ss下delay的差别会比较大，容易导致同时出现setup和hold的情况。
2.小的buf/inv delay的正态分布会比较宽，即需要更大的ocv来覆盖。
你用大的buf 一个不够可以用多个，还可以手动把它们拉远点，我看你数据路径上的逻辑不是用的很大的size，你可以优先换它们

高手啊！ 刚才查看了一下lib，确实如此，举个例子，x1的inv的cell_rising 差0.31139/0.39953，x16的inv的cell_rising差0.22832/0.26764都是相同的input transition和output load的情况下
多谢啊！

借机学习了

学习了学习了~

但是问了师兄说，现在做的16nm中，推时钟时候，都是D4以及以上，D2的禁用，因为说是d2面积小 划线有特殊drc checkem问题很明显

也来学习一下

先找datapath能修的吧，路径上x2,x4的BUF和INV都可以修改

也来学习一下

failed power too low

学习了

小编，你不是建议说用X4的，怎么又用X1的了?到底用多大的驱动去推时钟?