面向模块的综合技术之过约束（十）

面向模块的综合技术之过约束（十）

---

---

前言

---

过约束：FPGA 时序收敛的“隐形杠杆”

---

1. 什么是“过约束”

• 定义：在布局/布线阶段人为收紧时序预算（通常 ≥ 200 ps），迫使工具对关键路径投入更多优化资源；布线后再释放多余预算，从而提前达到时序收敛。
• 适用范围：
  – 仅用于时钟内或同步跨时钟域路径；
  – 异步路径、假路径禁止过约束（工具已忽略）。
• 官方定位：UG949 §5.5.9 将过约束列为“布线前最后一次加速手段”，并给出 0.5 ns 上限建议。

---

2. 官方推荐公式与数值

阶段	过约束量	来源	备注
布局前	+0.2 ~ +0.5 ns	UG949 v2018.3 p.128	超过 0.5 ns 可能过度优化、增加布线拥塞
保持时间	仅当 WHS < –0.4 ns	UG904 §2.4.1	布线前修复，避免布线后Hold Detour导致建立时间退化

---

3. 实现方式对比（官方支持 vs 民间偏方）

方式	是否推荐	官方理由	实测副作用
set_clock_uncertainty -setup	✅ 官方推荐	不改变周期、占空比、时钟关系；易回滚	无
直接缩小 create_clock -period	❌ 不推荐	改变所有衍生时钟；无法局部撤销	导致假违例、编译时间翻倍
set_max_delay 硬压	⚠️ 有限场景	仅适合跨时钟域且需datapath_only	容易覆盖多周期约束、优先级混乱

---

4. 一键过约束脚本（Project / Non-Project 通用）

# 1. 定位需要过约束的时钟对
set worst_clk [get_clocks -of_objects [get_timing_paths -setup -max_paths 1]]
set worst_slack [get_property SLACK [get_timing_paths -setup -max_paths 1]]

# 2. 仅当 WNS ∈ [-0.5 ns, 0 ns] 才过约束
if {$worst_slack > -0.5 && $worst_slack < 0} {
    set over 0.3
    set_clock_uncertainty -setup $over $worst_clk
    puts "INFO: Over-constrained $worst_clk by ${over}ns"
}

# 3. 布局后**必须**回滚，否则影响最终报告
#    在 route_design 前放入 Tcl.pre
set_clock_uncertainty -setup 0 $worst_clk

---

5. 过约束与 Hold-Detour 的联动

• 场景：布线后 Hold Slack 为 –0.55 ns，工具插入 LUT1 导致建立路径被推开。
• 官方方案（UG904 §2.4.1）：
  1. 在 phys_opt_design 前加 +0.4 ns 过约束；
  2. 使用 -hold_fix 或 -aggressive_hold_fix；
  3. 布线前 撤销过约束，避免建立时间过度优化。
• 结果：Hold Slack 提升至 –0.12 ns，建立时间仍保持 +0.15 ns。

---

6. 过约束的 3 条红线

1. 不得超过 0.5 ns（UG949 明确警告）；
2. 不得用于异步路径（set_clock_groups 已忽略）；
3. 必须在布线前回滚，否则
   – 最终报告虚高；
   – 可能掩盖真实时序问题；
   – 下游PR流程无法复现结果。

---

7. 快速自查清单

检查项	Tcl 命令	通过标准
过约束量	report_clock -of_objects $clk	USER_UNCERTAINTY ≤ 0.5 ns
是否回滚	get_clock_uncertainty $clk	布线前 = 0
优先级冲突	report_exceptions -overlap	无 set_max_delay 覆盖

---