2. PrimeTime时序分析基础回顾

OCV（On-Chip Variation）分析并不是一套独立于传统静态时序分析（STA）之外的新方法，它是在标准STA的时序方程上，对时钟路径和数据路径引入额外的裕量（derate）或统计分布。因此，要真正理解OCV报告中的slack为何变化、为何某些路径突然违例，必须先回到PrimeTime最基础的四个概念：建立时间与保持时间的检查方程、时序路径的四种类型、时钟模型（理想时钟与传播时钟）、以及约束如何定义时序分析的空间。本节把这些基础重新梳理一遍，并明确它们与后续OCV分析的接口在哪里。

建立时间与保持时间：两个方向相反的检查

建立时间（setup）检查的是数据到达时间必须早于捕获时钟有效沿所要求的时刻。PrimeTime中的基本关系为：

setup slack = (capture clock edge + clock latency_capture - T_setup)
              - (launch clock edge + clock latency_launch + T_clk2q + T_datapath)

保持时间（hold）检查的是数据在捕获沿之后必须保持足够久，其关系为：

hold slack = (launch clock edge + clock latency_launch + T_clk2q + T_datapath)
             - (capture clock edge + clock latency_capture + T_hold)

注意两个方程中数据路径延迟的符号方向相反：setup中数据路径越长越不利，hold中数据路径越短越不利。这正是OCV分析中“setup与hold需要不同derate方向”的根本原因——setup关注最慢数据路径与最快时钟路径的组合，hold关注最快数据路径与最慢时钟路径的组合。PrimeTime通过set_timing_derate对cell delay和net delay分别施加early/late系数，本质上就是在这些方程的各项上乘以不同因子。

时序路径的四种类型

PrimeTime把设计中所有时序检查归纳为四类路径，理解它们的起点和终点是读懂时序报告的前提：

• 输入到寄存器（input to reg）：起点是输入端口，终点是寄存器数据引脚，受输入延迟set_input_delay约束。
• 寄存器到寄存器（reg to reg）：起点和终点都是寄存器，是OCV分析最核心、最典型的路径类型。
• 寄存器到输出（reg to output）：起点是寄存器，终点是输出端口，受输出延迟set_output_delay约束。
• 输入到输出（input to output）：纯组合路径，起点和终点都是端口，通常由set_max_delay或输入输出延迟共同约束。

OCV的derate会同时作用于这四类路径，但reg-to-reg路径因为同时包含launch和capture两个时钟沿，对clock derate最敏感，也是分析中最需要关注的类型。

时钟模型：理想时钟与传播时钟

PrimeTime默认使用理想时钟（ideal clock），即时钟沿到达所有寄存器的时间完全一致，clock latency只由set_clock_latency人为指定。此时时钟网络上的延迟、偏斜（skew）都被忽略，setup/hold检查只反映数据路径的差异。

当执行set_propagated_clock后，PrimeTime改用传播时钟（propagated clock），时钟树上的buffer、net延迟被真实计算，launch和capture时钟路径的延迟不再相等，skew自然产生。OCV分析几乎总是建立在传播时钟之上，因为只有真实的时钟路径延迟才能被derate区分对待——理想时钟下所有时钟路径延迟相同，derate时钟路径没有意义。

约束：定义时序分析的空间

约束决定了PrimeTime在什么条件下检查时序。核心约束包括：

• create_clock：定义时钟周期和波形，是所有时序检查的基准。
• set_input_delay / set_output_delay：描述外部器件与芯片接口的时序关系。
• set_clock_uncertainty：为setup和hold分别预留裕量，OCV分析中常与derate配合使用。
• set_false_path / set_multicycle_path：排除或放宽特定路径的检查。

这些约束共同划定了时序分析的有效路径集合。OCV分析不会改变约束本身，但会在约束定义的每条有效路径上叠加derate，因此约束的正确性直接决定OCV报告的可信度。

从基础到OCV：接口在哪里

把上述基础串起来看，OCV分析的接口非常清晰：

1. 路径类型决定derate对象：reg-to-reg路径同时derate launch和capture时钟路径，input-to-output路径只derate数据路径。
2. setup/hold方程决定derate方向：setup对数据路径用late derate、对capture时钟用late derate、对launch时钟用early derate；hold方向相反。
3. 时钟模型决定derate是否有效：只有传播时钟下，clock derate才能区分不同寄存器的时钟到达时间。
4. 约束决定derate作用范围：false path和multicycle path上的derate行为需要单独确认，避免误报。

举个具体的教学示例：假设一个reg-to-reg路径，时钟周期T=2.0ns，launch时钟延迟0.3ns，capture时钟延迟0.5ns，T_cq=0.15ns，数据路径延迟0.8ns，T_setup=0.1ns。无OCV时setup slack = (2.0+0.5−0.1) − (0+0.3+0.15+0.8) = 2.4 − 1.25 = 1.15ns。若对数据路径施加late derate 1.1、对launch时钟施加early derate 0.9、对capture时钟施加late derate 1.1，则slack变为 (2.0+0.5×1.1−0.1) − (0+0.3×0.9+0.15×1.1+0.8×1.1) = (2.0+0.55−0.1) − (0+0.27+0.165+0.88) = 2.45 − 1.315 = 1.135ns。可以看到OCV使slack减少了0.015ns，这个差值就是derate带来的额外裕量。实际项目中derate系数通常更大（如1.05~1.15），累积效应可能直接导致路径违例。