扫码关注
上周帮同事看项目，Vivado 编译报了一万多条时序违例。打开他 xdc 一看——时钟约束二十几条，假路径五百多条，各种命令混着上。问他都管什么，他沉默了半天。时序约束不是"加得多"就安全，是"加得准"才有用。
一、时序约束到底管什么？
▲ Vivado 时序分析报告
工具要的不是"穷举所有路径"，是你明确告诉它电路的预期行为。时序约束管三件事：时钟（create_clock、create_generated_clock）、I/O 端口（set_input_delay、set_output_delay）、例外路径（set_multicycle_path、set_false_path）。写清楚这三类，工具就知道怎么算时序。其他的，不加反而是默认安全。
二、五个最常见的翻车姿势
▲ 时钟树理不清，后面的约束全是空谈
姿势一：约束太松。时钟周期填 100ns 实际跑 10ns。工具按 100ns 评估，布线完发现 setup 违例一堆。
姿势二：约束太严。把异步跨时钟域路径当同步路径跑，工具疯狂优化，逻辑越改越乱，资源暴涨性能上不去。
姿势三：跨时钟域没约束。两个异步时钟工具不知道关系，直接按同时钟域算肯定报几百条错。正确做法是 set_false_path 或 set_max_delay -datapath_only。
姿势四：直接抄模板 xdc。网上下的工程，信号名全是别人的，你工程里压根没这些信号。工具要么忽略要么报 unconstrained。
姿势五：忽略时钟不确定性。晶体有 jitter、PLL 有偏移，set_clock_uncertainty 一句没加，工具算出完美 0 skew，物理上根本跑不到。
三、怎么写"少而精"的约束？按这个顺序：理清所有时钟，PLL 输出、MMCM 分频、门控时钟全画出来；I/O 约束要算准，set_input_delay 是要算"外部 Tco + 板级走线 + 时钟到外部延迟"，算不准就留 1-2ns margin，别瞎填大数；跨时钟域只加 false_path，别再叠 max_delay 和 multicycle；例外路径按需加，每加一条都要清楚在管什么。写完先跑 check_timing 自己审一遍，能列出所有 unconstrained 端口，比看一片红色报错清晰得多。
四、报错几千条怎么办？
▲ 用 report_timing_summary 定位关键路径
真遇到别慌：先看第一条最严重的违例，往往是问题根源；用 report_timing_summary 看摘要定位 path；优先解决 setup，再看 hold——setup 是频率问题，hold 是布线问题，处理顺序不一样；大量相似违例时先检查源头约束，别一条一条改叶子路径，下一次综合又会被推翻。
写在最后时序约束的原则就三条：理清时钟树、算清 I/O 约束、例外路径按需加。做到位，编译报错基本能控制在一百条以内。剩下的就交给工具去优化，别把自己活成综合器。
你踩过什么时序约束的坑？评论区聊聊，一起避雷。
![电子设计：IIR数字滤波器设计[学以致用系列课程之数字信号处理]](https://api.fanyedu.com/uploads/image/58/2fe737b3ff3f854913ef2c5df8df52.png)
