40LL tapeout签核避坑：版本矩阵、PEX/RC corner与IR drop全流程对账

简介：面向采用中芯国际40LL（40nm低漏电）工艺进行后端物理设计与签核验证的工程师，这份《40LL Design Sign-off Guideline》为SMIC官方发布的设计签核指南，用于梳理流片前各项签核检查的流程要求与判定口径，帮助团队在项目收尾阶段对照确认检查项是否完整。压缩包内共1个文件，即1份PDF文档，约2.18MB、36页，开篇给出文档编号与版本信息、免责声明及保密与使用条款，正文以条目化方式组织签核相关内容，结构清晰便于按章节检索。已有496人学习下载，可作为项目自查清单、评审前的对照材料或新人培训读物，适合正在推进40LL工艺项目、需要按官方口径核对签核项并降低流片风险的版图与后端工程师参考。

1. 40LL 签核挤在 tapeout 前十天，工具都跑完了却没人能拍板

项目排到 tapeout 前十天，时序报告全绿，物理验证只剩几十条密度告警，团队里没人觉得还有问题。直到把这份 40LL sign-off guide 的 checklist 逐条对了一遍，才发现动态压降用的是两年前的向量、STA 读的 SPEF 和当前 RC corner 不是同一批生成。这类翻车跟工具会不会用没关系，问题出在没人把签核当成一次对账。

40LL sign-off guide 是某代工厂面向 40nm 低漏电平台客户的一份签核方法论文档，36 页，覆盖参考流程与工具版本矩阵、时序签核（单元库、PEX、OCV、signoff corner）、电源签核（静态与动态压降）、物理验证（DRC/LVS/PEX）、可制造性（LFD、dummy）和可靠性（EM）。它不教工具怎么点，只回答三个问题：该跑什么、按哪个角跑、结果看到什么程度可以停。适合正在或准备上 40LL 的数字后端、STA、PV 工程师；带过一两个项目的人读它会觉得句句在讲自己踩过的坑。文档本身带保密标识，随工艺包发放，别往外传。

2. 参考流程与工具版本矩阵：四道 gating 的输入输出怎么对账

2.1 四道 gating 各交什么物

指南把参考流程拆成四道 gating：时序签核、电源签核、物理验证、可制造性分析。gating 的意思是“过不了这道门就不许往下走”，不是说“跑完就完事”。这四步之间存在硬依赖：物理验证不过，提取出来的网表本身就是错的，后面所有时序和压降都建立在错误基础上；提取不对，时序跑到天荒地老也只是自我安慰。

我一般会先把每道门对应的交付物列成一张表，贴在项目墙上，谁交谁签字：

注意这张表的顺序：DFM 和 EM 排在最后，并不是因为它们不重要，而是它们必须建立在“版图已经定稿、提取已经正确”的前提下。反过来做，改动一次金属就会把前面所有结论推翻。

2.2 版本矩阵直接决定结果可不可比

指南花了整整一页列 EDA 工具版本，从模拟、综合、DFT、PnR、提取、STA 到 IR drop、DRC/LVS，逐项给了推荐版本。很多人扫一眼就跳过，觉得“新版本总比旧版本好”。真实情况是，签核结果的可信度一半来自版本一致性。同一份网表，提取工具换个 ISR，RC 值就能差出几个百分点；STA 换个版本，默认 derate 和 SI 处理策略可能已经改了，你根本没动脚本，报告就变了个样。

所以我会把版本矩阵落成一个环境体检脚本，每次开跑签核之前先执行一遍，把工具路径、版本号、库路径全打到日志里留档：

