企业官网建设流程全解析

每次跑完place和CTS，我打开时序报告的姿势，基本都是先深吸一口气。不是因为怕看到violation——数字IC后端工程师谁没见过成百上千条violation——而是怕看到那种“在PR工具里明明还有余量、到PT一签核全是红”的诡异差异。曾经我花了两周时间追一条hold path，最后发现里面根本没有setup或者hold的计算错误，而是Delta Delay和Timing Window这两个变量把整条路径的时序结论“平移”了几十皮秒。从那天起，我就意识到，做后端如果只懂得看slack数值，不搞懂这两个影子变量是怎么产生的、怎么参与分析的，时序收敛基本就是在靠运气。

这个“后端”跟网上那些Java后端、Spring Boot后端完全是两回事。芯片后端是物理实现后端，要负责把逻辑网表变成可以流片的版图，而时序分析是这个环节里最硬的一块骨头。下面这篇总结，我想把Delta Delay和Timing Window从概念到实操、从计算逻辑到修复手段完整拆一遍，特别是那些在不同分析模式下容易让人翻车的差异点，希望能给正在做PR、STA或者刚转入物理实现方向的工程师一些参考。

1. 先把两个“影子变量”的区别钉死

1.1 Delta Delay到底是什么

Delta Delay，叫法很多，有的叫delay change，有的叫crosstalk-induced delay variation。它的本质是：在一个网络(net)上的信号跳变过程中，相邻网络的耦合电容通过电荷注入改变了这个网络的充放电速率，导致信号到达翻转阈值的时间发生了变化，这个变化量就是Delta Delay。

可以类比成两辆车并排在高速上开，中间隔着一条很窄的隔离带。你本来匀速加速，旁边一辆车突然从对面方向冲过来，气流会把你往一边顶一下，你的速度就会瞬间变快或变慢。这一下“气流扰动”造成的时间差，就是Delta Delay。数字芯片里的耦合电容就相当于那条隔离带上传递的气流。

具体到STA里，Delta Delay分为两类：

• 一类是正向Delta Delay（delay derating），即aggressor与victim同向翻转，耦合电容帮助victim更快跳变，延迟变小。
• 另一类是反向Delta Delay，即aggressor与victim反向翻转，耦合电容拖着victim的反向充放电，延迟变大。

在先进工艺中，信号沿越陡、耦合电容越大、victim的驱动能力越弱，Delta Delay越明显。最坏情况下，它能把一条原本满足时序要求的路径直接拉红。

1.2 Timing Window到底在划什么范围

Timing Window，也经常写成timing window / switching window，描述的是“某个节点上的信号翻转可能发生的时间区间”。为什么要用“可能”？因为在芯片工作时，一个节点的跳变不是固定发生在某一时刻的，它会受到PVT、输入矢量、拥塞、串扰等因素的共同影响，信号可能早一点到达，也可能晚一点到达。

STA按照early mode和late mode两条路径分别计算到达时间（arrival time），于是每个节点都有两个边界：最早到达时间和最晚到达时间。Timing Window就是由这两个边界定义的一个时间区间。

如果只用一句话解释，那就是：Timing Window回答的是“这条线在什么时候会动”这个问题。这个问题在串扰分析里极其关键，因为一个aggressor只有在victim也在翻转的时候互相重叠，才可能产生明显的Delta Delay。假如victim在时刻10ns翻转，aggressor在时刻5ns就翻完了，两者在时间上压根没有交集，那么即便它们空间上靠得很近，也不会产生时序上的耦合影响。

1.3 两者之间为什么总是“纠缠不清”

很多人一开始容易把这两个概念混在一起，原因在于它们总是出现在同一个SI分析流程里。Delta Delay计算的时候要考虑Timing Window，而Timing Window推演的过程中又要考虑串扰引起的延迟变化。两者互为输入输出，形成了一个复杂的耦合系统。

我的理解方式是这样的：

• Delta Delay是串扰的“结果量”，描述的是victim延迟被干扰后的净变化，属于输出。
• Timing Window是串扰的“判断条件”，用来决定哪些aggressor在时间维度上会对victim构成威胁，属于前置输入。

