Altera平臺遠程更新中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文件前面有大量的不明數據，不清楚具體作用，所以
和正確的bin文件相比，pof前面的開頭部分確實也是多餘的。所以rbf也比pof文件更接近於最終的bin文件。
3.rbf文件
rbf文件確實幾乎非常接近最終的文件。
從文件格式中可以看到，數據可以對應上，只是位序有點不同。
不過比較大的問題是，rbf文件的開頭相比bin文件，少了一些內容。
調整位序對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文件中的內容
從開頭部分就可以看出，數據是有明顯的對應關係，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讀寫控制器的方案，已經都做了粗淺的介紹。
關於FPGA遠程更新設計的需求分析
XTWL TPCL：FPGA遠程更新設計的需求分析
關於Xilinx平臺下的FPGA讀寫Flash設計的討論
XTWL TPCL：Xilinx平臺遠程更新中FPGA讀寫Flash設計的討論更多關於FPGA的分享，可以參考知乎專欄：FPGA Coding
FPGA Coding
推薦閱讀：