目录

简介

状态字定义      

Unknown Device/Many Unknow Devices

解决办法

一般原因

---

简介

 Xilinx的FPGA有多种配置接口，如SPI，BPI，SeletMAP，Serial，JTAG等；如果从时钟发送者的角度分，还可以分为主动Master（即由FPGA自己发送配置时钟信号CCLK）和被动Slave（即由外部器件提供配置所需要的时钟信号）；另外还可由板上稳定晶振提供时钟信号，经由FPGA的EMCCLK接口，再从CCLK端口送出。

        如此多的配置形式，一旦发生配置失败怎么办？大家都知道先要查看一下板子上FPGA的DONE管脚。但绝大多数情况下，DONE管脚此时会是低电平，只能证明配置确实失败了。但是失败的原因到底是什么呢？调试到底应该如何入手呢？

        FPGA的状态字寄存器Status Register能直接告诉你或者极大地辅助判断失败的原因，Xilinx FPGA的状态字，在赛灵思所有器件系列中都基本保持一致的定义（个别位由于系列特性不同可能有细微区别，这些不是最重要的，不在我们今天讨论的范围内）。

状态字定义      

 以7系列 FPGA为例，我们看看UG470上对状态字的完整定义：

         首先，用下载线连接好板子和电脑，板子上好电。打开Vivado硬件管理器，扫描板子上的JTAG链 （Open target -AutoConnect）, 板子上的JTAG链中的器件会显示在Hardware窗口中：

        鼠标选中扫描出的FPGA器件，在下方的Hardware Device Properties窗口中，选择Properties项，会出现该FPGA的一系列属性。找到其中的REGISTER分类，展开，第二个寄存器CONFIG_STATUS, 即是我们要讨论的状态字了。

       这里可以看到的是一个配置前的状态字的标准状态：

      只有BIT02 PLL_LOCK, BIT03 DCI_MATCH, BIT11 INIT_B_INTERNAL, BIT12 INIT_B_PIN的值必须是1；

      BIT08-10 MODE PINS，BIT21 SECURITY_STATUS, BIT25-26 BUS_WIDTH，BIT28 PUDC_B根据FPGA和板子具体的设定，可以为1或者0，其他都必须是0。

      如果一上电，状态字就表现出了非典型值，那么大概率硬件上就有错误或者不合理的地方了。比较典型的几个例子：

1. 状态字全0

REGISTER.CONFIG_STATUS 00000000000000000000000000000000

       这种情况，说明FPGA被强行控制在全局复位状态了。一般是硬件上PROGRAM_B管脚，或者INIT_B管脚被错误的拉到了地上，两个管脚上的有效电平为0.

非常偶尔的情况下，当DONE管脚被错误拉为0电平时也能出现此种状态字。

2. 状态字全1，或者一串1后面跟着一个到数个0（一般不超过4个）

REGISTER.CONFIG_STATUS 11111111111111111111111111111111

REGISTER.CONFIG_STATUS 11111111111111111111111111111110

REGISTER.CONFIG_STATUS 11111111111111111111111111111100

        这种一般是板子上设计的JTAG链里面不只一个FPGA器件，比如是Xilinx的FPGA和一个第三方的CPLD串联等。

        由于Vivado里面并没有第三方器件的BSDL文件，那么在扫描整个JTAG链时，它无法识别链中各器件的型号以及数目，所以往往从TDO管脚中移位出一串1来。如果Xilinx的FPGA位于链的末端（接近TDO的位置），那么有时可以识别出正确的FPGA型号。但是这种情况仍然无法正确进行将要进行的配置操作。另外很多例子中则是FPGA的型号也被识别错误了。

解决方案如下：

https://www.xilinx.com/support/answers/61312.html

Unknown Device/Many Unknow Devices

        此时，不要说状态字无法检测了，整个JTAG已经无法正确扫描，Vivado里面无法识别出任何器件。这一般是板子上的JTAG接口的TDO或者链中最后一个器件的输出管脚TDO，被短接到了地平面上。

        除了上述典型情况，当然还有很多一上电就无法继续配置的情况，原因不胜枚举。这种情况下请详细描述你的JTAG链构成，读出当前的状体字（如何还能够读的话），如果状态字正常，可以接下来进行配置操作。或者是在你的配置失败后，保留失败现场再连接好板子和电脑继续读出状态字。

       如果你的板子已经重新上下电了，那么当时失败的场景也就消失了。这也就是我们一再强调失败后要保留现场，板子上要保留JTAG接口的原因。当然在设计成熟后，或者实验室调试工作结束后，可以去掉JTAG接口以期得到产品更高的安全性。

配置完成后，得到的状态字如下：

REGISTER.CONFIG_STATUS 00010010100100000111110111111100

注意其中的：

BIT02 PLL_LOCK, BIT03 DCI_MATCH, 绝大多数情况已经变为1;

BIT04 EOS，BIT05 GTS, BIT06 GWE, BIT07 GHITH，以及BIT11 INIT_BINTERNAL， BIT12 INIT_B_PIN，BIT13 DONE_INTERNAL, BIT14 DONE_PIN必然是1;

BIT18-20 STARTUP_STATTE应该是100;

BIT25-26 BUS_WIDTH应该是检测出了正确的配置位宽，或者在serial的情况下，保持默认的01值;

其他BIT01 DECRYPTOR, BIT09-10 MODE_PINS, BIT21-23 SECURITY_STATUS, BIT28 PUDC_B, BIT30CFGBVS_PIN, 根据你的使用，有可能是其他的0或者1组合。

RESERVED的不用管。

如果不是这种结果，那么就要看看出什么问题了。

在一些相对简单，典型的情况下，只看某一位就可以直接得到想要的答案。

