1. FPGA固件升級(jí)方案

FPGA的硬件可編程性給設(shè)計(jì)帶來(lái)了很高的靈活性，基于FPGA的產(chǎn)品也會(huì)有更新或升級(jí)的需求，而且大多數(shù)情況下由于現(xiàn)場(chǎng)環(huán)境、人力物力成本的限制，無(wú)法通過(guò)下載器JTAG方式進(jìn)行刷新程序，比如機(jī)房服務(wù)器中的FPGA加速卡或采集卡，無(wú)法隨便出入機(jī)房進(jìn)行升級(jí)，F(xiàn)PGA部署在偏遠(yuǎn)山區(qū)的基站或高高的通信塔臺(tái)等等場(chǎng)景，現(xiàn)場(chǎng)通過(guò)下載器JTAG方式升級(jí)固件，一方面影響用戶體驗(yàn)和滿意度，另一方面又要耗費(fèi)大量的人力物力。所以就有了FPGA遠(yuǎn)程更新固件的需求，要滿足以下升級(jí)要求：

基本的固件升級(jí)功能，傳輸方式可基于常見(jiàn)的通訊協(xié)議，如串口、USB、CAN、網(wǎng)口、WiFi、藍(lán)牙、PCIe等協(xié)議來(lái)實(shí)現(xiàn)升級(jí)。

基本的防止變磚功能，即在升級(jí)過(guò)程中任何時(shí)刻，出現(xiàn)異常情況，如斷電，線纜斷開(kāi)等，都應(yīng)該能保證重新上電后，還可以再次完成升級(jí)流程，防止芯片變磚。

升級(jí)流程的優(yōu)化，可靠的通訊協(xié)議，例如握手、校驗(yàn)、應(yīng)答等等，在滿足基本功能的情況下，更高的升級(jí)效率。

對(duì)于單片機(jī)來(lái)說(shuō)，IAP固件升級(jí)有非常成熟的應(yīng)用方案，升級(jí)方式也很豐富，尤其是在當(dāng)前日益豐富的ARM芯片環(huán)境下，不同廠家的單片機(jī)升級(jí)程序之間進(jìn)行移植也非常方便。

但是對(duì)于FPGA來(lái)說(shuō)，IAP升級(jí)就比較復(fù)雜。目前Xilinx和Altera的FPGA都是基于RAM結(jié)構(gòu)，內(nèi)部沒(méi)有Flash存儲(chǔ)器，固件程序一般都存儲(chǔ)在外置的SPI Flash中，芯片上電之后，會(huì)先從Flash中讀取數(shù)據(jù)，并加載到FPGA內(nèi)部RAM。

在程序加載完成之后，SPI Flash就可以被用戶執(zhí)行讀寫(xiě)操作，所以我們只需要在程序中實(shí)現(xiàn)對(duì)SPI Flash讀寫(xiě)控制器就可以達(dá)到升級(jí)固件的目的。

固件通過(guò)串口或網(wǎng)口等傳輸協(xié)議發(fā)送到FPGA，F(xiàn)PGA將此數(shù)據(jù)寫(xiě)入到SPI Flash，當(dāng)完全寫(xiě)入之后，重新上電執(zhí)行的就是更新之后的程序。

這種方案理論上是可行的，但是有一個(gè)很大的風(fēng)險(xiǎn)，一旦在數(shù)據(jù)寫(xiě)入的過(guò)程中斷電，或者線纜松動(dòng)等異常情況發(fā)生，就會(huì)導(dǎo)致固件程序?qū)懭氩煌暾?，那么在下次啟?dòng)時(shí)，程序就無(wú)法運(yùn)行，F(xiàn)PGA變磚，拯救的辦法還是要通過(guò)最原始的下載器JTAG方式來(lái)恢復(fù)。

那可不可以像單片機(jī)那樣存儲(chǔ)兩套固件程序：Bootloader和Application，Bootloader程序永遠(yuǎn)不會(huì)被破壞，從而保證不會(huì)變磚。

