ICC时钟树最小优化探讨
http://bbs.smic-asic.com/read.php?tid=187&fid=34
点我
随着片上系统功能完整性提升，工艺节点提高，时钟树最小优化日益变得重要。在建立时间违例检查时，如设set_timing_derate –early 0.95; set_timing_derate –late 1.0，时钟频率800MHz，发送和捕捉时钟长度都为10ns，那么两者中较长时钟产生500ps的时钟不稳定性，对时序检查影响较大。所以，时钟结构最小化显得尤为重要。以下探讨了三种时钟树问题。
1.0端口斜率问题
片上系统中，时钟穿过端口单元非常正常。端口单元上下沿斜率一般会存在较大的差异，这种差异会贯穿时钟网络中，导致较大的上下沿偏移。时钟综合引擎做时钟结构时为了平衡上下沿，会插入冗余的缓冲器或反向器，这会形成较长时钟树结构。
如果将时钟定义在端口单元输出口，工具将看不到端口单元上下沿斜率差异，不会插入冗余缓冲器或反向器，从而规避这种问题。
2.0高负载时钟接口问题
在宏模块时钟输入口，一般有较高负载。它由内部电容和外部耦合电容两部分组成。外部耦合电容大小取决于时钟接口形状和耦合信号线。小形状接口耦合电容较小，一般可以忽略。但当宏单元接口以外区域存在绕线阻止向导，ICC抽取寄生参数时会将绕线阻止向导当成虚拟信号线，且等价于宽金属线，此时抽取的外部耦合电容非常悲观。时钟综合引擎第一步为了修正最大电容违例，会在宏接口插入过多缓冲器或反向器，直至修正最大电容违例或缓冲级数达到最高。时钟综合第二步为平衡时钟树长度，工具在其他时钟分支插入过多缓冲或反向器以平衡宏单元时钟长度，这造成过长的时钟树结构。为避免此问题，可在宏单元时钟口插入一缓冲器，在缓冲器输入口设一浮点值，该值为此缓冲器及后续逻辑延时。这就可规避由于绕线阻止向导引起的高负载时钟接口问题。
3.0多时钟域选择端口处理
多时钟域结构中，异步时钟树不需做平。但往往存在这种现象，几个异步时钟经过时钟选择不同输入口，传到一公共路径上。
如上图，公共路径时长1.2ns，test_clk剩余时钟长度为2.5ns，cpu_clk剩余时钟长度为1.1ns。为平衡test_clk时钟树，工具在公共路径插入0.8ns，选择器A1接口插入0.5ns。此后为了平衡cpu_clk时钟树，需在cpu_clk时钟分支插入0.9ns。本来只需在cpu_clk时钟上插入0.1ns，而此时插入了0.9ns，时钟被拖长。
为防止此现象，可对选择器做如下处理：选择器选择端口设常态0，在A1端设浮点值1.2，那么ICC会在cpu_clk时钟分支插入0.1ns延迟，在A1端插入1.3ns延迟。这既平衡了两个时钟，又防止了某个时钟树被拖长。
以上分析了三种情况下对时钟的处理方式。时钟树长短直接影响设计质量，我们需要加强时钟树最小化方法性的探究。Layout大牛Leesa在此抛砖引玉，请小伙伴们畅所欲言。 你认为：
1、ICC工具中不同的时钟域综合是否有相互影响?
2、用缓冲器和反相器综合时钟树分别有什么好处和弊端?
3、如果将时钟定义在hierarchy pin上对时钟树的最小化是否有影响?
很久没来EETOP了，从别的论坛转一个过来，和大家分享。
本文不见得是完全准确的，大家试着来提提问题。
文章好长啊，看完我再回，
lulu~，3.0 那个问题，为什么预先会有公共路径时长1.2ns，test_clk剩余时钟长度为2.5ns，cpu_clk剩余时钟长度为1.1ns，是因为没有对MUX 设置case吗?我的理解是MUX 先设置0， 先做cpu_clk domain的cts， 完成后对clock treeset dont touch。 再MUX 设置为1， 做test_clk domain 的cts。 这样是否ok?
VV，厉害啊。 其实我发这个帖子是想表达，文中的问题本身就可以避免的。
传统的CTS策略，对于这种结构，一般采用2-pass方案，正如你所说。
不过Cadence CCOPT的CTS引擎——iCTS，可以直接处理这种，甚至更加复杂的时钟树结构。
我最近在写一个小帖子，还要等公司的批准才能发。
到时候学习一下，虽然我们不用EDI
thanks
东西不错。谢谢