企业官网建设流程全解析

简介：面向SMIC 40LL工艺的IC设计与签核工程师，这份Design Sign-off Guideline用于梳理流片前设计签核的规范、检查项与交付要求，帮助版图、物理验证及项目负责人统一对签核标准的理解。包内共1个PDF文件，大小约2.18MB，以36页文档形式呈现，内容围绕40LL设计签核指南展开，并附有SMIC免责声明与保密使用说明，便于按章节查阅和团队内部对照。目前已有496人学习下载，适合需要快速了解SMIC 40LL签核流程、准备设计交付自查或开展新人培训的从业者参考。文档可用于核对签核项目、整理检查清单及理解官方文档结构，但涉及保密与知识产权条款，使用时应遵守SMIC授权范围。

1. 一颗 40LL SoC 的成败，经常在签核阶段才决定

40LL 平台上的第一颗 SoC，常常失败在签核阶段，而不是设计阶段，而不是设计阶段。前端仿真全过、时序看起来收敛、DRC 跑出来一片绿，结果 tape-out 评审会上被问一句“你的动态压降用什么激励跑的、PEX 用的是哪个 RC corner”，当场就说不出来。这份 40LL sign-off 签核指南要解决的就是这件事：把“我觉得没问题”变成“每一步都有报告、每份报告都有判据、每个判据都有版本可查”。它面向的是用 40LL 工艺做同步 SoC 的团队——可以是第一次流片的学生课题，也可以是赶 schedule 的工程团队，只要你要交一份能被别人复核的签核结论，这套结构就能直接参考。

2. 参考流程与工具版本基线：五道签核环节和一张版本锁定表

签核这件事最怕两种情况：一种是把所有检查堆到最后一周一起跑，报告出来发现问题时版图已经动不了了；另一种是报告齐全但没人说得清每条结论是在哪个工具版本、哪个规则 deck、哪个库 corner 下得出的。前者是排期问题，后者是基线问题，而基线问题更致命——同一份网表，工具小版本差一个补丁，时序结果能差出几十 ps，这种玄学背后其实全是版本。

2.1 五道签核环节与交付物定义

一份合格的 40LL 签核方案，通常把流程切成五道依次通过的环节，而不是一堆并列的检查项。时序签核负责建立时间、保持时间与时钟质量；功耗签核负责静态 IR drop 与动态压降；物理验证负责 DRC、LVS、ERC 和天线规则；可制造性负责光刻友好性检查与 dummy 填充；可靠性负责电迁移与老化。前四道是能挡住流片的硬性环节，第五道是决定产品寿命的软性环节，很多团队会把第五道往后放，最后被 EM 违例逼着重铺电源网格，这是典型的因优先级判断错位而返工。

每道环节的交付物不只是“一份报告”，而是四件套：可复现的运行脚本、原始报告、结论摘要、结论所依赖的版本记录。我一般要求摘要里必须写明三件事——覆盖了哪些 corner、有哪些违例被 waiver 及理由、哪些项是本轮未覆盖。没有这三行字的报告，评审时基本等于没跑。

提示：如果标准单元库来自第三方库厂商而不是工艺平台自带，签核判据要按库厂商给出的清单执行，不能直接套用平台默认值，两边对同一根路径的 derate 口径可能不一致。

2.2 版本锁定表：版本不是越新越好

签核规则 deck 和工具版本是互相绑定的。规则 deck 里的某些检查项依赖工具的语法支持，工具太老跑不动新 deck，工具太新又可能对老 deck 的写法给出不同解释。所以正确做法是先锁定一条经过验证的工具链基线，再在这个基线上做设计，而不是每次出问题就升级工具。下面这张表是我一般会在项目启动会上就贴出来的版本基线，数字只是示例，具体以你们平台提供的对照表为准。

表里最右边那列“备注”是真正值钱的部分。很多团队只抄版本号，结果综合用 A 线、P&R 用 B 线，时序模型里的单元延迟特征在两个工具间存在细微差异，最后签核时对不上，白白花两周查一个本来不存在的“时序违例”。凡是跨线混用，都必须在项目早期做一次小规模对标：同一份网表、同一套约束、同一个 corner，两边 WNS 差多少，超过判据就得统一到一条线上。

