企业官网建设流程全解析

做FPGA+MicroBlaze的工程，最绕不开的一个坎就是“程序在JTAG下跑得好好的，一断电全没了”。调试阶段无所谓，但到了要交付、要量产、要上电自启的时候，DDR启动和Flash固化这套流程就必须吃透。这几个月我正好把一个MicroBlaze项目从纯JTAG调试一路做到了SPI Flash固化，中间踩了无数坑，包括Flash下载失败、启动不自启、DDR训练不过这些经典问题，今天把这套全流程整理出来，给正在折腾固化的朋友一个能直接照着做的参考。

这篇内容围绕一个核心场景展开：MicroBlaze软核程序量比较大，片上BRAM放不下，代码必须跑在DDR里；同时量产要求FPGA上电后自动从Flash加载bitstream和应用程序，不需要接电脑、不需要JTAG。整个过程涉及DDR地址映射、Bootloader设计、镜像合并、Flash烧写、上电验证，每个环节我都会把原理和实操一起讲。

1. 为什么“DDR启动”和“Flash固化”总是成对出现

1.1 调试阶段的真相：不是真启动

很多刚开始接触MicroBlaze的朋友会有一个误解，以为在SDK里点一下“Run As -> Launch on Hardware”程序跑起来了，这就是启动。其实完全不是这么回事。这个操作的本质是：电脑通过JTAG把bitstream下载到FPGA，然后调试器（通常是GDB）把ELF文件通过JTAG加载到DDR或者BRAM，再让MicroBlaze的PC指针跳到程序入口。整个过程依赖电脑在线，板子一旦断电，FPGA配置丢失，DDR里的数据全部清空，一切归零。

这个阶段用的其实是“调试模式”，不是真正的“启动模式”。接下来如果项目要脱离电脑独立工作，就必须让系统自己完成三件事：FPGA上电后主动从非易失存储介质加载配置、MicroBlaze核能自己找到并运行应用程序、应用程序运行所需的DDR内存能被正确初始化。这三件事合在一起，就是Flash固化要解决的完整问题。

1.2 Flash固化要解决的三个问题

把程序固化到Flash，表面上看起来只是“把文件写进一颗芯片”，但实际拆解下来，必须同时解决三个问题。第一个问题是FPGA配置源的切换，出厂时JTAG模式只能调试用，量产板必须把模式引脚拨到Master SPI或者Slave SPI，让FPGA上电后自己从SPI Flash加载bitstream。第二个问题是应用程序的存放位置，bitstream只是硬件逻辑，MicroBlaze要跑的软件代码是独立的东西，它也得有个地方存，正常情况下和bitstream放在同一颗Flash里，只是偏移地址不同。第三个问题是运行环境准备，DDR这种外部存储控制器上电后初始状态是不可用的，必须先经过初始化（MIG会自动做校准），MicroBlaze才能把代码搬进去执行。

这三个问题一环扣一环，任何一个没处理好，结果就是上电后FPGA灯亮了但程序不跑，或者直接跑飞。

1.3 启动链路全貌：从按下电源到main函数

我自己习惯用一条链路来描述整个启动过程，理解了这条链路，后面所有操作就都有方向感了。按下电源后的完整时序是这样的：

1. FPGA配置引擎按照模式引脚设定，从SPI Flash偏移0x0处读取bitstream，完成内部逻辑配置，此时MicroBlaze内核和MIG DDR控制器已经存在于FPGA内部。
2. MicroBlaze复位释放后，PC指针指向复位向量，也就是0x00000000地址。这个地址必须映射到一个非易失、已经可用的存储介质上。在标准固化方案里，这个位置是片内BRAM，且BRAM里的内容已经被bitstream初始化好了。
3. 位于BRAM的Bootloader代码开始执行，它首先等待MIG DDR控制器完成初始化校准，然后通过SPI控制器从Flash的应用程序偏移地址读取代码数据。
4. Bootloader把读取到的代码搬运到DDR的指定地址，搬运完成后刷新Cache，然后跳转到应用程序入口。
5. 应用程序在DDR里开始执行，CPU正式进入main函数。

