FPGA远程更新设计的需求分析

可编程逻辑

1364人已加入

描述

注:本篇是一个需求分析,不涉及具体的FPGA型号和工具的使用。

FPGA可重配置带来了很高的灵活性,所以基于FPGA的设计/产品往往也会有后期更新/升级的需求。同时,需要更新/升级的FPGA板卡由于物理条件的限制,可能无法现场升级。比如:

1.FPGA板卡部署在异地机房中,无法随时进入机房进行升级(异地来回成本及机房不允许随便出入的限制)。

2.FPGA板卡部署在相对复杂的环境中,例如无线通信设备安放在通信塔台上,或者客户手中的设备无法由供应商一一回收升级。

3.FPGA升级对系统影响较大,不方便随时升级。比如PCIE设备受到系统总线的监测,随便的更新可能导致机器重启,在一些要求严格的环境中是不能允许的。

所以就有了对FPGA进行远程更新的需求,需要满足下面几个限制条件:

1.可以在满足一定条件下(类如可用网络进行远程访问),进行远程的升级(不一定需要全自动化,但全自动化更方便);

2.更新过程中不能对系统带来影响,以防止系统错误地实施保护措施(例如服务器重启);

远程更新,整体分为两部分:1)数据传输;2)更新镜像;

数据传输部分可以选择的方案非常多,比如可以通过网络将数据传递过去。通常会借用以有的通信接口来实现。如果FPGA板卡是部署在计算机中,那么先将数据通过网络传递给计算机,然后再由计算机转发给FPGA进行镜像更新,也是可以的。这其中数据传输主要由上位机来实现。所以对数据传输部分,并没有严格的要求。通常FPGA远程更新的设计重点,在如何更新镜像。

更新镜像这一概念,会有两个完全不一样的概念,需要先说清楚。

1.更新FPGA的配置

这种方案对应Xilinx的bit文件下载和Intel(Altera)的sof文件下载,更新的是FPGA的配置,立即生效。这种方案存在的问题是配置过程中,FPGA的原有配置会被清除掉。此时系统可能做出不正确的反应。例如使用FPGA实现的PCIE设备可能会由于重配置导致PCIE功能失效,部分服务器检测到PCIE设备异常会触发重启,带来影响。

2.更新存储FPGA配置镜像的Flash

这个方法更新的目标是存储FPGA配置的存储器(通常是Flash)。

更新Flash过程中,通过一些措施使FPGA原有设计继续工作不受影响,完成后并不立即生效,FPGA依然是旧镜像;更新Flash之后,在合适的时间触发FPGA的重新配置,配置过程中更新的镜像数据会送往FPGA进行加载;整个过程是相对可控的,所以对系统的影响较小。

所以,可以看到,远程更新方案的需求,总结为以下三点:

1.利用以有的数据通道传输数据

2.将更新数据写入存储FPGA配置信息的存储器中

3.更新Flash的过程中,不要影响FPGA的正常功能

其中第一点,由于可选方案非常多,需要根据系统的需求来决定,所以本文不做深入讨论。下面重点探讨后两点。

FPGA有多种配置/加载方式。粗略可以分为主动和被动两种。主动加载是指由FPGA控制配置流程,被动加载是指FPGA仅仅被动接收配置数据。

最常见的被动配置模式就是JTAG下载bit文件。此模式下,主动发起操作的设备是计算机,数据通路是JTAG,FPGA会被动接收数据,根据需要的操作来进行更新FPGA配置。而上位机如何获取配置数据就非常灵活了,可能是本地运行EDA工具生成的,也可以是网络/USB存储设备获取的。

主动配置就是FPGA在配置过程中处于主导地位,主动发起对Flash的读写,获取配置信息进行配置。

下面利用间EDA工具自带的烧录Flash的操作为例,分析一下具体的烧录过程。

在Vivado中可以使用bin文件和mcs文件烧录Flash,在Quartus中可以用jic文件更新Flash。通常情况下,完整的过程是:

1.上位机主动发起配置,FPGA被动接收数据进行重配置,此时的配置模式是上文提到的基于JTAG的被动配置。此操作的结果是将FPGA配置为一个Flash的读写器。

2.配置完成后,上位机开始发送/接收Flash的数据,数据通道为JTAG。FPGA通过JTAG接收到数据之后,根据需求发起对Flash的读写操作,将需要更新的数据写入Flash,完成更新。此过程是更新Flash的过程,烧录过程中Flash只收到FPGA的控制。

3.Flash更新完毕后,在合适的时候让FPGA进行重新配置(例如重新上下电),FPGA会开始主动配置过程,从Flash中读取配置数据完成加载。

这种烧写Flash的过程通常称为间接编程(间接烧录)。Xilinx可以在工具的Help文件中找到详细的描述。

