【IC】数字后端设计的timing margin window

为了把这个问题讲透，我们构建一个具体的数值案例。

我们将计算一个 Register-to-Register 路径的 Timing Window。我们将引入 OCV Derate（片上偏差系数）和 CPPR（CRPR），因为如果不算这两个，Common Path 和时钟树长度就没有意义了。

一、案例参数设定

假设我们处于一个先进工艺节点（如 12nm/7nm），参数如下：

时钟周期 (Period): T=1000psT = 1000psT=1000ps (1GHz)
PVT Scaling Factor (KKK): DelaySS/DelayFF=2.5Delay_{SS} / Delay_{FF} = 2.5DelaySS/DelayFF=2.5
时钟树结构 (Clock Tree):

SS Corner 下的总 Latency: 500ps (这是一棵比较长的树)
Common Path (公共路径): 300ps (大部分是公共的)
Divergent Path (分叉后): 200ps (Launch和Capture各走200ps)

OCV Derate (工艺偏差):

Late (变慢): 1.05
Early (变快): 0.95

库要求 & 不确定性:

Tsetup=50psT_{setup} = 50psTsetup=50ps, Usetup=30psU_{setup} = 30psUsetup=30ps
Thold=30psT_{hold} = 30psThold=30ps, Uhold=20psU_{hold} = 20psUhold=20ps

二、具体计算步骤

我们的目标是求出：Available Logic Window (in SS Corner)。

即：在SS下，我的组合逻辑（Logic）最长能跑多少（Setup Limit），最短必须跑多少（Hold Limit换算回SS）。

步骤 1：计算 Setup Limit (在 SS Corner)

Setup 检查最悲观的情况是：Launch Clock 慢，Capture Clock 快。

Launch Clock Delay (Late): 500ps×1.05=525ps500ps \times 1.05 = 525ps500ps×1.05=525ps
Capture Clock Delay (Early): 500ps×0.95=475ps500ps \times 0.95 = 475ps500ps×0.95=475ps
Skew (原始): 475−525=−50ps475 - 525 = -50ps475−525=−50ps (这对Setup不利)
CPPR 补偿:
公共路径 (300ps) 在物理上是同一段导线，不可能既快又慢。所以我们要把这部分虚假的偏差加回来。
CPPR=CommonPath×(Deratelate−Derateearly)=300×(1.05−0.95)=30psCPPR = CommonPath \times (Derate_{late} - Derate_{early}) = 300 \times (1.05 - 0.95) = 30psCPPR=CommonPath×(Deratelate−Derateearly)=300×(1.05−0.95)=30ps
有效 Skew: −50ps+30ps=−20ps-50ps + 30ps = -20ps−50ps+30ps=−20ps
Setup 允许的最大逻辑延时 (Max_Logic_DelaySSMax\Logic\Delay{SS}Max_Logic_DelaySS):
=Period+Effective_Skew−Tsetup−Usetup= Period + Effective\Skew - T{setup} - U{setup}=Period+Effective_Skew−Tsetup−Usetup
=1000+(−20)−50−30=900ps= 1000 + (-20) - 50 - 30 = \mathbf{900ps}=1000+(−20)−50−30=900ps
关键点：注意 Common Path 越长，CPPR 补偿越大，Effective Skew 的损失就越小，Setup 就越容易。如果 Common Path = 0，你的 Skew 损失就是纯粹的 -50ps。
步骤 2：计算 Hold Limit (在 FF Corner)
Hold 检查最悲观的情况是：Launch Clock 快，Capture Clock 慢。
首先，把时钟 Latency 换算到 FF Corner (除以 K=2.5)：
FF Clock Latency = 500/2.5=200ps500 / 2.5 = 200ps500/2.5=200ps
FF Common Path = 300/2.5=120ps300 / 2.5 = 120ps300/2.5=120ps
现在计算 FF 下的 Hold：
Launch Clock Delay (Early): 200×0.95=190ps200 \times 0.95 = 190ps200×0.95=190ps
Capture Clock Delay (Late): 200×1.05=210ps200 \times 1.05 = 210ps200×1.05=210ps
Skew (原始): 210−190=20ps210 - 190 = 20ps210−190=20ps (这对Hold不利，增加了Hold要求)
CPPR 补偿: 120×(1.05−0.95)=12ps120 \times (1.05 - 0.95) = 12ps120×(1.05−0.95)=12ps
有效 Skew: 20−12=8ps20 - 12 = 8ps20−12=8ps
FF 下需要的最小逻辑延时 (Min_Logic_DelayFFMin\Logic\Delay{FF}Min_Logic_DelayFF):
Hold Check 公式: Launch+Logic>Capture+Hold+UncertaintyLaunch + Logic > Capture + Hold + UncertaintyLaunch+Logic>Capture+Hold+Uncertainty
Logic>Effective_Skew+Thold+UholdLogic > Effective\Skew + T{hold} + U{hold}Logic>Effective_Skew+Thold+Uhold
Logic>8+30+20=58psLogic > 8 + 30 + 20 = \mathbf{58ps}Logic>8+30+20=58ps
也就是说，在 FF Corner，为了修好 Hold，你的逻辑延时至少要是 58ps。
步骤 3：跨 Corner 换算与 Window 计算
这是最残酷的一步。你在 FF 下需要的 58ps，在 SS 下会变成多少？
Min_Logic_DelaySS=58ps×2.5(Scaling)=145psMin\_Logic\Delay{SS} = 58ps \times 2.5 (Scaling) = \mathbf{145ps}Min_Logic_DelaySS=58ps×2.5(Scaling)=145ps
最终的 Timing Margin Window:
Window=Max_Logic_DelaySS−Min_Logic_DelaySSWindow = Max\_Logic\Delay{SS} - Min\_Logic\Delay{SS}Window=Max_Logic_DelaySS−Min_Logic_DelaySS
Window=900ps−145ps=755psWindow = 900ps - 145ps = \mathbf{755ps}Window=900ps−145ps=755ps