很多人一开始不理解为什么非要加一道Bootloader的工序，不能直接把应用程序放在Flash里让CPU跑吗？这个问题的答案涉及存储器属性差异，后面详细展开。

2. 启动原理：上电之后，CPU到底是怎么找到程序的

2.1 复位向量和BRAM：MicroBlaze上电后的第一步

MicroBlaze作为软核处理器，它的复位行为其实和硬核ARM差不多，复位后PC指针固定指向一个地址，这个地址就是复位向量。在SDK的链接脚本里，这个地址由LSCRIPT里的“vectors”段决定，常见设置是0x00000000，也就是本地存储器总线上挂的那个BRAM控制器。

为什么非得是BRAM而不是DDR或者Flash？原因很现实：DDR上电后没初始化，连读都不一定读得动；并行NOR Flash或者SPI Flash虽然是非易失的，但MicroBlaze要通过额外的控制器去访问，而且复位早期外设时钟、引脚复用未必ready。只有BRAM是FPGA内部资源，bitstream配置完就能读能写，零延迟、零初始化过程，是最可靠的启动位置。

但BRAM有个致命的限制——容量极小。以常见的Artix-7系列为例，块RAM总量撑死几百KB，实际还要被缓存、FIFO、DMA占用，能留给程序的空间往往只有几十KB。我们的应用代码随便加点协议栈、驱动，轻轻松松超过100KB。这就逼得我们必须让代码运行在DDR里。

2.2 Bootloader存在的理由：搬运工

Bootloader本质上是一个特制的微型程序，它的体积被刻意控制得很小（通常几KB到十几KB），只做三件事：初始化DDR、从Flash读数据、跳转执行。它就像一个搬运工，把真正的应用程序从Flash这个“仓库”搬到了DDR这个“工作台”上。

有朋友会问，为什么不直接把应用程序烧到Flash里，然后设置MicroBlaze复位向量指向Flash？理论上可以，前提是系统里有XIP（Execute In Place）支持，而且Flash访问速度能接受。但实践中MicroBlaze的简单总线访问SPI Flash需要CPU时钟分频，代码在Flash里直接执行会慢得离谱，而且Flash读时序还要和CPU取指周期匹配，调试起来非常痛苦。所以Bootloader搬运方案成了绝对主流。

这里还有一个关键点：Bootloader本身放在哪里？前面说过，它的代码在BRAM里。但BRAM是易失的，断电就丢，固化了又有什么用？这个问题引出了整个流程里最容易被忽略的细节——Bootloader机器码其实是“嵌”在bitstream里的。

2.3 DDR在启动链路里的作用：程序运行的主战场

DDR在启动链路里的角色，是作为应用程序的运行内存。它容量大（几百MB到几GB）、访问速度快，适合跑复杂的应用逻辑。但DDR有一个特性：上电后需要初始化训练，具体包括时钟使能、模式寄存器配置、ZQ校准、读写训练等，这一套动作由MIG IP核的校准逻辑自动完成，时间大约在几十微秒到几毫秒量级，具体取决于DDR颗粒类型和时钟频率。

在Bootloader方案里，DDR的初始化和校准是在Bootloader代码里等待完成的。具体来说，MIG IP核会输出一个calib_done信号，Bitstream配置完成后这个信号自动开始拉高，Bootloader代码只要轮询这个信号，等它变高就代表DDR可以正常读写了。这个轮询等待的动作虽然简单，但必须做，否则代码搬一半数据全是乱的，程序跳转过去直接Hard Fault。

2.4 一个很多人忽视的细节：Bootloader是怎么“塞”进BRAM的

