时序例外：false_path / multicycle_path / max_delay

一、从一个问题开始

上两篇我们写了基本时钟约束、IO 约束——给了工具足够的路径信息。但有一个问题没解决：不是所有路径都需要做 setup/hold 检查。

有些路径天生就不该被检查——比如异步时钟域之间的路径、芯片刚上电时的复位信号。有些路径确实需要检查，但不是每个周期——比如 SPI 的数据路径，数据可能在 2~3 个时钟周期后才稳定。

这就是"时序例外（Timing Exception）"要解决的问题。学懂了时序例外，你的 SDC 才真正属于这个设计，而不是一个模板复制品。

二、时序例外的全景

三种时序例外，对应三类场景：

╔══════════════════╦══════════════════╦══════════════════════╗ ║ false_path ║ multicycle_path ║ set_max/min_delay ║ ╠══════════════════╬══════════════════╬══════════════════════╣ ║ 不检查时序 ║ 放宽检查周期 ║ 自定义绝对延迟上限 ║ ║ → 异步跨域路径 ║ → 慢速逻辑路径 ║ → 异步组合信号 ║ ║ → 测试模式路径 ║ → 同步使能路径 ║ → IO 接口组合路径 ║ ║ → 复位路径 ║ → 特定计算路径 ║ → 跨时钟握手信号 ║ ╚══════════════════╩══════════════════╩══════════════════════╝

三、false_path：不存在的路径

3.1 什么时候用

打个比方：一条路从 A 到 B，但中间有扇永远锁着的门——你永远不会走这条路。那就别浪费时间在这条路上设交警查超速了。

具体场景：

3.2 异步时钟域的 false_path 写法

最常见的场景——两个异步时钟域之间的所有寄存器到寄存器的路径：

# ⚠️ 错误写法：只考虑了一个方向 set_false_path -from [get_clocks clk_spi] -to [get_clocks clk_sys] # ✅ 正确写法：两个方向都要设（或者用 clock groups） set_clock_groups -asynchronous \ -group [get_clocks clk_spi] \ -group [get_clocks clk_sys] # 等效于： set_false_path -from [get_clocks clk_spi] -to [get_clocks clk_sys] set_false_path -from [get_clocks clk_sys] -to [get_clocks clk_spi]

注意：set_clock_groups -asynchronous是双向的，而set_false_path是单向的。用 clock groups 更简洁不易遗漏。

3.3 常见错误

# ✗ 错误：对复位端口设 from → 只覆盖了从该端口出发的路径, # 如果复位树有多级内部节点（如 por_b → sftRst → regRst）， # 中间节点的复位路径不会被覆盖 set_false_path -from [get_ports rst_n] -to [all_registers -async] # → 这只覆盖了 rst_n 直连的路径，漏掉了复位树内部的异步路径 # ✅ 正确：不限制源端，对所有寄存器的异步端设 false_path set_false_path -to [all_registers -async] # → 无论复位源来自顶层端口还是内部复位树节点，全部覆盖

四、multicycle_path：多周期路径

4.1 核心概念

打个比方：一辆快递车每天发一班，但有的包裹需要 3 天才能到——你查快递状态时在第 3 天查才是合理的，第 2 天查肯定显示"未到达"引发误报。multicycle_path 就是告诉工具："这条路径的包裹要 3 个时钟周期才能到，别在 1 个周期后催。"

默认情况：没写 multicycle_path 时，工具假设每个启动沿（launch）都在下一个捕获沿（capture）完成检查。如果数据实际需要 2 个或更多周期，工具会报假违例。

4.2 基础语法

# 3-cycle setup mulicyle path set_multicycle_path 3 -setup -from [get_pins reg_a/CK] -to [get_pins reg_b/D] # 配套的 hold multicycle（重要！容易忘） set_multicycle_path 2 -hold -from [get_pins reg_a/CK] -to [get_pins reg_b/D]

4.3 hold 的"减一"规则

