FPGA设计中flash读写工作原理解析

Flash读写控制方案

与Xilinx相比，Intel(Altera)提供了读写控制器方案。而且，同时提供了两个方案。

首先，Altera似乎没有开放配置Flash的Pin的控制。如果没有找到办法直接控制这些Pin，也就没有办法自行设计Flash读写控制器。

自行设计Flash读写控制器的优点在于可控性很高，缺点在于需要花费时间设计并进行稳定性测试。相应的，使用提供的Flash读写控制器IP，优点是免去设计和测试的成本，但缺点在于兼容性。

由于提供的IP可选项很少，可以使用的操作命令也有限，所以很难保证这个IP能兼容哪些Flash。即使能兼容，也可能只能使用基础的操作命令，而部分高级操作比如快速擦写等，不保证能兼容。

方案一：JTAG烧录Flash

在专栏文章《FPGA远程更新设计的需求分析》中，分析了EDA工具通过JTAG烧录Flash的操作。

1.上位机主动发起配置，FPGA被动接收数据进行重配置，此时的配置模式是上文提到的基于JTAG的被动配置。此操作的结果是将FPGA配置为一个Flash的读写器。
2.配置完成后，上位机开始发送/接收Flash的数据，数据通道为JTAG。FPGA通过JTAG接收到数据之后，根据需求发起对Flash的读写操作，将需要更新的数据写入Flash，完成更新。此过程是更新Flash的过程，烧录过程中Flash只收到FPGA的控制。
3.Flash更新完毕后，在合适的时候让FPGA进行重新配置（例如重新上下电），FPGA会开始主动配置过程，从Flash中读取配置数据完成加载。

配置过程是将原厂提供的JTAG-Flash读写控制器加载到FPGA中，在通过JTAG和这个内部的FPGA控制器烧录Flash。这个JTAG-Flash读写控制器本身也是一个设计。Xilinx并没有将这个设计独立提供出来给用户，不过Altera将这个设计以IP的方式提供给用户使用。

上图是串口Flash的读写控制器，在IP Catalog中还能找到Altera Parallel Flash Loader这个IP。这里仅以Altera Serial Flash Loader（下文简称ASFL）为例做简单介绍。关于IP的具体细节，请参考IP的手册。

将这个IP集成到FPGA工程中就可以直接使用。烧录工具为Quartus Programmer，烧录文件为.jic文件。

在烧录的时候，点选jic文件，上一行会自动勾选上，第一行也会变为Factory default SFL image。此时即为下载内置的镜像，将FPGA配置为Flash读写控制器。如果将第一行勾选去掉，则工具会自动尝试在FPGA当前设计中寻找ASFL IP。如果找不到，则直接提示错误，不会做任何变化；如果找到ASFL IP，则利用JTAG进行Flash的烧录工作。这里重点提示，使用这个方法的时候务必取消第一行自动勾选上的Factory default SFL image。

这种用法的最大限制在于需要使用Quartus Programmer工具和JTAG。如果有条件，在环境中拥有Quartus支持的OS系统和JTAG Cable的硬件连接，则可以使用这个方案。由于有OS的存在，镜像Jic文件可以通过OS来管理文件的传输，再通过远程访问OS，启动Quartus Programmer，烧录Jic文件。

但是，对于某些环境，OS和JTAG是无法获取的。所以还需要另一个方案来适配更多的应用场景。

方案二：Flash读写控制器

方案一的IP结合了JTAG和FLASH读写控制器，数据通路固定是JTAG。而Altera ASMI Parallel（下文简称ASMI)这个IP就仅仅是个Flash读写控制器，可以自由的设计数据来源。

关于这个IP的使用，可以参考IP的文档。需要进行相关信号控制来控制IP的行为。这里对这个IP的使用不进行详细的描述。

