自学Vivado一年，功能仿真都过，一上板就跑飞。看时序报告一堆setup violation，但不知道从哪条约束改起。网上教程有的先写create_clock再写set_input_delay，有的顺序反过来，到底有没有讲究？还有set_false_path和set_multicycle_path什么时候该用，用错了会不会把真问题掩盖掉？求过来人讲讲新手最容易写错的约束顺序和排查思路。
3 个回答
先说结论：顺序本身不是Vivado的硬性规定，约束是描述设计的『事实』，工具不会因为你把set_input_delay写在create_clock前面就报错。真正会出问题的是：你在没定义时钟之前就写了依赖时钟的IO延迟，或者时钟定义得跟板上实际不一致，工具算出来的采样窗口就是错的，于是要么假违例、要么真违例被漏掉。
稳妥的习惯是先把时钟树描述清楚：create_clock定义主时钟，衍生时钟用create_generated_clock，然后把输入输出延迟挂到对应时钟上，最后才谈例外。这个顺序不是为了讨好工具，是为了让你自己排查时有一条清晰的因果链。
新手最容易踩的坑其实是set_false_path。看到路径违例就加一条false_path，报告立刻干净了，上板照样跑飞——因为你把真实的跨时钟域路径也一起屏蔽了。跨时钟域该用的是set_clock_groups -asynchronous，而且前提是你确实做了同步器。multicycle同理，只有当你确认数据是多周期稳定的时候才能用，用错等于给建立时间打折。
排查思路建议从report_timing的path group入手，先看是哪一组违例、起点终点分别是什么，再判断是约束缺失还是设计本身组合逻辑太深。你板子上的输入时钟实际频率是多少，跟约束里写的一致吗？
先说个可能让你松口气的结论：Vivado 不会因为你把 create_clock 写在 set_input_delay 后面就报错，约束文件本质是一堆描述设计事实的命令，工具最后统一求解，不是逐行执行的脚本。真正会让你被打脸的是「描述的事实和板上不一致」，比如时钟周期填错、输入延迟只拍脑袋写了个 2ns、或者外部器件是源同步你却按系统同步算。
顺序上的讲究更多是给人看的：先 create_clock 把主时钟立起来，衍生时钟用 create_generated_clock 跟上，再写 set_input_delay / set_output_delay 挂到对应时钟，最后才谈 set_false_path 和 set_multicycle_path 这些例外。这条链路清晰了，你打开 report_timing 才能顺着 path group 一眼看出是哪类路径在违例，而不是对着一屏红字发呆。
新手最容易埋雷的其实是 false_path。看到违例就加一条屏蔽掉，报告瞬间干净，上板照样跑飞，因为被屏蔽的可能是真实的跨时钟域路径。个人建议：例外约束每加一条都要能说出「为什么这条路径在功能上不需要时序保证」，说不出来就先别加。
你现在跑飞的板子，外部接口是源同步还是系统同步？这个条件不清楚的话，输入延迟基本没法算对。
先别急着纠结命令的先后，把约束当成给工具画一张板级事实图：时钟长什么样、数据从哪个器件来、什么节拍被采样。Vivado 对语句顺序基本不敏感，你把 create_clock 写在最后它也能求解，所以顺序错了不会直接报错，只会让你自己排查时找不到因果链。真正会打脸的是事实写错，比如外部 ADC 是源同步接口，你却只写了个主时钟加随手 2ns 的 input_delay，那工具算出来的采样窗口天生就是错的，报告再干净上板也照飞。
新手可以按里程碑走：第一步只写 create_clock，跑一次 report_timing，确认主时钟周期和板上晶振对得上；第二步补 set_input_delay / set_output_delay，挂到对应时钟上，再看 path group 里到底是哪一组违例；第三步才碰例外。false_path 是最容易掩盖真问题的一条，看到违例就加，报告立刻清爽，但跨时钟域的真实路径也被一起屏蔽了。稳妥做法是先确认这条路径确实不需要时序收敛，比如异步 FIFO 两侧、复位同步器，再写 false_path，并且尽量窄到具体 from/to。multicycle 同理，只有当你和外部器件的协议真的允许多拍采样时才用，否则就是给自己挖坑。
排查顺序上我个人习惯先看 report_timing 的 path group，分清是内部 reg2reg 还是 IO 违例，IO 违例再回头核对外部器件手册的建立保持要求。你现在的违例主要落在哪一组，是内部逻辑还是输入输出？
发表回答
登录后可在本页底部提交回答