#!/usr/bin/env bash # signoff_env_check.sh —— 签核环境体检，先跑这个再开工具 set -u # 1) 工具必须指向工艺平台推荐的版本目录，而不是 PATH 里默认找到的那个 STA_BIN="${STA_HOME:?未设置 STA_HOME}/bin/sta" PEX_BIN="${PEX_HOME:?未设置 PEX_HOME}/bin/pex" PV_BIN="${PV_HOME:?未设置 PV_HOME}/bin/pv" for t in "$STA_BIN" "$PEX_BIN" "$PV_BIN"; do [ -x "$t" ] || { echo "[FAIL] 找不到可执行文件: $t"; exit 1; } # 版本号打印在第 2 行的情况很常见，取前 3 行足够人工核对 printf '%-14s %s\n' "$(basename "$t")" \ "$("$t" -version 2>&1 | head -n 3 | tr '\n' ' ')" done # 2) 关键变量：库与工艺文件必须来自同一套 PDK 发布包 echo "STDCELL_LIB = ${STDCELL_LIB:-<empty>}" echo "TECH_FILE = ${TECH_FILE:-<empty>}" echo "PDK_RELEASE = ${PDK_RELEASE:-<empty>}"

${VAR:?msg}的写法会在变量为空时直接报错退出，比if [ -z ]少写几行，也避免“变量没设但脚本继续跑”的经典事故。-version那段用head -n 3是因为不同工具打印版本的行数不一致，取前三行拼成一行，人工核对足够，想自动比对可以再加一层grep匹配版本号。最后三个变量是这套流程的命门：库、工艺文件、PDK release 必须来自同一次发布，混用两套 PDK 是最难查的一类问题，因为它不报错。

2.3 标准单元库的类型与表征角

指南给 8 轨（8T）单元库列了一张覆盖表，按栅长分 C40 和 C50 两种，按 VT 分 RVT、HVT、LVT、ULVT 四档，另有两类特殊套件：

这张表最容易被误读的是 ECO 库。它跟基础库里的同名单元是两个不同的 cell，物理尺寸和时序模型都不一样，混着读会 double-book，LVS 阶段才会炸。电源管理套件也别乱挑，隔离单元和电平转换单元必须成对使用，落单了功能上就是错的。

库的“表征角”这一节更值得反复读。每个库文件背后是一组 PVT 加 PEX 条件的组合，文档明确说明库是在哪些工艺、电压、温度和寄生参数条件下表征出来的。签核时你选的 corner，必须能在这套表征角里找到对应或者落在其覆盖范围内，否则就是拿一个没被表征过的条件去签核。常见错误是随手加一个“更严”的温度点，觉得更保险——实际上那个组合可能根本没有 silicon 数据支撑。

3. 时序签核的三层账：库角、PEX 与 OCV 的设定顺序

3.1 PEX 提取模式与 RC corner 的匹配

寄生提取这一步，指南单列一节讲，因为它同时出现在时序签核和物理验证两个章节里，是唯一被重复引用的环节。提取模式大致分三档：理想 RC（只用于早期评估）、基于规则或场求解的 2.5D 提取、全三维场求解。签核阶段用哪一种，取决于设计规模和频率，40LL 这种节点上大部分同步 SoC 用 2.5D 提取就够，只有高频模拟或者关键时钟网络才值得上更重的求解。

关键在于 RC corner 与 STA corner 的配对。提取工具通常输出 Cmax/Cmin/RCmax/RCmin 四类角，时序分析也有自己的 setup/hold corner，两者必须一一对上：

我见过最常见的错误是：提取跑完出了四份 SPEF，STA 脚本里硬编码了一份，后来重新提取了但脚本没改，报告上的 WNS 看着没变，实际上用的还是上一版数据。解决方式很土但有效——SPEF 文件名里带时间戳和 corner 名，脚本里用变量拼接，跑完把实际读入的路径打印到日志。

3.2 OCV derate 的粒度：别用一个数打天下

片上偏差（OCV）这一节，指南给的是方法论而不是固定数值：derate 应该按路径的物理相关性来设，而不是全局一个 1.05 完事。粗粒度做法是全芯片统一 derate，简单但过度悲观，往往导致大量假违例，然后你开始怀疑设计；细粒度做法是按时钟路径、数据路径、单元延迟、线延迟分别设，甚至用 AOCV/POCV 那种基于级数和分布的表。

