芯片设计中的门级仿真（GLS）：从零延迟验证到 SDF 时序反标

前言

RTL 仿真回答"设计逻辑是否符合功能预期"，而门级仿真回答的是另一个问题：当 RTL 被综合成真实标准单元，并加入传播延迟、时钟树、复位树、DFT 与低功耗结构后，系统是否仍能按预期工作？

门级仿真（Gate-level Simulation，GLS）并不是把 RTL 回归在网表上重跑一遍。大型 SoC 的门级仿真速度慢、波形大、调试成本高，真正有效的方法是采用风险驱动策略，把有限的仿真资源集中在 RTL 阶段看不清、静态分析无法覆盖完整动态过程、且硅后最容易失败的场景上。

本文从工程实践角度梳理 GLS 的目标、输入文件、零延迟仿真、SDF 时序反标、关键风险场景、常见问题和推荐流程。

一、为什么需要门级仿真？

1、RTL 仿真的局限性

RTL 仿真运行在理想化环境中，通常无法真实反映：

标准单元的 Clock-to-Q 与组合逻辑传播延迟；
布局布线后的互连 RC 延迟；
物理时钟树和复位树的偏斜与传播行为；
Clock Gating、Scan、Tie Cell、Hold Buffer 等新增结构；
Level Shifter、Isolation、Retention 等低功耗单元；
标准单元时序检查触发后的 Notifier 与 `X` 传播；
不同逻辑路径到达时间不同造成的毛刺；
综合优化、ECO 和 DFT 插入引起的结构变化。

例如，如果一条真实关键路径被错误地设置成 `false_path`，STA 可能不会检查和优化它。带 SDF 的 GLS 虽然不能穷尽所有路径，但有机会在实际业务激励下暴露这类约束错误。

2、GLS 在芯片验证流程中的位置

不同方法解决的问题并不相同：

RTL Simulation ：功能、协议和算法是否正确
LEC ：RTL 与综合网表是否逻辑等价
Zero-delay GLS ：网表、库模型、复位、DFT 和门级环境能否正常运行
SDF GLS ：真实延迟下关键动态场景是否仍然正确

二、GLS 需要哪些文件

一个可运行的门级仿真环境通常包括：

Post-synthesis / Post-layout Gate-level Netlist

Standard-cell Verilog Simulation Model

SRAM / ROM / IO Behavioral Model

Testbench 与仿真激励

仿真器配置和 Source List

SDF 文件

这里有两个容易混淆的概念：

门级网表：描述实例及其连接关系；
标准单元 Verilog Model：描述每个 Leaf Cell 的功能与 `specify` 时序行为。

如果网表中存在：

cpp 复制代码

NAND2_X1 U10 (...);
DFF_X1   U11 (...);

仿真器必须同时读入 `NAND2_X1`、`DFF_X1` 对应的仿真模型，否则会出现 `Unresolved Module` 或 `Undefined Cell`。

SRAM 的 Liberty .lib用于综合与 STA，LEF 用于物理实现，而 GLS 需要的是 SRAM 的 Verilog 行为模型。

三、 3种门级延迟模式

波形为什么会出现毛刺？

零延迟模式下，寄存器输出和组合逻辑在同一个仿真时间点完成传播。加入 SDF 后，传播过程变为：

Clock Edge

↓

Clock-to-Q Delay

↓

不同组合路径依次到达

↓

输出出现短暂中间状态

↓

最终稳定

例如总线正确变化应为：11 → 12

实际波形可能短暂出现：11 → 8 → 12

原因是不同逻辑分支的传播时间不相同。普通同步数据上的短毛刺只要在采样边沿前满足 Setup/Hold，未必造成实际错误；但以下信号上的毛刺必须高度警惕：

Clock；
Asynchronous Reset / Set；
Clock Gate Enable；
Latch Enable；
Memory Write Enable / Chip Select；
Interrupt；
Valid / Ready 等握手控制；
脉冲型异步接