2.3 工程目录与一键复现脚本

基线定下来之后，落地方式是目录结构。签核工程的目录要按“输入、脚本、输出、版本”四分离，不要把所有东西堆在一个目录里靠文件名区分。下面这个骨架我用了很多次，好处是任何人接手时能在三十秒内找到某份报告是用哪个脚本、哪个 corner 跑出来的。

# 签核工程根目录：按 输入/脚本/输出/版本 四分离 export SIGNOFF_ROOT=$PWD/40ll_signoff mkdir -p $SIGNOFF_ROOT/{lib,netlist,spef,sdc,scripts,decks,run,rpt,waiver,version} # 1) 版本落盘：每次跑签核前先冻结一次基线，只追加不覆盖 { echo "date: $(date '+%Y-%m-%d %H:%M')" echo "sta_tool: $(sta_shell -version 2>/dev/null | head -1)" echo "drc_deck: $(md5sum $SIGNOFF_ROOT/decks/drc.rule | cut -d' ' -f1)" echo "lib_set : $(ls $SIGNOFF_ROOT/lib | sort | md5sum | cut -d' ' -f1)" } >> $SIGNOFF_ROOT/version/baseline.log # 2) 一键复现：corner 由清单驱动，避免手工敲错组合 for c in $(cat $SIGNOFF_ROOT/scripts/corner.lst); do # corner.lst 每行格式：名称,库文件,SPEF文件,SDC文件 sta_run -corner "$c" -out "$SIGNOFF_ROOT/rpt/$c.rpt" || exit 1 done

这段脚本有两个设计点值得说。第一，baseline.log只追加不覆盖，工具版本、规则 deck 的校验和、库文件集合的校验和三样东西一起记录下来，出问题时能直接定位是不是基线漂移。第二，corner 组合由一个corner.lst清单驱动，而不是写在脚本里的 hardcode，这样新增一个温度点或 RC corner 只改一行清单，不会漏跑。清单本身也进版本库，评审时把清单和报告一起交，覆盖度就有据可查。

3. 时序签核：库表征、PEX、OCV 与 corner 的四层组合

时序签核是整份方案里最容易“看起来做完”的部分——报告能出、路径能列、数字好看，但结论未必站得住。原因在于时序结论是四层输入叠出来的：库的表征条件、寄生的提取精度、OCV 的施加方式、corner 的组合覆盖。任何一层错位，最终 WNS 都能被“修”成正的，只是修错了地方。

3.1 先确认你手上的库是哪一类表征

40LL 平台的标准单元通常按轨道高度、栅长和阈值电压分档。常见的是 8 轨道（8T）基础库，栅长分两档，阈值电压从常规阈值一路到超低阈值四档；此外还有电源管理专用库和 ECO 专用库。轨道高度决定单元面积和驱动能力，阈值电压决定漏电与速度的取舍，这两件事在签核阶段必须写清楚，因为它们直接影响时序库与功耗库的配对关系。

真正容易翻车的是表征条件。同一档位的库，会分别在若干组工艺、电压、温度、寄生条件下做特征化，签核时库文件必须和你要分析的 corner 一一对应。低阈值库配慢速 corner 的分析结果，和高阈值库配快速 corner 的结果，放在一张表里比较是没有意义的。我的习惯是先做一张“库—corner 对照表”，把每个库文件对应的电压、温度、RC 条件列出来，再和 corner 清单交叉验证，缺哪个就补哪个，绝不靠“差不多”糊过去。

还有一点常被忽略：ECO 库的覆盖范围和基础库不同。做时序 ECO 时如果用了 ECO 库里没有的单元，工具可能静默替换成基础库的等价单元，面积和延迟都会变，最终版图和网表对不上。这种问题在 LVS 阶段才暴露，返工成本极高。

3.2 寄生提取：Cmax、Cmin 与耦合电容的处理

