最近在咱们社区复杂时钟设计的时钟树综合训练营中发现很多同学对clock tree质量的debug分析和案例都特别感兴趣。社区很多读者都是2018年的老读者了（分享数字后端技术经验已经快7周年了），为了感谢大家一如既然的支持和鼓励，今天小编给大家分享几个SoC芯片中典型的时钟树综合的案例，分析常见几种clock tree长度太长的原因及解决方案，希望对大家的学习和工作带来一些帮助。

案例一：Clock Net Detour

由于同一个clock domain或同一个skew group的sink点都是要做clock balance的。如果某个sink点的clock path出现比较严重的detour，那么它会直接影响其他clock分支的clock tree insertion delay。

出现这个问题通常是由于局部区域存在congestion，所以遇到这种情况，大概率需要调整模块的分布位置来解决。而且这种情况通常也会表现为在clock clustering阶段的clock tree长度要远小于clock routing后的长度。

数字IC后端实现之Innovus specifyCellEdgeSpacing和ICC2 set_placement_spacing_rule的应用

数字IC后端时钟树综合专题（OCC电路案例分享）

案例二：Channeless设计Long CTS Delay Chain

这是一个channeless的design。当我们从cts的log或Clock Tree Debugger（CTD）中发现某路clock path delay特别大，我们可以通过ctd_trace或GUI来快速定位有问题的点。

这个案例出现的问题是CTS engine在做early global route时发现这条clock path只能沿着各个模块的边界处来长clock inverter tree。

出现这种情况我们可以在core区域预留一条小通道给这类clock path来长clock tree。甚至还可以通过添加clock guide buffer来引导工具做出我们想要的clock tree。

当然，在实际后端项目中类似的问题也有可能是某条clock path上的clock logic cell被摆放至几个模块的不同channel处导致的。

数字IC后端实现时钟树综合系列教程 | Clock Tree，Clock Skew Group之间的区别和联系

案例三：clock logic cell摆放不合理

从这个案例我们可以看到工具做完clustering后大部分sink的时钟长度是1.6ns。而且我们发现有一个sink点的长度高达2.45ns。

所以需要把这路的clock tree长度做短。经过进一步分析发现这路clock path存在兜圈的情况，注意这里不是routing detour，而是clock tree上的clock logic cell存在一些摆放不合理的cell，而且这些cell是被fixed的状态。

所以解决方法是通过分析这路clock tree的时钟结构，把需要摆放的clock cell摆放到合理的位置即可。

又比如下面这个案例最终clock tree insertion delay比较大的原因也是因为某个clock path分支上的clock gating cell摆放不合理导致的。

这个情况在咱们社区第一期复杂时钟结构clock gen的时钟树综合训练营中也有学员遇到过。因为小编教过大家我们可以通过manual place clock tree上的主要逻辑来进一步把clock tree长度做短的方法。但是在完全画出时钟结构图，理清楚时钟的走向，这样做可能会弄巧成拙。

所以，这方面的技能必须通过多加练习，通过几个这样的项目练习就可以实现从入门到精通的目的。

比如在咱们项目中，如下所示的clock gating cell如果被fix在图中红色圈圈处，那么左侧这个memory的clock tree长度就会长很多。这个分支一旦做长了，同一个clock skew group下的sink点就会跟着做长。

而clock tree长度越长是越不利于setup和hold的（OCV效应）。

Clock Skew和Clock Tree长度太大怎么破？

案例四：Non-Clock Aware Placement

在这个案例中展示的是在PR实现时没有做clock aware placement导致的ICG的各个fanout比较分散的情况。

当然，如果我们在对其中位于左上角那部分sink点的时钟net做了dont touch处理，也会直接带来整体clock tree做得比较长。

所以，当我们某一段tree没有长出来的时候，我们需要重点检查下面几个方面。

1）是否create_clock？
2）是否对net设置dont_touch？
3）clock tree上cell的sink_type类型是否正确？*

大家发现没有，上述这几个案例我们都是通过分析发现clock path太长了才去想办法解决。只能说具备这方面分析问题和解决问题的能力只能算达到及格线。

真正的高手一定是从时钟结构出发，制定合理的长clock tree策略，在画出时钟结构图后就可以把clock tree漏tree，clock tree不balance，clock tree长度太长等一系列问题提前规避掉。

PS:想要把clock tree做到最短，分段长tree的方法是必备方法！想系统学习分析时钟结构，掌握分段长tree思想，分段sdc编写等实战技能，可以私信咨询小编的复杂时钟设计的时钟树综合课程。

大家可以拿小编2019年写的OCC这个时钟结构的设计来理解分段长Clock Tree的核心思想。

数字IC后端时钟树综合专题（OCC电路案例分享）

最后分享SoC芯片中几个典型复杂时钟结构的设计给大家。

Case1: SoC芯片标准时钟产生电路clock gen

Case2: STM32时钟系统

Case3: Clock Delay Mux

Case4: 特殊clock + data balance需求

Case5: DDRPHY内部reg如何和Memory Controller DFI相关接口寄存器做balance?SoC top上从PLL输出到Divder Free这部分clock tree应该怎么长？