这个方案的一个问题是，IP默认只支持Intel（Alterad）的Flash，所以如果Flash是其它型号，则不能保证百分之百兼容。建议查看IP文档，使用比较基础的读写控制命令（通常性能差一些但兼容性好的命令）；同时在更换Flash之后，进行测试看看是否兼容。

方案一的截图中，有一个配置参数：

方案二的ASMI IP配置中，有一个配置参数：

勾选这两个参数，可以让两个方案同时存在与一个FPGA设计中。这样，可以更自由地选择使用那个方案来进行更新。由于Flash只有一个配置接口，所以两个方案肯定是无法同时使用的。

Altera配置文件分析

方案一已经是个完备的方案，无奈对使用环境有着较高的要求。所以方案二才是更通用的方法。不过相对方案一直接使用jic文件，方案二只是一个Flash读写控制器，并没有说明将什么数据写入Flash。所以需要找到写入文件的数据。

Altera常见的几个配置文件：sof/pof/jic/rbf

sof文件是最基本的文件，用这个文件作为基础可以直接用Quartus Programmer进行JTAG下载。同时也可以通过这个sof文件生成其它文件。

pof是针对altera Flash的配置文件器。需要用Quartus Programmer软件，通过JTAG烧录Flash。由于这个文件需要使用JTAG连接Flash，所以在很多环境下并不使用这个文件进行配置。

jic是间接配置Flash的文件，具体使用已经介绍过了。

rbf文件，从名称看是二进制文件，可能最接近写入Flash的文件。

由于并没有在Intel(Altera)网站上找到几种配置文件的具体数据内容和格式，所以需要手动分析文件内容。实际上这几种格式没有一种可以直接写入Flash

这里已经得到最终的数据文件，暂时称之为bin文件，下面直接给出各个文件无法使用的原因。文件基于Altera A10系列FPGA。

1.sof

对比最终写入Flash的数据，几乎看不到正常的数据，怀疑是存在一些Quartus工具才能识别的命令。

2.pof文件

pof文件是针对Flash的，所以里面内容和rbf文件有大部分都是相同的。

不过差别在于pof文件前面有大量的不明数据，不清楚具体作用，所以

左边为rbf文件，右边为pof文件

和正确的bin文件相比，pof前面的开头部分确实也是多余的。所以rbf也比pof文件更接近于最终的bin文件。

3.rbf文件

rbf文件确实几乎非常接近最终的文件。

左边为bin文件，右边为rbf文件

从文件格式中可以看到，数据可以对应上，只是位序有点不同。

不过比较大的问题是，rbf文件的开头相比bin文件，少了一些内容。

左边为bin文件开头，右边为rbf文件开头

调整位序对FPGA开发来说，几乎没有难度。不过开头这些数据的作用，就不太清楚了。如果有条件可以尝试写入rbf文件，试试FPGA能否从Flash中加载成功。本人尝试过两次，失败后直接尝试bin文件。对于rbf无法成功的原因，并没有深究。所以失败也有可能是操作失误导致的，而rbf文件是可以这样使用的。

4.jic

对比发现jic和pof文件的格式位序一样，但开头依然多出部分数据。多出来的部分长度几乎和pof文件一样，但数据内容由不完全相同，所以怀疑开头部分包括了一些Quartus工具的操作命令，如果直接写入Flash，可能会导致无法加载成功。

从上述分析可以看到，Quartus提供的四种配置文件，并没有保证直接对应Flash中的数据，对比后也发现多少都有点出入。由于没有找到对各自文件详细的内容说明，所以也不便于直接修改。

所以这就是使用ASMI方案的最大问题，如何获取最终的写入Flash的数据。

从这一点说，Xilinx的方案其实更直接，直接使用原始的二进制数（bit、bin)文件，或者标准文件——MCS。

Flash标准内容文件

Xilinx的MCS文件，后缀mcs是Xilinx独有的，但是其内容是标准格式。

MCS为文本文件，查看内容，可以看到两种内容。第一种是相对较短的一行，第二种是相对较长的一行。

