FPGA 时序约束与收敛

引言

功能仿真通过、综合布线也通过，比特流能生成——但上板之后系统随机出错、偶尔死机、温度一高就异常。这类问题的九成根源是时序不满足：某些路径的信号没能在时钟边沿之前稳定下来，触发器采到了不确定的值。

时序约束是 FPGA 开发中最容易被跳过、也最容易被误解的环节。很多工程师以为「不写约束也能跑」——确实能跑，但工具会按默认的、往往过于乐观的假设去分析，结果就是比特流生成了、功能却不可靠。约束文件（XDC/SDC）的本质是把设计的真实时钟、真实接口时序、真实的异步关系告诉工具，让静态时序分析（STA）给出可信的余量报告。

本文从时序方程出发，依次讲约束语法、例外路径、报告解读、优化手段和收敛流程。内容偏工程实战，涉及 有限状态机与时序设计 中提到的 CDC 与亚稳态概念，也会用到 RISC-V 流水线 CPU 与冒险处理 里的流水线切分思路。

目录

1. 时序分析的基本模型
2. XDC 与 SDC：约束语言基础
3. 时钟约束：create_clock 与 generated clock
4. 输入输出延迟约束
5. 时序例外：false path、multicycle、max_delay
6. 时钟组与跨时钟域约束
7. 读时序报告：WNS、TNS、WHS
8. 关键路径定位方法
9. 优化手段：流水线、重定时与寄存器复制
10. 高扇出网络与布局拥塞
11. 时钟资源：BUFG、MMCM 与 PLL
12. 收敛流程与迭代策略

1. 时序分析的基本模型

STA 把所有时序路径抽象成「起点触发器 → 组合逻辑 → 终点触发器」的三段结构，然后检查两个不等式。设 Tclk 为时钟周期，Tcq 为时钟到输出延迟，Tcomb 为组合逻辑延迟，Tsu/Th 为建立/保持时间，Tskew 为时钟偏斜：

setup:  Tclk + Tskew >= Tcq + Tcomb_max + Tsu
hold:   Tcq + Tcomb_min >= Th + Tskew

slack = 要求的时间 - 实际需要的时间
  setup slack >= 0 且 hold slack >= 0 才算收敛

四条重要推论：

1. setup 违例 = 路径太长，解法是降频、切流水线、优化布局。
2. hold 违例 = 路径太短，降频无效，只能加延迟（工具通常自动插入）。
3. 时钟偏斜帮 setup 但害 hold，所以时钟网络要做得短而平衡。
4. 同一路径无法同时满足极端情况，需要 PVT（工艺、电压、温度）角分析：慢角看 setup、快角看 hold。

FPGA 工具默认会分析多个角（如 Vivado 的 Slow/Fast corner），报告里给出最差角的 slack。

2. XDC 与 SDC：约束语言基础

Xilinx 用 XDC（基于 Tcl 的 SDC 方言），Intel 用 SDC（.sdc 文件）。语法同源，命令名基本一致。

# XDC 文件示例：约束一个 100MHz 系统时钟
create_clock -name sys_clk -period 10.000 [get_ports clk_in]

# 引脚分配（FPGA 特有，不属于 SDC）
set_property PACKAGE_PIN E3 [get_ports clk_in]
set_property IOSTANDARD LVCMOS33 [get_ports clk_in]

# 输入输出延迟
set_input_delay  -clock sys_clk -max 3.0 [get_ports data_in[*]]
set_input_delay  -clock sys_clk -min 1.0 [get_ports data_in[*]]
set_output_delay -clock sys_clk -max 4.0 [get_ports data_out[*]]

约束的三条纪律：

• 约束必须反映真实意图：写宽了工具不报错但设计不可靠；写窄了工具拼命优化却仍然违例。
• 所有时钟都要约束：漏掉一个时钟，经过它的路径就不被分析，等于给 bug 开了后门。
• 约束文件纳入版本管理，与 RTL 一起评审。

3. 时钟约束：create_clock 与 generated clock

create_clock 定义主时钟。对输入引脚上的时钟，用 -period 指定周期（ns）：

# 主时钟：200MHz
create_clock -name clk_core -period 5.000 [get_ports clk_p]

# 差分时钟（P/N 成对）：只需约束 P 端
create_clock -name clk_sys -period 8.000 [get_ports sys_clk_p]

