自动时钟树ECO解决方案
相信大家在route之后，都有过手工ECO的经历。目前，对于45nm的工艺而言，方法不外乎有换BUFFER, 高层金属走线，多倍线宽、线间距，时钟树偏移，以及BUFFER换INV等方法。
这次，我主要与大家分享的是，我在做自动时钟树偏移脚本时的心得。
众所周知，usefulskew一般是修timing的最后一步才用的手段。但只要对关键路径的前后级进行过分析，就不难发现，Encounter并没有将前后级空余完全利用上，或者说没有最大程度上平衡前后级的Slack。因此，才有了人工做时钟树ECO的需求。
人工修CTS，主要原理并不复杂，基本上就是在时钟路径上插BUFFER，把时钟路径延时增加，以达到时钟借用的目的。
但实际操作中，则会遇到各种各样问题：，
1，如果只对单一路径插入BUFFER，则会造成标准单元浪费。因为，很多关键路径的时钟路径，有公共部分，对于公共路径操作，可以一次修许多条，还不会带来额外的BUFFER数量。另外，如果做的ECO数量多了，只对单一路径插入BUFFER，会造成标准单元拥塞，而修得少，又达不到timing收敛的目的。
2，如果是对公共路径进行插入BUFFER的操作，则会出现各路径后续slack富余不同的情况。如果按最大的借，往往会使别的路径恶化，如果按最小的借，关键路径所获得的好处又有限。这就成为了一个两难的选择。
3，对于插入BUFFER数量的估算，是个难点。举个例子，如果一个CKBUFFER的延时是20ps左右，你将其插入时钟路径后，并不一定会带来20ps的时钟借用。举例来说，如果是插入长线之间，反而会加快时钟路径，导致时序进一步恶化。而根据你插入的地点不同，时序的变化结果也不相同，这就造成了，即使你知道要借80ps，却估不出要插入多少级BUFFER。
针对以上三个问题，结合我在工作中编写ECO脚本的经验，我用了以下方案实现时钟树自动借用。
整体分为 五步：
第一步，通过对时序报告的分析，提取出关键路径中，时钟路径中最靠近寄存器的那根net的名字。并提取出，该级的slack，终点reg名，以及该net的fanout。
第二步，用encounter中的DB命令和report命令，得出与该NET所接的所有reg的名字，并将这些reg的最大的后一级slack报出来。
第三步，粗略计算出，需要插入的buffer数量。
第四步，进行ECO操作。（之后返回第一步，迭代1-2遍）
第五步，对于最后2%左右的路径。提取其最后一根NET的两个term名字，对单一路径进行ECO操作。迭代两遍。
时钟树自动ECO脚本的操作基本完成。
下面，我对这几个步骤进行一下说明。
首先，我选取最后一级NET，是希望，操作针对公共路径进行，但要尽量减少需要同时考虑的公共路径数量，提升脚本可操作性。
其次，迭代多遍，是因为，对于同一条线，插入第一个BUFFER，对于时钟的影响是不确定的。但插入后，以后再插入的buffer，由于驱动以达到饱和，因此，每多插入一级buffer，时钟路径都会稳定的增加相应的延迟。因此，迭代2-3遍，所估算的BUFFER插入数量就变得比较精确了。
最后，对于少量的关键路径。采用对公共的借用已然达不到要求，这时，就在该路径的时钟路径的非公共部分，进行ECO操作。因为，这类操作
需要插入的buffer数量较多，因此，只对1-2%操作，才不容易造成标准单元拥塞。
此外，首次迭代，我建议设置一个ECObuffer插入的最大数量，例如，我设置是5，这样，可以防止时钟树借用过大，造成的后续问题。比如hold等等。
最后说一下实现：
在提取参数阶段，我推荐使用perl语言编写，perl对大量文本的查找，提取和生成报表，效率比tcl要好一些。
在需要跟ENCOUNTER进行交互部分的脚本，还是用tcl编写比较好，这样实现起来比较容易。
最后给出一个初步BUFFER数量的运算公式：数量= （后一级最大slack - 当前一级最大slack）/ 一个buffer的延迟。
好了，这次的分享基本到这里，希望能对各位同事有所帮助。
大家如果有什么问题，或者有更好的方案，请告诉我哦，谢谢大家啦。
写这么多不容易，加分了
小编的方案很适用，不过编写出这样智能的脚本恐怕要费些力气啊，通常都是眼睛观察，分析，尝试ECO。
小编已经写出这样的pl ，tcl脚本了吗?
这个要顶一下
小编！
i know who you are...
有空去你们那儿交流...
乖乖，这么复杂， 可以写个脚本卖给公司了，
真的可以，
这个脚本已经写完了，调试也通过了。
效果还是很明显的，在我的设计中，能将slack从-92ps修到-12ps
其实复杂度还可以，写脚本都是熟能生巧的功夫。
原理搞定，实现起来，也不是太难。
4个嵌套脚本工程量大概也就1000行左右吧，编写用3天时间。
不过迭代调试，用了4天多。（主要是实验一些参数）
如果大家写得时候，遇到什么问题，可以问我哦。
学习了！
这么看来， icc 的 skew_opt就幸福的多了
谢谢分享！
赞一下lz写脚本的耐心！
学习了！真希望也可以有机会写些类似的script
原来是师兄啊，绝对要顶的~
不错，谢谢
最近也要用perl时钟树的自动调节，比小编的简单些，不过现在还没思路，望小编不吝赐教！
是这样的：有8个tile，每个人tile里面有三级buffer，8路时钟输入/输出，
也就是说每个tile共有24个buffer；每个tile要连接到PLB单元，要求clk从
tile的输入到每个PLB的延迟相同，也就是，clk到达PLB要经过的buffer的级
数相同，最终要生成每个tile的网表，要用perl实现！
这篇写的很精采
请问一下
(1)如何
"通过对时序报告的分析，提取出关键路径中",可以多描述一些吗?
(2)每插入一个buffer，就会update timing吗?
ICC的这个命令也很有限啊，手动修改时钟树的时序问题有些时候还是很必要的。我以前也修改过，不过插完buffer后发现另一条路径又有时序问题了（估计插到公共路径上去了）。个人觉得这个还是很考经验的啊
另外，小弟想问一下，为什么buffer加到长线上反而会让延时变短呢?仅仅是因为buffer驱动能力增强了吗?但是这个并不能决定时延呀
插入buffer之所以能够减小时延，是比较相对于没插buffer之前的，插入buffer之后，相当于把线变短，变短之后，总的延迟再加上buffer的延迟会小于没插buffer之前的总的延时，这种结果的前提是在深亚微米工艺中。 个人是这样理解的，仅供参考
牛～～受教了
谢谢啊····长见识了
都是大牛啊
学习了！
原来是西西
对长线来说,能把delay 变小要看buffer上的delay能不能减下来,线上的RC固定, 那么delay ~ RC 是确定的,插入buffer并不能减小线上的delay, 但是可能对buffer 内部的delay 有改善.
牛人一个...
看来要学习perl了
类似脚本我当年也写过。脚本应用起来看着确实爽，一次遍历所有能推的地方，包括时序反馈环路，最大嵌套500层循环，结果TNS下降非常明显。但是如果design做的好，WNS有时候其实降不了多少，毕竟关键路径在那里挡着，能推时钟早就推了，不会等到这会。比如在模块级，你不能牺牲太多边界上面的时序，因为顶层要留有余量。另外，如果在DC阶段就用这种方案，其实网表质量就烂了。所以这种方法在修时序的后期可以用用。如果大面积violation不要指望这方法能搞定
佩服佩服！值得学习！
know this?
请问有脚本吗?