数字IC后端STA必修：OCV与timing derate配置详解

1. 为什么OCV和timing derate是数字IC后端绕不开的坎

做数字IC设计的同行都有个共识：前端RTL写得再漂亮，最后能不能signoff，很大程度上取决于STA（Static Timing Analysis）做得够不够扎实。而提到STA，PrimeTime几乎是绕不开的工具，OCV（On-Chip Variation）和timing derate又是其中最容易让人犯迷糊的部分。

我刚开始接触PrimeTime的时候，看到脚本里一堆set_timing_derate就头大——为什么setup和hold要设不同的derate值？为什么clock path和data path要区别对待？AOCV和POCV又是什么鬼？这些问题如果不搞清楚，脚本抄来抄去，signoff结果要么过于悲观导致面积和功耗浪费，要么过于乐观导致流片回来timing挂掉。前者是浪费钱，后者是灾难。

这篇文章面向的是有一定STA基础、正在用PrimeTime做signoff的IC设计工程师，尤其是那些已经能跑通基本flow、但对OCV和derate配置还停留在“抄脚本”阶段的同学。我会从OCV的基本概念讲起，把timing derate的计算逻辑、配置方法、常见坑点全部拆开揉碎，最后给出一套可以直接参考的完整配置流程。所有内容基于我在实际项目中的经验，结合PrimeTime的常用命令和参数，尽量做到“看完就能上手改脚本”。

需要说明的是，不同工艺节点、不同foundry对OCV的要求差异很大，本文给出的derate数值是示例性质的，实际项目中必须以foundry提供的signoff guide为准。但配置的思路和方法论是通用的，这也是我希望传递的核心价值。

2. OCV和timing derate到底在解决什么问题

2.1 从一颗芯片的“不一致性”说起

同一颗芯片上，同一个标准单元，在不同位置的实际延时是不一样的。原因很多：制造过程中的光刻偏差、掺杂浓度波动、氧化层厚度不均匀，以及工作时的电压波动、温度梯度等等。这些因素导致芯片上不同区域的晶体管特性存在随机和系统性的偏差，这就是OCV的来源。

举个生活化的例子：你和朋友同时从家出发去同一个目的地，走同一条路，但你们到达的时间可能差好几分钟——因为红绿灯等待时间不同、路上遇到的行人不同、你们各自的步速也有细微差异。芯片里的信号也一样，即使逻辑上走的是相同级数的路径，实际延时也会有偏差。

对于时序分析来说，这种偏差意味着什么呢？假设有一条setup检查的路径，launch clock path和capture clock path在物理上经过不同的单元和连线。如果launch path恰好偏慢（延时比标称值大），而capture path恰好偏快（延时比标称值小），那setup就会比标称分析更紧张。反过来，hold检查时如果launch path偏快、capture path偏慢，hold也会更紧张。

timing derate就是用来模拟这种“最坏情况组合”的手段。通过对不同的path、不同的检查类型施加不同的缩放系数（derate factor），让STA分析覆盖到这些极端情况。

2.2 OCV、AOCV、POCV的区别与选择

早期工艺节点（比如65nm以上），大家用的是简单的OCV模型：给所有path统一加一个固定的derate值，比如setup时data path加5%、clock path加3%之类的。这种做法简单粗暴，但随着工艺进步到28nm、16nm甚至7nm，固定derate越来越不现实——它要么过于悲观（导致过度设计），要么覆盖不到真正的worst case。

于是有了AOCV（Advanced OCV），它引入了两个维度的考量：逻辑深度（depth）和物理距离（distance）。逻辑级数越多，随机偏差相互抵消的效果越明显，derate值可以相应减小；物理距离越远，系统性偏差越大，derate值需要增大。AOCV通常以查找表的形式提供，PrimeTime通过set_timing_derate配合-late/-early以及-cell_delay/-net_delay等选项来使用。

再往后是POCV（Parametric OCV），也叫SOCV（Statistical OCV）。它把延时建模为统计分布（均值和标准差），通过概率方法计算时序裕量的分布，最终给出一个满足特定良率要求的timing结果。POCV更精确，但对库的要求更高，配置也更复杂。

选择哪种模型，取决于工艺节点和foundry的推荐。一般来说：

我个人的经验是，在28nm项目上如果foundry同时提供了AOCV和固定OCV的选项，优先用AOCV，因为它在保证覆盖度的同时能省下不少面积。但前提是你要正确配置depth和distance的对应关系，否则可能适得其反。

