「知りません、書けません」
と逃げ回っていたのです。
ところが最近身近で FPGA ブームが起きていまして、 DE1 を買って来たのです。
DE1 は低価格で Sound DAC や DSUB を備えた楽しいボードなのですが、気軽に使える IO はプッシュボタンと 7SEG と LED くらいなので LED 光らせる(いわゆる L チカ)などラボの講義を終えたくらいで止まっておりました。
(だっていきなり音とか出したら耳ぶっ壊れそうだし、 DSUB のモニターなんかもうないよ……)
ところが最近よいものが DE1 の価格帯で売っていると聞きました。
Altera SoC Cyclone V の評価ボード Helio です。
CycloneV はデュアルコア ARM SoC に FPGA fabric をオンダイに搭載したものです。
FPGA として見ても、 DE1 の Cyclone II から見ればとても豪華なものです。
Helio ボード上には UART, JTAG, USB Blaster, Ethernet, DDR3, USB(OTG), MMC が実装されており、すぐ MMC で Linux をブートして LAN 上に見ることができます。
Ethernet, DDR3 は説明不要でしょう. UART はシリアルポート, JTAG はデバッグインターフェイス, USB Blaster は FPGA の再構成デバイス, USB(OTG) は Host にもなれる USB コントローラー、 MMC はマルチメディアカードです。
どれも実績と人気のあるパーツでまとまっております。
HDMI や DVI がないくらいです。
 | |