这是整个方案里最精妙也最容易被忽视的一环。前面提到Bootloader在BRAM里，而BRAM是易失的，那么固化后上电，BRAM里的Bootloader代码从哪来？

答案隐藏在bitstream文件里。FPGA的bitstream包含了所有可配置逻辑的初始化数据，其中就包括BRAM的初始内容。也就是说，如果在生成bitstream的时候，把一个ELF文件（Bootloader程序）解析出来，把它的机器码作为BRAM的初始化数据写进bitstream，那么这个bitstream配置完FPGA之后，BRAM里天然就有Bootloader的代码了。

这就是为什么必须在SDK里专门生成一个Bootloader工程，并且在使用bootgen合并镜像时，要把Bootloader的ELF作为“bootloader”类型单独指定。工具会把它的机器码嵌入到bitstream的BRAM初始化区域中。这个机制和Zynq的BootROM思想非常像，只不过Zynq的BootROM是硬编码在芯片里的，而MicroBlaze的“BootROM”是用BRAM模拟出来的。

MMI文件在这条链路里扮演的角色也要提一下。MMI（Memory Map File）是Vivado导出的一个文本文件，描述了bitstream里各个BRAM块的地址映射关系。SDK和bootgen就是靠这个文件知道该把ELF里的哪一段数据写到bitstream的哪个BRAM位置。有一些旧版本或特殊流程需要手动指定MMI路径，不理解这个原理就会卡在报错上。

3. 动手前准备：DDR和MicroBlaze系统配置的几个关键点

3.1 MIG DDR控制器配置心得

DDR这块我在Vivado里用的是Memory Interface Generator（MIG）IP核。配置时最核心的是选择合适的颗粒型号和位宽。颗粒型号要严格跟板子上焊的DDR颗粒一致，比如镁光MT41K256M16这种，选错了训练根本过不去。位宽方面，Artix-7上常见16bit或者32bit，位宽越大带宽越高，但占用管脚也越多。MicroBlaze总线和MIG之间通常通过AXI Interconnect转接，数据位宽不匹配时自动做宽度转换，但会有少量性能损失，能对齐尽量对齐。

DDR的地址分配也要提前规划好。MIG的接口地址通常设为0x80000000开头，这样在AXI地址空间里，DDR就落在高端地址区域，和低端的BRAM（0x00000000）以及外设地址（0x40000000之类）天然分开，不容易冲突。

MIG生成的时钟频率和DDR颗粒的speed grade有关系，如果你的板子DDR跑不到标称频率，时序上不去，训练就会失败，报“DDR calibration failed”。这个错误经常会连带Flash烧写报错，因为很多烧写方案需要通过DDR做中转缓存。后面排障章节会细说。

3.2 MicroBlaze存储器映射规划

MicroBlaze的存储映射规划，直接决定后面Bootloader链接脚本和应用链接脚本怎么写。我通常按这样的方式划分地址空间：

这个规划里有个容易犯的错误：外设地址和DDR地址重叠。AXI总线上地址译码是按范围匹配的，如果两个从设备地址范围有交集，访问冲突的地址时行为不可预测，轻则数据错乱，重则总线挂死。配置完每个IP的Base Address之后，一定要在Address Editor里检查一遍，确认没有重叠。

另外，BRAM大小设置也很关键。Bootloader代码必须能在BRAM里放下，我一般设32KB，官方模板的SREC Bootloader编译出来大约十几KB，比较充裕。如果BRAM设得太小，链接脚本分配失败，生成bootloader elf会报错“region BRAM_CTRL_MEM is full”。

3.3 导出硬件到SDK

在Vivado里完成Block Design、约束、综合、实现后，还要做一步“Export Hardware”，并且一定要勾选“Include bitstream”。这个步骤会生成一个HDF硬件描述文件，里面包含了MicroBlaze配置信息、外设地址映射、MMI文件位置以及bitstream信息。SDK启动时会读取这个文件来创建平台工程。

