XilinxFPGAMultiboot設(shè)計(jì)與實(shí)現(xiàn)（Spartan-6和Kintex-7示例）

都有哪些內(nèi)容？

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

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

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

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

5. Golden鏡像Header分析

6. 參考資料

7. 示例工程

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

• 基本的防止變磚功能，即在升級(jí)過(guò)程中任何時(shí)刻，出現(xiàn)異常情況，如斷電，線纜斷開等，都應(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)部沒有Flash存儲(chǔ)器，固件程序一般都存儲(chǔ)在外置的SPI Flash中，芯片上電之后，會(huì)先從Flash中讀取數(shù)據(jù)，并加載到FPGA內(nèi)部RAM。

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

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

這種方案理論上是可行的，但是有一個(gè)很大的風(fēng)險(xiǎn)，一旦在數(shù)據(jù)寫入的過(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)稱為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鏡像地址，開始加載M鏡像，如果加載成功，則直接運(yùn)行M鏡像

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

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

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

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

2. 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ù)寫入時(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ù)：

-g?next_config_register_write:Disable

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

使用iMPACT合成mcs文件，以M25P16為例，G鏡像中已經(jīng)包含了Header部分，所以選擇從0地址開始存儲(chǔ)，M鏡像從0x100000開始存儲(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í)鐘頻率約束：

#?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鏡像工程要單獨(dú)添加以下約束，指定M鏡像的存儲(chǔ)地址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鏡像工程要單獨(dú)添加以下約束：

#?multiboot使能fallback功能
set_property?BITSTREAM.CONFIG.CONFIGFALLBACK?ENABLE?[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ù)*/
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數(shù)據(jù)解析*/
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???//執(zhí)行完此命令后，跳轉(zhuǎn)到M鏡像起始地址開始加載

20?00???//NOP
20?00???//NOP
20?00???//NOP
20?00???//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部分。

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_Config.pdf

• Spartan6 Mutiboot實(shí)現(xiàn)方法記錄

  https://www.cnblogs.com/cnpirate/p/14030839.html

• xapp1247-multiboot-spi.pdf

  https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf

• xapp1246-multiboot-bpi.pdf

  https://www.xilinx.com/support/documentation/application_notes/xapp1246-multiboot-bpi.pdf

7. 示例工程

• xc6slx9_multiboot_golden_demo.rar

  https://download.csdn.net/download/whik1194/87615764

• xc7k325t_multiboot_golden_demo.rar

  https://download.csdn.net/download/whik1194/87615745

精選文章