仿真模式	延迟模型	主要适用场景	局限
Zero-delay GLS 零延迟门级仿真	不考虑 Cell 和 Net 延迟	网表冒烟测试、复位与初始化、DFT、基本功能验证	无法反映真实时序、传播延迟和组合逻辑毛刺
Unit-delay GLS 单位延迟门级仿真	为每个逻辑门设置统一延迟	粗略发现 Race、组合环路和仿真调度依赖	不考虑 PVT、单元类型、输出负载和互连 RC
SDF GLS SDF 反标门级仿真	反标 STA 与寄生提取得到的 Cell Delay、Net Delay 和 Timing Check	Setup/Hold 检查、毛刺分析、关键场景验证和功耗活动提取	仿真时间长、调试复杂，通常只能覆盖有限场景和 Corner

工程上最常用的是：先跑通零延迟 GLS，再进行 SDF 时序反标。

1、零延迟 GLS：先证明"网表能正常跑"

零延迟 GLS 使用真实综合网表，但忽略标准单元模型中的路径延迟与时序检查。以 Xcelium/Xrun 为例，概念配置如下：

cpp 复制代码

-define GATE_LEVEL
-f dut_source_list_gls.f
-nospecify
-access +rwc

-nospecify 的含义是忽略标准单元 Verilog Model 中的 specify Block。此时所有门和网络都近似为理想零延迟。

零延迟阶段重点检查：

网表能否 Compile 和 Elaborate；
标准单元、SRAM 和 IO 模型是否完整；
Testbench 是否错误依赖 RTL 内部层次；
上电、复位和退出复位是否正常；
是否出现非预期 `X`；
Clock Gating、Scan MUX 等新增结构是否破坏功能；
关键功能冒烟测试是否通过。

RTL 与门级共用 Testbench

RTL DUT 可能带参数，但综合后参数已经在 Elaborate 阶段固化，因此门级网表通常不再参数化。可以通过条件编译复用 Testbench：

cpp 复制代码

`ifdef GATE_LEVEL
    chip_top dut (
        .clk     (clk),
        .reset_n (reset_n)
    );
`else
    chip_top #(
        .DATA_WIDTH(DATA_WIDTH)
    ) dut (
        .clk     (clk),
        .reset_n (reset_n)
    );