3. PrimeTime中timing derate的核心配置方法

3.1 set_timing_derate命令的基本语法与参数

PrimeTime中设置derate的核心命令是set_timing_derate，基本语法如下：

set_timing_derate -early <value> [选项] set_timing_derate -late <value> [选项]

其中-early用于hold检查（launch path偏快的情况），-late用于setup检查（launch path偏慢的情况）。常用的选项包括：

• -cell_delay：作用于单元延时
• -net_delay：作用于连线延时
• -cell_check：作用于单元内部的setup/hold check时间
• -clock：仅作用于clock path
• -data：仅作用于data path
• -rise/-fall：分别作用于上升沿和下降沿

一个典型的配置片段长这样：

# 全局derate设置 set_timing_derate -early 0.95 set_timing_derate -late 1.05 # clock path单独设置 set_timing_derate -early 0.97 -clock set_timing_derate -late 1.03 -clock # cell check的derate set_timing_derate -early 0.98 -cell_check set_timing_derate -late 1.02 -cell_check

这里需要理解一个关键逻辑：-early的值通常小于1（表示path变快），-late的值通常大于1（表示path变慢）。对于setup检查，我们需要launch clock path尽量慢（late derate）、data path尽量慢（late derate）、capture clock path尽量快（early derate），这样才能构造最悲观的setup场景。PrimeTime会自动根据检查类型选择对应的derate值，你只需要把early和late都设好就行。

3.2 clock path和data path的derate策略差异

很多新手会问：为什么clock path和data path的derate值不一样？这要从clock path的特殊性说起。

Clock path上通常有大量的clock tree buffer和较长的走线，这些单元和连线在物理上往往比较对称，而且clock tree综合时已经做了balancing。因此clock path上的偏差通常比data path小。另一方面，clock path的偏差对setup和hold的影响是“双向”的——launch clock偏慢对setup不利，但capture clock偏慢对setup有利。所以对clock path的derate通常比data path温和一些。

在实际项目中，我通常会把derate分成四组来管理：

具体数值要看foundry的signoff guide。有些foundry会给出更细的粒度，比如区分不同VT类型的单元、区分不同金属层的连线等。

3.3 用derate覆盖setup和hold的最坏情况

理解derate的关键在于搞清楚“谁快谁慢”对时序的影响。我用一个简单的例子来说明。

假设有一条setup路径：

• Launch clock path延时 = 1.0ns
• Data path延时 = 2.0ns
• Capture clock path延时 = 1.2ns
• Setup time = 0.1ns
• Clock period = 5.0ns

标称情况下，setup slack = (1.0 + 5.0 - 1.2) - 2.0 - 0.1 = 2.7ns，很充裕。

现在施加derate：launch clock late derate = 1.03，data path late derate = 1.08，capture clock early derate = 0.97。

• Launch clock延时变为 1.0 × 1.03 = 1.03ns
• Data path延时变为 2.0 × 1.08 = 2.16ns
• Capture clock延时变为 1.2 × 0.97 = 1.164ns

新的setup slack = (1.03 + 5.0 - 1.164) - 2.16 - 0.1 = 2.606ns。

可以看到，derate让slack减少了约0.094ns。如果路径本身裕量就不大，这个减少量足以让timing挂掉。

对于hold检查，逻辑正好反过来：launch clock要尽量快（early derate），data path要尽量快（early derate），capture clock要尽量慢（late derate）。PrimeTime在分析hold时会自动使用early derate作用于launch path和data path，用late derate作用于capture path。

注意：PrimeTime默认对clock path和data path使用相同的derate值，如果你需要区分，必须显式地用-clock和-data选项分别设置。很多脚本bug就出在这里——以为设了全局derate就万事大吉，结果clock path和data path用了同一个值，要么过悲观要么过乐观。

4. 完整配置流程：从库读入到derate生效

4.1 环境准备与库文件加载

在开始配置derate之前，需要确保PrimeTime环境已经正确加载了库文件和设计。一个典型的启动脚本如下：

# 设置搜索路径 set search_path [list . ./libs ./db] # 加载目标库和链接库 set target_library [list "tcbn28hpcp_ssg_0p81v_125c.db"] set link_library [list "*" "tcbn28hpcp_ssg_0p81v_125c.db" "io_ssg_0p81v_125c.db"] # 读入网表 read_verilog ./netlist/top.v # 读入SDC约束 read_sdc ./constraints/top.sdc # 链接设计 link_design top # 读入寄生参数 read_parasitics -format spef ./spef/top.spef

