时钟树综合篇(持续更新)

我们都知道想要做好时钟树综合，需要事先了解设计的时钟结构，然后才能有时钟树综合的策略，最后写工具认识的约束来guide工具做好时钟树。

那么当你拿到一个design，你应该如何入手呢？

可以从RTL来trace，一般都会有个clock gen的module，直接看这部分即可。

可以利用DC或verdi trace时钟结构。

了解清楚设计的时钟结构后就可以画出整个设计的时钟结构图，这幅图一定要深深刻在脑海里。一方面是它可以帮你理清各种时钟的走向，另外一方面可以高效协助你debug 时钟树质量。

有了时钟结构图后，就可以开始编写时钟约束文件。这个文件主要包含以下内容：

具体命令其实大家不用去背，关键是要搞清楚这些概念，比如每个命令的作用是什么？什么时候用ignore pin？为何要设置clock sense？

那到底是要定义create_clock还是create_generated_clock？它取决于你的timing需要。如果分频点要与后面的reg进行交互，那么generated clock更为恰当。默认情况generated clock会和master clock做balance。

对于使用hierarchical flow的同步设计，做top tree时需要考虑子模块内部的tree。另外对于高频时钟需要格外注意主干时钟路径上的crosstalk，通常需要做shielding处理来最大限度减少其对timing的影响。

对clock做shielding处理，有何利弊？

时钟树综合默认是从时钟树是从root开始长，比如这位星友所说的clock port开始直至该clock domain下的sink。但很多时候由于时钟结构上有很多的mux，即各种时钟切来切去，工具默认做tree可能会把整体的tree做的比较长。

为了让工具做出更好的时钟树质量，往往会采用分段长tree的方法来做，即在mux的输出端定义时钟，而mux的输入端设floating或ignore pin。

但记住cts阶段是不负责做propgated的，这个工作是后续timing优化时要做的。因此，如果CTS阶段将两个原本是同步的分支通过create_clock来做tree，那post-cts后可能会出现比较大的timing violation。