4、时序约束与分析错误：时钟约束缺失或错误、I/O约束不匹配、跨时钟域处理不当、时序报告解读错误
时序约束，说白了就是给FPGA设计定规矩。你告诉工具：我的时钟跑多快，数据什么时候来，什么时候走。工具才能按这个规矩去布线。我见过太多项目，功能仿真跑得飞起，一上板就崩。十有八九，都是时序约束没做好。
这一章，我把自己踩过的坑、看别人踩过的坑，都给你捋一遍。四个大方向：时钟约束、I/O约束、跨时钟域、时序报告解读。咱们一个一个来。
4.1 时钟约束缺失或错误
时钟是FPGA的心跳。你连心跳都没告诉工具，它怎么知道该跑多快？
4.1.1 最常见的错误：忘了约束
很多新手，尤其是从纯软件转过来的，觉得“我代码写对了就行”。嗯，我刚开始也这么想。结果呢？综合布线后，时序报告里一堆红色violation。为什么？因为工具默认时钟频率是无穷大，它根本不在乎时序。
正确的做法，是在SDC文件里明确声明所有时钟：
# 主时钟约束
create_clock -name clk_sys -period 10.000 [get_ports {clk_sys}]
# 生成时钟（PLL输出）
create_generated_clock -name clk_pll_out -source [get_pins {pll_inst/CLKI}] \
-divide_by 1 -multiply_by 2 [get_pins {pll_inst/CLKOP}]
注意，-period 10.000 对应100MHz。如果你实际跑50MHz，却写了10ns，工具会按100MHz去布线。结果就是：资源浪费，甚至布不通。反过来，你跑100MHz却写了20ns，那时序大概率过不了。
create_generated_clock 显式声明。
4.1.2 时钟分组与异步时钟
设计中如果有多个异步时钟域，必须告诉工具它们之间不需要做时序分析。否则工具会去分析那些根本不可能同步的路径，白白浪费时间，还可能报一堆假violation。
# 将两个异步时钟分组
set_clock_groups -asynchronous -group [get_clocks {clk_a}] -group [get_clocks {clk_b}]
我个人习惯，在项目一开始就把所有时钟域梳理清楚。哪些是同步的，哪些是异步的，直接分组。省得后面报告里一堆红色，你分不清真假。
4.2 I/O约束不匹配
I/O约束，就是告诉工具：芯片引脚上的信号，什么时候来，什么时候走。这个搞错了，板级调试能让你怀疑人生。
4.2.1 输入延迟约束
外部器件把数据送到FPGA引脚，数据相对于时钟是有延迟的。这个延迟必须告诉工具。
# 输入延迟约束
set_input_delay -clock clk_sys -max 2.5 [get_ports {data_in}]
set_input_delay -clock clk_sys -min 0.5 [get_ports {data_in}]
这里的 -max 和 -min 怎么设？我一般看外部器件的datasheet。比如ADC的datasheet说数据在时钟上升沿后2ns有效，那我 -max 就设2.5ns，留点余量。 -min 通常设0.5ns左右，防止hold violation。
4.2.2 输出延迟约束
输出延迟，是FPGA输出数据到外部器件的时间要求。同样要约束：
# 输出延迟约束
set_output_delay -clock clk_sys -max 3.0 [get_ports {data_out}]
set_output_delay -clock clk_sys -min 1.0 [get_ports {data_out}]
这里有个坑：输出延迟的参考点是FPGA的时钟引脚，不是内部寄存器。很多人搞混了，结果约束出来的时序根本不对。我曾经帮一个同事排查问题，他折腾了两天，最后发现是输出延迟的参考时钟选错了。
4.3 跨时钟域处理不当
跨时钟域（CDC）是FPGA设计里最容易出bug的地方。没有之一。
4.3.1 单比特信号的CDC
单比特信号跨时钟域，标准做法是两级同步器：
module sync_2ff (
input wire clk_dst,
input wire rst_n,
input wire data_in,
output reg data_out
);
reg sync_reg1, sync_reg2;
always @(posedge clk_dst or negedge rst_n) begin
if (!rst_n) begin
sync_reg1 <= 1'b0;
sync_reg2 <= 1'b0;
end else begin
sync_reg1 <= data_in;
sync_reg2 <= sync_reg1;
end
end
assign data_out = sync_reg2;
endmodule
注意，两级同步器只能解决亚稳态问题，不能保证数据不丢失。如果源时钟域的信号变化太快，目的时钟域可能采样不到。所以，单比特信号跨时钟域，通常只用于控制信号（如使能、复位），不用于数据。
4.3.2 多比特信号的CDC
多比特信号（比如总线）跨时钟域，绝对不能直接用两级同步器。为什么？因为每个bit的路径延迟不同，到达目的时钟域的时间可能不一致，导致采样到错误的数据。
正确的做法有两种：
- 异步FIFO： 最通用的方案。用格雷码做指针同步，保证多比特指针的跨时钟域安全。
- 握手协议： 数据量小、速率低时可以用。源时钟域发请求，目的时钟域回应答，确保数据稳定后再采样。
我个人偏好异步FIFO。Lattice的IP核里有现成的，直接例化就行。但要注意，FIFO的深度要够，不能写满或读空。我曾经在一个项目中，FIFO深度设小了，结果数据丢包，查了两天才发现是深度不够。
4.4 时序报告解读错误
时序报告，是工具给你的“体检报告”。但很多人看不懂，或者看错了。
4.4.1 看懂Setup和Hold
时序报告里最核心的两个指标：Setup Slack和Hold Slack。
- Setup Slack： 数据到达时间 vs 数据要求时间。正数表示满足，负数表示violation。
- Hold Slack： 数据保持时间 vs 数据要求保持时间。同样，正数满足，负数violation。
我见过有人看到Setup Slack是负数就慌了。其实不一定。如果负数很小（比如-0.01ns），可能是工具精度问题，或者约束稍微紧了一点。先看看是不是假路径，再决定要不要改。
4.4.2 常见误读
| 报告现象 | 常见误读 | 正确理解 |
|---|---|---|
| Setup Slack为负 | 设计一定不能工作 | 可能只是约束过紧，或假路径未排除 |
| Hold Slack为负 | 加buffer就能解决 | Hold violation通常需要调整时钟树或约束 |
| 报告里全是红色 | 设计废了 | 先看是不是异步时钟域没分组 |
| WNS很大 | 最差路径很差 | WNS大不一定代表整体差，可能只是个别路径 |
嗯，这里要特别说一下Hold violation。很多人觉得“数据保持时间不够，加个buffer延迟一下不就行了？” 没那么简单。Hold violation通常是因为时钟偏斜（clock skew）太大，或者数据路径太短。加buffer可能会让setup更差。正确的做法是调整时钟约束，或者用工具自带的hold fixing功能。
4.4.3 如何快速定位问题路径
时序报告动辄几百页，怎么看？我一般三步走：
- 看WNS（Worst Negative Slack）： 最差的slack是多少。如果WNS是-0.5ns，那所有slack小于-0.5ns的路径都要修。
- 看TNS（Total Negative Slack）： 所有负slack的总和。TNS很大，说明问题路径很多，可能是整体约束有问题。
- 点开最差路径： 看具体是哪条路径。是组合逻辑太深？还是扇出太大？还是跨时钟域没处理好？
我曾经遇到一个案例，WNS是-1.2ns，但TNS只有-1.2ns。说明只有一条路径有问题。点开一看，是一个64位加法器，组合逻辑太深。拆成流水线，问题就解决了。
4.5 本章知识体系
下面这张图，帮你理清时序约束与分析的完整流程：
这张图把四个核心模块串起来了。时钟约束是基础，I/O约束是接口，跨时钟域是难点，时序报告是验证手段。四者缺一不可。
最后说一句：时序约束不是写一次就完事的。它是迭代的过程。先写基础约束，跑时序，看报告，修问题，再跑。直到所有slack都为正，且留有一定余量。我一般留5-10%的余量，防止温度电压变化导致时序变差。