如何避免升级失败而使FPGA变砖呢？

FPGA配置两种模式：主动配置和被动配置方式，采用主动配置下，我们就需要一片FLASH来存储FPGA固件，那么我们在升级固件写FLASH的过程中如何避免因意外情况发生导致升级失败而使FPGA变砖呢?下面就由笔者带领大家来挖山掘石、一探究竟。

 

 

本文主要针对Xilinx的Spartan-6和7-series FPGA。在设计FPGA的远程升级功能时，我们要实现以下两个指标：

1、FPGA具有升级功能，即在正常工作状态下，FPGA可以将新的固件数据烧写到FLASH里面并在下次重启的时候能够正常加载;

2、如果升级过程中出现意外情况，FLASH里面原有的固件被破坏，那么FPGA能够从备份固件区启动配置，即FLASH里要有另外一份没有问题的固件备份，且FPGA可以自动跳转到这个固件区读取固件。

好了，功能需求明确，下面就该潜下心来进行框架流程设计、时序设计、代码编写以及仿真验证了。一番辛苦劳作之后，IP设计好了，这个时候心里暗暗自喜：应该没问题，只待硬件测试啦。三下五除二，找了台机器测试了一遍，发现能够正常升级，这个时候心里那个是乐开了花啊，一次搞定，哈哈。

接下来就要进行激动人心的防砖测试了，于是你就邀请了周围的同事来一起见证奇迹，于是测试开始，于是在升级运行的过程中你自信的断了电，然后你对着周围的同事说：下面就是见证奇迹的时刻，于是你接通了电源，此时你笑的是那么春光灿烂。突然，你耳边传来一句轻轻的、温柔的耳语：老兄，你的FPGA变砖啦!“怎么可能!”，你不屑的低吼了一句，可是，当你看到那颗小小的LED灯安静的还在沉睡的时候，你傻眼了，“What the hell is going on!”，看着周围的同事，我理解你的心情：一种被狠狠打脸的刺痛感袭上了你的心头。你埋着头绷着脸，折腾了半天没找出原因在哪，这到底是怎么回事儿呢?

FPGA升级防砖也即支持FALLBACK模式，赛灵思官方的指导文档里也进行了相应的指导说明。对于FALLBACK模式，最重要的就是要构建起一个FLASH镜像文件，该镜像文件的架构如图1所示。

 

 

图1 FLASH镜像文件架构

关于FLASH镜像架构的信息，赛灵思官方的configuraTIon user guide里有详细说明。图中，MulTIboot Header决定了FPGA上电之后要先从哪个固件区读取配置文件以及如果失败了该跳转到哪个固件区读取备份配置。我们的镜像里划分了两片区域用于存储固件，分别为：AcTIve区和Old(golden)区，我们的升级指的就是对AcTIve区的固件进行更新，Header区和Old区的信息不改动;FPGA每次上电先从Active区读取配置文件。Old区是一份固件备份，它的作用就是当Active区因为升级意外而固件被破坏的情况下，FPGA能够从此处启动配置。

那么，如何保证当Active区的固件因为升级意外被破坏时FPGA能够主动切换到Old区域读取配置文件呢?这就是我们要说明的问题。

FPGA升级固件的烧写一般有两种方式，分别如下：

1、顺序烧写，这是最传统的烧写方式，即不对固件进行任何更改直接往FLASH里烧写;

2、调整固件烧写顺序，即对固件进行一定的修改，然后分两次烧写。

我们在设计的时候首先想到的就是第一种方式，况且赛灵思官方文档也说了在如下情况下FPGA会跳转到备份区启动配置：

1、读取配置文件的同步字超时，此时会触发跳转;

2、检查到固件CRC出错，此时会触发跳转。

根据这些说法，采用第一种方式也不会出问题啊!可是为什么就不行呢?也许细心测试的你会发现，在擦除的过程中断电的话FPGA能够从备份区启动，在烧写的过程中断电的话FPGA就会启动失败，你，有没有感悟到什么?是不是看到了一丝丝亮光?奥特曼说过：有光的地方就有希望!你可能会问：为什么有第二种烧写方式?要怎样调整固件呢?为什么要调整呢?在这里，我先给你肯定答案：采用第二种方式完全不会出问题。现在，我们接着往下卖关子。

既然有上面的一系列疑问，那么我们就需要去研究一下ISE工具在生成固件的时候是怎样的一种打包格式。经过研究发现两个很重要的信息：

1、配置文件的同步字在固件的首部;

2、CRC检查命令一般在固件的后部，而FPGA必须在收到CRC检查命令之后才会去检查CRC值。

前面也提到，当擦除的时候断电FPGA能够发生配置跳转，当烧写的时候断电FPGA无法进行配置跳转，说到这里再结合上面的两条重要的发现，你也许已经为自己心中的疑问找到答案了吧?很显然，因为固件的同步字很少，所以能够很快被擦除也可以很快被写入FLASH;因此，当擦除的时候断电了，此时固件的同步字已经破坏，而FPGA读不到同步字就会出现看门狗超时，那么此时FPGA就会跳转到备份区读取配置文件;当在烧写的时候断电呢?因为此时同步字已经被正确写入，而CRC检查命令被破坏了，FPGA在配置的时候会去读CRC检查命令，直到读到为止，可是CRC检查命令被破坏了怎么办呢?没得办法啊，FPGA有一种不撞南墙不回头，撞了南墙依然不回头的韧劲和坚持，它会一直读下去，所以它就陷入死循环了，哎!你说如果爱情里也有这种精神该多好啊!

经过上面的解释，我们会恍然大悟：原来通过CRC错误触发FPGA配置跳转不靠谱啊!既然如此，我们就只能在固件的同步字上做文章了。好了，不卖关子了，其实，在固件的同步字上做文章也就对应着升级固件的烧写方式2：修改固件并调整固件的烧写顺序，简单解释如下：

1、把固件的同步字修改掉，第一步烧写的时候不烧同步字;

2、当固件的其余部分烧写完毕之后再单独把固件的同步字烧写入原来对应的FLASH位置处。

 

 

这样做了之后，无论是擦除过程中断电还是烧写的过程中断电，固件的同步字都会被破坏，那么肯定会触发FPGA的配置跳转，即FALLBACK一定会成功!小小剧透一下：赛灵思官网里的AR问答记录里也有相应的解决方案说明哦，自己去搜吧，祝你好运!