寄生提取是时序精度的地基。提取要给的不是一个数，而是至少三个 RC corner：最差电容、最好电容和典型值，有些团队还会补上电阻最差的情形。提取工具版本、提取用的工艺文件版本、以及提取时的精度档位，三样必须和库文件同源。我见过最典型的翻车是：库是新一轮特征化的，SPEF 却还是上一轮工艺文件提出的，两者对同一层金属的单位电容假设不同，时序结果偏差被误判成设计问题，查了一周才发现是数据不配套。

耦合电容的处理方式直接决定要不要做串扰分析。提取时若不保留耦合电容、直接按 Miller 系数折算成对地电容，速度快但会丢掉串扰引起的延迟变化；若保留耦合关系，就要在时序工具里开启串扰分析，并设定合理的切换窗口和传播条件。40LL 这个节点上，长并行走线的串扰影响不能忽略，我一般要求关键模块必须做带串扰的时序分析，非关键模块可以先用折算电容做快速迭代，但最终签核必须切回耦合模式重跑一次。

注意：SPEF 里的网络数量和网表里的网络数量要对得上。差几个往往是提取时开了过滤，把某些网络或器件过滤掉了，这种情况下的时序结果是残缺的。

3.3 OCV、AOCV、POCV 与时钟共同路径悲观移除

片上偏差的建模方式有三代：单一的全局 derate、按路径深度和物理距离查表的 AOCV、按统计分布建模的 POCV。三者的差别不在精度高低，而在你能否解释清楚每个数字的来源。全局 derate 简单，但对短路径过于悲观、对长路径过于乐观；AOCV 引入了级数与距离维度，需要库厂商提供对应的降额表；POCV 用均值和标准差描述，签核时看的是几个 sigma。

不论用哪种方式，时钟共同路径悲观移除必须打开。否则同一段时钟路径在发起端按最慢算、在捕获端按最快算，凭空造出一段不存在的悲观量，你会为了修一个假违例去改本来正确的时钟树。开启之后还要确认工具确实识别到了共同路径节点，有些情况下时钟树综合后插入的缓冲器命名规则变化，会导致共同路径识别失败，报告里的悲观移除量变成零，这时候的时序结果是偏悲观的，别高兴太早也别急着修。

derate 的数值来源也要写清楚：是平台推荐值、是库厂商提供值、还是团队根据硅数据回归出来的值。三者可以不同，但必须在报告摘要里注明，答辩时这是必问项。

3.4 corner 组合与签核判据

corner 覆盖的原则是“每个物理机制至少有一个 corner 能暴露它”。建立时间看慢速高压高温之外，还要看慢速低压低温；保持时间看快速低压低温，同时不能漏掉高温下的温度反转——40LL 这类节点上，温度升高反而使某些路径变快，保持违例会在高温快速 corner 冒出来。下面这张表是我一般会用的最小覆盖集。

判据不能只看最差松弛。我的做法是四项一起看：最差负松弛、总负松弛、违例路径条数、违例路径的分布（集中在哪几个模块、哪几级逻辑）。只盯最差值容易漏掉“一堆小违例”，而这类违例往往说明约束本身有问题，比如某条跨时钟域路径没设虚假路径，工具在拼命修一条根本不需要修的路径。例外路径的审查要和时序报告一起做，先确认约束正确，再谈收敛。

3.5 一份可复用的时序签核脚本骨架

脚本层面的关键不是命令多，而是每一条命令都能对应到上面某一层输入。下面这段骨架按“读库—读网表与寄生—读约束—施加偏差—出报告”的顺序组织，注释里写清了每一步为什么这么做。

# 1) 读库：慢速库与快速库成对载入，禁止混用不同特征化条件的库 read_lib $LIB/slow_lowv_hot.lib read_lib $LIB/fast_highv_cold.lib # 2) 读网表与寄生：SPEF 必须与当前 RC corner 严格对应 read_netlist $NETLIST/post_pnr.v read_parasitics -corner rc_max $SPEF/rc_max.spef read_parasitics -corner rc_min $SPEF/rc_min.spef # 3) 约束：功能模式与时序例外一并读入，避免工具修无效路径 source $SDC/functional.sdc source $SDC/exceptions.sdc # 4) 片上偏差：时钟与数据分别施加，早/晚两侧成对出现 set_timing_derate -early 0.97 -clock set_timing_derate -late 1.03 -clock set_timing_derate -early 0.98 -data set_timing_derate -late 1.05 -data # 5) 时钟共同路径悲观移除，必须打开 set_app_var timing_remove_clock_reconvergence_pessimism true # 6) 报告口径：只报负松弛路径，条数固定，便于跨轮次对比 report_timing -delay_type max -max_paths 200 -slack_less_than 0 \ -nworst 1 > $RPT/setup_${CORNER}.rpt report_timing -delay_type min -max_paths 200 -slack_less_than 0 \ -nworst 1 > $RPT/hold_${CORNER}.rpt

