干货 | 如何理解FPGA的配置状态字寄存器 Status Register

点击蓝字关注我们

关注、星标公众号,精彩内容每日送达
来源:网络素材

赛灵思的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,不管软件的版本如何,永远都是这个。

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

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

1bc356db1f880b867be458327715ac24.png e3d458aba963c38b5348b808478fbaef.png e2d1ffecd14fe67a874a21b0e58873be.png

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

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

fb3ca2a93dc5da102f3e8fc2ab77d44a.png

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

81696a9035467c302376f20f2e07ad0f.png

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

78bd036cfff936cbc6442eaa1cb12b35.jpeg

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

只有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链构成,读出当前的状体字(如何还能够读的话),在论坛上发贴问问赛灵思的专家吧:

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

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

配置完成后,得到的状态字如下:

REGISTER.CONFIG_STATUS      00010010100100000111110111111100

3e61094b96f8b034519a66f95bb9ebb6.jpeg

注意其中的:

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最终的启动失败。

赛灵思的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文件,硬件设计原理图和工具版本信息,以及通过其他一些配置接口在不同条件下去对比测试才能逐步定位。

80c6dbf1305330806fda2f3c68b159ef.jpeg

想要了解FPGA吗?这里有实例分享,ZYNQ设计,关注我们的公众号,探索

  • 1
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值