做FPGAMicroBlaze的工程最绕不开的一个坎就是“程序在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函数我自己习惯用一条链路来描述整个启动过程理解了这条链路后面所有操作就都有方向感了。按下电源后的完整时序是这样的FPGA配置引擎按照模式引脚设定从SPI Flash偏移0x0处读取bitstream完成内部逻辑配置此时MicroBlaze内核和MIG DDR控制器已经存在于FPGA内部。MicroBlaze复位释放后PC指针指向复位向量也就是0x00000000地址。这个地址必须映射到一个非易失、已经可用的存储介质上。在标准固化方案里这个位置是片内BRAM且BRAM里的内容已经被bitstream初始化好了。位于BRAM的Bootloader代码开始执行它首先等待MIG DDR控制器完成初始化校准然后通过SPI控制器从Flash的应用程序偏移地址读取代码数据。Bootloader把读取到的代码搬运到DDR的指定地址搬运完成后刷新Cache然后跳转到应用程序入口。应用程序在DDR里开始执行CPU正式进入main函数。很多人一开始不理解为什么非要加一道Bootloader的工序不能直接把应用程序放在Flash里让CPU跑吗这个问题的答案涉及存储器属性差异后面详细展开。2. 启动原理上电之后CPU到底是怎么找到程序的2.1 复位向量和BRAMMicroBlaze上电后的第一步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理论上可以前提是系统里有XIPExecute 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文件在这条链路里扮演的角色也要提一下。MMIMemory Map File是Vivado导出的一个文本文件描述了bitstream里各个BRAM块的地址映射关系。SDK和bootgen就是靠这个文件知道该把ELF里的哪一段数据写到bitstream的哪个BRAM位置。有一些旧版本或特殊流程需要手动指定MMI路径不理解这个原理就会卡在报错上。3. 动手前准备DDR和MicroBlaze系统配置的几个关键点3.1 MIG DDR控制器配置心得DDR这块我在Vivado里用的是Memory Interface GeneratorMIGIP核。配置时最核心的是选择合适的颗粒型号和位宽。颗粒型号要严格跟板子上焊的DDR颗粒一致比如镁光MT41K256M16这种选错了训练根本过不去。位宽方面Artix-7上常见16bit或者32bit位宽越大带宽越高但占用管脚也越多。MicroBlaze总线和MIG之间通常通过AXI Interconnect转接数据位宽不匹配时自动做宽度转换但会有少量性能损失能对齐尽量对齐。DDR的地址分配也要提前规划好。MIG的接口地址通常设为0x80000000开头这样在AXI地址空间里DDR就落在高端地址区域和低端的BRAM0x00000000以及外设地址0x40000000之类天然分开不容易冲突。MIG生成的时钟频率和DDR颗粒的speed grade有关系如果你的板子DDR跑不到标称频率时序上不去训练就会失败报“DDR calibration failed”。这个错误经常会连带Flash烧写报错因为很多烧写方案需要通过DDR做中转缓存。后面排障章节会细说。3.2 MicroBlaze存储器映射规划MicroBlaze的存储映射规划直接决定后面Bootloader链接脚本和应用链接脚本怎么写。我通常按这样的方式划分地址空间地址范围用途说明0x00000000 - 0x0000FFFF本地存储器BRAMBootloader代码运行区复位向量指向这里0x40000000 - 0x4000FFFFAXI GPIO / UART / SPI等外设挂在AXI总线上的低速外设0x80000000 - 0x8FFFFFFFDDR应用程序运行区应用程序被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启动时会读取这个文件来创建平台工程。老版本Vivado2018.3及以前里叫“Export Hardware”新版本Vitis2019.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基地址比如0x80000000Bootloader跳转到这个地址时要保证对应的机器码是有效的。为了让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 microblazeBIF文件内容示例如下the_ROM_image: { [bootloader]D:/proj/bootloader/Debug/bootloader.elf [image]D:/proj/vivado/system.bit [image]D:/proj/app/Debug/app.elf }有几点值得提醒。第一如果用的是老版本Vivadobootgen支持的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文件Bootloaderbitstreamapp的合并镜像一次成型。实际量产我更多用SDK的Program Flash Memory。烧写时要注意勾选正确的偏移量。默认情况下完整BIN镜像的偏移是0x0但如果只想更新应用程序可以只把app.bin写到之前规划的偏移比如0x00600000Bootloader依然从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 InvalidateDDR里数据虽然写进去了但CPU读到的是旧数据跳转地址不对比如应用ELF的.text段不是从DDR基地址开始。这些都可以通过打印关键地址和数据来定位比如在Bootloader里把DDR前16字节打印出来和应用ELF前16字节对比很快就能判断搬运是否完整准确。DDR训练失败的原因前面提过再强调一遍DDR颗粒型号选错是头号杀手其次就是电源纹波和时序不满足。用示波器量一下DDR供电纹波超过几十毫伏就会影响训练。如果条件允许把DDR时钟频率往下降一档再试能快速判断是不是时序裕量不够。5.4 补充Zynq和MicroBlaze固化方案的差异有朋友做Zynq会遇到类似的固化问题这里顺便说下区别。Zynq是ARM硬核加FPGA的SoC它的启动流程由片内BootROM主导固化用FSBLFirst Stage Bootloader镜像格式是BOOT.BIN。Zynq固化Flash时DDR不是绝对必须的因为FSBL可以运行在OCM里但要加载较大应用或者跑LinuxDDR基本绕不开。而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跑跑通了再走固化流程。不要每次改几行代码就烧一次FlashFlash是有擦写寿命的而且烧写一遍要好几分钟效率非常低。第四条Bootloader里一定加上详细的打印信息。有些工程师觉得Bootloader越精简越好打印信息能省则省。我的观点恰恰相反Bootloader阶段的打印信息是启动排障的唯一手段至少要把DDR等待、Flash读取起始地址、搬运长度、跳转地址这些关键信息打出来以后排查问题能救命。第五条每次固化完成后把BOOT.bin、BIF、对应Vivado工程的版本和Git提交号记录下来。现场出问题时能快速确认当前烧的是哪一版镜像否则两个工程师对着不同版本的程序排查兼容性问题会浪费大量时间。