一段可抄的骨架大概长这样：

# sta_signoff.tcl —— 时序签核的最小设定骨架 set DESIGN "soc_top" set PARASITIC "./pex/${DESIGN}_ss_rcmax.spef" ;# 必须与当前 RC corner 同批生成 set LIB_SLOW "./lib/ss_125c_cmax.db" ;# 慢角，看 setup set LIB_FAST "./lib/ff_m40c_cmin.db" ;# 快角，看 hold read_verilog ./netlist/${DESIGN}.v link_design $DESIGN read_parasitics -format SPEF $PARASITIC read_sdc ./sdc/${DESIGN}.func.sdc # derate 先用平台给的基线，再按路径分组细化，不要全局一把梭 set_timing_derate -early 0.97 -late 1.03 set_timing_derate -early 0.99 -cell_delay set_timing_derate -late 1.01 -net_delay # 只报最差的若干条，避免报告几千行没人看 report_timing -max_paths 200 -nworst 5 -slack_lesser_than 0 \ -path_type full_clock_expanded > ./rpt/sta_violators.rpt

-early/-late分别控制最紧和最松两个方向，-cell_delay和-net_delay把单元和线分开，是因为单元延迟的偏差主要由工艺和电压主导，线延迟的偏差还叠了提取误差，两者的合理 derate 量级本来就不一样。-nworst 5是对每条终点路径报 5 条，-slack_lesser_than 0只输出负 slack，这组参数的目的是让报告“能被人读完”——几千行报告等于没报告。

注意 derate 数值必须来自平台基线，不能自己拍。设松了漏检真实违例，设紧了全线告急、团队开始给工具“调参数”，那是另一种翻车。

3.3 signoff corner 的组合不是越多越好

指南的时序章节专门列了 signoff corner。逻辑上要覆盖工艺快慢、电压高低、温度高低、RC 极值的组合，但全组合会爆炸。常见的收法是：setup 用慢工艺、低压、高温，配合 RCmax；hold 用快工艺、高压、低温，配合 RCmin。有一个反直觉点必须记住——温度反转。在低电压下，低温不一定快，某些单元在低温反而更慢，所以 hold 角不能想当然只写低温，要看库的表征结果。

我会把每个 corner 对应的库、SPEF、SDC、derate 组做成一张配置表，脚本按表循环跑，输出统一命名的报告目录。这样做的直接好处是：出了问题时能一眼定位是哪个条件退化，而不是对着一堆rpt1、rpt2猜。

3.4 报告怎么读：三类违例分别处理

拿到报告先别急着修。按我的习惯，先把违例分三类：时钟路径问题（skew、latency、clock gating 引入的偏差）、数据路径问题（组合逻辑太深、扇出过大）、信号完整性问题（串扰导致的延迟变化）。三类对应完全不同的修法，混在一起修只会互相打架。

快速汇总可以用一行命令，把每条路径的 slack 抽出来排序：

# 从 report_timing 输出里抽 slack，按从差到好排序 grep -E '^\s+slack' ./rpt/sta_violators.rpt \ | awk '{print $3}' | sort -g | head -n 20

awk '{print $3}'取的是 slack 数值那一列，具体列号跟工具输出格式有关，第一次用先head看一眼再定。这行命令的价值在于三十秒内知道“最差有多差”——如果最差只有 -8ps，大概率是 derate 偏悲观；如果有 -200ps，那就是真问题，别再调参数了。

4. 电源与物理验证：IR drop、DRC/LVS 的可复现命令

4.1 静态 IR drop 的输入清单

静态压降分析的输入看起来简单，实际上最容易缺项：DEF/LEF 要跟最新版图一致，电源网格的金属层定义要和工艺文件里的电阻率对得上，功耗文件必须来自同一个 corner 的时序分析，pad 位置和封装模型也要给。少任何一项，结果都不具备参考价值。