真实数据是保存在较长的一行。分析后可以看到较长行的长度都是一样的。具体内容是，前端若干位是控制符（包含地址），然后是具体数据，之后是校验码。找到规律后，就可以直接提取其中内容了。

Quartus中没有直接提供这个格式的文件，不过Quartus下用于Nios2开发的套件（nios2eda）中，有一个小工具：sof2flash

在Nios2 Shell中启动这个工具，可以将sof文件转为.flash文件。查看这个.flash工具，就能发现这个文件的语法结构和MCS文件一样。

那么后面的事情就很容量了，用脚本语言（Python）写一个转换工具，生成一个文件，后缀名可以随意取（本人使用.bin这个后缀)。将这个文件以二进制形式读取，直接传给ASMI IP写入Flash，从实际效果看，没有任何问题，FPGA顺利从Flash启动。

这里要感谢：武汉芯路恒科技有限公司的小梅哥。当初是小梅哥的提点，才知道有.flash这个文件的存在。

这个方法算是另辟路径，用不是很正式的方法将sof文件转为了一个标准的Flash内容描述格式。本人使用的是这种格式。不过，从道理上分析，Altera应该是提供了正确的配置文件。

通过朋友向Altera技术支持打听，得到一个方案，这里云分析一下。先给出结论：这个方案应该是可行的。

通过Quartus提供的文件转换工具，可以将sof转为pof文件。这一步上文已经做了分析，pof并不是直接写入Flash中的文件。

再一次使用文件转换工具，利用pof文件，转为rpd文件。这个rpd文件，就是需要使用的文件。

分析一下rpd文件和.flash文件中的内容

左边为.flash文件内容，右边为.rpd文件内容

从开头部分就可以看出，数据是有明显的对应关系，56565656调整位序后就可以得到6a6a6a6a。第10行的20000000和04000000也能看出对应的关系。

从这个结果可以看到.rpd的数据是可以使用的，只是在位序方面需要做一些调整。

这一还有一些地方需要讨论，就是文件大小。

sof文件代表FPGA的配置文件，FPGA的配置文件都是和FPGA的型号相关。与Xilinx不同，Altera的sof文件似乎无论是否打开压缩，均不会改变文件大小。

bin文件是从.flash文件中提取的，.flash是从sof中提取的。所以bin文件包含的是完整的配置信息。实际使用中可以发现这个bin文件的大小会比sof文件小一些。而.flash文件由于是文本格式，所以无法比较大小。

jic、pof和rpd文件，这三个文件是针对Flash的，所以这三个文件的大小是依据Flash而变化的。使用中可以发现这三个文件其实比sof/bin文件大很多。但这三个文件几乎是一样大小的。

用一个例子来说明，假设sof文件是20MB，Flash是128MB。那么bin文件代表sof文件中有效内容，可能是16MB，而由于Flash固定是128MB，则jic/pof/rpd三个文件都几乎是128MB大小，其中只有开头的16MB是有效内容，后面的数据基本为填充的无效数据（或者在生成时添加了其他数据源的数据）

这里有一个例子，rpd文件，二进制用文本展开，32bit一组用8位16进制数表示，一共33554432组，其中ffffffff占了22578142，可以看到几乎大部分都是无效的flash初始数据。

33554432*32bit / 1024/1024 / 8 = 128MB

这个128MB的Flash，大概三分之二都是无用的Flash数据。

这可以侧面验证，jic/pof/rpd文件虽然很大，但其中有效数据并没有很多。

所以，如果只有一个镜像的远程更新，那么bin文件其实是很方便的，但生成的方法会麻烦一些。如果直接使用rpd文件，代价是要么写入大量无用数据，要么确认一下有效数据的结尾，来避免大量无效数据的写入。

至此，Altera平台远程更新设计中Flash读写控制器的方案，已经都做了粗浅的介绍。

编辑：黄飞