老版本Vivado（2018.3及以前）里叫“Export Hardware”，新版本Vitis（2019.2以后）里直接把HDF或XSA拖进去就行。细节略有差异，但原理一致，不展开。

导出完成后，可以在SDK里看到自动生成的platform工程，里面包含了所有的驱动库和地址映射定义。一个常见问题：如果你的MicroBlaze系统里没有添加AXI UART Lite或者串口，后面Bootloader调试时会非常痛苦，因为看不到任何打印信息。所以强烈建议MicroBlaze系统里带一个串口外设，烧写和启动阶段的打印输出是排障最重要的依据。

4. 完整实操：从DDR调试到Flash固化

4.1 第一步：让应用先在DDR上跑起来

不要一上来就搞固化，先把应用程序在DDR上跑通了再说。这一步其实是在验证DDR硬件链路和MicroBlaze访问DDR的能力，如果这一步都跑不通，后面固化必然失败。

操作流程是：在Vivado导出的基础上启动SDK，创建一个Application Project，选择模板时用“Hello World”，然后右键工程属性，修改链接脚本。在Linker Script里，把.text、.data、.bss、.heap、.stack这些段的运行内存全部改到DDR空间（比如0x80000000）。改完后编译，然后执行“Run As -> Launch on Hardware”，这时程序会被JTAG下载到DDR并运行。

如果串口能打印出Hello World，说明DDR链路完全正常。如果打印不出来，优先检查MIG配置里的DDR颗粒型号、时钟频率、位宽、引脚约束，以及MicroBlaze和DDR之间的AXI连接是否完整。出现“DDR calibration failed”的话，重点排查电源和时钟，DDR的供电纹波过大非常容易导致训练失败。

4.2 第二步：制作Bootloader

应用在DDR跑通之后，开始制作Bootloader。在SDK里再新建一个Application Project，模板选择“Empty Application”，然后从Xilinx官方库引入SREC Bootloader的源码，或者直接自己写。很多工程师选择自己写，因为可控性强，打印信息可以自定义。下面是一个最简Bootloader的核心逻辑：

#include "xparameters.h" #include "xil_io.h" #include "xil_printf.h" #include "xspi.h" #include "xil_cache.h" #define FLASH_APP_ADDR 0x00600000 #define DDR_APP_ADDR 0x80000000 #define APP_MAX_SIZE 0x00400000 static void spi_flash_read_all(u32 src, u32 dst, u32 len) { // 这里调用xilisf或xspi驱动，从src地址连续读取len字节到dst // 实际项目用XSpi_Transfer实现，需要先打开SPI设备、配置模式 } int main(void) { u32 timeout = 0; xil_printf("MicroBlaze Bootloader start...\r\n"); // 等待DDR校准完成 while (xil_in32(XPAR_DDR_MIG_BASEADDR + 0x0) == 0) { // 典型做法是读MIG状态寄存器 timeout++; if (timeout > 0xFFFFFFFF) { xil_printf("DDR calibration timeout!\r\n"); return -1; } } xil_printf("DDR calibration done, load app from flash...\r\n"); // 禁Cache，保证搬运一致性 Xil_DCacheDisable(); // 从Flash把应用程序读到DDR spi_flash_read_all(FLASH_APP_ADDR, DDR_APP_ADDR, APP_MAX_SIZE); xil_printf("App loaded, jump to 0x%08X\r\n", DDR_APP_ADDR); // 跳转到DDR里的应用程序入口 void (*app_entry)(void) = (void (*)(void))DDR_APP_ADDR; app_entry(); return 0; }

实际工程里还要处理Flash驱动的初始化、SPI时钟配置、擦写保护等细节，但整体框架就是这样。注意等待DDR校准完成的方式，很多MIG配置下，DDR基地址加偏移可以读到校准状态，也可以在Block Design里把calib_done引出来接到GPIO输入，Bootloader去轮询GPIO，两种方式都可以。用MIG内部状态寄存器读起来更直接，但不同版本IP寄存器偏移略有差异，需要查一下对应文档。