这里有几个实操要点：

第一，库的选择。setup分析用ss（slow-slow）工艺角，hold分析用ff（fast-fast）工艺角。有些团队会在同一个PrimeTime session里同时做setup和hold分析，这时需要加载两套库，通过set_operating_conditions切换。但更常见的做法是分开跑两个session，避免混淆。

第二，寄生参数的读入。SPEF文件的质量直接影响net delay的准确性。如果SPEF是从StarRC提取的，注意检查提取时的corner是否和当前分析corner匹配。

第三，link_design之后要检查。用check_design和report_design确认没有unresolved reference，否则后续分析结果不可信。

4.2 基础derate脚本的编写与调试

环境准备好之后，就可以开始写derate配置了。我通常把derate配置单独放在一个tcl文件里，方便管理和复用。以下是一个完整的示例：

# ============================================ # Timing Derate Configuration # Process: 28nm HPC+ # Corner: SSG 0.81V 125C (setup) / FFG 0.99V -40C (hold) # ============================================ # --- 全局derate --- set_timing_derate -early 0.95 set_timing_derate -late 1.05 # --- Data path cell delay derate --- set_timing_derate -early 0.92 -cell_delay -data set_timing_derate -late 1.08 -cell_delay -data # --- Data path net delay derate --- set_timing_derate -early 0.90 -net_delay -data set_timing_derate -late 1.10 -net_delay -data # --- Clock path cell delay derate --- set_timing_derate -early 0.96 -cell_delay -clock set_timing_derate -late 1.04 -cell_delay -clock # --- Clock path net delay derate --- set_timing_derate -early 0.95 -net_delay -clock set_timing_derate -late 1.05 -net_delay -clock # --- Cell check derate --- set_timing_derate -early 0.97 -cell_check set_timing_derate -late 1.03 -cell_check

写完之后，用report_timing_derate命令检查配置是否生效：

report_timing_derate

这个命令会列出当前所有derate设置，包括全局的、分类的、以及是否有冲突。我踩过的一个坑是：先设了全局derate，后来又设了-data的derate，结果发现某些path的derate不是预期的值——原因是PrimeTime的derate是“叠加”还是“覆盖”取决于具体选项组合，需要仔细看文档确认。

4.3 用report_timing验证derate效果

配置完derate后，不能直接看slack就完事，必须验证derate是否按预期作用到了正确的path上。我通常用以下步骤验证：

第一步，跑一条关键路径的timing report，加上-derate选项：

report_timing -derate -delay_type max -max_paths 1 -nworst 1

这个report会显示每个单元和连线的标称延时、derate值、以及derate后的延时。检查clock path和data path的derate是否和你设置的一致。

第二步，对比derate前后的slack变化。可以先不加derate跑一次，再加derate跑一次，看看slack的减少量是否合理。如果减少量异常大，可能是derate设得太激进；如果几乎没变化，可能是derate没生效。

第三步，检查hold分析。用-delay_type min跑hold report，确认early derate正确作用。

实操心得：我习惯在derate脚本里加一些puts语句，打印关键derate值，这样在log里能快速确认脚本是否按预期执行。比如：

puts "INFO: Data cell late derate = [get_timing_derate -late -cell_delay -data]"

这比事后翻report高效得多。

5. 常见问题与排查技巧实录

5.1 derate不生效的几种典型原因

在实际项目中，derate配置了但没生效是最常见的问题之一。根据我的经验，原因通常有以下几种：

原因一：命令顺序错误。PrimeTime中某些命令有先后依赖关系。比如set_timing_derate必须在read_sdc之后、update_timing之前执行。如果顺序反了，derate可能被后续的约束覆盖。

原因二：选项冲突。比如同时设了-cell_delay和-net_delay的全局derate，又设了-data的分类derate，PrimeTime的行为可能是后者覆盖前者，也可能是叠加，取决于版本和具体选项。建议用report_timing_derate确认最终生效值。

原因三：path类型不匹配。比如你设了-clock的derate，但实际路径被PrimeTime归类为-data（比如generated clock的某些segment），导致derate没作用到预期的path上。

原因四：没有update_timing。设置derate后必须执行update_timing才能让新配置生效。这个命令会重新计算所有时序，耗时可能较长，但必不可少。

排查方法很简单：用report_timing_derate看配置，用report_timing -derate看实际作用值，两者对比就能定位问题。