# 虚拟时钟：用于约束输入输出接口，本身不驱动任何寄存器
create_clock -name vclk_ext -period 10.000

生成时钟（generated clock）指由 MMCM/PLL 分频倍频、或由逻辑分频得到的时钟。工具能自动推导 MMCM 输出时钟，但逻辑分频必须手工约束：

# MMCM 输出时钟（工具通常自动推导，显式写出更稳妥）
create_generated_clock -name clk_100m \
    -source [get_pins mmcm_i/CLKIN1] \
    -divide_by 10 [get_pins mmcm_i/CLKOUT0]

# 逻辑分频时钟：源是寄存器 Q 端，divide_by 2
create_generated_clock -name clk_div2 \
    -source [get_pins div_reg/Q] -divide_by 2 [get_pins div_reg/Q]

注意：不推荐用逻辑分频产生时钟（偏斜大、时序不可控），正确做法是改用时钟使能或 MMCM。这里写出来是因为很多遗留设计会这么做，必须知道如何约束。

4. 输入输出延迟约束

FPGA 与外部器件的接口时序，用 set_input_delay / set_output_delay 描述。它们的含义是「外部器件相对时钟边沿的数据到达时间」，而不是 FPGA 内部延迟。

# 场景：外部 ADC 在时钟上升沿后 2~5ns 输出数据，FPGA 采样
# 需要知道外部器件的 Tco（输出延迟）和 PCB 走线延迟
set_input_delay -clock sys_clk -max 5.0 [get_ports adc_data[*]]
set_input_delay -clock sys_clk -min 2.0 [get_ports adc_data[*]]

# 场景：FPGA 输出给外部 DAC，DAC 需要数据在边沿前 3ns 稳定
set_output_delay -clock sys_clk -max 3.0 [get_ports dac_data[*]]
set_output_delay -clock sys_clk -min -1.0 [get_ports dac_data[*]]

实践要点：

• 必须成对写 -max 和 -min：分别对应 setup 和 hold 分析。
• 值来自数据手册：外部器件的 Tco/Tsu/Th 加上 PCB 走线延迟（约 6~7 ps/mm），不要凭感觉填。
• 源同步接口（时钟与数据同向传输）用 set_input_delay -clock 指向随路时钟，这是 DDR、千兆网等接口的标准做法。

5. 时序例外：false path、multicycle、max_delay

时序例外告诉工具「某些路径不需要按正常时钟周期分析」。这是最容易用错的地方——写错例外等于关掉了检查。

# false path：逻辑上不可能同时变化的路径（如静态配置寄存器的输出）
set_false_path -from [get_cells cfg_reg*]

# multicycle path：允许多个时钟周期完成的路径
# 例：一个慢速乘法器需要 3 拍完成
set_multicycle_path 3 -setup -from [get_cells mult_pipe_reg*]
set_multicycle_path 2 -hold  -from [get_cells mult_pipe_reg*]
# 注意：setup 设 N，hold 通常要设 N-1，否则 hold 检查会前移

# max_delay：跨时钟域路径只限制最大延迟（不按时钟周期分析）
set_max_delay -datapath_only 8.0 \
    -from [get_cells src_domain_reg*] -to [get_cells dst_sync_reg*]

三条使用纪律：

1. 例外必须有文档说明：每条 set_false_path 都要写清楚为什么这条路径不可能活跃，否则后来人不敢删、也不敢信。
2. 优先用 -datapath_only：它只忽略时钟偏斜，仍然检查数据路径延迟，比 set_false_path 安全。
3. 不要用 false path 掩盖真实违例：这是自欺欺人的常见做法，上板必炸。

6. 时钟组与跨时钟域约束

当设计中有多个异步时钟（如 100MHz 核心时钟与 125MHz 以太网时钟），必须告诉工具它们之间的关系：

# 两个时钟完全异步：不分析它们之间的路径
set_clock_groups -asynchronous \
    -group {clk_core} -group {clk_eth} -group {clk_ddr}

# 如果两时钟同源但有确定相位关系，用 physically_exclusive 或
# 保持默认（工具会按最坏相位差分析）

关键区别：

对于 CDC 路径，推荐组合是：在 RTL 里加同步器 + 用 set_max_delay -datapath_only 限制延迟。这样既避免了虚假违例，又保证同步器前的组合逻辑不会长到让亚稳态传播时间不够。

7. 读时序报告：WNS、TNS、WHS

