在PT中，如果将一个时钟create在hierarchical pin上，工具会报"UITE-136"这类warning。查看warning解释，能够看到S司建议将时钟创建到leaf pin上。（啊哈，什么是hier pin，什么又是leaf pin？）
而在CTS中更是要求时钟源必须是具有物理信息的点。通常，hierarchical pin都是不具备物理信息的，把它当成时钟源并不能准确地计算出时钟延时。因此，在B2008.09版本以前的ICC中，工具会将create在hierarchical pin上的时钟自动从CTS中exclude掉，即不对它做balance。在这种情况下，我们需要修改约束，将时钟create在leaf cell pin上。而为了减少用户手动修改约束的工作，在B2008.09版本之后，S司提供了“cts_enable_clock_at_hierarchical_pin”这个变量，该变量默认是“true”。这时为了满足前面所说的“CTS要求时钟源必须具有物理信息的点”，工具会从create时钟的hierarchical pin往回追，最终将时钟创建点挪到最前面（top-most）的buffer上。
有了上面的变量，是不是就可以在约束上为所欲为了呢？NO！之前martin就在某个项目中，因为时钟创建点的问题，导致clock skew很大，timing无法收敛，卡了超久，血的教训！下面我们回到案发现场分析一下。
下表中，除了clk_scan是在test mode对应的scenario创建的时钟，其它时钟都是在function mode对应的scenario创建的时钟，CTS采用MCMM的方式同时对两个scenario进行处理。从CTS和ROUTE的结果看，部分时钟的skew很大，尤其是clk_scan，这直接导致了后面的timing无法收敛。
查看CTS的log，发现U_pad/FDQS0_P报了CTS-561这个warning，即创建在这点的ddr_clk_320m在CTS过程中被exclude掉了，没有参与balance。
从CTS的报告中也可以看到与上面warning相符的信息：ddr_clk_320m的levels数为0，即ddr_clk后面的逻辑并没有挂到该时钟上，如下图所示。
再回去分析代码和sdc，代码中pad module实例化了整个chip需要用到的PAD，然后chip_topmodule调用了pad module。刚开始，STA owner将ddr_clk创建在了U_pad/FDQS_P这个点上如下。
再回头去检查sdc的时钟约束，发现有很多时钟都是约在hier pin上，如下图所示：
修改约束，将ddr_clk_320m创建在pad的C端，如下图所示。其它时钟也改成创建在leaf pin上，问题解决。
原因2：
工具在优化的时候，有可能会把hier pin的连接关系改掉。如下：
RTL中分频器输出是o_divider_clk，但是在最终网表中，分频器输出从o_divider_clk变成了cts_0。
如果把时钟约束在o_divider_clk上，工具会报一下error:
作者：martin
原文链接：IC小迷弟
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏。