这个Bootloader工程的链接脚本，所有段必须放BRAM。SDK生成默认链接脚本时，把.text、.data、.bss、.heap、.stack都指到本地存储器即可，注意Heap和Stack不能设置太小，因为Bootloader里的库函数（比如SPI驱动）也会用栈，一般各给8KB以上。

4.3 第三步：应用工程的链接脚本调整

应用工程就是我们真正要跑业务的程序。前面在DDR上调试时，已经把链接脚本改到了DDR地址。固化场景下，应用的运行地址保持DDR不变，但要注意一个细节：应用程序编译出来的ELF，入口地址就是DDR基地址（比如0x80000000），Bootloader跳转到这个地址时要保证对应的机器码是有效的。

为了让Bootloader跳转后能正确进入C运行环境，应用程序的启动代码（crt0.S）必须位于DDR最开头。SDK生成的链接脚本自动把_start和crt0相关段放在最前面，正常情况下不需要手动干预。但如果你修改过链接脚本，要确认.text的第一个段确实是启动代码，否则跳过去可能就是一堆莫名其妙的数据，程序直接跑飞。

此外，应用程序链接脚本里的Heap和Stack大小要按需设置。因为它们占用的也是DDR空间，稍微给大点没关系，但要注意不能跟其他段的地址重叠。链接脚本里heap和stack通常放在.bss后面，编译器会自动分配地址，一般不会撞车。

4.4 第四步：用Bootgen合并镜像

Bootloader和应用都编译好后，接下来就是把bitstream、Bootloader ELF、应用ELF合并成一个可用于Flash烧写的镜像。这一步在SDK里可以用图形界面，也可以敲命令。

图形界面方式：SDK菜单“Xilinx Tools -> Create Boot Image”。会弹出对话框，指定输出BIF文件路径和输出镜像路径。关键的是要添加上下文内容：

• 第一行加一个类型为“bootloader”的ELF，就是Bootloader的ELF。
• 第二行加bitstream文件（.bit）。
• 第三行加应用程序的ELF。

顺序不能乱，bootloader必须放在最上面。Bootgen会根据Bootloader ELF自动解析其机器码，结合MMI文件写入bitstream的BRAM初始化区域。生成的BIN文件就是完整的启动镜像。

命令行方式更适合自动化，BIF文件写好后，执行：

bootgen -image boot.bif -o BOOT.bin -w on -arch microblaze

BIF文件内容示例如下：

the_ROM_image: { [bootloader]D:/proj/bootloader/Debug/bootloader.elf [image]D:/proj/vivado/system.bit [image]D:/proj/app/Debug/app.elf }

有几点值得提醒。第一，如果用的是老版本Vivado，bootgen支持的BIF语法和现在略有不同，建议先跑一次图形界面生成一个BIF模板，再基于模板改。第二，Bootloader ELF必须对应正确的FPGA型号和DDR配置，如果Bitstream换了但Bootloader没重新编译，BRAM初始化数据不匹配，程序必挂。第三，应用ELF如果太大，超出Flash预留的应用区大小，也会出问题，所以在规划Flash分区时要留够余量。

4.5 第五步：烧写Flash的两种方式

镜像生成之后，烧写Flash有两条路线。

第一条路线是直接用Vivado的“Add Configuration Memory Device -> Program Configuration Memory Device”。先在Vivado里选好Flash型号，然后把BIN或者MCS加载进去烧写。这个方式走的是FPGA配置通道，不依赖MicroBlaze，比较适合烧写纯bitstream场景。但对MicroBlaze固化场景，需要注意：如果Bootloader希望在烧写后做进一步验证，这种方式没法执行Bootloader，它只是把数据写进Flash。