第 4 步的 derate 是示例值，实际数值要按 3.3 节说的方法确认来源。第 6 步把报告条数固定成 200 条，是为了让不同轮次的报告可以直接做差集比较——这一轮比上一轮多了哪几条违例、少了哪几条，比只看 WNS 数字有用得多。如果违例超过 200 条，说明还没到签核阶段，先回去收敛。

4. 功耗、物理验证与可靠性：三块最容易拖到最后一刻的签核

时序收敛之后，很多团队会松一口气，然后被功耗和物理验证打回原形。这两块的共同点是：问题往往不是设计逻辑错，而是版图实现和物理效应之间的耦合——电源网格铺得够不够、填充做得干不干净、电流密度算得对不对。它们没法靠改 RTL 解决，只能回到版图层面。

4.1 静态 IR Drop：先看网格拓扑，再看压降数字

静态压降分析的本质是求解一个电阻网络。输入的完整性决定结果的可信度：需要版图的 DEF、单元和宏的库信息、电源意图描述（电源域划分、开关单元位置）、以及各单元的功耗值。少一样，工具会给你一个数，但那个数是“某个假设下的数”，不是你设计的数。

分析之前先做拓扑检查，比看报告更有价值。检查三件事：电源网格在每一层金属上的走向和宽度是否与规划一致、过孔阵列是否在交叉点密集布置、电压域边界处的电源开关单元是否连续。我一般会先出一张各层金属的电流密度分布图，看有没有明显的瓶颈点——如果某个区域的电流全部要经过一条窄金属过，那压降数字再怎么调参数也好看不了。

判据通常按标称电压的百分比设定，静态压降控制在 5% 以内是常见口径，但这个值必须和平台给出的限制核对，不同电压域、不同单元类型可能不同。更稳妥的做法是分层看：核心逻辑域、存储器域、模拟域各自设限，取最严的那个作为整体结论。报告里除了最大压降点，还要给出去掉前后 1% 极值点之后的分布，防止个别孤立点掩盖整体偏高的事实。

4.2 动态压降：激励从哪来决定一切

动态压降的难点从来不是工具，而是激励。用真实波形跑最准，但波形往往覆盖不全；用无向量概率传播跑得快，但对峰值电流的估计偏保守或偏乐观。实际项目里我一般两条路都跑：先用无向量方式做全芯片扫描，找出压降热点区域；再针对热点区域用真实波形做局部精细分析，两者结论不一致时以波形分析为准。

波形选择上有几个细节：波形要覆盖同时翻转概率最高的场景，而不是平均活动率最高的场景；时间窗口要和时钟树的传播延迟对齐，否则峰值电流出现时刻对不上；多电压域设计要确认每个域的开关行为是否在同一时刻发生，同时开关带来的峰值叠加是最常见的动态压降来源。

片上去耦电容的作用要单独评估。工具报告的压降是考虑去耦之后的净值，但去耦电容本身的有效性受版图位置、电源网格阻抗、以及工作频率影响。频率接近去耦网络谐振点时，去耦效果会显著下降，这时候压降曲线会出现一个凹坑。稳妥的做法是扫一遍频率，看压降随频率的变化趋势，别只跑一个目标频率就下结论。

4.3 DRC 与 LVS：把假错和真错分开

物理验证跑出来的违例，一半以上是“假错”——不是设计违反了规则，而是验证环境不完整。常见的假错来源有：缺少填充导致密度检查不过、缺少密封环导致边界规则报错、层次化单元未按规则展平、以及规则 deck 版本与工艺版本不匹配。分辨假错的方法很简单：看违例的分布形态。真错通常集中在特定结构或特定模块，假错往往沿着芯片边界、沿着空白区域均匀分布。