5.2 AOCV配置中depth和distance的坑

如果项目用的是AOCV，配置会比固定derate复杂不少。AOCV的核心是两张查找表：一张根据逻辑深度（depth）给derate，一张根据物理距离（distance）给derate。PrimeTime通过set_timing_derate的-aocv选项或者单独的AOCV文件来加载。

常见的坑包括：

坑一：depth计算方式不匹配。不同foundry对depth的定义可能不同——有的算cell级数，有的算stage数，有的把clock path也计入。如果PrimeTime的depth计算方式和AOCV表不匹配，derate值就会取错。

坑二：distance单位不一致。AOCV表的distance单位可能是um、mm或者die的百分比，而PrimeTime默认用的单位可能不同。需要确认set_timing_derate的-distance选项和库文件的单位一致。

坑三：AOCV和固定derate混用。有些团队为了保险，在AOCV基础上再加一层固定derate。这种做法不是不可以，但必须清楚两层derate是叠加的，最终值可能过于悲观。我一般建议二选一，除非foundry明确要求叠加。

5.3 如何判断derate值设得是否合理

derate值设得是否合理，直接关系到signoff的质量。设得太松，流片风险大；设得太紧，面积和功耗浪费。判断方法有几个：

方法一：看slack分布。如果加了derate之后，大量路径的slack从正变负，说明derate可能过紧。如果几乎所有路径slack都远大于0，说明derate可能过松。

方法二：对比不同corner的结果。在ss corner下setup slack紧张是正常的，但如果ff corner下hold slack也大面积挂掉，可能是early derate设得太激进了。

方法三：参考foundry的signoff guide。这是最权威的依据。foundry通常会给出推荐的derate值范围，以及不同工艺节点、不同金属层、不同VT类型的细分建议。

方法四：做derate sweep。在项目早期，可以跑一组不同derate值的实验，看看slack对derate的敏感度。如果slack对derate非常敏感，说明设计本身裕量不足，需要从前端或后端优化，而不是靠调derate来“解决”问题。

下面这张表是我总结的常见问题速查：

5.4 多corner多mode下的derate管理

实际项目中，芯片通常需要在多个corner（ss/tt/ff）和多个mode（func/test/scan）下做STA。每个corner和mode的derate配置可能不同，管理起来很容易乱。

我的做法是：为每个corner单独写一个derate配置文件，用变量控制关键参数，然后在主脚本里根据当前corner source对应的文件。比如：

# 主脚本中 if {$corner == "ss"} { source ./derate/derate_ss.tcl } elseif {$corner == "ff"} { source ./derate/derate_ff.tcl } else { source ./derate/derate_tt.tcl }

每个derate文件里只放该corner特有的设置，公共部分抽到一个base文件里。这样既避免了重复，又方便维护。

另外，scan mode下的derate通常和func mode不同——scan path上的clock tree结构不一样，derate值可能需要调整。建议在SDC里用set_case_analysis区分mode，然后在derate脚本里根据mode设置不同的值。

6. 一些实战中的个人体会

做STA这些年，我最大的体会是：derate不是万能的，它只是对制造偏差的一种建模手段。如果设计本身时序裕量就不够，靠调derate是调不出来的。我见过有团队为了signoff通过，把derate从1.08降到1.03，结果流片回来timing挂了，损失惨重。derate值的确定必须基于foundry的推荐和充分的实验验证，不能拍脑袋。

另一个体会是，PrimeTime的derate配置虽然命令不多，但组合起来非常灵活，也容易出错。我的建议是：每次修改derate配置后，都用report_timing_derate和report_timing -derate双重确认，确保配置按预期生效。这个习惯帮我避免了好几次潜在的signoff事故。

最后分享一个小技巧：如果你不确定某个derate值是否合理，可以先用一个较宽松的值跑一遍，看看哪些路径最紧张，然后针对这些路径单独分析。如果紧张路径集中在某个模块或某种单元类型上，可能是设计问题而非derate问题。这种“先粗后细”的方法比一上来就死磕derate值高效得多。

对于正在准备数字IC设计面试的同学，OCV和timing derate是STA部分的必考题。面试官通常会问“setup和hold的derate有什么区别”、“AOCV和POCV的适用场景”这类问题。我的建议是不要死记概念，而是从“为什么要做derate”这个根本问题出发，理解偏差的来源和对时序的影响，这样回答起来才能有逻辑、有深度。