本文转载自： 电子电路开发学习微信公众号
1. FPGA固件升级方案
FPGA的硬件可编程性给设计带来了很高的灵活性，基于FPGA的产品也会有更新或升级的需求，而且大多数情况下由于现场环境、人力物力成本的限制，无法通过下载器JTAG方式进行刷新程序，比如机房服务器中的FPGA加速卡或采集卡，无法随便出入机房进行升级，FPGA部署在偏远山区的基站或高高的通信塔台等等场景，现场通过下载器JTAG方式升级固件，一方面影响用户体验和满意度，另一方面又要耗费大量的人力物力。所以就有了FPGA远程更新固件的需求，要满足以下升级要求：
对于单片机来说，IAP固件升级有非常成熟的应用方案，升级方式也很丰富，尤其是在当前日益丰富的ARM芯片环境下，不同厂家的单片机升级程序之间进行移植也非常方便。
但是对于FPGA来说，IAP升级就比较复杂。目前Xilinx和Altera的FPGA都是基于RAM结构，内部没有Flash存储器，固件程序一般都存储在外置的SPI Flash中，芯片上电之后，会先从Flash中读取数据，并加载到FPGA内部RAM。
在程序加载完成之后，SPI Flash就可以被用户执行读写操作，所以我们只需要在程序中实现对SPI Flash读写控制器就可以达到升级固件的目的。
固件通过串口或网口等传输协议发送到FPGA，FPGA将此数据写入到SPI Flash，当完全写入之后，重新上电执行的就是更新之后的程序。
这种方案理论上是可行的，但是有一个很大的风险，一旦在数据写入的过程中断电，或者线缆松动等异常情况发生，就会导致固件程序写入不完整，那么在下次启动时，程序就无法运行，FPGA变砖，拯救的办法还是要通过最原始的下载器JTAG方式来恢复。
那可不可以像单片机那样存储两套固件程序：Bootloader和Application，Bootloader程序永远不会被破坏，从而保证不会变砖。
答案是肯定的，FPGA厂商也考虑到了这个问题，Xilinx 6和7系列FPGA上都提供了双镜像方案，即：Golden镜像和Multiboot镜像，简称为G镜像和M镜像，可以简单理解为单片机的Bootloader和Application程序。
M镜像就是用户程序，G镜像就是为了防止变砖而存在的备用固件，无论出现任何异常情况，都不会破坏G镜像的数据内容，从而可以实现即使升级失败，也不会变砖。
Xilinx FPGA还支持被动加载，即通过外置MCU来提供数据，从而实现程序升级，所以FPGA固件升级问题就转换为单片机的程序文件升级，这种方式无需FPGA设计做任何修改，需要外部增加一颗MCU硬件支持，本文不做介绍。
本文介绍如何创建Golden镜像和Multiboot镜像，以及加载失败Fallback回退的原理。
2. Golden镜像和Multiboot镜像简介
Multiboot镜像是用户应用程序，Golden镜像是用来保证升级过程中出现错误，设备不会变砖。
那么这两个镜像是如何启动的呢？
首先Golden镜像的最前面是Header部分，为了方便介绍，还是分为三个部分来介绍：Header、Golden和Multiboot，我们先来看看它们在SPI Flash中的存储顺序，以SPI Flash M25P16为例，存储空间大小是16Mbit（2MByte），地址范围是：0x0-0x1FFFFF
上电后的启动顺序是：
1.执行Header中的命令，Header中指定了Multiboot镜像地址（0x100000），以及Multiboot加载失败后回退地址，即Golden地址（0x44）。
2.跳转到M镜像地址，开始加载M镜像，如果加载成功，则直接运行M镜像
3.如果加载M镜像地址遇到错误，比如没有找到同步字、IDCODE或CRC校验错误，则跳转到Golden镜像地址开始运行。
下图介绍了Xilinx双镜像方案的启动过程：
所以一般的应用方案是：
1. G镜像实现对M镜像所在的存储区域写操作
2. M镜像的功能，除了用户逻辑之后，也包括对M镜像自身所在的存储区域进行更新，即自更新。
Golden镜像一旦确定，就不会更改，升级过程中也不会操作G镜像所在的存储区域，这样就可以保证在M镜像加载出错时，G镜像能够正常加载。
下面以正常升级和升级出错，来介绍两个镜像的加载过程：
正常升级：上电后会直接运行M镜像程序，在程序运行过程中，接收到升级指令后，执行对M镜像区域的更新，更新完成后，重新上电，因为此时M镜像存储区的数据已经被更新，所以重新上电后执行的是新的M镜像程序，即可以达到程序升级的功能。
升级出错：当M镜像升级过程中出错时，比如在执行数据写入时断电，此时会导致更新后的M镜像区域不完整，那么在下次重新上电后，M镜像加载失败，会回退到G镜像运行，因为G镜像同样包括更新功能，所以可以对M镜像存储区进行升级，即使升级过程中出错，也不会对G镜像造成影响，下次上电启动仍然可以通过运行G镜像来实现M镜像更新。
接下来分别以XC6SLX9和XC7K325，演示在ISE和Vivado环境下，Golden镜像和Multiboot镜像如何生成。
3. ISE环境下实现（XC6SLX9）
为了区分G镜像和M镜像运行现象，分别新建两个ISE工程，bit流生成选项都先保持默认配置，G镜像功能为1个LED闪烁，M镜像功能为4个LED闪烁，可以通过观察LED闪烁的个数来区分当前运行的是哪个镜像程序。
下面我们分别针对G镜像和Ｍ镜像进行bit流生成选项配置。
为了保证加载失败时，重新执行配置过程，无论是G镜像还是M镜像都需要使能General Options->Retry Configuration if CRC Error Occurs：
G镜像还需要配置以下两个地方，M镜像的地址需要根据所使用SPI Flash型号进行设置。
我所使用的是M25P16，整个存储区域分为两部分，前半部分存放Header和G镜像（0x44），后半部分存放M镜像，起始地址0x100000。
为什么前面有0x03呢？这是SPI Flash的读操作命令，G镜像的偏移量为什么是0x44呢？因为Header部分数据长度是0x44，G镜像位于Header之后，G镜像的起始地址就是0x44。
M镜像需要配置以下两个地方：
M镜像还要加上一条配置参数：
分别编译生成G镜像bit文件和M镜像bit文件。
使用iMPACT合成mcs文件，以M25P16为例，G镜像中已经包含了Header部分，所以选择从0地址开始存储，M镜像从0x100000开始存储。
分别加载对应的bit文件：
mcs文件烧录到FPGA外部Flash之后，通电运行，会发现4颗在LED闪烁，说明当前是M镜像在运行。
也可以通过人为修改M镜像的内容来触发G镜像启动，比如修改G镜像中的IDCODE，或中间的数据部分导致CRC校验错误触发回退。
把修改之后错误的M镜像bit文件和G镜像bit文件重新合并成mcs，烧录到FPGA，再次运行，会发现1个LED在闪烁，说明启动M镜像时遇到错误，回退到G镜像运行。
启动之后，也可以通过iMPACT读取状态寄存器来判断是哪种方式触发的回退。
正常的M镜像启动流程：
加载Ｍ镜像时遇到CRC错误，启动G镜像：
4. Vivado环境下实现（XC7K325T）
Vivado和ISE环境略有不同，是在xdc约束文件中分别配置M镜像和G镜像，同样，先建立两个工程，M镜像的功能是4个LED闪烁，G镜像的功能是1个LED闪烁。
无论是G镜像还是M镜像，都需要添加以下QSPI总线宽度、加载时钟频率约束：
# bit stream compression enable
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]
# qspi flash buswidth=4
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 50 [current_design]
G镜像工程要单独添加以下约束，指定M镜像的存储地址0x800000：
# golden工程需要配置以下Multiboot加载的地址：128Mbit/2
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 32'h00800000 [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_REBOOT ENABLE [current_design]
M镜像工程要单独添加以下约束：
# multiboot使能fallback功能
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
G镜像和M镜像bit文件合并成一个mcs：
烧录之后会发现4颗LED闪烁，即当前是M镜像运行。
M镜像加载成功的状态寄存器值：
修改M镜像的数据部分，人为造成CRC错误启动G镜像，状态寄存器的值：
5. Golden镜像Header分析
下面对ISE环境下生成的G镜像bin文件进行解析，看看G镜像是怎么启动的，Vivado生成的G镜像命令略有不同。
G镜像其实已经包含了Header部分，位于G镜像的前面44个字节，之后才是G镜像部分。
Header部分解析：
/*原始Header数据*/
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF AA 99 55 66 31 E1 FF FF 32 61 00 00 32 81 03 10 32 A1 00 44 32 C1 03 00 32 E1 00 00 30 A1 00 00 33 01 21 00 32 01 00 5F 30 A1 00 0E 20 00 20 00 20 00 20 00
/*Header数据解析*/
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
AA 99 55 66 //Sync Word
31 E1 //WRITE:Configuration Watchdog Timer.
FF FF //0xFFFF
32 61 //WRITE:GENERAL1:M镜像起始地址低16位=0x0000
00 00
32 81 //WRITE:GENERAL2:SPI操作命令0x03(READ), M镜像起始地址高8位=0x10
03 10
32 A1 //WRITE:GENERAL3:G镜像起始地址低16位=0x0044
00 44
32 C1 //WRITE:GENERAL4:SPI操作命令0x03(READ), G镜像起始地址高8位=0x00
03 00
32 E1 //WRITE:User-defined register for fail-safe scheme.
00 00
30 A1 //WRITE:Type 1 Write 1 Word to CMD
00 00
33 01 //WRITE:Reboot mode.
21 00
32 01 //WRITE:House Clean Option register.
00 5F
30 A1 //WRITE:IPROG Command
00 0E //执行完此命令后，跳转到M镜像起始地址开始加载
20 00 //NOP
20 00 //NOP
20 00 //NOP
20 00 //NOP
关于Header部分命令的说明，可以参考文末的官方文档，6系列对应UG380，7系列对应UG470。
可以看出，我们在ISE中G镜像bit生成选项中的配置，比如M镜像地址和G镜像地址，最终体现在G镜像bit文件的Header部分。
6. 参考资料
UG380_Spartan-6 FPGA Configuration
https://classes.engineering.wustl.edu/cse462/images/9/99/Ug380.pdf
UG470_7 Series FPGAs Configuration
https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_C...
Spartan6 Mutiboot实现方法记录
https://www.cnblogs.com/cnpirate/p/14030839.html
xapp1247-multiboot-spi.pdf
https://www.xilinx.com/support/documentation/application_notes/xapp1247-...
xapp1246-multiboot-bpi.pdf
https://www.xilinx.com/support/documentation/application_notes/xapp1246-...
7. 示例工程
xc6slx9_multiboot_golden_demo.rar
https://download.csdn.net/download/whik1194/87615764
xc7k325t_multiboot_golden_demo.rar