| Helio のメインコンポネント |
さて、ところが FPGA fabric を搭載した ARM なんて使ったことがありません。
例えば ARM はメモリを混成しておらず、ボード上の DDR3 を使いますが、 FPGA から DDR3 を使えるのでしょうか。
FPGA からはどのバスで DDR3 を叩くのがベストな方法でしょうか。
ここでは FPGA から DDR3 に書き込んで ARM から読むのを目標に、 Cyclone V のアーキテクチャを見ていこうと思います。
準備編
Linux の起動
とりあえず Helio ボード上で Linux くらい起動していなければ話になりません。Helio の開発元である rocketboards のサイトに丁寧な Getting Start Guide がありますのでそれを見て行ってください。
Helio には SD カードが付属していますが漢のブランクであります。
ラズベリなんかだとちょっとお金を払うだけで u-boots で起動する Linux のイメージを焼いたものが付属しますが、イメージは rocketboards に各種ありますので好きなものをダウンロードして dd で焼きます。
一番シンプルなものでも httpd,sshd くらいは動いてくれます。これで充分でしょう。
起動すると DHCP で勝手に IP アドレスを取得します。
UART は Linux の起動に割り込むのに必要ですので常時繋いでおきます。
FPGA の再構成に使うケーブルも繋いでおいたほうがいいので、二本は必要ですね。
なくても Linux のブートくらいはできますが(ありがちな話ですが) UART は IP アドレスを確認するのにも必要です。
Helio では、何かがバグっているものか起動するたびに MAC アドレスが変わってしまいます。
このためルーターで IP を指定することもできません。会社で使うにはトラブルの元でしょう。
しかもブロードキャストに応答しないので、真っ先に static にしておきましょう。
開発環境
ソフトの人向けに、まず開発環境とワークフローについて書いておきます。Parallels9 for Mac + Ubuntu13.04 の環境に Quartus II 14.1 web edition を入れて使っています。
Quartus II は Altera によるいわゆる IDE で論理合成、配置配線といったソフトでいうところのビルドを行います。
Cyclone II などの古い FPGA は Quartus II 14.0 以降サポートを切られていますが、 Cyclone V では Quartus II 14.1 を使いましょう。
v14 以降は 64bit サポートもしています。(シミュレータである ModelSim は 64bit 対応ですがインストーラが 32bit というクソです)
詳しくは後述しますが Quartus II よりはその付属の Qsys というツールをよく使います。
Qsys はかつて SoC Builder と呼ばれていたソフトで、ハードウェアの情報から IP (ソフトでいうライブラリみたいなもの）をカスタムした一つの大きな回路とそのインターフェイスを生成するものです。
cmake みたいなもの……といえばいいでしょうか。
IP というと「高そう」とか思ってしまいますが、後述する GHRD というリファレンスデザインが既に IP として提供されています。
シミュレーションには敢えて ModelSim を使わず GHDL や icarus verilog を使っています。
GHDL は幸せでしたがこれは VHDL 用ですんで icarus verilog にしました。
ARM コア用にはツールチェインが提供されていますが、普通に arm-eabi 用の gcc を使うことにします。
(VM で clang ビルドしたら三日四日かかってもリンクが終わらなかったのでいったん諦めました)
ちなみに Quartus II は安定しているときは安定していますが、死ぬときは 10 分で死にます。
調べてみると Talkback を OFF にしていても定期的に CDN に https で何かのリクエストを送っており、これがタイムアウトすると割り込みハンドラの中で死んでいます。
場合によってこのリクエストは一度も発行されない状態で起動することもあるので、その場合は安定します。二度と終了しないでください。
あとアメリカが寝ている、日本時間の昼間には安定しています。
会社から帰って来て夜中に起動すると大体時間を無駄にすることになるので、「なるべく昼間にやる」「安定したら二度と終了しない」ルールで運用しています。
さてフローは、 Quartus II で .sof などのネットリストのファイルを生成し、 Programer という何とも漠然とした名前のツールでそれを FPGA に焼き、ボードの動きを確認することが目的になります。ボードには WARM/COLD のリセットボタンが付いていますが、これはどうやら HPS 側であって FPGA 側は焼いた時にリセットが走っているっぽいので、やらなくてもいいです。
（HPS 側をリセットしても FPGA 側のリセット信号は動きません。よくできている）
.sof は揮発性なので電源スイッチでハードオフすると飛んじゃいます。開発時には便利です。
Programmer は onboard USB Blaster を使って FPGA を再構成します。
Parallels9 for Mac ではゲスト OS の Ubuntu 側で USB Blaster の認識が安定しませんでした。(20 回に一回くらい？)
しかし VM の設定で USB3.0 サポートを切るとすんなり認識するようになりました。
Altera のドキュメント通り udev だけ設定しておけばドライバは不要です。
UART も伝統の FTDI 互換ですので(Linux では)ドライバ不要です。 Mac OSX でも marverics なら不要のはず。うちのは違うので知りませんが Arduino はドライバ不要でいけたのにこれはちょっとダメそうでした。
Quartus II でコンパイル(正確には論理合成)するソースは好きなエディタで書いてかまいませんが、 Qsys が生成する HDL は再度上書きされる可能性があります(標準では soc_system ディレクトリ以下に生成される)。
このへんは Qsys を使うときにまた詳しく書きます。
回路の HDL を書いたら(シミュレーション用のテストベンチも書いて)シミュレータで波形を見ましょう。
僕は icarus verilog と GHDL, gtkwave を使っています。
これらのシミュレータは論理合成をしてくれません。従って、シミュレータでは動いても、論理合成不可能な回路を書いている可能性があります。
その場合 Quartus II でエラーが発見されるので TAT が長くつらいです。
icarus verilog 0.9 では -S を付けてコンパイルすると論理合成を試します。この機能は開発中のようですが、シミュレーションできるが論理合成できない記述を発見するには大変役立ちました。
HPS
HPS とは Hard Processor System (再プログラム不可能なプロセッサとそのシステム)のことで、おそらくはこれは Altera の言葉と思います(Soft Processor ありきの言葉なのでね)。ここでは、要するに ARM 側のシステムのことです。 ARM の MPU コア以外にも L3 インターコネクトや AXI が含まれます。
Altera が決めてないことは全部 HPS だと思っていいのではないでしょうか。 ARM を主体に見ると軒先を貸して母屋に変な名前を付けられたように見えるかもですが、 ARM はそもそも IP で売ってるものですし、土地は元々 FPGA のものだっりします(今回 HPS の家屋を造り直すことはできませんが)。
これはドキュメントじゅうに現れる言葉ですので、何が何でも最初に覚えておかねばなりません。
本記事で主に扱うのは FPGA 側と ARM 側のやりとりの方法でありますから、これは即ち HPS Subsystem の使い方であるわけです。
HPS SDRAM Controller Subsystem
Cyclone V のマニュアル(の一部. Book3)より https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v4.pdf "HPS SDRAM Controller Subsystem" の章、 Figure.11 がまさしく求める情報です。 |
| Altera SoC Cyclone V の全容 |
右側の赤丸を付けたコンポネント、これがメモリコントローラです。
L2 キャッシュを経由せずに L3 インターコネクトから接続されていますので、ほぼ全コンポネントからこのメモリコントローラにアクセスすることができます。
FPGA fabric から直接このコントローラを叩くには FPGA-to-HPS SDRAM というのがヒントになるようです。
当然ながら——このレベルの混同はないと思いますが念のため断っておくと、ここでいうメモリコントローラは飽くまでメモリモジュールを制御するコントローラで、 MMU は含みません。
ARM の、ちょっと特殊な MMU はコア側に実装されております。つまり、物理アドレスが必要です。
FPGA-to-HPS SDRAM のインターフェイスについて更に調べていきます。
Figure.11-1 SDRAM Controller Subsystem High-Level Block Diagram によるとこの部分についての詳細が記述されています。
AXI は ARM の定義する AMBA 第三世代か第四世代のバスアーキテクチャだったはず(うろ覚え)ですが、 Avalon-MM というのはあまり耳馴染みがありません。
Avalon, Altera, ARM, AXI, AMBA, AHB …… A から始まる用語がゲシュタルト崩壊しそうです。電話帳かよ！！
これは Altera が定義するインターフェイスのようで、使い方は簡単です。
仕様はこちらにございました。
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/manual/mnl_avalon_spec.pdf
シンプルな Master/Slave のアーキテクチャで、実際のバスアーキテクチャは任意に選ぶことができる……というようなものだった気がします。
SDRAM Controller に関しては直接繋がってるようなのであまり気にしませんでした。
データのリードライトを要求する側が Master で、物理的なレジスタやメモリにアクセスしてデータを提供するのが Slave です。
従って、この Avalon MM の Master を実装するのが今回の目的です。
実際の作業を始めましょう。
……ところがここまでで非常に長くなってしまったので、作業編は次の記事に回します。
つづく。
0 件のコメント:
コメントを投稿