`endif

注意：即使门级 DUT 不再带参数，Testbench 自身仍可能需要相同参数来生成激励和检查预期结果。

2、SDF 时序反标：把真实延迟带入仿真

SDF 全称为 Standard Delay Format。它通常由 Genus、Innovus、Tempus 等工具根据时序库与寄生参数生成：

Liberty + Netlist + RC Parasitics + Analysis View

↓

write_sdf

↓

SDF

↓

$sdf_annotate

↓

Timing GLS

SDF 中常见的内容包括：

`IOPATH`：Cell Pin-to-Pin Delay；
`INTERCONNECT`：实例引脚之间的互连延迟；
`SETUP/HOLD`：建立与保持时间检查；
`RECOVERY/REMOVAL`：异步控制信号释放检查；
`WIDTH/PERIOD`：脉宽与周期检查。

四、SDF 文件

1、Post-synthesis SDF 与 Post-layout SDF

对比项	Post-synthesis SDF（综合后）	Post-layout SDF（布局布线后）
Cell Delay	包含标准单元延迟	包含标准单元延迟
Interconnect Delay	基于线负载模型或物理估算，精度较低	基于实际布线寄生 RC 提取，精度较高
Clock Tree	通常尚未实现，时钟网络接近理想状态	已完成 CTS 和时钟布线，包含真实时钟路径延迟
Via / Metal Layer	缺少准确的金属层、线长和 Via 信息	来自实际 Routing，包含金属层、线长和 Via 的影响
寄生参数精度	较低，以估算数据为主	较高，使用布局布线后的提取结果
主要用途	早期门级功能和初步时序验证	Post-route 门级时序仿真及关键场景验证
与真实芯片的相关性	较低	更接近最终芯片的实际时序行为

后仿通常优先使用 Post-route SDF，因为它包含真实 Wire、Via 与寄生参数信息。

2、$sdf_annotate的基本用法

在 Testbench 中可以条件执行 SDF 反标：

cpp 复制代码

`ifdef BACK_ANNOTATION
initial begin
    $sdf_annotate(
        `SDF_FILE,               // SDF 文件
        dut,                     // 反标作用域
        ,                        // 可选 Config File
        "sdf_annotation.log",    // 反标日志
        "MAXIMUM"                // MINIMUM / TYPICAL / MAXIMUM
    );
end
`endif

对应的 Xrun 配置示意如下：

cpp 复制代码

-define GATE_LEVEL
-define BACK_ANNOTATION
-define SDF_FILE="export/post_route/chip_max.sdf"

-f dut_source_list_gls.f

+sdf_verbose
-sdf_stats reports/sdf_statistics.log

-access +rwc

⚠️注意：**运行 SDF GLS 时必须删除 `-nospecify`**，否则 `specify` Timing Arc 和 Timing Check 被关闭，SDF 很可能无法正确生效。

3、 SDF、网表和库模型必须严格匹配

SDF 反标不是"文件读进来就算成功"。以下内容必须一致：

cpp 复制代码

Netlist Version
Hierarchy / Instance Name
CELLTYPE
Standard-cell Library Version
SDF Scope
Timescale
Min / Typ / Max Selection

SDF 常以三元组表示延迟：

cpp 复制代码

(min:typ:max)

如果文件只写出了 Max 值，例如 (::0.12)，仿真却选择 MINIMUM，可能产生空延迟或 Annotation Warning。

4、如何检查 SDF 是否反标成功

不要只看"仿真跑完了"，至少检查两类文件：

（1）Annotation Log

重点关注：

SDF 是否成功打开；
Design Name 与 Scope 是否正确；
Timescale 是否合理；
Cell Type 是否匹配；
`IOPATH`、`INTERCONNECT` 与 Timing Check 是否反标；
是否存在大量 `Instance Not Found`。

（2）SDF Statistics

建议统计：

cpp 复制代码

Annotated Cell Delay
Annotated Interconnect Delay
Annotated Timing Check
Unannotated Delay
Unannotated Timing Check
Failed Instance
Cell Type Mismatch

少量未反标项可能来自 Filler、Tap、Tie、PG 或其他 Physical-only Cell，但必须分类确认。覆盖率高不等于正确，覆盖率低也不能直接归因于"工具问题"。

五、GLS 验证策略

1、风险驱动的三层GLS

（1）第一层：冒烟测试

目标是证明环境没问题：

网表、库模型和 Testbench 能否正常 Compile/Elaborate；
Clock、Reset 是否可以启动；
系统是否能够完成最小启动序列；
是否存在大量初始 `X` 或模型缺失。

（2）第二层：风险驱动测试

重点攻击门级独有的高风险场景：

复位风险：上电复位、运行中复位、异常恢复、异步释放；
时钟风险：Clock Gating 切换、窄脉冲、丢脉冲、多时钟切换；
时序风险：Max/Min Corner、短路径、敏感控制信号毛刺；
X 风险：未初始化寄存器、悬空输入、默认值和控制信号传播；
实现风险：DFT、低功耗单元、ECO 与综合优化副作用。

（3）第三层：Signoff 验收测试

选择少量但必须通过的系统级场景，例如：

Boot 到可观测的稳定状态；
正常功能进入与退出；
运行中 Reset 后完整恢复；
关键 Clock/Power Mode 切换；
错误注入与恢复闭环；
Scan/Test Mode 的基本连通性。

核心原则是：GLS 测试"门级新增风险"，而不是复制完整 RTL Regression。

2. 三个最值得优先验证的场景

（1）复位与恢复

真实复位树存在传播延迟，不同寄存器不一定在完全相同的时刻退出 Reset。建议至少覆盖：

Power-up Reset；
Reset 在 Clock 稳定前后释放；
数据高速传输过程中的运行中复位；
异常状态下触发复位并重新启动；
Recovery/Removal Violation；
Reset 被 Clock Gate 或低功耗状态阻挡的情况。

不要只验证"复位能拉低"，还要验证**复位后系统能恢复到正常工作状态**。

（2）时钟完整性

RTL 中时钟通常是理想信号，物理实现后却加入了 Buffer、Inverter、ICG、MUX 和测试逻辑。建议检查：

Clock Gating Enable 在边沿附近变化；
时钟源切换是否产生毛刺；
是否存在短脉冲或丢脉冲；
Generated Clock 和 Test Clock 是否正确；
Clock Gate 在 Reset、Scan、Low-power 场景中的行为。

（3）极限时序与敏感控制

常见经验是：

cpp 复制代码

MAX SDF → 重点观察较慢路径与 Setup 场景
MIN SDF → 重点观察较快路径与 Hold/短脉冲场景

但 GLS 不是 MCMM STA。SDF 通常只代表某个特定 Corner/Mode，无法穷尽所有 Path。它的价值是用真实激励观察系统级动态行为，尤其是控制通路上的短脉冲和状态误跳转。

五、X态传播与毛刺

1、Timing Violation 与 X 传播怎么查

标准单元模型中的 Timing Check 触发后，可能：

只打印 Warning；
翻转内部 Notifier；
将寄存器输出置为 `X`；
继续向后传播，最终形成大面积 `X`。

调试时应遵循：

发现大量 X

↓

定位最早出现 X 的时间点

↓

检查同一时刻之前的第一条 Timing Violation

↓

确认是 Setup/Hold、Recovery/Removal 还是 Pulse Width

↓

回查 Clock、Reset、Data 与 SDF Scope

后面出现的数千个 X 往往只是第一个错误的连锁反应。不要从最后一个失败 Checker 倒着猜，应抓住第一处违规和第一处未知态源头。

2、毛刺传播

毛刺是否继续传播，还取决于仿真器采用的延迟模型。

（1）Transport Delay

每个输入脉冲都会在延迟后完整出现在输出端，即使脉冲很窄也不会被过滤。它更接近理想互连模型。

（2）Inertial Delay

逻辑门具有"惯性"。如果输入脉冲短于一定阈值，门来不及完成翻转，脉冲会被过滤。标准单元仿真更常使用这种概念。

对比特性	Transport Delay（传输延迟）	Inertial Delay（惯性延迟）
窄脉冲传播	所有输入脉冲都会传播到输出端	小于拒绝阈值的窄脉冲可能被过滤
Gate 惯性	不体现逻辑门的惯性特征	能够体现逻辑门对短脉冲的过滤能力
Glitch 数量	较多，窄毛刺也会继续传播	相对较少，取决于 Pulse Reject Threshold
输出波形	延迟后完整复制输入波形	只传播宽度足够的有效脉冲
常见应用	互连、理想传输路径	标准单元及组合逻辑门
功耗活动	记录的切换活动可能偏高	可能因过滤毛刺而降低切换活动
功耗估算影响	可能高估 Glitch Power	Reject Threshold 过大时可能低估 Glitch Power

这会直接影响后续功耗估算，因为：

其中 `α` 是 Switching Activity。毛刺越多，记录到 SAIF/VCD 中的翻转活动越高。因此进行向量功耗分析时，应记录所使用的 SDF、Delay Model、Pulse Reject Threshold 和有效仿真窗口。

六、常见误区

误区一：只测功能，不测恢复

只检查计数器、总线或状态机功能，却不验证复位、错误恢复和重新启动。硅后很多问题并非发生在稳定运行阶段，而发生在进入、退出和恢复阶段。

误区二：只跑 Typical Corner

Typical 只能说明典型延迟下场景可运行。至少应根据项目方法学选择 Max 与 Min SDF，分别关注慢路径、短路径、Hold 与 Pulse Width 风险。

误区三：只盯数据通路

真正危险的毛刺通常出现在 Clock、Reset、Enable、Valid/Ready、IRQ、Memory Control 等控制信号上。数据错误可能只影响一个数值，控制错误可能改变整个系统状态。

误区四：忽略默认值和悬空输入

Test、Bypass、Isolation、Scan Enable、Macro 配置脚等输入必须有明确默认值。RTL 中被"友好"初始化的信号，门级环境中未必如此。

误区五：依赖人工看波形

门级波形巨大且毛刺多，人工检查容易漏掉短脉冲和瞬态 `X`。应尽量增加自动 Checker：

全局和关键控制信号 `X` 检测；
Clock 周期与 Pulse Width 监控；
Reset 后状态机合法状态检查；
Valid/Ready 协议断言；
Boot/Recovery 超时检查；
自动汇总 Timing Violation。

七、推荐的 GLS 流程

八、Signoff 前检查清单

1、网表与模型

-网表与 SDF 来自同一版本数据库；

标准单元、SRAM、IO Model 完整；
无 Unresolved Instance；
Testbench 不依赖已变化的 RTL 内部层次。

2、零延迟 GLS

Boot、Reset 和基本功能通过；
无非预期 `X`；
Clock Gating、DFT 和低功耗结构基本正常；
Checker 与 Timeout 生效。

3、SDF 反标

已删除 `-nospecify`；
Scope、CELLTYPE、Timescale 正确；
Min/Typ/Max 选择与 SDF 内容一致；
Cell、Interconnect 与 Timing Check 覆盖率合理；
Unannotated Path 已分类解释。

4、时序与动态风险

无未解释的 Setup/Hold Violation；
无 Recovery/Removal、Pulse Width、Period Violation；
Clock、Reset 和敏感控制信号无危险毛刺；
第一处 `X` 的根因已闭环；
Max/Min 关键场景均有自动结果检查。

九、总结

GLS 的价值不在于"把 RTL 仿真再跑一次"，而在于验证实现阶段新增的真实风险：标准单元传播延迟、互连 RC、复位树、时钟树、DFT、低功耗结构、毛刺与 `X` 传播。

工程上建议遵循四个原则：

先零延迟，后 SDF：先排除环境和功能问题，再引入时序复杂度；
风险驱动，而非全量复制 RTL 回归：重点验证复位、时钟、控制和恢复；
SDF 反标必须可量化验证：检查 Log、Statistics 与未反标项；
自动 Checker 代替人眼看波形：把第一处 Violation、第一处 `X` 和危险毛刺变成可回归的结果。

GLS、STA、LEC 和 CDC/RDC 是互补关系。STA 穷尽检查受约束时序路径，LEC 证明逻辑等价，CDC/RDC 检查跨域结构，而 GLS 用真实场景验证门级动态行为。只有把这些方法组合起来，才能形成完整可靠的数字芯片验证闭环。

芯片设计中的门级仿真（GLS）：从零延迟验证到 SDF 时序反标

前言

一、为什么需要门级仿真？

1、RTL 仿真的局限性

2、GLS 在芯片验证流程中的位置

二、GLS 需要哪些文件

三、 3种门级延迟模式

1、 零延迟 GLS：先证明"网表能正常跑"

2、SDF 时序反标：把真实延迟带入仿真

四、SDF 文件

1、Post-synthesis SDF 与 Post-layout SDF

2、$sdf_annotate的基本用法

3、 SDF、网表和库模型必须严格匹配

4、如何检查 SDF 是否反标成功

（1）Annotation Log

（2）SDF Statistics

五、GLS 验证策略

1、风险驱动的三层GLS

（1）第一层：冒烟测试

（2）第二层：风险驱动测试

（3）第三层：Signoff 验收测试

2. 三个最值得优先验证的场景

（1）复位与恢复

（2） 时钟完整性

（3） 极限时序与敏感控制

五、X态传播与毛刺

1、Timing Violation 与 X 传播怎么查

2、 毛刺传播

（1）Transport Delay

（2）Inertial Delay

六、 常见误区

误区一：只测功能，不测恢复

误区二：只跑 Typical Corner

误区三：只盯数据通路

误区四：忽略默认值和悬空输入

误区五：依赖人工看波形

七、推荐的 GLS 流程

八、Signoff 前检查清单

1、 网表与模型

2、零延迟 GLS

3、SDF 反标

4、时序与动态风险

九、 总结

1、零延迟 GLS：先证明"网表能正常跑"

（2）时钟完整性

（3）极限时序与敏感控制

2、毛刺传播

六、常见误区

1、网表与模型

九、总结