打个比方：Timing Window像是一张“哪些时间段会有车经过”的班次表，Delta Delay则是“真的会遇到会车时，车速被影响了多少”。你不会在没有班次重叠的情况下纠结会车影响，同样，在Timing Window不重叠时，谈Delta Delay是没有意义的。

2. Delta Delay的来源拆解：从库表到物理网表

2.1 单元延迟建模：NLDM与CCS/ECSM的分水岭

想要深刻理解Delta Delay，先得知道单元延迟是怎么算出来的。传统上，标准单元库使用NLDM（Non-Linear Delay Model）来建模延迟。NLDM把每个单元的延迟与输入transition time、输出load capacitance关系做成二维查找表，通过查表插值得到延迟。这个模型计算快速、运行高效，但它本质上假设了单元输出波形是一个理想化的一阶RC响应。

问题来了：在先进工艺下，输入波形不再是好看的单调斜线，输出负载也不再是单纯的电容，NLDM的一阶近似已经扛不住串扰和波形畸变带来的误差。于是后来的库开始采用CCS（Composite Current Source）或ECSM（Effective Current Source Model）模型，用电流源加输出波形的方式描述单元行为。

CCS/ECSM的好处在于，它能够更准确地建模输出波形的非线性，也能够更真实地反映外部噪声对输出延迟的影响。当你打开SI分析开关，让工具计算Delta Delay时，使用CCS/ECSM模型的库通常能给出比NLDM更贴近硅实测的结果。这也是后端flow里一个容易忽略的细节：如果你的库里明明支持CCS，却为了压缩运行时间把库降级为NLDM，那Delta Delay的分析精度会明显下降，时序收敛后冒出来的问题会非常难排查。

2.2 线延迟、耦合电容与金属层的关系

线延迟是Delta Delay的另一半源头。一段net上的延迟可以拆成两部分：一部分是self capacitance（对地电容）带来的延迟，另一层是coupling capacitance（耦合电容）带来的延迟。在先进工艺中，coupling capacitance往往会占据总电容的60%甚至更高，这就是为什么线延迟对串扰如此敏感。

具体到金属层，越往上层走的线，间距越大、线宽越宽、线高也越高，对应的侧向耦合电容占比通常有所不同。底层金属因为更细更密，coupling占比同样不低。后端绕线时，如果两条长距离并行线恰好走在相邻层并且重叠较长，它们之间的耦合电容就会相当可观。

还有一点：via的影响。信号线换层之后，via产生的电阻和电容会叠加到整条路径上。via数量越多，路径上的RC散落点越多，Delta Delay被放大的概率越大。这也是在优化长走线时，我们尽量少绕线、少换层的物理原因之一。

2.3 OCV derate和Delta Delay叠加时的坑

时序签核的时候，绝大多数团队都会做OCV（on-chip variation）处理，常见做法是设置timing derate。比如：

# 在PrimeTime/Tempus中设置derate set_timing_derate -early 0.95 set_timing_derate -late 1.05

这个derate是在原始路径延迟基础上乘以一个系数，用来模拟片上偏差。问题是，Delta Delay作为“额外增加的延迟或减少的延迟”，在STA工具里通常是在derate之后再叠加的。这就导致了一个比较隐蔽的坑：

• late path上，如果Delta Delay让路径变慢，那么它不仅要算上自身的变慢量，还被derate进一步放大。
• early path上，如果Delta Delay让路径变快，它同样会被early mode的derate系数再压缩一次。

所以如果你的设计里本身SI噪声严重，你又额外加了激进的高derate系数，时序报告会同时把两边的余量都吃掉。有些团队一看到setup大量违例就拼命拉大derate，结果越修越乱，其实问题源头在最基础的SI分析上。

2.4 工具里怎么把Delta Delay“看”出来

PrimeTime/Tempus中，打开SI delta delay分析通常需要配置set_si_options这类命令。让我给一个常见的查询思路：

# 打开SI分析中的delta delay计算 set_si_options -delta_delay true # 在report_timing时同时报出delta delay分量 report_timing -delay_type max -si_delta_delay yes

Innovus里面查看noise/si问题的方法也很多，常用的是：

report_noise -violating