答案是肯定的，F(xiàn)PGA廠商也考慮到了這個(gè)問(wèn)題，Xilinx 6和7系列FPGA上都提供了雙鏡像方案，即：Golden鏡像和Multiboot鏡像，簡(jiǎn)稱(chēng)為G鏡像和M鏡像，可以簡(jiǎn)單理解為單片機(jī)的Bootloader和Application程序。

M鏡像就是用戶程序，G鏡像就是為了防止變磚而存在的備用固件，無(wú)論出現(xiàn)任何異常情況，都不會(huì)破壞G鏡像的數(shù)據(jù)內(nèi)容，從而可以實(shí)現(xiàn)即使升級(jí)失敗，也不會(huì)變磚。

Xilinx FPGA還支持被動(dòng)加載，即通過(guò)外置MCU來(lái)提供數(shù)據(jù)，從而實(shí)現(xiàn)程序升級(jí)，所以FPGA固件升級(jí)問(wèn)題就轉(zhuǎn)換為單片機(jī)的程序文件升級(jí)，這種方式無(wú)需FPGA設(shè)計(jì)做任何修改，需要外部增加一顆MCU硬件支持，本文不做介紹。

本文介紹如何創(chuàng)建Golden鏡像和Multiboot鏡像，以及加載失敗Fallback回退的原理。

2. Golden鏡像和Multiboot鏡像簡(jiǎn)介

Multiboot鏡像是用戶應(yīng)用程序，Golden鏡像是用來(lái)保證升級(jí)過(guò)程中出現(xiàn)錯(cuò)誤，設(shè)備不會(huì)變磚。

那么這兩個(gè)鏡像是如何啟動(dòng)的呢？

首先Golden鏡像的最前面是Header部分，為了方便介紹，還是分為三個(gè)部分來(lái)介紹：Header、Golden和Multiboot，我們先來(lái)看看它們?cè)赟PI Flash中的存儲(chǔ)順序，以SPI Flash M25P16為例，存儲(chǔ)空間大小是16Mbit（2MByte），地址范圍是：0x0-0x1FFFFF

Header位于存儲(chǔ)器的頭部分，地址范圍是0-0x43，其中包括了G鏡像和M鏡像的24位起始地址。

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

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

上電后的啟動(dòng)順序是：

1.執(zhí)行Header中的命令，Header中指定了Multiboot鏡像地址（0x100000），以及Multiboot加載失敗后回退地址，即Golden地址（0x44）。

2.跳轉(zhuǎn)到M鏡像地址，開(kāi)始加載M鏡像，如果加載成功，則直接運(yùn)行M鏡像

3.如果加載M鏡像地址遇到錯(cuò)誤，比如沒(méi)有找到同步字、IDCODE或CRC校驗(yàn)錯(cuò)誤，則跳轉(zhuǎn)到Golden鏡像地址開(kāi)始運(yùn)行。

下圖介紹了Xilinx雙鏡像方案的啟動(dòng)過(guò)程：

所以一般的應(yīng)用方案是：

G鏡像實(shí)現(xiàn)對(duì)M鏡像所在的存儲(chǔ)區(qū)域?qū)懖僮?/p>

M鏡像的功能，除了用戶邏輯之后，也包括對(duì)M鏡像自身所在的存儲(chǔ)區(qū)域進(jìn)行更新，即自更新。

Golden鏡像一旦確定，就不會(huì)更改，升級(jí)過(guò)程中也不會(huì)操作G鏡像所在的存儲(chǔ)區(qū)域，這樣就可以保證在M鏡像加載出錯(cuò)時(shí)，G鏡像能夠正常加載。

下面以正常升級(jí)和升級(jí)出錯(cuò)，來(lái)介紹兩個(gè)鏡像的加載過(guò)程：

正常升級(jí)：上電后會(huì)直接運(yùn)行M鏡像程序，在程序運(yùn)行過(guò)程中，接收到升級(jí)指令后，執(zhí)行對(duì)M鏡像區(qū)域的更新，更新完成后，重新上電，因?yàn)榇藭r(shí)M鏡像存儲(chǔ)區(qū)的數(shù)據(jù)已經(jīng)被更新，所以重新上電后執(zhí)行的是新的M鏡像程序，即可以達(dá)到程序升級(jí)的功能。