三、结果分析：这 755ps 意味着什么？

理想情况: 如果没有 OCV，没有 Scaling，你的 Window 接近 1000ps。
现实情况: 因为时钟树长带来的 OCV 惩罚（Setup 扣了20ps，Hold 扣了 8ps*2.5=20ps），以及为了修 Hold 被迫垫高的延时（145ps），你实际能用的逻辑级数只有 755ps。
如果 Window 很小（比如 < 100ps）:
说明无论你怎么优化组合逻辑，只要 Setup 和 Hold 一起看，这条路基本就是死路。

四、算出这个值之后怎么用？（实战指南）

算出这个值不是为了写报告，而是为了指导 Floorplan 和 Timing Signoff 策略。

评估 Floorplan 和时钟树结构 (Pre-CTS / Post-CTS)

现象：如果你发现某条长距离的 Global Path（比如从左下角到右上角），Window 算出来很小甚至是负的。
原因：这通常是因为 Common Path 太短。Launch 和 Capture 的时钟从 PLL 出来没多远就分叉了，导致它们各自跑了很长的 Uncommon Path，累积了巨大的 OCV 惩罚。
对策：
- 做 H-Tree 或 Spine: 强行把 Common Point 往后推，让分叉点靠近 Sink 端。
- 利用 Clock Mesh: Mesh 结构天然有极好的 Common Path 特性，能显著增大 Timing Window。

指导逻辑级数 (RTL Design)

应用：前端设计人员问你："我这个模块两个寄存器之间最多能塞几级 Logic？"
错误回答："周期是1ns，如果你用 SS Library 算一级 Cell 是 50ps，那你可以塞 20 级。" (1000/50 = 20)
正确回答："扣除 Setup/Hold 的 OCV 惩罚和 Scaling 效应，有效 Window 只有 750ps 左右。建议你不要超过 15 级 (750/50)，否则后端很难收敛。"

决定修 Hold 的策略 (ECO Stage)

场景：Setup Slack = 30ps (很紧)，Hold Violated = -20ps (FF下)。
判断：
- FF 下违例 -20ps，意味着我需要插 20ps 的 Delay。
- 换算到 SS，这 20ps 会变成 20×2.5=50ps20 \times 2.5 = 50ps20×2.5=50ps。
- Setup 只有 30ps 裕量，插入后 Setup 会变成 30−50=−20ps30 - 50 = -20ps30−50=−20ps。爆了！
决策：
- 这时候不能插 Buffer！
- 必须用 Useful Skew (借时钟)：把 Capture Clock 往后推，或者把 Launch Clock 往前拉。Useful Skew 只是平移 Window，不会像插 Buffer 那样压缩 Window（因为它不涉及 SS/FF 的 Scaling 放大）。

调整 Derate 设置

如果算出来 Window 全是负的，说明你的 Derate 设得太悲观了。
比如对于 500ps 的短时钟树，你还设 5% 的 Derate 可能不合理。这时候需要去和 Foundry 或 Signoff 团队 Argue，看能否引入 AOCV (Advanced OCV) 或 POCV (Parametric OCV)，这些统计学模型能去除多余的悲观量，让 Window 变大。
总结
Timing Margin Window 是一个**"时序预算"**。
Setup 决定了天花板。
Hold + Scaling + OCV 决定了地板。
Common Path 决定了地板和天花板会不会因为 OCV 而剧烈收缩。
算好这个账，你就不至于在 ECO 阶段修了 Hold 坏 Setup，陷入死循环。