这里必须提醒一句：不同工具、不同版本之间的命令写法千差万别，上面的命令主要是给大家一个概念，千万别把它当万能模板。真正要做的，是理解报告里那些数值的含义。通常在报告timing时，工具会输出类似“Delay delta = xx ps”的字段，这个数就是当前路径上所有victim-aggressor耦合造成的累计延迟变化。如果这个值占整条路径延迟的比例超过10%，这条路径基本就可以判定为受串扰影响严重，单纯靠优化驱动和load不一定能解决，还需要考虑physical层面的shielding或者绕线。

3. Timing Window：不是可有可无的参数，是SI分析的判据

3.1 Timing Window怎么计算出来

Timing Window的计算其实不需要额外做一套复杂算法，它就是基于STA中arrival time的传播结果。对一个给定节点，工具会分别沿着early mode和late mode两条路径计算：

• earliest arrival time：对应最快路径、最小延迟、最激进的PVT条件组合。
• latest arrival time：对应最慢路径、最大延迟、最悲观的PVT条件组合。

Timing Window就是[earliest_arrival_time, latest_arrival_time]。它的宽度反映了这个节点“可能跳变的波动范围”。窗口越宽，说明该节点受PVT、OCV、串扰等因素的影响越大；窗口越窄，说明这个节点的时序行为越稳定。

在时钟树上，Timing Window还天然受到clock insertion delay的影响。同样一个寄存器，数据端口的窗口位置和时钟端口的窗口位置是不同的，这在串扰分析中会直接关系到数据信号和时钟信号的相互影响。

3.2 窗口重叠是串扰发生的时间前提

SI分析中判断一个aggressor是否会影响victim，第一步不是看耦合电容有多大，而是先看两个节点的Timing Window是否重叠。假设victim的窗口是[2ns, 2.5ns]，aggressor的窗口是[1ns, 1.2ns]，那么即便两条线物理上完全相邻，aggressor翻转时victim还没开始翻转，等到victim翻转时aggressor早就稳定了，两者根本不会在时间上相遇，串扰效应近似为零。

反之，如果aggressor的窗口是[2.1ns, 2.3ns]，那这个窗口完全包含在victim的窗口内，两者存在显著的时间重叠，工具就会进一步计算这个aggressor的翻转方向和victim的翻转方向组合，得到具体的Delta Delay值。

这里有一个容易忽视的细节：Timing Window本身也会因为SI修复而变化。工具在迭代计算时，会根据初步算出的Delta Delay更新aggressor和victim的到达时间，从而更新各自的窗口。最终的窗口是一个经过多次迭代后的收敛结果。

3.3 Timing Window对时钟树和hold预算的影响

Timing Window不只是用于数据路径的串扰分析，对时钟树同样很重要。CTS之后，时钟路径上的每个节点都有自己的Timing Window。如果一条时钟路径与一条数据路径靠得很近，两者窗口重叠，就可能在时钟信号上叠加额外的Delta Delay，最终体现在clock skew上。

这意味着什么？意味着你在CTS阶段精打细算出来的hold margin，可能因为布线后串扰引起的时钟到达时间偏移而被吞噬。这也是为什么很多熟练的后端工程师不会完全信任ideal clock阶段的hold报告，他们心里会预留一个基于Timing Window重叠情况的hold budget。

3.4 在IR-drop和噪声验证里的另一重身份

Timing Window还有另外一重身份：IR drop分析中的“开关密度窗口”。芯片局部电压降严重，往往是因为某个区域大量cell在同一时间窗口内同时翻转，瞬间拉高电流需求。如果你的IR drop分析只考虑静态平均电流，不结合Timing Window，就会严重低估动态压降。

结合Timing Window做动态压降分析时，工具会计算在每个时间窗口内有多少个cell发生翻转。大量cell集中在同一个窗口翻转，局部供电网络就会瞬时电压崩落，进而增大信号延迟。这种延迟增幅虽然不完全等同于串扰Delta Delay，但它在时序报告里的表现形式非常相似，又会和Delta Delay叠加在一起，让人难以分辨到底是谁拖垮了时序。

4. 后端工程里的高频翻车现场

4.1 GBA和PBA用不好，Delta Delay会骗人