LVS 的问题更隐蔽。报告写着“一致”，但器件数、网络数、参数对不上，这种情况不能算通过。必须逐项核对：器件总数、各类器件分别的数量、电源和地网络是否短路、衬底接触是否完整、器件参数（宽长比、并联数）是否与原理图一致。我见过最坑的一次是 LVS 通过但提取后的网表器件数比原理图少几十个，原因是提取时开了过滤把某些小尺寸器件滤掉了，时序结果因此偏乐观。

天线规则和电学规则检查要和 DRC 一起跑，不要放到最后。天线违例的修法通常是加跳层或加二极管，前者影响时序，后者影响面积和漏电，越晚修代价越大。

4.4 光刻友好性检查与 dummy 填充：顺序错了就白干

光刻友好性检查是通过模式匹配找出在光刻工艺下容易失真的图形组合，输出的是热点坐标。这些热点不是 DRC 违例，规则检查抓不到，但对良率的影响实实在在。处理方式通常是修图形或者改走线，修完要重新跑一遍确认热点消失，而不是“改了就完事”。

dummy 填充的目的有两个：满足各层金属密度的上下限窗口，以及改善化学机械抛光后的表面均匀性。填充的坑在于它会改变寄生参数。填充金属和信号线之间产生耦合电容，原本收敛的时序可能因此出现新的违例，尤其是长距离并行走线附近。所以正确的迭代顺序是：先做功能布线和时序收敛，再做填充，填充后重新提取寄生、重跑时序，必要时只对受影响的局部区域调整填充图形。反过来做——先填充再收敛时序——几乎必然返工。

密度检查要按层看，不只看全芯片平均值。某层金属局部密度过低会在抛光时形成凹陷，过高则可能影响刻蚀均匀性，两个方向都要设限。密度梯度也是常见检查项，相邻区域的密度突变同样会带来问题。

4.5 电迁移检查：三个电流口径别用错

电迁移检查的核心是电流密度与寿命的换算。这里有三个电流口径必须分清：平均电流决定金属的长期迁移，均方根电流决定焦耳热引起的温升，峰值电流决定瞬时冲击。用平均电流去查本该用均方根电流的规则，结果会偏乐观；反过来则过度保守，逼着你无谓地加宽金属。

检查对象也要分清。电源网格的电迁移和信号线的电迁移是两套判据：电源网格承受的是单向大电流，方向固定，失效模式以空洞和短路为主；信号线是双向翻转电流，平均电流接近零，主要看均方根值和峰值。不少团队只查电源网格就以为做完了，实际上高速信号线的电迁移问题在高温下同样会暴露。

寿命目标要在项目早期定下来。常见口径是按目标结温下工作若干年（比如十年）不失效率超过某个比例，这个目标会直接换算成允许的电流密度上限。目标定得晚，等到检查发现大面积违例时，改电源网格的代价已经很高了。

5. 避坑与常见问题排查：五个把签核拖回起点的地方

签核阶段的时间损失，八成来自五类重复出现的问题。它们不是技术难点，而是流程和口径上的疏漏，但每一个都足以让进度倒退一到两周。

5.1 corner 组合拼错，时序假通过

现象：某个 corner 下时序全绿，换到相邻 corner 突然出现大量保持违例，两条路径的延迟差出几百皮秒。原因通常是库文件和 SPEF 不属于同一个 corner，或者清单里某一行的库文件名写错但仍能正常读入。解决方式是加一道自动自检：解析 corner 清单，把库文件与 SPEF 的命名规则做匹配校验，不匹配直接报错退出，别让它跑完再人工看。另外，清单里每个 corner 至少要标注库的电压温度标签，人工也能一眼看出错配。

# 校验 corner 清单：库文件标签必须与 SPEF 的 RC 标签匹配 import csv, re, sys PAIR = {"slow": "rc_max", "fast": "rc_min", "typ": "rc_typ"} bad = [] with open("scripts/corner.lst") as f: for row in csv.DictReader(f): lib_tag = re.search(r"(slow|fast|typ)", row["lib"]).group(1) # SPEF 文件名里必须带对应的 RC 标签，否则判为错配 if PAIR[lib_tag] not in row["spef"]: bad.append(row["name"]) if bad: sys.exit("corner 错配: " + ",".join(bad)) print("corner 清单校验通过")

