最近的一个项目里有一项功能是,用ARM来配置FPGA,配置模式是FPP模式。这么做的目的是,ARM可以实现通过网络来实现FPGA配置文件的远程升级,从而实现FPGA的远程配置。
参考FPGA的芯片手册中关于其FPP配置的描述,FPGA要想实现FPP配置,需要完成三步:
第一步:硬件连接。硬件连接只要按照FPGA芯片手册中提供的参考电路连接即可,要注意手册中关于FPGA的模式选择的配置电路。
第二步:配置文件的生成。测试的时候我们使用的配置文件时.rbf格式的,由Quartus II软件直接生成,也可由.sof转换得来。
第三步:按照FPP配置时序来写入配置文件。FPGA芯片手册中给出了FPP配置的时序图,按照这个时序图来编写实现FPGA配置的程序(这里是ARM程序)。
在完成第三步以后,FPGA并不能初始化成功,测量FPGA引出来的CONF_DONE引脚,也是一直为低(CONF_DONE为低,说明FPGA在配置阶段就没有成功)。起初怀疑是FPP配置的连接电路有问题,检查排除了这个可能。后猜测可能是发送的数据不对的原因,可能是ARM这边发送一个数据,但FPGA这边接收的确实错误的数据,因为这块电路板上,ARM部分的最高电压是1.8V,而FPGA这边的最高电压是3.3V。打算编写程序测试一下是否是由于传输过程中数据不能正常接收的,但是由于一些原因,最终没有测试。而是一直在测是不是ARM的配置程序有问题,问题没有找到原因。偶然一个测试发现,在ARM发送.rbf文件的数据给FPGA时,nSTATUS信号会被拉低,而不是正常写入数据是的拉高。猜测nSTATUS被拉低的原因是由于nCONFIG信号被置低了,用示波器测量在写入配置数据期间nCONFIG的变化情况,果然nCONFIG被置低,导致FPGA重新开始配置过程。为什么写入.rbf的配置数据时,nCONFIG会被置低呢?测试发现,当不写入任何数据时,只用ARM拉高nCONFIG信号,nCONFIG不会变低。我们把写入的数据换成足够多数量的0x55数据组成的数组,重新写入到FPGA中,nCONFIG信号不会被置低。由此推断nCONFIG被置低应该是写入.rbf配置文件导致的。写入.rbf文件的过程是这样的,在ARM中读取.rbf文件,把读出的数据放到一个buffer里,然后发送给FPGA。因此我们就直接把.rbf文件中的数据读出并打印出来,然后做成一个数组,重新写入FPGA,nCONFIG依然会被置低。由于之前测试过把这个数组里的数据换成0x55,nCONFIG不会被置低,因此应该不是.rbf文件的读取并写入到FPGA的过程引发的问题,而是.rbf文件本身的问题导致nCONFIG被置低的。重新在Quartus II里设置配置模式(Configure Scheme),把AS模式更改为FPP模式,并且设置成配置文件不压缩的方式,重新编译生成.rbf文件。把更改后的.rbf文件写入到FPGA中,问题就解决了,FPGA也可以正常配置并正常进入到用户模式,自此,应用ARM对FPGA进行FPP配置就大功告成了。可是,问题虽然解决了,但是还有一些疑问没有消除,如果说只是.rbf文件的格式不对,那为什么只写入0x55时nCONFIG不被置低呢?还有为什么更改后的.rbf文件就可以实现FPGA的正常配置,而之前的.rbf不能实现FPGA的配置,而且会出现nCONFIG被置低的问题?猜测问题可能的原因是,没更改的.rbf文件由于生成的时候,在Quartus II中设置的配置模式是AS模式,因此在把这个.rbf文件数据写入的时候,FPGA被引导成AS模式,所以nCONFIG会被置低。写入更改后的.rbf文件到FPGA,在这个文件中FPGA的配置模式被设成了FPP模式,所以可以实现FPGA的正常配置。写入0x55,nCONFIG不被置低,有可能是因为0x55组成的数组中,并没有FPGA配置模式的引导数据,所以nCONFIG不会被FPGA置低,而是由ARM控制,被一直拉高。
文章评论(0条评论)
登录后参与讨论