做时钟树平衡的目的是什么

我觉得你说的有一定道理. 但也不全对.
在慢速设计中. skew的重要性明显下降.
但我认为, 时钟树除了 skew latency这些东西以外.
最最重要的是品质是: 强壮.
所谓强壮就是在任意corner下都能满足时序. 这点对提高良率的意义重大.
在考虑到工艺偏差, 模型偏差等因素后.
一种常用的让时钟树强壮的方式就是对称.
我用类似的cell, 类似的拓扑结构, 经过类似的级数到达每个register.
这样, 即使工艺偏差, 即使模型偏差.
我也更可能在不同的corner下保证时序可控. 也就是 "强壮".
其实, 不用delay cell 去CTS,CTS时尽量用较少的buffer类型, 以及专门的CLK cell 等方法.
都或多或少的是为这一目的服务的.
以上是我的理解. 求指正.

balance 该需要平衡的clock 主要是为了timing修复能简单些
如果latency差的太远，inter clock timing就会很差
balance好了，就很少了，
尤其是hold，就更明显了，

学习啦！

学习了！

下面是我的一点理解，还请有PR经验的各位指正。
(其中一个观点是，CTS之后的优化，PR工具不会再动clock tree，除非ECO)
1、hold
在datapath上修hold，就只能一条一条插buffer，用更多的buffer。
在时钟树上修，可能在一个公共时钟节点插一个buffer，就可以同时修复好几条hold违例。但是动时钟树，只能ECO，要人
为去考虑在哪插buffer最划算。况且修一个寄存器的hold，还可能恶化前/后的寄存器hold slack。牵一发，动全身，这种
事情给计算机做比较合适。
所以，事先做好时钟树平衡，虽然在时钟树上的buffer要多些。但后面的hold违例要少些，小些。总的negative hold
slack少些，修复代价代价小些。
当然，如果不考虑代价多与少的差异，无论clock skew的大、小，hold总是可以修复的。
2、setup
对于快速设计，在理想时钟条件下的setup slack本来就不大。
时钟树上的偏差很容易将一个本来正的setup slack恶化成负的slack，
在data path上已经修不掉，只能在clock path上做文章，只能用ECO。
（例如帖子http://bbs.eetop.cn/thread-309533-1-1.html中提到的）
由于动时钟，会恶化前/后寄存器的setup slack，
所以ECO时钟树前，必须确认前/后寄存器的setup slack是充分的。
这都是人工的，违例一多就很麻烦，而且不一定能修复。
如果不做时钟树平衡，setup违例就可能很多，依靠ECO时钟树来修复是很麻烦的。
相反，如果事先做好时钟树平衡，就可以尽量降低clock skew 对setup slack的恶化，修复起来就容易得多。
3、CTS
由于clock tree牵一发，动全身的特性，所以CTS必须在route之前。好的CTS，更容易时序收敛。

正解，这么多答案就你说到点子上了
其他答案都忽略了一个前提，时钟慢，timing容易满足

既然在慢时钟下timing容易满足，强壮不强壮的时钟树，setup违例都几乎不存在，hold违例都是可以修复的，为什么还要优化clock skew来创造强壮的时钟树呢?
我认为跟修Hold的代价不同可能有点关系吧。从OCV的角度，skew小的clock tree因为考虑OCV而增加的hold修复代价要小于skew大的clock tree。
即使不考虑OCV，也会是这样的，正如前面所说，在clock path上修hold，比在data path上修hold会更划算。

所以，创造一个skew小的clock tree，虽然看似在clock tree上多用了buffer，但是会减少后面的hold违例。
这种减少应该会抵消clock tree上为获得小skew而增加的buffer。

修Hold插一堆Delay Cell，又浪费面积又浪费电，如果你觉得这不算什么代价那就不算吧...

很多公司ECO阶段都不允许动clock tree的

学习了

上面说的“在clock tree上修hold”,只是想换一个角度说明，事先做好clock平衡、再走线、优化的代价，要比不做clock平衡、直接走线优化的代价小。进而说明，在慢速设计中，平衡时钟树的目的是：减小修hold的总代价。

满足时序

你建个后端群吧，大家有问题去群里讨论

学习了

一般skew会作为减数出现在时序计算中，balance后能减小对slack的负面影响。但针对具体路径和具体的分析，有时需要useful skew.

学习了！

做反向的路过

学习了

学习学习