这段脚本放在流程最前面，比跑完两小时再发现错配划算得多。校验规则本身很简单，价值在于把它变成流程里不可跳过的一步。

5.2 加完填充，时序和 DRC 一起回退

现象：填充前时序收敛、DRC 干净，填充后出现新的建立违例和一片密度违例。原因有两层：填充金属引入了额外耦合电容，同时填充图形可能压到了本不该碰的间距规则。解决办法是把填充做成局部迭代——按区域分块填充，每填完一块就重提该区域的寄生并局部重跑时序，发现问题只回退这一块。全芯片一次性填充再整体重跑，返工成本会翻好几倍。

5.3 压降报告很漂亮，动态一跑就崩

现象：静态压降报告最大压降只有百分之一二，看起来余量充足，但动态分析在某个模块附近出现明显凹陷。原因通常是静态分析用的是平均功耗，掩盖了局部同时翻转带来的峰值电流；或者动态分析用的波形活动率设置过低。解决办法是拿顶层仿真波形统计各模块的翻转率分布，取高分位而不是平均值作为动态分析输入，同时核对去耦电容在版图上是否真的覆盖到了热点区域。

5.4 LVS 通过但提取网表对不上

现象：LVS 报告一致，但提取后的网表器件数与原理图差几十个，或者某些网络的寄生值明显偏小。原因多半是提取时开了网络或器件的过滤选项，或者是提取精度档位设得太低、把短线段合并掉了。解决办法是提取配置里显式关闭过滤，先用高精度档位对关键模块单独提取做交叉验证，确认数量一致后再切回全芯片档位。数量一致性检查应该写进流程，作为提取完成的判定条件。

5.5 工具或规则 deck 中途升级，结论全部作废

现象：项目跑到一半，工具出了新补丁、规则 deck 也更新了版本，重跑之后原本通过的项开始报违例。原因是新版本对某些规则的判定更严格，或者对时序模型的处理方式有变化。解决办法不是拒绝升级，而是把升级当成一次正式的基线变更：先在分支上跑完整套签核，对比新旧结果的差异清单，逐条判断差异是“修好了”还是“变严了”，确认可接受后再合并基线，并把变更记录写进版本日志。

6. 验收与答辩：用一张签核清单把方案讲成闭环

到了要交结论的时候，评审关心的不是你跑了多少条命令，而是这套结论能不能被别人复核。我一般会准备一张签核清单，每行一个检查项，四列：检查项、证据文件路径、判据、责任人。检查项按五道环节分组，证据文件必须是能直接打开看的原始报告而不是口头描述，判据写具体数字或规则条目，责任人写人名而不是“团队”。这张表往投影上一放，评审的提问方向立刻从“你到底做没做”变成“这一项为什么这么定”，主动权就回来了。

答辩时有四类问题几乎必被问到，提前准备好答案能省很多时间。第一类是“corner 为什么是这几个”，答案要落到物理机制上——温度反转、RC 极值、电压容差各自对应哪个 corner。第二类是“derate 数值哪来的”，要么是平台推荐、要么是库厂商提供、要么是硅数据回归，说清来源并说明为什么适用于这个设计。第三类是“waiver 凭什么通过”，每一条 waiver 都要有失效机理分析和风险评估，不能只写“影响可忽略”。第四类是“如果下个月规则 deck 更新，你的结论还成立吗”，答案是版本基线和差异评估流程，而不是“应该没问题”。

我吃过一次亏：第一版方案里所有报告都齐，唯独没有版本记录，评审问到某条时序结论用的是哪版提取文件时，翻了半天找不到，最后整轮重跑。从那以后我每次开签核工程，第一件事就是把版本落盘脚本跑一遍，把库集合校验和、规则 deck 校验和、工具版本三样写进日志，跑完一轮再追加一行。这个习惯看着笨，但它能保证半年后有人问起时，你翻得到。

希望帮到你。

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