FPGA 设计流程 — HDL 综合到位流

FPGA 开发流程6 个阶段串行——RTL 设计 → 综合 → P&R → 时序分析 → 仿真 → 烧录。每段失败要回到上一段重做,所以工程师按"先 RTL 仿真定型再综合"的工作流。

把每一步的工具与中间产物展开看，就能定位调参错位发生在哪一段：综合用 Synplify Pro / Vivado / Quartus 把 RTL 变成逻辑网表，映射落到 LUT/FF/DSP/BRAM，P&R 分配物理位置并走线，STA 失败时回到综合或 P&R 重做，最后才生成位流并下载。

每阶段都有专属验证手段——RTL 用 Verilog/VHDL simulator、综合用 Synthesis report、P&R 用 timing report、仿真用 testbench、烧录用硬件 lab。新人容易忽略时序分析,导致烧出来的板时序违反实际功能不对。

最常见的错误顺序：

• 功能仿真能通过，但综合失败（不可综合的代码）
• 综合通过，但时序违例（路径太长）
• 时序通过，但实际运行不对（同步问题、毛刺）

setup 违例：从 $F{F}_{source}$ 到 $F{F}_{dest}$ 的组合路径太长，在一个时钟周期内来不及到达。

解决方法：

• 优化代码：简化组合逻辑
• 插入流水线（Pipelining）：在中间加一个 FF 把长路径切成两段
• 降低时钟频率（妥协）
• 布线调整：让关键路径走得更近

hold 违例：组合路径太短，目的 FF 还没采样完源 FF 的上一个值，新值就到了。

解决：综合工具自动插入延迟 buffer——通常不需要设计者干预，但要注意过约束的情况。

Lattice Diamond 是 ECP5 / iCE40 系列的工具链——免费版可以做项目级开发。新人用免费版熟悉流程,然后转到 Xilinx Vivado 或 Intel Quartus 做大项目。

Lattice Diamond 是 Lattice FPGA 的完整 EDA 工具链：

Reveal（Lattice）/ ChipScope（Xilinx）/ SignalTap（Altera）都是片上逻辑分析仪。

价值：

• 在不改变电路的前提下，从 FPGA 芯片内部抓取任意信号
• 等价于把示波器"接到"芯片内部
• 可调触发条件（如"当 state == IDLE 时开始抓取"）
• 采样深度由 BRAM 决定（几 K 到几十 K 样点）

实际调试流程：

• 在 FPGA 上实例化 Reveal 核
• 选择想观察的内部信号
• 设置触发条件
• 烧录设计，在板上运行
• 通过 JTAG 读取抓取的波形
• 像示波器一样查看

这对 FPGA 调试至关重要——没有 Reveal 就像做 PCB 调试没有示波器。

前面把 Diamond 当作一条具体工具流来讲，但真正提高调试效率的，不是记住某个报错对应哪个按钮，而是先判断错误落在工作流的哪一层。Diamond 3.11 的 known issues 之所以有价值，是因为它不是按零散 bug 编排，而是沿着 Design Entry → IPExpress → Simulation → Synthesis → Implementation → Timing Analysis → Programming → Reveal 这条真实链路切开故障面。

这批已知问题反复暴露同一个事实：很多看起来像逻辑设计错误的现象，其实发生在工具阶段边界。真正难的不是修某一条 bug，而是避免把约束、缓存、模型和 GUI 失真误判成 RTL 失效。

• 约束冲突比语法错误更隐蔽。PERIOD 覆盖 FREQUENCY、自动生成的 LPF 覆盖手写约束、Timing View 与 IO report 数字不一致，本质都在说明约束解释权可能漂移。出现异常 fMAX 或 violation 时，先查最终生效的文本约束，再决定是否改设计。
• 自动生成物和缓存是第一类脏状态来源。.ipx、.sbx、初始化文件、PLL 计算结果、simulation script 和 process status 只要不同步，Diamond 仍可能继续往后跑，但中间产物的语义已经变了。切过综合器、改过顶层或重配过 IP 后，优先再生成并清理旧 implementation。
• 仿真模型不等于硅行为。UFM、OSCH、PMI、IBIS 这类 vendor model 都出现过模型与硬件不一致、库名错误或自动生成文件有缺陷的情况。仿真失败时，先分清是 RTL 错、模型错，还是脚本没把正确库送进 simulator。
• 报表和视图是观察层，不是事实层。Spreadsheet View、Timing Analysis、Netlist Analyzer 和 Power Calculator 都可能显示旧状态、遗漏边界或基于错误假设给出精确数字。真正的签核对象仍是 datasheet、明文约束、生成日志和最终 report。

位流生成成功，只说明前端、综合和实现暂时走通；它不自动推出部署链和板上调试链也可靠。Diamond known issues 在 Programming 和 Reveal 两章最重要的启发，就是把下载与调试从实现流里单独拆出来管理。

• Programmer 依赖的是一整条主机环境链：操作系统版本、USB/FTDI 驱动、线缆服务器、Flash 厂商命令集、配置模式和 XCF 元数据，任何一层失配都可能表现成 verify 失败、器件识别异常或假成功。
• XCF、JEDEC、feature row、erase time 和 readback 结果都要单独复核，不能把 GUI 里某一列 status 或某次导出成功当成最终证据。
• Reveal 比普通 JTAG 下载更苛刻，因为它同时依赖板级电气前提、调试核插入后的 hierarchy 解释和 trigger 配置语义。Analyzer 打不开、扫描崩溃或 link signal 失败时，优先检查 JTAG 参考电压、生成 hierarchy、调试核配置和受支持的设计规模，而不是先怀疑功能 RTL。

如果项目已经超出单纯的 Diamond 主流程，还依赖 ispLEVER Classic、PAC-Designer 或 LatticeMico System，主风险往往不再是逻辑理论，而是环境契约。此时路径、权限、helper 进程、仿真库、ELF 到 memory init 的映射，都会变成一等设计输入。

1. 先冻结版本矩阵。把 IDE、综合器、IP 版本、仿真器、驱动、操作系统和目标器件族一起记录，不接受只升级其中一项的试错式维护。
2. 再冻结中间产物。把 .ipx、初始化文件、simulation script、patch 过的 vendor wrapper 和 deployment 文件一起纳入配置管理，不把它们当成可随时再生的无关缓存。
3. 只要 source list、top-level、implementation 或综合器切过，就默认旧的绿色图标和旧 report 已经失效，优先做一次真正的 clean build。
4. GUI 服从文本与 datasheet。图形化默认值、蓝色默认属性、视图里的计数器和自动补出来的频率都只能当线索；一旦与明文约束、生成日志或器件手册冲突，后者优先。
5. 把生成、下载和调试拆开验收。JEDEC 或 bitstream 能生成，只代表设计流的一部分通过；真正可交付还要分别确认 memory 映射、编程链、读回验证和板上调试链都闭环。