升級(jí)出錯(cuò)：當(dāng)M鏡像升級(jí)過(guò)程中出錯(cuò)時(shí)，比如在執(zhí)行數(shù)據(jù)寫(xiě)入時(shí)斷電，此時(shí)會(huì)導(dǎo)致更新后的M鏡像區(qū)域不完整，那么在下次重新上電后，M鏡像加載失敗，會(huì)回退到G鏡像運(yùn)行，因?yàn)镚鏡像同樣包括更新功能，所以可以對(duì)M鏡像存儲(chǔ)區(qū)進(jìn)行升級(jí)，即使升級(jí)過(guò)程中出錯(cuò)，也不會(huì)對(duì)G鏡像造成影響，下次上電啟動(dòng)仍然可以通過(guò)運(yùn)行G鏡像來(lái)實(shí)現(xiàn)M鏡像更新。

接下來(lái)分別以XC6SLX9和XC7K325，演示在ISE和Vivado環(huán)境下，Golden鏡像和Multiboot鏡像如何生成。

3. ISE環(huán)境下實(shí)現(xiàn)（XC6SLX9）

為了區(qū)分G鏡像和M鏡像運(yùn)行現(xiàn)象，分別新建兩個(gè)ISE工程，bit流生成選項(xiàng)都先保持默認(rèn)配置，G鏡像功能為1個(gè)LED閃爍，M鏡像功能為4個(gè)LED閃爍，可以通過(guò)觀察LED閃爍的個(gè)數(shù)來(lái)區(qū)分當(dāng)前運(yùn)行的是哪個(gè)鏡像程序。

下面我們分別針對(duì)G鏡像和Ｍ鏡像進(jìn)行bit流生成選項(xiàng)配置。

為了保證加載失敗時(shí)，重新執(zhí)行配置過(guò)程，無(wú)論是G鏡像還是M鏡像都需要使能General Options->Retry Configuration if CRC Error Occurs：

G鏡像還需要配置以下兩個(gè)地方，M鏡像的地址需要根據(jù)所使用SPI Flash型號(hào)進(jìn)行設(shè)置。

我所使用的是M25P16，整個(gè)存儲(chǔ)區(qū)域分為兩部分，前半部分存放Header和G鏡像（0x44），后半部分存放M鏡像，起始地址0x100000。

為什么前面有0x03呢？這是SPI Flash的讀操作命令，G鏡像的偏移量為什么是0x44呢？因?yàn)镠eader部分?jǐn)?shù)據(jù)長(zhǎng)度是0x44，G鏡像位于Header之后，G鏡像的起始地址就是0x44。

M鏡像需要配置以下兩個(gè)地方：

M鏡像還要加上一條配置參數(shù)：

-gnext_config_register_write:Disable

分別編譯生成G鏡像bit文件和M鏡像bit文件。

使用iMPACT合成mcs文件，以M25P16為例，G鏡像中已經(jīng)包含了Header部分，所以選擇從0地址開(kāi)始存儲(chǔ)，M鏡像從0x100000開(kāi)始存儲(chǔ)。

分別加載對(duì)應(yīng)的bit文件：

mcs文件燒錄到FPGA外部Flash之后，通電運(yùn)行，會(huì)發(fā)現(xiàn)4顆在LED閃爍，說(shuō)明當(dāng)前是M鏡像在運(yùn)行。

也可以通過(guò)人為修改M鏡像的內(nèi)容來(lái)觸發(fā)G鏡像啟動(dòng)，比如修改G鏡像中的IDCODE，或中間的數(shù)據(jù)部分導(dǎo)致CRC校驗(yàn)錯(cuò)誤觸發(fā)回退。

把修改之后錯(cuò)誤的M鏡像bit文件和G鏡像bit文件重新合并成mcs，燒錄到FPGA，再次運(yùn)行，會(huì)發(fā)現(xiàn)1個(gè)LED在閃爍，說(shuō)明啟動(dòng)M鏡像時(shí)遇到錯(cuò)誤，回退到G鏡像運(yùn)行。

啟動(dòng)之后，也可以通過(guò)iMPACT讀取狀態(tài)寄存器來(lái)判斷是哪種方式觸發(fā)的回退。