这是 multicycle 最让人困惑的细节。看公式：

setup check 的周期偏移 = M - 1 hold check 的周期偏移 = N - 1 其中 M = setup multicycle 值 N = hold multicycle 值

规则：hold multicycle 一般比 setup 少 1。原因：

默认（M=1, N=1）: setup check: launch 沿的下一个沿（偏移=0=1-1） hold check: launch 沿的同一个沿（偏移=0=1-1） 3-cycle setup（M=3）: setup check: launch 沿之后的第 2 个沿（偏移=2=3-1） hold check: 默认情况下会在同一个沿检查 → 太严格，实际上数据要在第 3 个沿才被捕获 为什么 hold 要减 1: 如果 setup 在第 3 个沿检查，hold 最早应该在 launch 沿之后的第 1 个沿检查 （因为数据必须保持到第 3 个沿，但第 0 个沿之后数据就变了） 所以 hold multicycle = setup - 1 = 2

一句话记住：写 M-cycle setup，一定要配套写 (M-1)-cycle hold。忘了 hold 是 multicycle 最常见的 bug。

打个比方：你约了朋友 3 天后见面（3-cycle setup），那"保持通信畅通"的时间应该是到第 1 天？还是到第 3 天？答案是到第 1 天之后就解除保持要求了——因为真正的检查在第 3 天，你需要在第 2 天之后才能改变计划。hold 的 (M-1) 就是这个道理。

4.4 典型应用场景

# 1. 使能控制的寄存器路径（数据每 N 个周期才更新一次） # 数据路径经过一个 en 控制的寄存器，只在 en=1 时更新 set_multicycle_path 2 -setup -through [get_pins u_en_reg/Q] set_multicycle_path 1 -hold -through [get_pins u_en_reg/Q] # 2. SPI 数据路径（在慢时钟域中组合逻辑较长） # SPI 时钟 2.5MHz，寄存器到寄存器的组合逻辑超过 400ns # 允许 2 个 SPI 时钟周期 set_multicycle_path 2 -setup -from [get_clocks clk_spi] -to [get_clocks clk_spi] set_multicycle_path 1 -hold -from [get_clocks clk_spi] -to [get_clocks clk_spi] # 3. 分频器输出路径（计数器分频后的信号） # 输出每 4 个时钟周期才翻转一次 set_multicycle_path 4 -setup -through [get_pins u_div_cnt/Q] set_multicycle_path 3 -hold -through [get_pins u_div_cnt/Q]

五、set_max_delay / set_min_delay：自定义延迟约束

5.1 什么时候用

打个比方：你有一条没有红绿灯的辅路（没有时钟同步），交通规则说"所有车必须在 10 秒内通过"。你不能用 setup/hold 来约束（因为没有时钟），只能用直接的"10 秒上限"。

5.2 典型场景

# 1. 异步握手信号 # data_valid 从 CLK_A 域到 CLK_B 域，组合路径没有时钟 set_max_delay 10 -from [get_pins u_sync/data_valid_reg/Q] \ -to [get_pins u_sync_b/data_valid_sync/D] set_min_delay 2 -from [get_pins u_sync/data_valid_reg/Q] \ -to [get_pins u_sync_b/data_valid_sync/D] # 2. IO 组合路径（输入直接到输出，不经过寄存器） set_max_delay 50 -from [get_ports data_in] -to [get_ports data_out] set_min_delay 5 -from [get_ports data_in] -to [get_ports data_out] # 3. 跨时钟域的 fast→slow 路径上的组合逻辑 set_max_delay 15 -from [get_clocks clk_fast] -to [get_clocks clk_slow]

5.3 优先级规则

当多个例外作用于同一条路径时，最严格的一个生效：

同一路径上同时存在： set_max_delay 10 set_false_path → false_path 优先级最高，覆盖 max_delay

优先级（从高到低）：