时序报告的核心指标：

判断标准：

• WNS ≥ 0 且 WHS ≥ 0：时序收敛，设计在目标频率下可靠。
• WNS = -0.05ns，TNS = -0.05ns：只有一条路径轻微违例，通常小改即可修复。
• WNS = -2ns，TNS = -500ns：大量路径违例，说明约束或架构有问题，需要重新审视。

# Vivado 命令行查看时序摘要
report_timing_summary -file timing_summary.rpt
report_timing -max_paths 20 -sort_by slack -file worst_paths.rpt

# 快速抓关键数字
grep -E "WNS|TNS|WHS|THS" timing_summary.rpt

8. 关键路径定位方法

定位关键路径有自顶向下和自底向上两条路：

（1）看报告：report_timing 会给出最差路径的完整链路——起点、经过的逻辑级数（logic levels）、每级延迟、终点。

Slack (VIOLATED) : -0.812ns
Source:      u_cpu/regfile/regs_3_0__C
Destination: u_cpu/alu/result_31__C
Path Group:  clk_core
Logic Levels: 24 (LUT6=18 LUT5=4 CARRY4=2)
  ... 每条 net 的延迟明细 ...

（2）看逻辑级数：FPGA 里一级 LUT 的延迟约 0.10.3ns，24 级逻辑意味着 37ns 的纯逻辑延迟。逻辑级数超过 15 级基本就要怀疑架构问题。

（3）看延迟构成：报告会区分 logic delay 和 net delay。如果 net delay 占比高（>50%），说明是布线问题（拥塞或跨区域），优化方向是布局而非逻辑。

典型诊断表：
  logic delay 高、level 高     → 组合逻辑太长，插流水线
  net delay 高                 → 布线拥塞，加区域约束或改架构
  单个 net 延迟异常高          → 高扇出，复制驱动或加 max_fanout
  路径跨越大半个芯片           → 加 Pblock 约束就近布局

9. 优化手段：流水线、重定时与寄存器复制

按「改动成本从低到高」排序：

（1）加流水线寄存器：在长组合路径中间插一级触发器。代价是延迟增加一拍、面积增加。

// 优化前：4 级加法串成一条长路径
assign sum = a + b + c + d + e + f + g + h;

// 优化后：两级流水线，路径长度减半
always @(posedge clk) begin
    s1 <= (a + b) + (c + d);
    s2 <= (e + f) + (g + h);
    sum <= s1 + s2;
end

（2）重定时（retiming）：综合工具自动把触发器在组合逻辑中前后移动，平衡各级延迟。Vivado 的 -retiming 选项、opt_design -retarget 都能做。它对数据通路类设计（DSP 链）效果显著。

（3）寄存器复制：高扇出信号（如复位、使能、状态译码输出）驱动数千个负载，延迟大。复制多份驱动不同区域可降低扇出。

# 限制最大扇出，工具会自动复制
set_property MAX_FANOUT 32 [get_cells rst_sync_reg]

（4）逻辑重构：把 if/else 链改成并行比较、把优先级编码器改成树形结构，减少逻辑级数。

10. 高扇出网络与布局拥塞

高扇出是 FPGA 时序问题的头号来源。一个信号驱动上千个负载时，其 net delay 可能达到 2~5ns。常见高扇出信号：全局复位、时钟使能、模式配置位、宽比较器的结果。

处理方式：

• MAX_FANOUT 属性让工具自动复制寄存器，最省事。
• 手工复制：写多份寄存器，各自驱动一块区域（需要配合 Pblock）。
• 降低扇出需求：如把全局复位改成局部复位，或用「复位 + 有效位」替代。

布局拥塞表现为 net delay 异常高、布线失败率高。缓解手段：

