我的理解：一个好的 clock tree ，max insertion delay 尽量小，common path尽量长，skew小。

大佬回答：

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，更容易时序收敛。