光
最近一个项目在配置方案上纠结了挺久，最后三种模式都实测了一遍，分享一下取舍思路。
先说结论：开发阶段用 JTAG，量产上板用 SPI Flash 主动加载，需要远程升级的场合再叠加多镜像（MultiBoot）方案。没有一种模式能通吃。
一、JTAG 模式：调试最顺，但只适合开发。优点是随时可以重新配置，不依赖板上 Flash，时序问题排查也方便。缺点是掉电就丢配置，量产没法用；另外 JTAG 链上器件一多，TCK 信号完整性就得单独处理，链长了还得加缓冲。
二、SPI Flash 主动加载：量产主力，但要算好上电时序。FPGA 上电后主动从 Flash 读 bitstream。实测里最容易踩的坑有三个：1. Flash 容量要留余量，bitstream 压缩后也要按未压缩尺寸的 1.5 倍估；2. 上电时序：Flash 的 ready 时间必须早于 FPGA 的配置超时窗口，否则偶发配置失败，复现还特别难；3. 四线模式（Quad SPI）速度快，但布线要求高，时钟线串扰大了会直接导致配置 CRC 报错。
三、远程升级：多镜像是底线。单镜像远程升级等于赌命。我的做法是 Flash 里放两个镜像：主镜像（Golden，永远不动）+ 应用镜像，应用镜像升级失败就回落到 Golden。代价是 Flash 容量翻倍，另外要留一个看门狗触发回落的硬件路径，不能只靠软件判断。
四、选型时容易忽略的两点。一是 bitstream 加密会拖慢加载速度，对启动时间敏感的系统要实测；二是配置引脚复用成普通 IO 后，调试阶段要留测试点，否则定位问题很被动。
大家在量产项目里一般怎么选配置方案？有没有遇到过 Flash 容量不够、被迫拆镜像的窘境？
先说结论：开发阶段用 JTAG，量产上板用 SPI Flash 主动加载，需要远程升级的场合再叠加多镜像（MultiBoot）方案。没有一种模式能通吃。
一、JTAG 模式：调试最顺，但只适合开发。优点是随时可以重新配置，不依赖板上 Flash，时序问题排查也方便。缺点是掉电就丢配置，量产没法用；另外 JTAG 链上器件一多，TCK 信号完整性就得单独处理，链长了还得加缓冲。
二、SPI Flash 主动加载：量产主力，但要算好上电时序。FPGA 上电后主动从 Flash 读 bitstream。实测里最容易踩的坑有三个：1. Flash 容量要留余量，bitstream 压缩后也要按未压缩尺寸的 1.5 倍估；2. 上电时序：Flash 的 ready 时间必须早于 FPGA 的配置超时窗口，否则偶发配置失败，复现还特别难；3. 四线模式（Quad SPI）速度快，但布线要求高，时钟线串扰大了会直接导致配置 CRC 报错。
三、远程升级：多镜像是底线。单镜像远程升级等于赌命。我的做法是 Flash 里放两个镜像：主镜像（Golden，永远不动）+ 应用镜像，应用镜像升级失败就回落到 Golden。代价是 Flash 容量翻倍，另外要留一个看门狗触发回落的硬件路径，不能只靠软件判断。
四、选型时容易忽略的两点。一是 bitstream 加密会拖慢加载速度，对启动时间敏感的系统要实测；二是配置引脚复用成普通 IO 后，调试阶段要留测试点，否则定位问题很被动。
大家在量产项目里一般怎么选配置方案？有没有遇到过 Flash 容量不够、被迫拆镜像的窘境？