正常的M鏡像啟動(dòng)流程：

加載Ｍ鏡像時(shí)遇到CRC錯(cuò)誤，啟動(dòng)G鏡像：

4. Vivado環(huán)境下實(shí)現(xiàn)（XC7K325T）

Vivado和ISE環(huán)境略有不同，是在xdc約束文件中分別配置M鏡像和G鏡像，同樣，先建立兩個(gè)工程，M鏡像的功能是4個(gè)LED閃爍，G鏡像的功能是1個(gè)LED閃爍。

無(wú)論是G鏡像還是M鏡像，都需要添加以下QSPI總線寬度、加載時(shí)鐘頻率約束：

#bitstreamcompressionenable
set_propertyBITSTREAM.GENERAL.COMPRESSTRUE[current_design]
set_propertyCONFIG_VOLTAGE3.3[current_design]
set_propertyCFGBVSVCCO[current_design]

#qspiflashbuswidth=4
set_propertyBITSTREAM.CONFIG.SPI_BUSWIDTH4[current_design]
set_propertyBITSTREAM.CONFIG.CONFIGRATE50[current_design]

G鏡像工程要單獨(dú)添加以下約束，指定M鏡像的存儲(chǔ)地址0x800000：

# golden工程需要配置以下Multiboot加載的地址：128Mbit/2
set_propertyBITSTREAM.CONFIG.NEXT_CONFIG_ADDR32'h00800000[current_design]
set_propertyBITSTREAM.CONFIG.NEXT_CONFIG_REBOOTENABLE[current_design]

M鏡像工程要單獨(dú)添加以下約束：

#multiboot使能fallback功能
set_propertyBITSTREAM.CONFIG.CONFIGFALLBACKENABLE[current_design]

G鏡像和M鏡像bit文件合并成一個(gè)mcs：

燒錄之后會(huì)發(fā)現(xiàn)4顆LED閃爍，即當(dāng)前是M鏡像運(yùn)行。

M鏡像加載成功的狀態(tài)寄存器值：

修改M鏡像的數(shù)據(jù)部分，人為造成CRC錯(cuò)誤啟動(dòng)G鏡像，狀態(tài)寄存器的值：

5. Golden鏡像Header分析

下面對(duì)ISE環(huán)境下生成的G鏡像bin文件進(jìn)行解析，看看G鏡像是怎么啟動(dòng)的，Vivado生成的G鏡像命令略有不同。

G鏡像其實(shí)已經(jīng)包含了Header部分，位于G鏡像的前面44個(gè)字節(jié)，之后才是G鏡像部分。

Header部分解析：

/*原始Header數(shù)據(jù)*/
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAA99556631E1FFFF326100003281031032A1004432C1030032E1000030A10000330121003201005F30A1000E2000200020002000

/*Header數(shù)據(jù)解析*/
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

AA995566//SyncWord

31E1//WRITE:ConfigurationWatchdogTimer.
FFFF//0xFFFF

3261//WRITEM鏡像起始地址低16位=0x0000
0000

3281//WRITESPI操作命令0x03(READ),M鏡像起始地址高8位=0x10
0310

32A1//WRITEG鏡像起始地址低16位=0x0044
0044

32C1//WRITESPI操作命令0x03(READ),G鏡像起始地址高8位=0x00
0300

32E1//WRITE:User-definedregisterforfail-safescheme.
0000

30A1//WRITE:Type1Write1WordtoCMD
0000

3301//WRITE:Rebootmode.
2100

3201//WRITE:HouseCleanOptionregister.
005F

30A1//WRITE:IPROGCommand
000E//執(zhí)行完此命令后，跳轉(zhuǎn)到M鏡像起始地址開(kāi)始加載

2000//NOP
2000//NOP
2000//NOP
2000//NOP

關(guān)于Header部分命令的說(shuō)明，可以參考文末的官方文檔，6系列對(duì)應(yīng)UG380，7系列對(duì)應(yīng)UG470。

可以看出，我們?cè)贗SE中G鏡像bit生成選項(xiàng)中的配置，比如M鏡像地址和G鏡像地址，最終體現(xiàn)在G鏡像bit文件的Header部分。

審核編輯：湯梓紅