# 用 Pblock 把相关模块约束到相邻区域
create_pblock pblock_dsp
add_cells_to_pblock pblock_dsp [get_cells u_dsp_array/*]
resize_pblock pblock_dsp -add {SLICE_X10Y100:SLICE_X30Y150}

# 降低布线密度
set_property MAX_FANOUT 24 [get_cells -hier -filter {PRIMITIVE_GROUP==FF}]

经验法则：资源利用率超过 80% 后，布线延迟会急剧上升，时序收敛难度非线性增长。设计时给布局布线留 20%~30% 的资源余量是明智的。

11. 时钟资源：BUFG、MMCM 与 PLL

FPGA 有专用的时钟资源，用错会带来偏斜和时序灾难：

# 约束 MMCM 的输入与输出（通常工具自动推导，但显式约束更可靠）
create_clock -name clk_in -period 10.000 [get_ports clk_in]
# MMCM 输出 200MHz（5ns）
create_generated_clock -name clk_200m \
    -source [get_pins mmcm_i/CLKIN1] -multiply_by 2 [get_pins mmcm_i/CLKOUT0]

关键原则：

• 时钟必须走 BUFG/BUFH：综合工具会自动推断，但如果时钟是从逻辑里产生的（分频器输出），必须手工例化 BUFG，否则工具会把它当普通信号布线。
• 不要超过 BUFG 数量：用超了工具会报错或自动降级到普通布线，时序立刻恶化。
• MMCM 有锁定时间：上电后需要几百微秒锁定，复位逻辑必须等 locked 信号有效才能释放。

12. 收敛流程与迭代策略

时序收敛是一个迭代过程，建议按固定顺序排查：

1. 检查约束完整性：所有时钟都约束了吗？CDC 路径都标注了吗？
2. 跑综合 + STA：先看综合后（无布局）的时序，过滤掉纯逻辑问题
3. 看 WNS/TNS：判断是「个别路径」还是「系统性」违例
4. 定位关键路径：report_timing 看逻辑级数和延迟构成
5. 优化：
   - 逻辑级数高 → 插流水线 / 重定时
   - net delay 高 → 加 Pblock / 降扇出 / 降利用率
   - 约束错误 → 修例外路径
6. 重跑实现，对比 WNS 变化
7. 收敛后做后仿真（可选）与上板验证

几个能显著缩短迭代时间的实践：

• 先固定布局再调逻辑：place_design 后先看时序，避免每次全流程重跑。
• 用增量编译：Vivado 的 -incremental 复用上次布局，小改动收敛快很多。
• 分离「逻辑问题」和「物理问题」：综合后违例是逻辑问题，布局布线后违例多半是物理问题，优化方向完全不同。
• 保存每次迭代的约束与结果，便于对比和回滚。

权衡取舍

常见坑清单

• 漏约束时钟：未约束的时钟其路径不被分析，工具不报错但设计不可靠，必须核对时钟清单。
• 用 false path 掩盖违例：把真实违例标注为 false path，上板随机出错且极难定位。
• multicycle 的 hold 未同步调整：setup 设 N 而 hold 未设 N-1，hold 检查前移导致虚假违例。
• CDC 路径未约束：工具按同步路径分析，报大量虚假违例，掩盖真实的延迟过长问题。
• 时钟走普通布线：逻辑分频时钟没例化 BUFG，偏斜达纳秒级，时序随机失败。
• 高扇出信号未处理：复位/使能驱动上千负载，net delay 高，加 MAX_FANOUT 或手工复制。
• 输入输出延迟凭空填写：不从数据手册和 PCB 参数推算，约束与实际不符，接口在板上失效。
• 忘了 PVT 角分析：只看典型角，忽略慢角 setup 和快角 hold，温度变化后失效。
• 资源用满再想收敛：利用率 >90% 后布线延迟急剧上升，应留 20%~30% 余量。
• 忽略 MMCM 锁定时间：上电后立刻释放复位，时钟未稳定导致初始化错误，必须等 locked。
• 约束文件不进版本库：约束丢失或版本不一致，导致「在我机器上是好的」。

小结

时序约束与收敛的本质是把物理世界的时序要求准确地翻译给工具，并让设计满足这些要求。约束写对了，工具才能给出可信的余量报告；约束写错了，一切优化都是盲人摸象。三个必须掌握的动作是：给所有时钟写 create_clock、给所有异步关系写时钟组或 max_delay、给所有例外路径写清理由。

优化侧的思路可以用一句话概括：逻辑级数高就切流水线，net delay 高就改布局，约束不对就修约束。大多数「时序收敛不了」的问题，本质上是架构问题（组合逻辑太长）或约束问题（例外写错），而不是工具调参问题。

下一步建议阅读 高层次综合 HLS 与流水线 ，看如何用 C++ 层面的 pragma 直接控制流水线级数与 II，把时序收敛的一部分工作前移到算法层；或者进入 RISC-V 流水线 CPU 与冒险处理 ，看流水线切分在处理器微架构中的具体应用。