时钟树综合（Clock Tree Synthesis）一直是数字后端实现中最为重要的步骤之一。随着芯片时钟越来越多，设计阶段都采用了时钟切换电路，时钟结构越来越复杂（除了func mode外，还有test mode和mbist等模式）。针对复杂的时钟结构，想单纯依靠EAD TOOL的CTS engine来实现一个比较好的clock tree质量，几乎不太可能。而且一个比较理想的clock tree，都是要通过若干次的迭代而产生的，绝对不是你随便跑一次flow就可以的。在这里顺便强调一个观念，数字后端实现绝对不仅仅是run flow，你的价值不应该停留于此。如果你还仅仅停留在run flow这个level，劝施主早日改邪归正，呵呵。
那么，下面进入今天的主题。首先谈谈衡量时钟树质量的几大指标。
1.clock tree latency最短
clock inverter更少，clock tree上的power更小，占用更少的routing resource以及更容易timing signoff。
2. skew最小
skew对setup和hold都有影响。特别是hold，如果两个需要进行hold check的register存在较大的skew，那么hold violation就会比较大。Hold 比较大，就意味着要插比较多的buffer，有可能导致route的问题。
3. Duty Cycle
对于时钟树需要保持一个很好的duty cycle。很多IO接口像DDR，在时钟上升沿和下降沿都会采样数据，所以在clock tree上也需要一个rise delay和fall delay一致的clock inverter。
4. Uncommon path最短
由于clock tree上的common path，会有一部分CRPR补偿（考虑OCV效应）。而对于un-common path，launch 和capture都会被加上不同的derate（假设各设5%的derate），导致两个DFF的clock skew更大。
图1 common clock path and uncommon path on clock tree
5. 信号完整性
对于clock net需要设置CTS NDR (Non-Default Rule) ，比如两倍width，两倍space。这样可以有效防止crosstalk和EM。对于高频时钟信号或者对于时钟质量要求特别高的clock，我们还需要对clock net进行shielding，保证clock tree上无任何串扰（作为一个signoff来check）。
说到CTS NDR，让我感慨万千。前几天有个粉丝问了一个问题，关于为何CTO之后timing是meet的，route后timing确变差很多。当我刚看到这个问题时就觉得最大的嫌疑是检查route后clock tree上是否存在较大的crosstalk。结果发现居然NDR没设置上，clock tree上每个cell都有个5-6ps左右的crosstalk。
说这个事情呢，主要想表达两个小建议：
遇到问题一定要先自己分析，必须自己学会思考，学会debug。
PR各个阶段都干了些啥，每个阶段不同的地方是什么，这些是debug的方向。
案例分析：
下面简单介绍下三个case。通过这几个case，希望各位能够慢慢养成独立分析时钟树的能力。而且能够将项目中时钟结构不合理的points，反馈给数字前端设计工程师。因为一个不合理的时钟结构，会导致timing 收敛非常缓慢，甚至不收敛。这样的结局就是做项目大家都累得半死。
CASE1:
第一个case如图2所示。func clock和tck1通过Mux1来进行时钟切换。在图中表箭头的地方定义了一个generated_clock。当Tool在build func clock时（假设Register set2离root最远），该func clock的 longest clock path为Register set2中的某个reg的clock path。所以工具为了balance 寄存器组1，寄存器组2和寄存器组3，不得不在MUX1的输出端和寄存器组1的CLK之间垫足够多的clock inverter 。
这样似乎没有问题，但是在低速test mode下，tck1的clock latency显然太长了。因此，为了避免测试时钟的clock latency过长，我们可以复制一个MUX，使得func和test mode分别走不同的时钟路径，如图3所示。
图2 原始时钟结构图
图3 改进后的时钟结构图
case2 :
假设CK1和CK2是同步时钟。Tool在做balance时，为了节省clock buffer往往会在MUX的output到reg group2之间插入clock inverter（有些时候可以用少量的clock buffer）。这样做会有问题吗？答案是可能存在问题，即导致Reg group1，group2和group3之间的uncommon path变长，如图4中左侧所示。如果我们将MUX输出端的两个clock buffer挪到mux的D0和D1 端口上，同样可以实现各个寄存器组之间的balance。而且它们之间的common path变长了，uncommon path变短了。这样的行为对Timing是极好的。
图4 case2 优化前后的时钟树
case3: power or timing based 的时钟树综合
人生面临很多选择，我们也在不断地做出不同的选择，每个选择都是一个tradeoff的过程。同样，数字IC设计实现的结果也是数字IC设计实现工程师在不断地做tradeoff，而所达到的一个结果（PPA）。第三个case如下图5所示，留给各位思考。左右侧两种时钟树，哪种更好？他们的优缺点是什么？
其实时钟树综合并不难，关键是要理清时钟结构，搞清楚各种mode下时钟如何切换，各个时钟间的同步异步，以及哪些clock需要做inter-balance等问题。
图5 两种不同的时钟树综合策略
