FPGA+SoC+LinuxでFPGA Managerを試してみた(まとめ)

# 注意(2017年7月29日追記)

この記事は Linux Kernel 4.4 時点に投稿したものであり、古い内容が含まれています。Linux Kernel 4.10 以降、FPGA 関連は大きく進歩しました。詳しくは[「Linux Kernel 4.10 でのFPGAのサポート事情」](http://qiita.com/ikwzm/items/2ff7d5429da8ace7c0bd)を参照してください。

# はじめに

## これまでの経過


次の記事で紹介したように、Linux  Kernel 4.4.4 からFPGA Manager Framework が追加されました。

* [「FPGA+SoC+LinuxでFPGA Managerを試してみた」@Qiita](http://qiita.com/ikwzm/items/9eb4d49545636162057e)



実際にどのようになっているのか、どのように使うのかを調べるために、人柱的な感じで試用してみました。これらの実施例は次の記事を参考にしてください。

* [「FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(ブートイメージの提供)」@Qiita](http://qiita.com/ikwzm/items/cdeb3c9c352776eac683)
* [「FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(ZYBO-Examples)」@Qiita](http://qiita.com/ikwzm/items/61ea3c5a037b83006f17)
* [「FPGA+SoC+Linux+Device Tree Overlay+FPGA Manager(DE0-Nano-SoC-Examples)」@Qiita](http://qiita.com/ikwzm/items/ca6229d4e32fb421b0a9)



この記事では、試用してみた現時点での結論とその理由について説明します。


## 結論


一言で言うなら、使うには  __時期尚早__  です。

もし同じような機能(FPGAを動的にプログラミング)を使いたいのであれば、各FPGAベンダーやボードベンダーが提供しているカスタマイズされたLinuxを使う方が良いでしょう。

~~ただ、この機能自体は大変有用なので、Linux 本家が正式にフルサポートするのを期待しています。~~

その後の話を[「FPGA+SoC+LinuxでFPGA Managerを試してみた(まとめ2)」](http://qiita.com/ikwzm/items/4f89cf7cb42f6cc2705f)に投稿しました。あわせて参照してください。


## 理由


時期尚早と考える理由は次の２点です。

* 必要な全ての機能が揃っていない
* FPGAベンダー間でのアーキテクチャの一貫性に問題がある



いずれの理由も、解決するには今しばらく時間が必要かと思います。




# 詳細な説明



## FPGAのプログラムに必要な機能


[「FPGA+SoC+Linuxのブートシーケンス(概要編)」@Qiita](http://qiita.com/ikwzm/items/b4ccae34cf554c80d1b4)でも説明したように、Linux  の上で、FPGA のプログラムを FPGA にロードして動作させるためには次の機能が必要です。

* Programmable Logic(FPGA) のクロック設定
* Programmable Logic(FPGA) にプログラムをロード
* Programmable Logic - Processing System Interface の設定
* Programmable Logic の起動
* Device Tree
* Device Driver



## Altera-SoC の場合のアーキテクチャ


前節で紹介した機能がAltera-SoC の場合、現時点でどのように構成されるかを下の図で示します。


![図1 Altera-SoC の場合のアーキテクチャ](https://qiita-image-store.s3.amazonaws.com/0/24981/e3455ae3-4e7b-e510-f472-382fe312e62f.jpeg "図1 Altera-SoC の場合のアーキテクチャ")


図1 Altera-SoC の場合のアーキテクチャ

<br />



上の図で、Linux Kernel のうち実線枠で囲まれているものが実装済みのもので、破線枠で囲まれているものが未実装のものです。見ての通り、未実装の機能がまだまだあります。



ユーザー側から各機能を制御するための Higher Level I/F が無いため、各種機能を使うにはカーネルモードで動くプログラム(デバイスドライバ)が必要です。



また、FPGA のプログラムをロードしている最中は、ハードウェアの誤動作を回避するために HPS-FPGA Bridge をオフにしておく必要がありますが、何故か HPS-FPGA Bridge を制御するためのドライバが未実装のため、実はFPGAのプログラムをロードすることさえ出来ません。したがって FPGA Manager Framework や Low Level FPGA Driver が単なるゴミに成り果てています。


## ZYNQ の場合のアーキテクチャ


前節で紹介した機能がZYNQ の場合、現時点でどのように構成されるかを下の図で示します。


![図2 ZYNQ の場合のアーキテクチャ](https://qiita-image-store.s3.amazonaws.com/0/24981/0905b7b0-4e15-453e-11f1-f854e75d53f2.jpeg "図2 ZYNQ の場合のアーキテクチャ")


図2 ZYNQ の場合のアーキテクチャ

<br />



上の図で、Linux Kernel のうち実線枠で囲まれているものが実装済みのもので、破線枠で囲まれているものが未実装のものです。見ての通り、未実装の機能がまだまだあります。


ユーザー側から各機能を制御するための Higher Level I/F が無いため、各種機能を使うにはカーネルモードで動くプログラム(デバイスドライバ)が必要です。


Altera-SoC の場合と異なり、ZYNQの場合は PS-PL Bridge の制御は Low Level FPGA Driver が行います。そのため特にBridge制御ドライバが無くても FPGA プログラムのロードが出来ます。




## アーキテクチャの一貫性


Altera-SoC場合 のアーキテクチャとZYNQの場合のアーキテクチャのところで少し触れましたが、双方のアーキテクチャで PS-PL Bridge の制御をどこが担当するかで相違があります。どういう経過でこうなってしまったのかは判りませんが、どのモジュールが何を担当するのか何をしないのかが不明瞭なまま、双方が勝手に実装を進めるとアーキテクチャの一貫性という点で問題が起こると思います。


おそらく、現時点ではそこらへんが不明瞭なため、Linuxのメインラインへの導入が遅れているのではないでしょうか。