AMD FPGA的MicroBlaze固化過程詳解

一、簡介

MicroBlaze是AMD FPGA推出的一款32/64位軟核嵌入式處理器，其高度可配置，可滿足通信、工業、醫療、汽車、以及消費類各場景需求。MicroBlaze是AMD FPGA嵌入式產品的重要組成部件，具有多功能互聯系統，可支持各種嵌入式應用。

MicroBlaze的易用性使得其開發如AMD其它嵌入式SoCFPGA一樣簡單?？蛻粼诖罱ê琈icroBlaze IP的工程后，經常遇到的問題是，如何將.bit文件與應用程序.elf文件結合，固化到存儲器件中（一般指串型/并行FLASH）。下面將結合原理與固化過程，詳細描述此問題。

二、疑難理解

首先，要理解的一點是，AMD FPGA在配置了適當的啟動模式后，上電即會按該模式去加載配置文件。以7系列FPGA為例，假設設置模式引腳M[2:0]=3’b001，上電后FPGA會以MasterSPI方式嘗試從FLASH加載配置文件，其與工程是否含有MicroBlaze IP無關。其次，客戶經常遇到的問題是，含MicroBlaze IP的工程中，需要考慮程序的運行地址空間（涉及DDR MIG IP）；需要考慮應用程序的加載（涉及AXI Quad SPI IP），在固化時某些選項配置錯誤，導致系統無法啟動。

三、固化過程詳解

思考一個問題，在含有MicroBlaze的設計中，DDR MIG IP和AXI Quad SPI IP必須同時存在嗎？帶著這個疑問，下面詳細講解MicroBlaze兩種應用場景下的固化過程。演示過程以7系列FPGA器件，以vitisv2022.2版本工具，以SPI FLASH存儲器件為例，其它系列器件和工具版本類似。

場景一，MicroBlaze運行簡單的應用。如GPIO控制，IIC、UART等低速嵌入式總線應

用，或者負責一些復雜IP和外圍IC的初始化輔助性工作。此時，FPGA固化固件組成形式如下圖所示。

?

在這個場景下，vivado生成的fpga.bit文件和vitis生成的應用程序app.elf文件，合并為download.bit文件，燒錄到FLASH的起始地址0x0中。此設計中，不需要借助AXI Quad SPI IP的應用搬運能力，對是否含有DDR MIG IP也無要求。下面展示該固化流程：

為增加迷惑性，設計中含有DDR MIG IP。vivado生成.bit文件后，導出.xsa文件，創建vitis軟件工程。應用程序的ld腳本默認Memory Region Mapping指向外部DDR。

?

點擊Program Device菜單生成download.bit文件將出現address mapped error錯誤，無法生成download.bit文件。

注意：

需要選擇應用程序生成的.elf文件(如圖示的hello.elf文件)，而不是vitis默認的bootloader。

?

此時需要修改工程ld腳本文件，將MemoryRegion Mapping設置為local bram，如下圖所示

?

再次點擊Program Device菜單生成download.bit文件即可。由于一般情況下，為節省FPGA block ram資源，用于MicroBlaze的local bram并不會設置很大，可使用下圖所示優化選項，減小固件的大小。

? ?

生成download.bit文件后，JTAG模式下，燒錄固件到FLASH中，注意Offset項為0x0。

?

燒錄過程log記錄：

?

斷電，將啟動模式設置為Master SPI，系統啟動log如下：

上述展示了一個簡單的應用程序的固件固化過程。

場景二，MicroBlaze運行復雜的應用。如輕量級的網絡協議棧LwIP，加載嵌入式文件

系統等。此場景一般生成的固件達到MB級別，對內存也有一定需求，需要借助DDR來運行應用程序。此時，FPGA固化固件組成形式如下圖所示

?

在這個場景下，vivado生成的fpga.bit文件和vitis生成的應用引導程序bootloader.elf文件，合并為download.bit文件，燒錄到FLASH的起始地址0x0中；復雜的應用程序app.elf文件，燒錄到FLASH的指定offset地址中。

此設計中，必須借助AXI Quad SPI IP的應用搬運能力，復雜應用程序一般對DDR也有要求，也即設計需要DDR MIG IP。下面展示該固化流程：

首先在vivado中，需要對AXI Quad SPI IP做正確的設置，選擇FLASH的型號，使能STARTUPPrimitive選項。

?

然后創建bootloader引導工程，如下

vitis工程引導界面提示修改合適的應用程序offset address。

?

查看bootloader工程的ld腳本，確定bootloader工程的Memory Region Mapping指向為local bram。

?

同時需要修改應用程序在FLASH中的程序地址，根據FLASH的容量大小，選擇合適的偏移地址。這里修改為0x800000(起始地址偏移8MB空間)。

點擊Program Device菜單生成download.bit文件，注意選擇的是bootloader.elf文件。

備注：

vitis IDE中，此菜單項包含Generate和Program選項，一般JTAG未連接板卡時選擇Generate選項；連接JTAG在線調試時，選擇Program。但是無論是否連接JTAG，兩個選項都能生成download.bit文件。

?

將生成的download.bit文件燒錄到FLASH的0x0地址中。

?

斷電，將啟動模式設置為Master SPI ，可驗證bootloader是否燒錄成功，其啟動log如上。

log顯示bootloader將從00800000地址中加載應用程序固件，證明bootloader燒錄成功。

接下來創建應用工程，應用工程較復雜，所需運行內存較大，應用工程的ld腳本文件Memory Region Mapping指向外部DDR。

點擊Program Flash Memory菜單，將應用程序hello.elf燒錄到FLASH中，注意Offset項為之前bootloader工程設置的0x800000，且需要勾選SREC轉換選項。

燒錄過程輸出log記錄。

斷電，將啟動模式設置為Master SPI，系統啟動log如下：

上述演示了一個稍復雜的應用程序的固件固化過程。

四、總結與拓展

1. 通過燒錄過程可發現，場景二的bootloader引導應用程序即相當于場景一的用戶程序；

2. 場景二的系統啟動速度相對場景一較慢，AMD FPGA提供了一種加速方法，詳細參考

https://support.xilinx.com/s/article/75646?language=en_US

3. 從2019.2版本工具開始，FLASH的驅動程序發生了變更，詳細參考

https://support.xilinx.com/s/article/73329?language=en_US

4. 從SDK到Vitis，上述固化過程原理不變，但一些菜單選項細節稍有不同；

5. 從UltraScale系列開始支持的SPIx8模式，細節上有一些區別，詳細參考官方手冊UG570。

審核編輯：劉清