Xilinx FPGA Multiboot设计与实现（Spartan-6和Kintex-7示例）

1. FPGA固件升级方案

FPGA的硬件可编程性给设计带来了很高的灵活性，基于FPGA的产品也会有更新或升级的需求，而且大多数情况下由于现场环境、人力物力成本的限制，无法通过下载器JTAG方式进行刷新程序，比如机房服务器中的FPGA加速卡或采集卡，无法随便出入机房进行升级，FPGA部署在偏远山区的基站或高高的通信塔台等等场景，现场通过下载器JTAG方式升级固件，一方面影响用户体验和满意度，另一方面又要耗费大量的人力物力。所以就有了FPGA远程更新固件的需求，要满足以下升级要求：

基本的固件升级功能，传输方式可基于常见的通讯协议，如串口、USB、CAN、网口、WiFi、蓝牙、PCIe等协议来实现升级。

基本的防止变砖功能，即在升级过程中任何时刻，出现异常情况，如断电，线缆断开等，都应该能保证重新上电后，还可以再次完成升级流程，防止芯片变砖。

升级流程的优化，可靠的通讯协议，例如握手、校验、应答等等，在满足基本功能的情况下，更高的升级效率。

对于单片机来说，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

Header位于存储器的头部分，地址范围是0-0x43，其中包括了G镜像和M镜像的24位起始地址。

G镜像位于Header之后，地址范围是：0x44-0xFFFFF

M镜像位于Flash后半部分，地址范围是：0x100000-0x1FFFFF

上电后的启动顺序是：

1.执行Header中的命令，Header中指定了Multiboot镜像地址（0x100000），以及Multiboot加载失败后回退地址，即Golden地址（0x44）。

2.跳转到M镜像地址，开始加载M镜像，如果加载成功，则直接运行M镜像

3.如果加载M镜像地址遇到错误，比如没有找到同步字、IDCODE或CRC校验错误，则跳转到Golden镜像地址开始运行。

下图介绍了Xilinx双镜像方案的启动过程：

所以一般的应用方案是：

G镜像实现对M镜像所在的存储区域写操作

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 next_config_register_write:Disable

 

分别编译生成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   //WRITEM镜像起始地址低16位=0x0000
00 00   

32 81   //WRITESPI操作命令0x03(READ), M镜像起始地址高8位=0x10
03 10   

32 A1   //WRITEG镜像起始地址低16位=0x0044
00 44  

32 C1   //WRITESPI操作命令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部分。

　　审核编辑：汤梓红