大家需要什么样的clocktree呢？芯片的动脉CLOCK TREE介绍-电子发烧友网

我觉得称时钟树为芯片的大动脉一点也不夸张，因为所有flipflop 翻转都要受到它的控制。而时钟树的设计到实现是一个很复杂的过程，从流程上说，它牵扯到使用的工具，流程，flow等。从人的角度讲，它需要设计，综合，dft ,pr, sta 工程师的通力合作。从知识上讲它需要一定的芯片架构设计知识，一定的综合，STA 知识，一定的dft知识，包括一定的pr 长clock tree的知识。我这里结合我的个人有限知识，结合实践经历以及理解对这些问题做多方面的阐述，难免有缺漏，也是为了抛砖引玉，欢迎同仁讨论。集思广益。

本文所涉及的工具综合DC, 时序分析PT, 物理实现工具innovus.

大家需要什么样的clocktree呢？

设计：我要更少的PLL, （更多的PLL 带来配值的麻烦，能用各种分频产生的频率。尽量用分频电路产生，能不多加PLL就不要多加。）我要没有毛刺，PLL jitter抖动更小（设计上没有毛刺需要电路结构上的改变如glitch free mux ， PLL jitter需要电路上更给力的模拟单元。）。我要更低的功耗（设计通过powerpro 添加更多的ICG 上去，ICG的效率提上去。尽量不要有组合逻辑clock gating检查。）