1. set_false_path → 完全跳过检查 2. set_max/min_delay → 自定义延迟上限/下限 3. set_multicycle_path → 放宽检查周期 4. 默认 setup/hold 检查 → 最宽松

六、虚拟项目实战：充电管理芯片的 SDC 例外

项目背景

工艺：180nm 9TV50 时钟： clk_sys = 2.5MHz (400ns) — 系统主时钟 clk_spi = 2.5MHz (400ns) — SPI 从模式时钟（与 clk_sys 异步） clk_pwm = 100kHz (10us) — PWM 调制时钟（由 clk_sys 分频）

需要处理的例外

完整 SDC 片段

# ========== 时钟例外 ========== # 异步时钟域 set_clock_groups -asynchronous \ -group [get_clocks clk_sys] \ -group [get_clocks clk_spi] # ========== false_path ========== # 复位路径（不限制源端，覆盖多级复位树的全部异步端） set_false_path -to [all_registers -async] # 测试模式路径 set_false_path -through [get_pins */test_mode] # ========== multicycle_path ========== # SPI 数据路径（使能控制） set_multicycle_path 2 -setup -through [get_pins u_spi_reg/Q] set_multicycle_path 1 -hold -through [get_pins u_spi_reg/Q] # ADC → PWM 路径（慢速更新，4 个周期） set_multicycle_path 4 -setup -from [get_clocks clk_sys] \ -to [get_clocks clk_pwm] set_multicycle_path 3 -hold -from [get_clocks clk_sys] \ -to [get_clocks clk_pwm] # ========== max/min_delay ========== # GPIO 纯组合路径 set_max_delay 300 -from [all_inputs] -to [all_outputs] set_min_delay 5 -from [all_inputs] -to [all_outputs] # 异步中断握手 set_max_delay 100 -from [get_pins u_int_gen/irq_reg/Q] \ -to [get_pins u_int_sync/irq_sync/D]

验证方法

写完例外后，一定要检查：

# 列出所有被 false_path 覆盖的路径 report_timing -exceptions all -significant_fp 10 # 列出所有 multicycle 路径的 setup/hold 周期 report_multicycle_path -all # 检查没有被任何例外覆盖的路径（遗漏检查） check_timing -override_defaults -verbose

七、记忆曲线回访

回访 SDC 时钟约束第一课（2026-05-20）

当时我们写了 basic clock constraints，但留下了"例外"这个缺口。现在补上了：

完整的 SDC 应该包含： ┌─────────────────────────────────────┐ │ 1. 时钟定义（create_clock） │ ← 已学 │ 2. 时钟特性（uncertainty/latency） │ ← 已学 │ 3. IO 约束（input/output delay） │ ← 已学 │ 4. 时序例外（false/multi/max/min） │ ← 现在 │ 5. 时钟组（clock groups） │ ← 现在 │ 6. 设计规则约束（transition/cap/fanout）│ ← 未学 └─────────────────────────────────────┘

与 OCV / POCV 的关系

例外和 OCV 是两个正交的概念：

例外影响"检查什么路径" OCV 影响"检查时用什么 margin" 两者不冲突： 先设例外（确定哪些路径需检查） 再设 OCV（确定检查的严格程度）

八、总结

┌────────────────────────────────────────────────────────────┐ │ │ │ 时序例外的选择法则： │ │ │ │ Q: 这条路径需要检查 setup/hold 吗？ │ │ ├─ NO → set_false_path │ │ │ │ │ └─ YES → Q: 每 1 个时钟周期都检查？ │ │ ├─ YES → 不需要例外（默认） │ │ │ │ │ └─ NO → Q: 路径有同步时钟吗？ │ │ ├─ YES → set_multicycle_path │ │ └─ NO → set_max/min_delay │ │ │ └────────────────────────────────────────────────────────────┘

三个容易忘的点：

1. set_multicycle_path 的 hold 必须比 setup 少 1 2. set_clock_groups -asynchronous 比两个 false_path 更安全 3. false_path 优先级最高，会覆盖 max_delay