判据方面，指南给的是相对压降的概念——最坏点的压降占标称电压的比例。具体门限以平台文档和项目约定为准，我不在这里写死数字，因为不同 IP 容忍度差很多。实践中的做法是：先跑一遍全芯片静态压降，找出 worst 点分布的规律（是集中在某个模块，还是均匀偏高），再决定要不要细化网格或者加 decap。

一个常被忽略的细节是：静态分析用的功耗是平均功耗，它回答的是“电网够不够粗”，不是“瞬间会不会塌”。这两件事必须分开看。

4.2 动态压降：向量选错，结果全是假的

动态压降依赖翻转活动，翻转活动来自仿真向量。这里有个很坑的地方：用扫描测试向量跑出来的动态压降通常比功能向量更恶劣，但扫描模式的时序要求跟功能模式不一样，直接拿它的结论去改功能模式的电网会过度设计。反过来，如果只用手工造的少数功能向量，覆盖率不够，压降图会漂亮得不真实。

我一般的做法是：功能模式下挑几个翻转最密集的时间窗口，扫描模式下单独跑一遍作为参考，两份结果分开出报告、分开下结论。仿真窗口的选取也有讲究——要看峰值电流出现的那段时间，而不是随便截一段波形。

4.3 DRC/LVS 批处理与结果分类

物理验证这一章指南讲得比较细，DRC、LVS、PEX 三节分开写。落到实处，批处理脚本要保证两件事：rule deck 只有一份、失败立即停。

#!/usr/bin/env bash # pv_batch.sh —— DRC + LVS 串行批处理，任一步失败立即停止 set -euo pipefail RUN_DIR="./pv/run_$(date +%Y%m%d_%H%M)" mkdir -p "$RUN_DIR" # DRC 与 LVS 用同一份 deck 派生，避免两套 deck 的层号定义漂移 pv -drc -rule ./deck/40ll_drc.rule \ -layout ./gds/${DESIGN}.gds -top ${DESIGN} \ -report "$RUN_DIR/drc.rpt" -threads 16 pv -lvs -rule ./deck/40ll_lvs.rule \ -layout ./gds/${DESIGN}.gds -top ${DESIGN} \ -netlist ./netlist/${DESIGN}_lvs.v \ -report "$RUN_DIR/lvs.rpt" -threads 16 # 汇总关键结果行，方便一眼看结论 grep -Ei 'TOTAL RESULT|ERROR|WARNING' "$RUN_DIR"/*.rpt | tee "$RUN_DIR/summary.txt"

set -euo pipefail是这套脚本的核心：-e保证 DRC 报错时不会继续跑 LVS，-u防止${DESIGN}没定义时静默传空串进去，-o pipefail让管道里的失败也能被捕获。-threads 16按机器核数调，但线程数不是越多越好，某些 deck 在线程过多时内存会炸。最后的grep是给 reviewer 看的，正式判据还是要人工逐条过——DRC 报告里的 WARNING 有些是平台已知的良性项，有些是真问题，工具分不出来。

4.4 顺序问题：DRC、dummy、LVS、PEX 谁先谁后

指南把 dummy insertion 放在可制造性章节，把 PEX 同时放在时序和物理验证章节，这个安排本身就在暗示顺序：DRC 首次通过 → dummy fill → DRC 复审（密度类违例通常在这一步才清零）→ LVS → PEX。LFD 检查一般跟在 dummy 之后，因为填充会改变局部图形密度，光刻友好性要按填完的版图重新评估。

顺序错了的典型症状是：dummy 加完之后 LVS 突然冒出一堆短路，或者 PEX 提出来的网表跟 LVS 网表层次对不上。这类问题不是工具 bug，是流程顺序问题。

5. 避坑与排查：五条从 tapeout 前夜攒下的记录

5.1 时序全绿，重提 PEX 后 WNS 掉了 60ps

现象：签核报告 WNS 是 +12ps，一周后复核变成 -48ps，中间没人改过 RTL。

原因：STA 脚本里的 SPEF 路径是硬编码的，重提之后新文件带了时间戳，旧文件还在原地，脚本读的还是旧的。旧 SPEF 对应的 RC corner 比当前设定的宽松。