DFT: 我要配值更少的PLL (尽量相同频率的逻辑用一个PLL 去拉通，更多的PLL 需要更多的tdr 配值增加面积还带来不确定性）。我要更少的occ (相同频率的fanout 尽量垫一个occ，更少的occ ，更少的面积，处理起来也更简便）

SYN&PR : 我要更精准的SDC ( 更精准的SDC 去除更多的假path, 在PR SI 分析上也能过滤掉不该分析的部分，还能指导clocktree的生长）。我要更好的useful skew (需要flow，分析，try run和调整，来达到不平的clock tree 与setup hold 之间微妙的平衡）。我要更长的common path ,更短的clock tree (长的common path 更短的clocktree, 可能需要设计clock tree结构调整， sdc 的调整，ccopt spec 调整， place 调整等等）。

我要PLL 的REF CLOCK 走更短的距离（PLL ref clock 需要高的时钟质量。提前有好的规划，不要插多余的cell到ref clock 路径上，pr floorplan 的迭代控制PLL 与ref clock 的距离，综合过程不要给这种net上加东西。）。我要更小的SI (pr clock tree 布线上更好的布线层规划，良好的shielding )。我要tree更好的平衡（该balance的地方balance，不该balance的地方不要相互拖拽，需要良好的ccopt_spec， sdc ，以及setting配合。）

等等，还有很多，所有的需求都需要相互trade off 来达到一个平衡。

我以图片举例来挑其中一些问题针对的谈谈。

能不要多点长tree平衡,尽量不要多点长tree，除非迫不得已。如图从物理实现角度说绿色是一个block ，A 和B 两个clock 从port进来需要相互balance。这种结构block的PR工程师好不容易把A 和B 调的tree平衡。但是到了顶层,顶层pr工程师还需要保证红色的到A &B两个hier pin的tree路线是平衡的。对时序收敛是不友好的。

设计牵扯到从block穿clock出来到顶层的结构那么红色的这路去顶层的clock路径不要带多余的逻辑，如果有多余的逻辑分配到A 那部分去，因为绿色的地方dft要加occ, 而occ一般是不级联的。

设计中驱动两个hinst如果是同频的能用一个occ （红色）就尽量不要用两个（绿色）。造成面积浪费不说，且如果A和B再有timing talk 会导致非 common path 变长。

分频模块在功能模式下的分频系数频率与dft 模式下的分频系数尽量一致。当功能模式时候toggle fun_reset 就能让div模块配置到需要的系数上。当dft模式下toggle dft cgu reset 也能让div模块配置到相同的系数上。否则需要dft通过tdr或者其它连线来配值自己想要的参数，增加多余逻辑。不过具体情况具体分析。没有通解。

STA 工程师尽量通过良好的使用 set_clock_group -physically_exclusive -logically_exclusive -asyncronus / set_clock_exclusivity 等命令去过滤掉C 位置不应该A B共存导致的SI 分析。

多种mode sdc 能merge的尽量merge ,不能merge再具体问题具体分析。多个mode sdc会产生更多需要分析的constraint mode 产生更多scenario 耗费更多时间。举个例子类似我遇到的这种结构的clock 就是相对不那么好做的 A B C三个mux会从ip上去选clock。而且A B C之间相互还需要balance, 那么就是2 *2 *2 = 8 种可能性。关键是这8种可能性在真实情况下可能只有5种是真实会产生的。

你如果只通过create_clock create_generated_clock set_clock_group set_false_path 方式来做，那么就会产生过约，因为会额外约束多余那3种可能性，如果我通过给mux sel set_case_analysis 来case的话那么就会产生更多的sdc mode，更多的view.事实上当时这种类似mode有好几十种情况。

合理的使用set_clock_sense set_sense.应用场景有时会有个A clock 高频clock和B clock 低频clock 经过mux去驱动后面的A INST 与B INST, 真实情况是可能B clock 只会打到A INST 模块进行搬运数据，比如芯片boot阶段。它不会去B INST 那么一定要用set_sense 去把B clock在B INST 前面停掉，这有利于timing分析也有利于PR 进行长clock tree。默认情况下innovus create ccopt spec 会转换 set_sense /set_clock_sense 为 set_ccopt_property -sink_type igore [get_pin xxx] 这样对于B clock 来说B INST 里面的sink点就不会被balance 。去掉不该balance的 sink点自然tree就会更好。

合理利用useful skew ECF/ccd 真实的设计中clock是不可能长的完全平的。那么可以通过useful skew 来达到data clock setup&hold 微妙的平衡。

通过分析DC 的timing报告人为通过set_clock_latency -clock xxx [get_pins xxxx]去调整clock tree 长度，让DC按照不平的clock tree 长度进行优化。进入INNOVUS的时候 INNOVUS create_ccopt_spec 会转换set_clock_latency 命令为

set_ccopt_property -insertion_delay xxx [get_pins xxxx] 来调整clock tree长度，达到更好的平衡。

或者在DC 中开启ccd ，通过write_scripts 写出工具根据组合逻辑和你的设置推出来的tree长度脚本set_clock_latency -offset ，通过脚本转换set_clock_latency -offset 为标准set_clock_latency -clock xxx [get_pins xxx] SDC ，进入INNOVUS 优化。

或者INNOVUS 删除set_clock_latency 开启Cadence 自己的useful skew ECF 来自动进行不平clock tree优化。

至于结果，不好说，不同设计反映不一，推的过多会导致hold难修。当然Synopsys会推荐DC 可以开hold corner 然后来估计hold的影响，让推的不要太凶。

针对这种结构一个M clock驱动两坨逻辑红色和上面黑色。

通常做法是整一个M 整一个GCLK G1 GCLK G2 然后设置clock_group 来解决。

不要尝试直接在G2 位置create一个master clk，然后设置clock_group

这种会导致G2 前面的source latency 丢失，导致无法分析前面路径的延时SI 等影响，也不能用来signoff

但是这种类型的SDC 用来INNOVUS ccopt 来长clock tree是极好的。尤其是当你不怎么熟悉innovus的ccopt spec ，但是你又很熟悉sdc和clock结构的时候。

innovus默认create的spec就不会balance 红色和蓝色因为你的G2 地方的create的是一个master_clock

当然别忘了update_constraint update回来，更别忘了手动call update_io_latency/set_propagate_clock 来propagated clock 否则你长完tree你的clock还是ideal的。

最后强调一点，默认innovus create ccopt spec 是不识别sdc里面的 clock_group , false_path 的，它只根据你的clock 物理连接结构走。当然有setting可以让create ccopt spec去识别 clock_group 和false_path ,但是只是大家都不这么做而已。具体原因可能是工具不完善吧，也有可能是这样创建的spec 文件太大，或者太多的这种ccopt的设置会导致不期望的结果之类的。

着重注意IP 位置的clock ,有的情况是一个ip是liberty ,internal pin会打数据 D 出来同时这个internalpin又会打clock出来 IP 外面会有flipflop来接数据，这种path由于launch clock 无法调整。导致timing不好收敛。

或者是这种IP 作为liberty internal pin会打clock出来给flipflop launch 然后再用这个internalpin到IP 边界上去check。这种由于capture clock 没法控制同样不好收敛。

针对这种情况及时syn pr，联系vendor 与设计，确认路径的正确。设计能retime flipflop 多次打拍就提前做。方便timing收敛。

PR 尽量和dft以及sdc owner多沟通。了解dft test_clock sdc里面是怎么下的。通常情况test_clock 会通过不同的occ去trigger 几乎所有的flipflop 。一般情况下dft 穿chain是分clock domain 穿的。也就是各个occ是相互不check的。当你的pr sdc为了简便下的比较粗的情况比如一个create 一个test_clock 完事，没有在各个occ上做test_clock的分开处理。那么建议在ccopt spec里面把test_clock skew group 设置成none不要让它去balance。否则它会退拽整个设计的tree。