浅谈FPGA配置状态字寄存器Status Register的调试

描述

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

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

答案是:

第一步要做的,永远都是拉出FPGA的状态字寄存器Status Register看,它能直接告诉你或者极大地辅助判断失败的原因!不管FPGA的型号是哪个,不管用的下载工具是Vivado HW Manager还是ISE的iMPACT,不管软件的版本如何,永远都是这个。

Xilinx FPGA的状态字,在赛灵思所有器件系列中都基本保持一致的定义(个别位由于系列特性不同可能有细微区别,这些不是最重要的,不在我们今天讨论的范围内)。

以UltraScale/UltraScale+系列为例,我们看看UG570上对状态字的完整定义:

 

FPGA

 

 

FPGA

 

 

FPGA

 

表格里面已经很清楚地解释了每一个bit位代表的意义。下面学习如何读出状态字并从其具体值中判断失败原因。

我们先来读一下一片未作配置的FPGA的状态字看看。首先,用下载线连接好板子和电脑,板子上好电。打开Vivado硬件管理器,扫描板子上的JTAG链 (Open target -Auto Connect), 板子上的JTAG链中的器件会显示在Hardware窗口中:

 

FPGA

 

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

 

FPGA

 

注意FPGA此时的状态是Not Programmed, 那么对应的状态字展开如下:

 

FPGA

 

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

只有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

3. Unknown Device/Many Unknow Devices

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

除了上述典型情况,当然还有很多一上电就无法继续配置的情况,原因不胜枚举。这种情况下请详细描述你的JTAG链构成,读出当前的状体字(如何还能够读的话),在论坛上发贴问问Xilinx的专家吧:

https://forums.xilinx.com/t5/%E8%B5%9B%E7%81%B5%E6%80%9D%E4%B8%AD%E6%96%...

如果状态字正常,可以接下来进行配置操作。或者是在你的配置失败后,保留失败现场再连接好板子和电脑继续读出状态字。

如果你的板子已经重新上下电了,那么当时失败的场景也就消失了。这也就是我们一再强调失败后要保留现场,板子上要保留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的不用管。

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

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

1) 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实在太差,那只有改板,或者尝试下其他配置方式了。

2) 其他位都正常,BIT13 DONE_INTERNAL也为1了,但是BIT14 DONE_PIN为0,FPGA不工作!

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

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

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

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

3) BIT29 BAD PACKET error

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

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

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

4) BIT15 IDCODE Error为1.

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

5) 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,那么需要更多的时钟信号。

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

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

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

一般的原因是:

1. 在非serial配置模式中,没有正确的做Byte Swap;

2. 配置文件生成时,BPI数据线宽设置不对(x8, x16, x32选错了)

3. SPI的x1, x2, x4选择错误;

4. 严重的板级SI问题导致的CRC错误;

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

编辑:hfy


打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分