1. 课程导入与Lattice FPGA时序挑战
在FPGA工程中，功能正确只是最低门槛，能否在目标时钟频率下稳定运行，才是设计能否交付的关键。Lattice FPGA以低功耗、小封装和成本友好著称，广泛用于接口桥接、电源管理、工业控制、通信背板以及嵌入式视觉等场景。这些场景往往时钟域多、外设接口杂、板级走线受限，时序收敛难度并不因为器件规模小就自动降低。相反，资源少、布线拥塞、时钟资源有限，常常让时序问题更集中地暴露出来。
学习目标
本课程围绕“时序收敛”和“约束治理”两条主线展开。学完本课程，你应当能够：
- 理解Lattice ECP5、Nexus、MachXO等器件家族的时序资源差异，知道不同系列在时钟网络、DSP、BRAM和布线结构上的特点；
- 读懂时序报告中的关键路径、建立时间、保持时间、时钟偏斜和不确定性，判断问题出在逻辑级数、布线延迟还是约束缺失；
- 为时钟、输入输出、跨时钟域路径编写可维护的SDC约束，而不是靠“先跑一遍再补约束”的救火方式；
- 建立约束治理流程：约束来源可追溯、约束变更可审查、约束与RTL同步演进；
- 面对典型工程痛点，能够定位是约束问题、RTL结构问题还是物理实现问题，并选择正确的修复顺序。
Lattice器件家族的时序特点
Lattice的器件家族定位不同，时序特征也不同。ECP5面向中低端通用市场，逻辑规模从十几K到八十多K LUT，带有DSP和BRAM，支持DDR3、PCIe等接口。它的时序瓶颈常出现在高速接口的输入输出路径和跨时钟域路径上，因为I/O资源与时钟资源相对有限，布局布线对时序的影响比较明显。Nexus系列采用FD-SOI工艺，强调低功耗和可靠性，逻辑密度和DSP资源比ECP5更丰富，适合需要一定算力和低静态功耗的场合。它的时序特点在于时钟网络更灵活，但高速设计仍需关注时钟树插入延迟和跨时钟域约束。MachXO系列则偏向小规模、低功耗、瞬时启动的控制类应用，逻辑资源少，时序通常不是频率极限问题，而是I/O时序和异步接口的稳定性问题。
理解这些差异的意义在于：同一套约束策略不能无差别套用。例如，ECP5的DDR接口需要仔细约束输入输出延迟和时钟相位；MachXO的异步复位和慢速总线更需要注意伪路径和异步时钟组的声明；Nexus在低功耗模式下时钟可能被门控，约束中要体现时钟使能和恢复关系。
时序收敛与约束治理的定义与关系
时序收敛，是指设计在目标器件、目标速度等级和指定工作条件下，所有时序路径都满足建立时间、保持时间、恢复时间和移除时间等要求，并且通过静态时序分析（STA）验证。它回答的是“设计能不能跑起来”。约束治理，是指对时序约束的来源、内容、变更和验证进行系统管理，确保约束真实反映设计意图和板级条件，并且可追溯、可审查、可复现。它回答的是“我们凭什么相信它能跑起来”。
两者不是并列关系，而是支撑与保障的关系。没有约束治理，时序收敛可能只是“约束写得松”造成的假象；没有时序收敛，约束治理就失去了目标。实际工程中，很多团队把约束当成一次性文件，项目初期随便写几条create_clock，后期时序不过就加set_false_path，结果约束越来越不可信，时序报告也无法作为交付依据。正确的做法是：约束从设计规格和板级时序需求出发，随RTL同步更新，每次时序收敛都基于同一套可信约束。
典型工程痛点
第一个痛点是约束缺失或照搬模板。例如，一个ECP5设计使用外部25 MHz晶振，内部通过PLL倍频到100 MHz，但约束里只写了create_clock -period 40 [get_ports clk_in]，没有对PLL输出时钟、生成时钟和输入输出延迟进行约束。STA报告可能显示“时序满足”，但实际上内部100 MHz路径根本没有被正确分析。判断方法是检查时序报告中的时钟列表和路径覆盖，确认每个实际时钟都有对应约束。
第二个痛点是跨时钟域路径处理不当。例如，一个Nexus设计中有100 MHz和33 MHz两个时钟域，通过异步FIFO通信。如果只对FIFO两端分别约束时钟，却没有声明两个时钟为异步组，工具可能尝试对跨域路径做时序优化，导致布线资源浪费，甚至引入不必要的不确定性。正确做法是使用set_clock_groups -asynchronous声明异步关系，并对FIFO指针同步器设置合理的伪路径或最大延迟约束。
第三个痛点是时序失败后的修复顺序混乱。很多工程师一看到负裕量就改RTL，加流水线、拆逻辑，但有时问题只是约束过紧或时钟不确定性设置过大。合理的排查顺序是：先确认约束是否真实反映设计意图，再检查时钟树和布局是否合理，最后才考虑RTL结构优化。例如，某条路径在ECP5上建立时间裕量为-0.8 ns，先检查是否误加了set_max_delay，再查看路径是否跨越了BRAM或DSP硬核，最后才决定是否插入寄存器。
第四个痛点是约束与RTL不同步。项目迭代中，RTL增加了新的时钟域或接口，但约束文件没有更新，导致新路径未被分析。治理手段包括：约束文件纳入版本管理，每次RTL变更后运行约束覆盖率检查，并在时序报告中确认所有时钟和I/O都有对应约束。
在进入具体工具和命令之前，先记住一个判断原则：时序报告中的每一个数字，都必须能追溯到一条明确的约束和一条真实的物理路径。如果做不到，时序收敛就只是偶然，而不是工程能力。