解决：SPEF 路径改成变量拼接并在日志里打印实际读入的绝对路径；每次签核前比对文件 mtime 与网表 mtime，网表比 SPEF 新就强制重提。

5.2 LVS 干净，后仿结果对不上

现象：LVS 报告零 error，但后仿的功能行为跟前仿不一致。

原因：只跑了 LVS 没跑 ERC。ERC 查的是衬底接触、浮空栅、电源地短接这类电气规则，LVS 只比拓扑。另外提取时的器件合并选项如果开了，网表层次会和原理图不一致，后仿的激励对不上端口。

解决：LVS 和 ERC 绑定成同一条流水线，任一不过都不算通过；提取网表后先做一次端口对齐检查，再拿去后仿。

5.3 动态压降结果漂亮得不真实

现象：动态压降最大值只有静态的一半，看着非常健康。

原因：仿真向量覆盖率不足，大部分模块在采样窗口里没有翻转，功耗活动文件几乎是空的。

解决：先在功耗分析里看各模块的翻转率分布，跟 RTL 仿真的统计值对比，偏差超过一定比例就换向量重跑；扫描模式和功能模式的报告分开出。

5.4 密度违例加完 dummy 反复出现

现象：DRC 密度违例清了一轮，加完填充又冒出来，来回三次。

原因：填充脚本用的密度目标跟 DRC deck 里的窗口定义不一致，填充工具按自己的格点算，DRC 按另一套窗口算，永远对不齐。

解决：从 DRC deck 里把密度检查的窗口尺寸和层号抠出来，直接作为填充脚本的约束参数，保证两边算的是同一件事；填充后必须重跑 DRC，不能只信填充工具的自检。

5.5 换机器后结果全变，脚本一个字没改

现象：同一份数据在另一台机器上跑，时序报告整体偏移几十 ps。

原因：新机器 PATH 里默认指向的工具版本比旧机器新，新版本改了某些选项的默认值（比如串扰计算的默认开关）。版本矩阵在那台机器上没人核对过。

解决：把 2.2 节那个环境体检脚本放进项目仓库，任何人跑签核前必须先执行，日志随报告一起归档。这件事看起来像流程洁癖，实际上是唯一能自证“结果可比”的手段。

6. EM 与签核收口：把 checklist 变成一次跑完的回归脚本

EM 检查放在指南最后一章，位置很说明问题——它是最容易被砍掉的一项，因为前面的时序、压降、DRC 已经把人耗光了。但电迁移不会因为你没查就消失，它只是在几个月后的可靠性测试里等你。

EM 分成电源 EM 和信号 EM 两类，判据是电流密度，而这个限值本身是线宽、温度、占空比的函数，还分 DC、AC、峰值三种场景。所以做这件事的第一步不是跑工具，而是把每层金属的限值表拿到手，确认你用的温度和占空比假设跟实际工作条件一致。

一个具体技巧：先跑峰值电流密度，再跑平均。峰值违例往往集中在少数几个 via 上，改起来成本低；平均值超标才是真的需要动电网结构。反过来做，你会花大量时间在加宽那些根本不热的线上。

收口阶段我习惯把整份 checklist 写成一个回归脚本，一次跑完所有环节并输出一张 pass/fail 汇总表，而不是靠人记着“还有哪项没跑”。脚本本身没什么技术含量，价值在于它把“签核完成”这件事从口头承诺变成了可复查的文件。

血泪经验是：签核文档里那些看起来像免责声明和流程废话的章节——版本矩阵、表征角覆盖、corner 定义——恰恰是出问题时唯一能救你的东西。真正的技术细节反而在工具手册里都有。从那以后我每次开新项目，第一件事都是把版本矩阵和 checklist 打印出来贴在跑签核的机器旁边，谁跑谁签字，跑完把日志和报告按 corner 归档。希望帮到你。

本文还有配套的精品资源，点击获取