从BRAM到DDR：MicroBlaze大应用在FPGA+SPI Flash的固化与引导策略

1. 从BRAM到DDR的必然选择

第一次用MicroBlaze做LED闪烁实验时，我把整个程序塞进FPGA的BRAM里运行，烧录过程简单得像拖拽文件。但当项目升级到需要运行LwIP协议栈时，编译出的507KB elf文件直接让BRAM爆仓——这时候才真正理解为什么需要DDR。

FPGA内部的BRAM就像办公室里的抽屉柜，XC7A100T提供的600多KB容量应付UART通信这类小工具绰绰有余。可当你需要部署文件系统或者TCP/IP协议栈时，这就好比要把整个档案室塞进抽屉柜。我遇到过最极端的情况是：一个包含Web服务的应用编译后虽然elf只有2MB，但运行时需要占用32MB内存空间。

这时候必须转向DDR，就像把档案搬到专门的仓库。但问题来了：SPI Flash通常只有16MB~128MB容量（比如常用的N25Q128），既要存放比特流和Bootloader，又要存储应用程序，还得考虑未来升级空间。我的经验法则是：前1/4容量留给硬件配置（比特流+Bootloader），剩余空间划分应用程序区。比如16MB Flash可以这样规划：

• 0x000000-0x7FFFF：比特流+Bootloader（8MB）
• 0x80000-0xFFFFFF：应用程序区（8MB）

2. 双模式固化方案对比

去年给工业控制器做OTA升级时，我同时实现了两种固化方案。简单应用直接合并比特流的方案，其优势就像把家具和日用品打包进一个行李箱——烧录后开机即用。在Xilinx SDK里操作只需要两步：

1. 右键工程选择"Create Boot Image"
2. 将生成的download.bit烧录到SPI Flash 0地址

但遇到需要DDR的大应用时，就得采用"引导加载"模式。这就像先往行李箱放个智能管家（Bootloader），管家再根据清单（SREC文件）从仓库取货。实测发现关键差异点：

• 合并方案启动时间：<100ms
• Bootloader方案启动时间：约12秒（加载50MB应用）
• 合并方案最大支持：约1.5MB（BRAM上限）
• Bootloader方案支持：仅受DDR容量限制

特别要注意的是，Bootloader本身必须足够精简。我优化过的SREC SPI Bootloader可以控制在18KB以内，这样才能确保其始终驻留在BRAM中