false path不设置有什么后果：工具白优化、报告噪音与真实风险
刚学时序约束时很多人都有这个疑问：代码里明明有些路径在功能上永远不会同时发生（比如配置寄存器写入后几个微秒才会被用、两个异步时钟域之间的单次握手），不告诉工具有什么大不了？这一篇把后果讲透。前置概念见时序分析入门与 STA 静态时序分析是什么，约束写法本身见多周期路径与伪路径约束。
本文要回答的问题
- false path 不声明，芯片功能会出错吗？
- 工具会在伪路径上浪费哪些优化资源？
- 时序报告的"噪音"是怎么把真问题淹掉的？
- 哪些路径应该声明 false path，哪些不应该？
简短结论
不设置 false path，芯片功能本身不会因此出错——伪路径在功能上本来就不会被真实激励同时触发。但代价落在两个地方：一是工具白优化，综合和布局布线引擎会把这些本来不需要满足单周期时序的路径当成关键路径来修，白白消耗面积、功耗和运行时间，甚至挤占真正关键路径的优化预算；二是报告噪音，时序报告里会堆出成百上千条伪违例，真正的 setup/hold 违例被埋在里面，工程师要么漏看、要么花大量时间逐条甄别。约束缺失的终点往往是时序签收（timing signoff）阶段才发现违例清单里真假混杂，返工成本最高。
理由一：工具在伪路径上做无用功
综合和布局布线（Place & Route，P&R）工具的优化逻辑是"最差路径优先"：哪条路径时序最差，就优先给它换更快的单元、加 buffer、调整布局。如果你不声明 false path，工具眼里所有路径都是真路径，伪路径一旦落到最差路径列表里，工具就会全力去修一条功能上根本不需要修的路径。
后果是实打实的三笔账：
- 面积浪费：给伪路径换上驱动更强、面积更大的单元，或插入冗余 buffer；
- 功耗上升：大驱动单元和额外的缓冲级都在白耗电；
- 真关键路径被挤占：工具的优化精力、布线资源（走线通道、过孔）是有限的，伪路径抢走了，真路径能分到的就少了，可能出现"伪路径修得很漂亮、真路径还差 50ps"的倒挂局面。
布局布线阶段还有一个隐形成本：工具为了修伪路径会把相关单元拉得很近或反复绕行，引起局部布线拥塞，整体迭代轮次增加，跑一次 P&R 的时间被拉长。
理由二：时序报告被伪违例淹没
静态时序分析（Static Timing Analysis，STA）不知道哪些路径在功能上不成立，它只按约束穷举所有时序路径。少一条 set_false_path，报告里就多一串永远修不掉的违例。
上面这张对比卡把两种情况并排放：左边是约束完整时的理想状态——报告里每条违例都是真待办；右边是不声明时典型的项目现场——违例清单动辄几千条，工程师靠经验和文件名逐条判断"这条是不是真的"，判断错的代价就是流片后功能异常。报告噪音的危害不是"看着烦"，而是它系统性抬高了漏看真违例的概率：人对着 3000 条违例和对着 30 条违例，注意力分配完全不同。
理由三：时序签收与 DFT 阶段的连锁返工
时序签收要求"零违例"或"每条违例都有书面豁免理由"。没声明 false path 的项目走到这一步，签收工程师面对的是一份无法直接签字的报告，只能回过头找设计人员补约束，而补约束意味着 STA 要重跑、ECO（工程变更）要重评估，运气好是一轮，运气不好牵连到已经冻结的布局。
在 DFT（可测试性设计）场景下问题更具体：scan 移位路径、测试模式下的时钟切换路径在正常功能模式下是伪路径，不声明就会被功能时序约束误伤，详见测试模式下 SDC false path 的处理。
补救不是没有抓手：主流 STA 工具都提供约束完整性检查命令（如 PrimeTime 的 check_timing），能列出没有被任何时钟约束覆盖的端点、缺少输入输出延迟的端口等。建议在项目早期就把 check_timing 的报告纳入每日回归，发现"疑似伪路径但没声明"的条目立即补约束，而不是攒到签收阶段一次性处理。漏声明的代价随项目阶段单调上升：综合期补是改一行 SDC 重跑一次，签收期补则可能牵动 ECO 流程和已经冻结的物理数据。
一个具体例子
假设 SoC 里有一个软件配置模块：寄存器 cfg_mode 上电后由固件写一次，写完 10 微秒后数据通路才开始用它。cfg_mode 到数据通路使能寄存器之间的路径，单周期（比如 5ns）根本不可能满足，也不需要满足——功能上它有几万个周期的裕量。
不声明 false path 时发生的事：
读这张图抓住主线：红色是问题所在（伪路径被当真路径、报告被污染），蓝色是工具的误判动作，橙色是最终代价。根源只有一个——工具不知道"这条路径功能上不会在一拍内发生"，而 set_false_path -from [get_pins cfg_reg/Q] -to [get_pins datapath_en_reg/D] 一句话就能告诉它。
常见误区
这张思维导图把五个高频误区收在一起，读的时候注意它们分成两类：左边两条是"不设/设错对象"的问题，右边三条是"用错手段/写太宽"的问题。其中误区 2 和误区 4 是真正会出芯片事故的：异步时钟域（CDC）之间的数据路径如果图省事整条 set_false_path，相当于放弃了所有时序检查，亚稳态和数据的时序要求就没人管了——正确做法是对握手控制路径用 false path、对数据路径用 set_max_delay -datapath_only 之类约束，约束写法的完整清单见 SDC 时序约束语法速查。反过来，"约束写宽点省事"也是同性质的风险：通配符一旦误伤真路径，违例被静默豁免，报告上一片干净，问题直接带到流片。
延伸阅读
- 多周期路径与伪路径约束怎么写——
set_false_path与set_multicycle_path的语法、适用场景与区别，本篇的"怎么设"续集； - SDC 时序约束语法速查——create_clock、set_false_path、set_max_delay 等常用约束一页查全；
- 时序收敛基本流程——从约束到违例修复的完整迭代闭环；
- STA 报 unconstrained endpoint 怎么排查——约束缺失的另一类典型症状；
- 时序分析专题总览——setup/hold、时钟不确定性与签收全景。
这一篇在知识体系里的位置
本篇是时序约束入门链路上的一环：上游是时序分析入门和 STA 静态时序分析是什么（搞清工具在算什么），本篇回答"为什么必须如实告诉工具哪些路径不用算"，下游接多周期路径与伪路径约束的具体语法和时序收敛基本流程的工程闭环。
一句话总结
false path 不设置不会让芯片功能出错，但会让综合和布局布线工具在伪路径上白白消耗面积、功耗与布线资源，挤占真关键路径的优化预算，同时让时序报告被成百上千条伪违例淹没、抬高漏看真违例的概率，最终在时序签收阶段以返工的形式还债——一句话 set_false_path 就能避免的事，不要拖到签收再补。