第二条路线是SDK的“Xilinx Tools -> Program Flash Memory”。这种方式会先把bitstream和Bootloader通过JTAG加载到FPGA，让MicroBlaze运行起来，然后由MicroBlaze通过SPI控制器直接操作Flash，把BIN文件写入指定偏移地址。它的好处是全程可以通过串口打印看到进度，而且最终写入的是BIN文件（Bootloader+bitstream+app的合并镜像），一次成型。

实际量产我更多用SDK的Program Flash Memory。烧写时要注意勾选正确的偏移量。默认情况下，完整BIN镜像的偏移是0x0，但如果只想更新应用程序，可以只把app.bin写到之前规划的偏移（比如0x00600000），Bootloader依然从Flash读这个偏移。这个“部分更新”的能力在开发迭代时非常有用，不用每次都擦全片重烧。

4.6 第六步：上电自启验证清单

烧写完成后，理论上板子就能上电自启了。但“烧完就成功”这种事在项目里基本不存在，所以我列了一个验证清单，每次固化后按这个顺序排查：

• 检查板子上的模式拨码是否拨到了SPI启动模式，很多板子默认是JTAG模式，拨错了一上电配置引擎根本不读Flash。
• 断电重启，串口接好，观察是否有Bootloader打印信息。如果没有任何打印，优先怀疑bitstream有没有正确加载，检查Flash偏移0x0区域是不是真的有bitstream数据。
• 如果打印停在DDR calibration timeout，说明DDR初始化失败，回到DDR硬件排查。
• 如果打印显示App loaded但没有应用日志，说明跳转地址或代码搬运长度不对，检查Bootloader里FLASH_APP_ADDR偏移、DDR_APP_ADDR是否和应用链接脚本一致。
• 最后确认应用程序完整跑起来，功能正常才算整个固化流程真正结束。

5. 常见问题与排障实录

5.1 flash download failed - target dll has been cancelled

这个报错在烧Flash时出现的频率极高，几乎每个做固化的人都遇到过。它本质上是个笼统的“传输失败”错误，背后原因五花八门。以我的排查经验，最常见的有四类：第一类，JTAG链路不稳定，比如线材过长、接口松动、下载器供电不足，换个短一点的质量好的JTAG线，或者降低JTAG时钟频率，很多问题直接消失；第二类，FPGA没有先配置成功，烧Flash之前如果bitstream没有正确加载，后续所有操作都会失败，可以先单独Program FPGA一次确认配置正常；第三类，DDR初始化失败，如果固化方案要借用DDR做中转，DDR坏了或者时序不过，报错也会是这个；第四类，Flash型号识别错误或者Flash本身有问题，需要用示波器看Flash的时钟和数据线是否有响应。

如果按这四类顺序排查还不行，我一般会在SDK里把连接超时时间调大，同时把SPI Flash的时钟频率从默认值往下降，比如从50MHz降到10MHz再试，很多时候是Flash芯片不支持那么高的SPI时钟。

5.2 cannot load flash device description与Flash型号识别

这个报错出现在Vivado或SDK用JTAG扫描Flash时。原因是工具自带的Flash器件描述库里没有对应型号的条目，或者Flash ID和库里的不匹配。最直接的解决办法是在烧写界面手动选择完全一致的Flash型号，比如Winbond W25Q128、Spansion S25FL128等。如果列表里确实没有，还得去Xilinx官网下载最新的板级支持包或者更新Vivado的器件库。

另外有一个容易被忽视的点：有些板子上的Flash和FPGA不是直连的，中间加了电平转换或MUX芯片，JTAG烧写识别不出来不一定是Flash型号问题，要先确认链路通畅。用Vivado的Hardware Manager扫描边界扫描链，看看能不能读到正确的Flash ID，这一步能快速定位是链路问题还是型号问题。

5.3 上电不自启、程序跑飞、DDR训练失败的排查

