2. 签核环境与数据准备
签核（signoff）阶段最昂贵的错误，往往不是工具跑不出来，而是环境与数据本身不一致：工具版本与工艺库不匹配、约束文件里残留了综合阶段的理想化假设、网表与寄生参数来自不同版本的布局布线结果。这类问题通常不会让工具报错，却会让时序、功耗、噪声的结论整体偏移。因此，在启动任何签核分析之前，必须先完成一次系统性的环境与数据自检。
一、工具版本：签核结论的可复现基线
签核工具链通常包含静态时序分析（PrimeTime / PrimeTime SI）、功耗分析（PrimePower / PrimeShield）、物理验证（IC Validator / Hercules）、寄生参数提取（StarRC）等。每个工具都有版本号与补丁号，例如 PrimeTime T-2022.03-SP3。签核前需要确认三件事：
- 版本一致性：同一项目内所有签核工具应来自同一 Synopsys 发布周期（如 T-2022.03），避免跨版本混用导致模型解析差异。
- 补丁级别：SP（Service Pack）补丁常修复时序计算、噪声模型或库解析缺陷。若项目基线要求 SP3，而实际使用 SP1，某些路径的 slack 可能相差数十皮秒。
- 许可证与特性：SI（信号完整性）分析、POCV（参数化片上偏差）等特性需要对应 license feature，缺失时工具会静默降级为简化模型。
建议在签核脚本开头显式打印版本信息，并写入日志，作为可追溯基线：
puts "PT version: [sh which pt_shell]"
puts "PT build : [sh pt_shell -version]"
puts "StarRC : [sh which StarRC]"
puts "ICV : [sh which icv]"
二、工艺库：从 .db 到 .lib 的一致性核对
签核使用的工艺库通常以 .db（二进制）形式被工具读取，但其源头是 .lib（Liberty）。需要核对的关键点包括：
- 库版本与工艺节点：确认
tcbn28hpcplusbwp30p140这类库名与项目 PDK 版本一致，避免误用不同 metal stack 或不同 Vt 档位的库。 - 操作条件（Operating Conditions）：签核通常需要同时加载 WC（worst-case）、BC（best-case）、TC（typical-case）三套条件，并确认
set_operating_conditions与库中定义的nom_voltage、nom_temperature、nom_process对应。 - PVT 角与 derate：确认是否启用 AOCV/POCV 库，以及
set_timing_derate的数值是否与签核规范一致。 - 库单元完整性：检查网表中引用的每个 cell 都能在库中找到，尤其是 level shifter、isolation cell、retention flop 等特殊单元。
check_library 与 report_lib 交叉验证库加载结果，并统计网表中未匹配的 cell 数量，若不为零则必须先解决。三、约束文件：从综合假设到签核现实
约束文件（SDC）是签核的“法律”。常见问题包括：时钟定义不完整、set_false_path 过度使用、set_clock_groups 未覆盖异步域、输入输出延迟未按板级实际更新。签核前应逐项检查：
- 时钟定义：
create_clock的周期、波形、source latency 是否与最终 PLL/时钟树一致。 - 时钟关系：同步时钟是否用
set_clock_groups -asynchronous正确隔离，避免工具对异步域做无意义的时序分析。 - 例外路径：
set_false_path、set_multicycle_path是否有注释说明来源，避免“祖传约束”掩盖真实违例。 - I/O 约束：
set_input_delay/set_output_delay是否基于最终封装与 PCB 模型更新。
一个实用的做法是生成约束覆盖率报告：统计所有时序端点中，被时钟覆盖、被例外覆盖、以及完全未约束的比例。未约束端点若超过阈值，签核结论不可信。
四、网表与寄生参数：签核数据的“最后一公里”
签核网表通常来自布局布线后的 post-route netlist，寄生参数来自 StarRC 提取的 SPEF。两者必须来自同一次 P&R 运行，否则会出现“网表里有这条 net，SPEF 里没有”或“SPEF 里的 RC 对应旧版布线”的错位。
检查要点：
- 网表与 SPEF 的 net 名一致性：用脚本比对网表中所有 net 与 SPEF 中
*D_NET条目，统计缺失率。 - 寄生参数角：确认 SPEF 覆盖 Cworst、Cbest、RCworst、RCbest 等签核所需角，且与库的 PVT 角对应。
- 单位与缩放：SPEF 中的电容单位（pF/fF）、电阻单位（ohm/kohm）、时间单位（ns/ps）必须与工具设置一致，否则 RC 计算会整体偏差。
- 耦合电容：若做 SI 分析，需确认 SPEF 包含耦合电容（
*CAP中的 coupling 项），而非仅对地电容。
五、环境自检流程与判据
把上述检查组织成一次可重复执行的自检流程，可以用下面的信号链来理解：从工具版本、工艺库、约束、网表、寄生参数五个输入，经过一致性核对，最终输出“可签核”或“需修复”的结论。
实际执行时，可以把上述核对写成 Tcl/Python 脚本，在签核流程入口自动运行。例如用 Tcl 统计未约束端点：
set all_endpoints [all_registers -data_pins]
set constrained 0
foreach_in_collection ep $all_endpoints {
if {[get_attribute $ep clocks] ne ""} { incr constrained }
}
puts "Total endpoints: [sizeof_collection $all_endpoints]"
puts "Constrained : $constrained"
puts "Unconstrained : [expr [sizeof_collection $all_endpoints] - $constrained]"
对于网表与 SPEF 的 net 比对，可以用 Python 快速实现：
import re
netlist_nets = set(re.findall(r'\b(\w+)\s*\(', open('netlist.v').read()))
spef_nets = set(re.findall(r'\*D_NET\s+(\S+)', open('design.spef').read()))
missing = netlist_nets - spef_nets
print(f"netlist nets: {len(netlist_nets)}, spef nets: {len(spef_nets)}")
print(f"missing in spef: {len(missing)}")
当所有检查项通过后，才进入真正的签核分析。此时得到的时序、功耗、噪声结果才具备工程可信度。反之，若跳过这一步，后续所有优化都可能建立在错误的数据基线上，返工成本极高。