当前位置：首页 > news >正文

数字IC后端实现教程| Clock Gating相关clock tree案例解析

news 来源：原创 2025/5/16 17:12:46

今天小编给大家分享几个跟时钟树综合，clock tree相关的典型问题。

数字IC后端设计实现之分段长clock tree经典案例

Q1:星主好，下面的图是通过duplicate icg来解setup违例的示意图。我没看懂这个 duplicate操作在cts阶段是怎么实现的，用什么命令实现的吗？为什么复制成5个icg之后，capture clk上的buffer会变多，然后就timing met了？

数字IC后端专家必备知识体系
在这里插入图片描述

Innovus PR实现阶段可以通过下面的命令来复制或合并clock gating cell。

set_ccopt_property ccopt_merge_clock_gates true
set_ccopt_property cts_merge_clock_gates true
set_ccopt_property ccopt_merge_clock_logic true
set_ccopt_property cts_merge_clock_logic true
set_ccopt_property merge_clock_gates true
set_ccopt_property merge_clock_logic true
set_ccopt_property clone_clock_gates true
set_ccopt_property clone_clock_logic true

复制其他4路ICG后，每路ICG都可以摆放靠近各自控制的寄存器。所以等效于clock gating cell会被摆放至靠近leaf端。这样实现的结果是对我们的setup timing是有利的（power gating的效果要差）。

如果觉得这个case还不够直观，我们可以来看看咱们社区低功耗四核A7 Top Hierarchical Flow实现项目中的一个案例。

从下图所示的clock tree structure报告，我们可以知道每个ICG会控制四个memory的时钟开关。如果把这四个memory分别摆放至芯片中的不同位置（距离相差较大），我们会发现下图框选出来的clock gating cell会被摆放至靠近root端。

在这里插入图片描述

对应到layout上我们可以高亮出这四颗memory和clock gating cell，具体如下图所示。这样的实现结果比较容易出现到clock gating cell使能端的setup violation。

在这里插入图片描述

Innovus clock tree spec文件解析

Q2:请问星主和大家ccopt_design 的时间特别长，到现在已经跑了十天了，有什么方法可以减少run的时间吗？

这又是一个老生常谈的问题了。时钟树综合CTS跑不出来，到底应该怎么debug？这个问题小编至少讲5年了！问题一定出在时钟树综合的clock balance阶段。

在这里插入图片描述

首先我们来看看这位会员在CTS阶段的绕线信息。clock net routing drc数量高达两百多万！这个数字要是年终奖该有多好！而我们知道这个阶段信号线完全都还没有走线呢？仅仅走clock net routing都能有这么多drc，是不是有点不给面子？

在这里插入图片描述

再进一步来看看cts log中clustering步骤做完的各个clock tree长度。从下图中我们可以清晰看到从Macphy到Mac controller的clock tree长度高达24.3ns!（其他clock tree也有十几ns的长度）小编13年的后端从业生涯还没做过这么长的clock tree！

在这里插入图片描述

在实际soc芯片实现中，我们还会经常遇到如下所示的case。clock mux的一个输入端是经过DLL的场景，此时工具做CLK的clock tree时会把mux的几个输入时钟做clock balance，最终也是跑不出cts结果的。

在这里插入图片描述

所以，遇到这种情况，我们需要先做cts阶段的clustering步骤，找到上述24.3ns的那路clock path，并定位到真正有问题的点。

set_ccopt_property -balance_mode cluster
ccopt_design -cts

当然，对于一个合理的数字IC后端工程师，我们还是建议大家拿到一个design后要认真去trace设计的时钟结构，并画出整体时钟结构图。

在这里插入图片描述

Q3:星主，我看了你的有关门控的主题，你通常设置set_clock_gating_check -setup 0.25，我目前的项目发现门控setup违反较大，在PT(PrimeTime)中setup为-0.6以上，因些我把这个值设为0.6,结果发现Place时门控的时序好一点，但CTS阶段时序变得比设置为0.25时还差，请问一下，这个值设置的依据是什么?

ICG的全称是Integrated Clock Gating。目前的芯片实现都是使用这种集成的时钟门控单元。之所以加ICG的目的是对设计中暂时不用的寄存器通过ICG来关断后面寄存器的时钟Clock来实现低功耗设计的目的。

Place阶段由于clock还是ideal的，此时Latency1=Latency2=Latency3=0 (默认情况不偷timing的情况下)。所以这个阶段其实不一定能看到ICG EN pin的setup violation。

在时钟树综合CTS阶段，ICG的时钟端ECK是non-stop pin或者说是Through pin，所以此时ICG的clock tree长度一定比其他寄存器的clock latency要短。至于短多少取决于ICG在clock tree中的位置。

如果ICG是靠近sink端（也叫leaf端），那么ICG的clock latency就会越接近其他寄存器的latency，这样setup就不容易会有violation。相反，如果ICG是靠近clock root，那么ICG的latency和寄存器latency的差值就会比较大，这时候就非常容易有setup violation。

在这里插入图片描述

此时有三个关键点，需要牢记！

1）Latency1约等于Latency3
2）Latency2小于Latency3
3）ICG Downstream Latency(ICG到寄存器这段的clock latency)约等于Latency1-Latency2

在这里插入图片描述

所以，长tree后ICG的latency并不再是约等于寄存器的Latency（Place阶段是相等的）。这样就会出现原来在place阶段ICG EN pin的timing是meet的，但此时经常会有很大的timing violation的情况。

为了解决placement（preCTS）阶段和CTS后的timing不一致性问题，我们主要采取以下几种方法:

1）设置更大的clock gating check

工艺库lib中有个clock gating check值的二维查找表。我们在place阶段设置一个比lib中更大的set_clock_gating_check约束是为了让工具提前把这类path的data path logic优化到位！

在这里插入图片描述

2）使用Early Clock Flow
在place阶段使用Early Clock Flow后我们可以从时序报告上看到工具会给ICG/CK反标一个负的delay值，这个跟长clock tree后的情况就比较match了。

在这里插入图片描述

3）控制clock gating的fanout

4）Manual Place Clock Gating cell和它的fanout

Q4:星主，请教一个问题，就是我现在这个block的timing有风险，然后根据place结果设置insertion delay到cto后仍然没做干净，但是前后余量都是够的。我一般是过约slack的30ps，但是工具还是没做干净，效果可能只有一半左右，我是继续加大过约的量还是后面到pt手动在tree上加ck inv来解呢。星主一版遇到类似情况是如何解决的，或者我就什么也不干预，等到pt，用pt的结果回到cts调一版tree?

在这里插入图片描述