时序分析有两大模式：GBA（graph-based analysis）和PBA（path-based analysis）。GBA沿时序图传播公共路径时，对所有可能路径取最大/最小值，天然更加保守；PBA则会沿着具体路径重新计算，结果更贴近实际。

问题是，GBA下计算的Delta Delay通常也比PBA更悲观。因为GBA在传播arrival time时会把同一个aggressor的干扰效果在所有可能的victim上重复计算，而PBA只计算在当前路径实际发生的情况。

我见过不少团队在GBA模式下看到一条路径有大量hold违规，于是疯狂插delay cell，结果到PBA模式下发现违例其实不存在，白白增加了面积和功耗。反过来，也有团队在PBA下看到没有violation就提前签核，结果GBA模式下漏了一堆问题。正确的做法是，根据项目的sign-off要求确定主分析模式，再用另一种模式做交叉验证，重点检查那些在两个模式下相差很大的路径。

4.2 CTS之后的“时序窗口漂移”

CTS阶段跑的时序，使用的是较早的RC抽取结果，时钟树还没有真正绕线。到了detail routing之后，时钟树上的物理RC会发生变化，时钟路径上每个节点的到达时间随之变化，Timing Window整体向右或向左漂移。

窗口漂移之后，原本没有时间重叠的aggressor和victim可能变得重叠了，原本没有串扰的路径突然冒出一堆Delta Delay。很多工程师遇到这类问题就会奇怪：为什么routing前后的时序报告差这么多？答案往往就出在窗口漂移后的SI重算上。

解决这个问题的思路是，在CTS后不要只看ideal clock的时序结果，而是做一次带初步RC的SI分析，提前发现那些窗口边缘靠得很近的路径，在布线阶段就通过约束或者physical guidance避免潜在问题。

4.3 MaxTransition设太紧，反而制造Delta Delay

后端优化时，为了确保信号沿够快，很多工程师会把MaxTransition约束设得很紧。这本身没错，问题在于违例一旦出现，工具最直接的手段是插buffer或者换大驱动cell。

缓冲区一多，网络数量变多、相连的coupling节点变多、整个区域内的信号跳变活动也变多。结果a路径的transition是改善了，但它周围的静态时序和串扰环境却被搅乱了，b路径和c路径反而出现了新的Delta Delay。这就是典型的“按下葫芦浮起瓢”。

更合理的做法是：在过渡时间违例不是特别严重时，优先调整单元位置、缩短走线长度，比盲目插buffer有效得多。只有当你通过SI report确认某个节点确实是驱动能力不足导致的transition问题，再插buffer也不迟。

4.4 修hold修出了一堆新crosstalk

Hold修复的本质是在数据路径上增加延迟，让数据晚到一点。最常见的操作是插入delay cell。但delay cell同样有输入输出端口，同样会与周围网络产生耦合。你每插一个delay cell，就相当于在物理世界里新增了一个“信号发射源”。

假设原本一条路径上没有crosstalk问题，你为了hold违例插了三个delay cell，这三个cell接入后改变了周边的信号环境，反而让相邻的agg与victim之间产生了新的Timing Window重叠，导致新增的Delta Delay变大。

所以我的习惯是：在修复hold之前，先把目标区域的SI情况和Timing Window分布摸清楚。如果发现附近有高度活跃的aggressor网络，优先选择把delay cell放到相对空旷的区域，或者直接复用已有的spare cell，避免在拥塞区域制造新的耦合源。

5. 怎么用Timing Window做“该修不该修”的判断

5.1 按Delta Delay和窗口重叠度分优先级

修时序不能眉毛胡子一把抓。我一般会把violating path按照Delta Delay和Timing Window重叠情况分成三档：

这套分档标准我用了很久，在大多数工艺节点下都比较有效。它帮你把有限的人力用在真正影响收敛的路径上，而不是被满屏的violation带偏节奏。

5.2 修复策略：哪些节点先动，哪些别动

Timing Window的实际应用，在于它可以告诉我们“什么时候动”比“动不动”更重要。举个例子，一条victim网络与三条aggressor网络存在窗口重叠，但其中两条aggressor只在victim窗口的边缘发生跳变，实际重叠时间非常短，真正有威胁的只有那一条完全落在victim窗口中间的agg。