上电不自启是固化后最让人头疼的问题。如果串口完全没有输出，第一件事是确认FPGA配置成功。用示波器看FPGA的DONE信号，如果DONE没有拉高，说明bitstream加载失败。这时需要检查Flash里偏移0x0处是否有正确数据，可以在Vivado Hardware Manager里回读Flash前几个字节，对比bitstream文件头部是否一致。

程序跑飞则比较复杂，常见诱因包括：搬运长度超了实际代码长度，把无效数据也搬过去执行；Cache一致性问题，DMA或者SPI搬运完数据后没有做Cache Invalidate，DDR里数据虽然写进去了但CPU读到的是旧数据；跳转地址不对，比如应用ELF的.text段不是从DDR基地址开始。这些都可以通过打印关键地址和数据来定位，比如在Bootloader里把DDR前16字节打印出来，和应用ELF前16字节对比，很快就能判断搬运是否完整准确。

DDR训练失败的原因前面提过，再强调一遍：DDR颗粒型号选错是头号杀手，其次就是电源纹波和时序不满足。用示波器量一下DDR供电，纹波超过几十毫伏就会影响训练。如果条件允许，把DDR时钟频率往下降一档再试，能快速判断是不是时序裕量不够。

5.4 补充：Zynq和MicroBlaze固化方案的差异

有朋友做Zynq会遇到类似的固化问题，这里顺便说下区别。Zynq是ARM硬核加FPGA的SoC，它的启动流程由片内BootROM主导，固化用FSBL（First Stage Bootloader），镜像格式是BOOT.BIN。Zynq固化Flash时DDR不是绝对必须的，因为FSBL可以运行在OCM里，但要加载较大应用或者跑Linux，DDR基本绕不开。而MicroBlaze是纯软核，它的“BootROM”本身就是bitstream里初始化出来的BRAM，所以固化链路里Bootloader ELF必须和bitstream合并，这个差异导致了镜像制作方式完全不同。如果你在两种平台上都做固化，工具箱和思维模式都得切换一下，别把Zynq的BIF语法硬套在MicroBlaze上。

6. 工程化建议：从“能固化”到“好固化”

最后分享几条我做固化流程工程化的实际经验，这部分算是我踩坑之后沉淀下来的方法，能帮你把“偶尔能固化成功”变成“每次都能稳定固化”。

第一条，把镜像生成和烧写脚本化。不要每次都在SDK的图形界面里点来点去，把bootgen命令和烧写命令写成一个批处理或Makefile脚本，参数用环境变量传。这样既减少了手动操作失误，也方便CI集成。实测下来，脚本化之后固化的平均耗时能缩短一半。

第二条，Flash分区一定要在设计阶段就规划好。我常用的分区方案是：0x0到0x500000放bitstream（具体大小取决于FPGA型号），0x500000到0x600000放Bootloader的备份或保留区，0x600000到0x1000000放应用程序。预留足够的应用区空间，避免每次代码一膨胀就往后面挪地址，把Bootloader里的偏移量改来改去改出问题。

第三条，开发迭代阶段用“先DDR后固化”的方式来加速。程序逻辑还在频繁修改时，先用JTAG加载到DDR跑，跑通了再走固化流程。不要每次改几行代码就烧一次Flash，Flash是有擦写寿命的，而且烧写一遍要好几分钟，效率非常低。

第四条，Bootloader里一定加上详细的打印信息。有些工程师觉得Bootloader越精简越好，打印信息能省则省。我的观点恰恰相反，Bootloader阶段的打印信息是启动排障的唯一手段，至少要把DDR等待、Flash读取起始地址、搬运长度、跳转地址这些关键信息打出来，以后排查问题能救命。

第五条，每次固化完成后，把BOOT.bin、BIF、对应Vivado工程的版本和Git提交号记录下来。现场出问题时，能快速确认当前烧的是哪一版镜像，否则两个工程师对着不同版本的程序排查兼容性问题，会浪费大量时间。