2. 门级网表生成与交付检查

门级仿真的第一步不是写 testbench，而是确认“手上这套交付物”本身是否自洽。综合工具输出的门级网表（通常为 .v 或 .vg）、时序信息（.sdf 或 .lib 中的时序弧）、标准单元库（.db/.lib）以及物理信息（.def/.spef）来自不同工具、不同阶段，任何一处版本错配都会让后续仿真结果失去意义。本节围绕“一致性检查”展开，说明检查什么、怎么查、查到什么程度可以放行。

一、四类交付物的角色与依赖关系

门级网表描述的是实例化的标准单元及其连接关系，它本身不含延迟；延迟来自标准单元库中的时序模型，以及物理信息提取出的互连寄生参数。SDF 文件则是把单元延迟与互连延迟“反标”到网表实例和网络上的载体。四者的依赖关系可以概括为：网表提供“谁连谁”，库提供“单元自身多快”，物理信息提供“线有多长、寄生多大”，SDF 把前两者与互连结合后落到具体实例和网络上。因此一致性检查的核心，是确认这四者描述的是同一个设计、同一个工艺角、同一个版本。

二、网表与标准单元库的一致性检查

最基础也最容易被忽略的一步，是确认网表中出现的每一个单元实例，都能在目标标准单元库中找到对应定义。综合工具在映射时可能使用了某个库中的特殊单元（如时钟门控单元、隔离单元、电平转换器），如果仿真时加载的库版本较旧或缺少这些单元，仿真器会报“module not found”或将其视为空模块，导致功能与延迟全部失真。

实际操作中，可以用脚本从网表中提取所有实例的模块名，去重后与库中单元列表做差集。例如网表中出现 CLKGATETST_X1、ISOLATION_X2、LVLHL_X1 等单元，而库中只有基础逻辑单元，差集就暴露了缺失项。此外还要检查库中是否包含网表用到的所有时序弧：某些单元在库中只有功能模型而无时序模型，仿真时该单元路径会被当作零延迟，掩盖真实时序问题。

三、SDF 与网表、库的匹配检查

SDF 反标是门级仿真最关键的一步。反标时仿真器会按“实例名 + 端口名”去 SDF 中查找对应的延迟值。如果网表在综合后被重命名、优化或层次被展平，而 SDF 是基于另一版本网表生成的，就会出现大量“未匹配”告警。检查方法是：在仿真日志中搜索 Warning: SDF annotation 或 Failed to annotate 关键字，统计未反标比例。工程上通常要求关键路径上的反标率达到 100%，整体反标率不低于 95%，否则需要重新生成 SDF 或核对网表版本。

另一个高频问题是时间单位不一致。SDF 头部会声明 (TIMESCALE 1ns) 或 (TIMESCALE 1ps)，而网表或仿真器的 timescale 可能是 1ns/100ps。若两者不一致，延迟会被放大或缩小 1000 倍。检查时直接比对 SDF 的 TIMESCALE 声明与仿真命令中 -timescale 设置，确保量纲统一。

四、物理信息与网表的对应检查

物理信息中的 DEF 描述布局后的实例位置与网络连接，SPEF 描述提取出的寄生电阻电容。它们与网表的对应关系体现在实例名和网络名上。如果网表在布局后又被修改（如插入缓冲器、优化逻辑），而 DEF/SPEF 未同步更新，就会出现实例找不到、网络名不匹配的问题。检查方法是：从 DEF 中提取实例列表，与网表实例列表做交集比对；从 SPEF 中提取网络列表，与网表网络列表比对。对于缺失的网络，其互连延迟将无法反标，只能按零处理，导致时序过于乐观。

五、可执行的交付检查清单

把上述检查固化为一份可执行的清单，每次交付前逐项确认，能显著降低“仿真跑通但结果不可信”的风险。以下清单中的参数为示例阈值，实际项目应根据工艺节点和签核要求调整。

一致性检查的本质，是确保“网表、库、SDF、物理信息”四份文件描述的是同一个设计、同一个工艺角、同一个版本。检查顺序建议从网表与库的单元匹配开始，再到 SDF 反标率与时间单位，最后核对物理信息。每一步都留下可量化的判断依据，而不是凭感觉放行。只有交付物自洽，后续的门级仿真结果才具备参考价值。