这种情况下，修复的优先级就很明确：优先处理窗口完全重叠的、驱动能力较强的、耦合电容较大的agg。可以从三个方向同时入手：

• 通过换驱动、加buffer，把victim的窗口变窄，减少重叠机会。
• 通过加大线间距或插入shield线，降低耦合电容。
• 通过调整绕线层，将受害线和攻击线分开到不同金属层。

很多时候只要处理掉最关键的1~2条aggressor，整条victim路径的Delta Delay就会大幅下降，这个优先级判断比盲目“把全部violating net都修一遍”高效得多。

5.3 回归验证的常用手段

每一次SI修复之后，都要重新跑timing并观察Delta Delay的变化。我会习惯性保存修复前后的两版时序报告，做一个快速对比，重点看这几个字段：

• victim net上的Delta Delay绝对值变化。
• victim net上的Timing Window宽度变化。
• 相邻aggressor的窗口是否发生了移动。
• 修复之后有没有新增的crosstalk violator。

如果发现Delta Delay变小了但Timing Window宽度反而变大，说明修复动作可能只是暂时绕开了当前aggressor，但整体信号稳定性并没有变好，后面还可能反弹。反之，只要Timing Window逐渐收窄，Delta Delay稳定下降，这条路径就算真正修住了。

6. 先进工艺下的两个放大效应

6.1 线延迟占比越来越高，Delta Delay从“噪声”变“主信号”

在28nm及以上的工艺节点，单元延迟占路径延迟的绝对主导，线延迟只占一小部分。那时候即使出现串扰，Delta Delay也常常是几十ps以内，对时序收敛影响有限。到了7nm、5nm，互连线电阻变大、耦合电容占比升高，线延迟在路径延迟中所占比重越来越大。Delta Delay不再是路径延迟上的一层“毛刺”，而是直接决定路径正负余量的关键项。

这也是为什么在先进工艺节点的后端项目中，SI分析不再是可选的“加分项”，而是和setup、hold检查一样必须全程开启的“必选项”。如果你还在用老工艺时代的flow，把SI分析关了跑PR，之后的时序收敛和sign-off基本会是一场灾难。

6.2 低电压下Timing Window更容易发生整体偏移

另一个先进工艺的显著变化是工作电压越来越低。电压降低后，单元本征延迟对电压的敏感性大幅度提高，同一个单元在相同负载和相同slew下，不同corner之间的延迟差异会拉大。这直接导致early mode与late mode之间的到达时间差变大，Timing Window变得更宽。

Timing Window变宽意味着什么？意味着aggressor和victim之间的时间重叠概率变大了。以前只有完整的窗口重叠才会触发串扰影响，现在只要窗口有交叉，就可能产生非零的Delta Delay。换句话说，低压下不仅是窗口本身变宽了，整个设计受串扰影响的范围也被放大了。

所以做低电压、低功耗项目时，我通常会额外关注两件事：一是确认库模型在低压下依然使用CCS/ECSM这类高精度建模，二是仔细检查多电压域之间的Timing Window边界，避免不同电压域的信号在转换过程中出现意外的窗口重叠。

讲了这么多，最后说点个人体会。有一回我接手一个28nm的MCU项目，hold收敛反复做了三轮都没过，每次修完一批又冒出一批新的。那时我只盯着report_timing里的slack看，压根没有去查SI报告里的Delta Delay分布。后来仔细一查，发现问题出在CTS阶段和布线后阶段之间时序窗口发生了明显漂移，原本没有重叠的两个网络在布线后被拉在了一起，产生了一条很大的串扰delay。我做的第一件有效修复，不是加buffer，而是手动引导那根victim线绕开了攻击线，然后再配合调整驱动强度，两层下来整个设计就收干净了。

从那以后，我养成了一个习惯：拿到任何一条时序违例，先不急着改电路，先问三个问题——这条路径的Delta Delay是多少？Timing Window有多大？和周围的aggressor窗口是否真的重叠？这三个问题想清楚，再动手修，速度快很多，也不容易返工。做数字后端的人，最值钱的不是敲命令的手速，而是对时序分析背后这些模型和逻辑的理解深度。