FPGA

间接编程是先把FPGA配置成一个Flash读写控制器,然后再通过这个读写控制读写Flash,所以配置过程可以看到FPGA先被加载成功,然后才会进行后续的Flash操作。Xilinx中,这个Flash读写控制器是保存在工具安装路径中的。ISE中称呼为cor文件。

FPGA

Vivado是直接保存了bit文件,并提供了三种模式,区别在于没有用到的Pin是出于上拉、下拉还是高祖状态。

FPGA

Intel(Altera)的这种模式使用的文件后缀是jic,全称是JTAG Indirect Configuration File。直接翻译是JTAG间接配置文件,原理和上述Xilinx的描述完全一样。在Quartus的Programmer界面中,当添加了Jic文件之后,可以看到有一个Factory default SFL image,就是将FPGA配置为Flash控制器的镜像。

FPGA

烧录Flash的时候可以关注一下控制台打印的消息,可以看到第一步配置成功后才对Flash进行读写控制。关于Xilinx和Interl(Altera)平台的具体操作,专栏会有后续文章进行分析。

根据配置的不同,也可以分为主动更新和被动更新两种。

如果是被动更新,那么通常配置过程会有一个主动发起的设备,常见有MCU。这样配置过程相对容易,数据的传输、存储和读取都交给主设备操作。整个更新过程按要求更新即可,然后再合适的时间重新加载FPGA即可。FPGA本身几乎和更新过程完全隔离,所以也很容易满足需求。

主动更新则相对麻烦。首先,Flash很可能只于FPGA有数据接口,表明Flash的读写只能从FPGA来发起;其次,由于FPGA需要发起Flash的更新写入,所以FPGA如何获取数据也是需要考虑的问题。可以参考上文,主动配置更新Flash完整过程的描述,可以看到FPGA需要一个数据通路(JTAG)接收配置数据,并实现一个Flash的读写控制器来读写Flash。更新Flash完成之后,下一次配置被触发(重新上下电)会主动发起读Flash的操作,加载配置数据完成配置。

现在,应该对远程更新有一些初步了解了。

如果条件允许,使用一个MCU作为远程更新的主控设备,会让方案简单不少。而且可以利用软件做更多的操作(例如数据的校验)。通常这么选择的原因是系统中已经存在一个主控的MCU,就同时承担远程更新的任务。

如果FPGA板卡使用的是主动配置模式,由于Flash的读写只能通过FPGA来实现,同时JTAG直接更新FPGA镜像可能无法满足要求(比如不能每次上下电都需要用JTAG配置一次),那么设计一个主动模式的远程更新方案就很重要的。此时,即便系统中有MCU或者上位机,但是由于Flash只能被FPGA控制,所以MCU/上位机更多的是作为数据通信来发送FPGA配置数据,而更新Flash的步骤依然需要FPGA来实现。

可以看到,如果将更新控制交给MCU,则单独下降了不少。配置过程中对FPGA的要求也不多,可以说大部分工作是外部设备(MCU)完成,FPGA工作量不多。所以讨论的重点在于难度更大、FPGA工作量更多的主动更新方案。以此为基础,目前的设计需求已经变为:

1.利用以有的数据通道传输数据给FPGA;

2.通过FPGA将更新数据写入Flash中;

3.更新Flash的过程中,不要影响FPGA的正常功能;

1.利用以有的数据通道传输数据给FPGA;

由于数据传输的可选方法非常多,而且任何一个方案都是一个非常大的话题,这里就不详细描述了。推荐的做法是做握手控制,将数据逐一写入Flash即可。设计要点在于数据传输和Flash读写的交互握手和跨时钟域。

通常数据传输的速率高于Flash读写速率,所以使用缓存,一方面存储空间容易溢出,另一方面更新操作的使用频率并不高,为了一个低频度的应用留一个大容量的存储空间并不划算。所以使用交互握手来处理,相对较慢的更新速度对低频度的Flash更新操作影响并不大,但带来的问题就是交互过程中需要考虑跨时钟。

2.通过FPGA将更新数据写入Flash中

3.更新Flash的过程中,不要影响FPGA的正常功能

这两点需求都是要求FPGA实现的,具体方案就是FPGA收到数据后开始对Flash的读写操作,将数据正确写入到Flash中去。关于这一点,由于和具体的FPGA相关,之后会有分别针对Xilinx和Intel(Altera)平台的文章进行进一步分析。

通过完整的分析,应该对远程更新需要做的事情有个大略的了解。出去数据通路会随着系统的不同而变化,FPGA端的读写控制是必然的需求。专栏后续文章会针对FPGA内部的Flash控制器及完整流程做一个更详细的分析。

  审核编辑:汤梓红

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

全部0条评论

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

×
20
完善资料,
赚取积分