BIT00的CRC error为1

在不是状态字全1的情况下CRC error位为1，说明配置出现了CRC错误。这是一种很常见，但比较难修复的错误，因为CRC错误的原因一般是因为板子上的信号质量（SI， Signal Integrity）不行，传输数据的过程中0/1电平判决错误，导致配置数据写入失败。

如何确定真的是SI问题呢？看失败概率。CRC错误一般是随机出错的，并不一定100%失败（除非板子的信号差得没法用了，这个一般不会）。那么配置文件中01翻转的次数越少，出错的概率越小。你可以生成一个只点亮板上一盏LED的小测试设计，此时bit文件中有效数据（1）非常少，试着下载该bit看看，是不是配置失败率降低了？如果是，那么基本可以确定了。

解决办法

一旦出现这种情况，可以尝试的办法有：

1. 降低CCLK频率

2. 在CCLK的输入端（以及输出端），加入合适的端接电路

3. 换用更高质量的配置时钟（比如使用质量较好的晶振通过EMCCLK提供时钟）

4. 改善数据链路的信号质量，如果对待CCLK，同样在数据通路上加入合适的端接匹配电路。

总而言之，要做的就是改善板上的信号质量。如果板子SI实在太差，那只有改板，或者尝试下其他配置方式了。

其他位都正常，BIT13 DONE_INTERNAL也为1了，但是BIT14 DONE_PIN为0，FPGA不工作！

       这种情况，其实配置数据已经完整、正确的送入FPGA并且被接收了，但是FPGA的DONE管脚连接不正确，导致DONE没有或者没有在规定时间内上拉到要求的电平，从而导致FPGA最终的启动失败。

       Xilinx的FPGA，一般要求DONE管脚上外加一个上拉电阻（330欧, 4.7K欧等，不同系列要求不同，请参照对应的Configuration User Guide）。如果这个上拉电阻没有加，或者加的阻值过大或过小，那么DONE管脚无法在规定的时间里面达到高电平，此时内部配置控制器会认为配置失败了，典型情况就是DONE internal为高（内部数据接收完毕，内部释放了），但是DONE外部管脚为低。

       此时需要做的，就是检查PCB上DONE部分的设计，看看是不是有和其他管脚相连的情况，被其他管脚强行拉低了。或者是设计的DONE点亮LED灯电路不合理， LED通电后把DONE管脚的电平降为低电平。

        如果你不清楚如何设计这部分电路，从 www.xilinx.com 上，找到一款和你使用的FPGA型号相同或者同系列的开发板，参考它的原理图设计。

BIT29 BAD PACKET error

       Bit29为1，大概率也是CRC错误。这不过这个CRC错误比较特殊，出错位跑到了配置文件里面的命令上，导致配置命令变成了一个无效无意义的指令。此时状态字会报出bad packet error。

       和CRC错误的随机性一样，多次重复加载过程，大概率出错的数据位下次落到其他的数据上。由于配置数据的数量远远大于配置命令，那么很有可能下次出错看到的是BIT00 CRC ERROR为1.

       如果每次都是BAD PACKET error，更要怀疑使用的配置文件已经损坏。比如进行了非法改写。Xilinx的任何配置文件，都是禁止手工修改的。

BIT15 IDCODE Error为1

        配置文件下载时，都要先经过FPGA的IDCODE校验。如果这一步通不过，那么后续的配置不会进行。这种情况下，看看配置文件的bit/bin/mcs是不是给错了。或者FPGA器件有silicon revision的变化。举个例子，有的系列ES芯片和Production芯片的配置文件是不能兼容的。这种错误情况，如果是用JTAG通过Vivado下载，那么log里面也会有相应的提示。

BIT13 DONE_INTERNAL+ BIT14 DONE_PIN均为0

       这也是一种较常见的错误。此时要重点检查一下BIT07 GHIGH位，看看它是不是1。如果是，那么大概率是，你的CCLK时钟给的不够多。FPGA在接收完所有的配置数据后，还需要一定数量的CCLK时钟去完成内部的初始化。如果发送端，此时常常是一个CPU用Slave模式加载，认为有效数据结束，强行停止了进一步的时钟发送，那么有时可以观测到此种状况。此时去检查BIT18-20 STARTUP_STATE，根据具体的情况，也有一定概率看到不是预期的100.

        标准的做法是，在默认设置下持续发送CCLK时钟，直至检测到DONE管脚已经拉高，然后再多发送至少64个时钟信号。如果修改了配置默认设置，比如选择了wait for PLL to lock，那么需要更多的时钟信号。

状态字看起来和没有发出配置数据，即和刚上电的表现一样。

      这种情况，说明所有发出的配置数据都被FPGA忽略掉了，因为它不认为你发送过来的是有效配置数据。

       FPGA的配置文件里面，有一个数据同步头，一般是AA 99 55 66。如果由于某种原因，这个同步头FPGA都没有认出来，那么后续的数据会被它全部忽略。

一般原因

１. 在非serial配置模式中，没有正确的做Byte Swap；

２. 配置文件生成时，BPI数据线宽设置不对（x8, x16, x32选错了）

３. SPI的x1, x2, x4选择错误；

４. 严重的板级SI问题导致的CRC错误；

        以上列举了常见的一些配置错误和其状态字的相应表现。需要注意的是，状态字寄存器有32位，其组合可以说是相当多的。除了上述情况，配置失败定位还可能需要结合状态字，加载过程中log文件，硬件设计原理图和工具版本信息，以及通过其他一些配置接口在不同条件下去对比测试才能逐步定位。 作者：硬件光阴 https://www.bilibili.com/read/cv26835920/?spm_id_from=333.999.0.0 出处：bilibili