思いつきメモ FPGA

今度はZYBOにてLinuxを動作させてみようと挑戦した備忘録。

まとまった情報がなかなか見つからなくて苦労したが、基本はMasahiro Yamadaさんの、"U-Boot と Linux Kernel のメインラインで Zynq を動かす"を参考にした。

STEP0: DTCの準備 はそのまま実施した。

STEP1: U-Bootのビルド ではまった。結論としては、ARMのクロスコンパイラとしてCodeSourcery Liteを使用した(単にXilinxからgccをダウンロードするのが面倒だったので。Xilinxのgccで動くかは試していないため不明)。

最初はLinaroのGCCでU-Bootをビルドしていたが、どうしても動作しなかった。U-Bootはlibcにも依存しているようで、LinaroのGCCだとダメだと思われる。

さらに、肝心のU-Bootは、オリジナルのものだと動かなかったので、DigilentのU-Bootを使用した。この手順は、Ryuzさんの"ZYBO(Zynq)のu-bootのビルドまで"に従った。CROSS_COMPILEのところは、(CodeSourceryなので)arm-none-eabi-にした。makeでu-boot.binができた(上記手順だとDTBはできないが、Linuxのブートは可能)。

STEP2 ...

Zynq USBデバイステスト (PC側ソフトウェア)の続き。

C:\Xilinx\SDK\2014.1\data\embeddedsw\XilinxProcessorIPLib\drivers\usbps_v2_0 のexamplesに対するパッチ。 usbMain関数を呼び出すと動作開始。examplesのファイル達はusbフォルダにコピーされたものとする。

概要としては、examplesはUSB mass storageとして動作するので、バルク転送のTX/RX割り込みがかかるところを 横取り(XUsbPs_HandleStorageReqをコメントにする)して、所望のデータ処理に置き換える。 また、サンプルはTX割り込みがかからないようになっているので、TXのビットをorして有効にする。

diff -cr examples/xusbps_ch9_storage.c usb/xusbps_ch9_storage.c

examples/xusbps_ch9_storage.c    2014-04-16 23:53:27.579740500 +0900
--- usb/xusbps_ch9_storage.c ...

先日digilentに注文しておいたZYBOが届いた。

いきなり確認不足だった点：
- VGAポートは抵抗分割のFPGA直結だった。しかもRGB565(計16bit)階調しかない。
-水晶はPSの50MHzが接続されているだけ？と思ったが、マニュアルを読んでみると、ethernet PHYから125MHzが出ていて、それがPL(pin L16)に接続されているみたいだ。こちらは、PHYRSTBをHighにしないと出力されない。

早速、4/25付けで上記ページにアップロードされているZYBO Base System Designをダウンロードし、Vivado 2014.1で合成してSDKで動かしてみた(IPのアップグレードは薦められるままでOKだった)。main.cのAudoInitializeを実行すると、デバッガが止まってしまったので、とりあえず後回しにし、コメントアウトして実行すると、UARTでメニュー操作ができるようになった。

HDMIを選択し、1920x1080@60pを選択すると、ちゃんとFull HD解像度で動作した。

Zynq7010は、デバイスとしては公式には1.5Gbpsはサポートしていないはずだけれど、安定して動作しているっぽいな。Zynq恐るべし。

HDMI出力のところは自分で作ろうかと思っていたのだが、サンプルがこんなに簡単に動いてしまうと、自作する気力は一気に萎えた。別のことに労力を使うことにしよう。

marseeさん ...

XilinxとAlteraのFPGAで、特に外部との高速信号をやりとりをするときの考え方の違いについてまとめてみる。ただしGTPなどのGigabit Transceiverは考えない(まだ使ったことがないので)。

Xilinxは、基本的にはIOモジュールにあるI(O)DELAYや、I(O)DDR, I(O)SERDESなどを自分でインスタンス化して使用するのが一般的な方法に思われる。これらを使用することで、動作時に信号のタイミングを動かすことができる。また、これらを使用するとシリアライズ/デシリアライズ部分の回路のタイミングはコンパイル毎にほぼ変化しないので、実際に動作させて、ちょうど良いタップを見つける、ということが可能である。

また、ツールとしても、入出力のタイミング制約は、たとえ掛けたとしても、これらのモジュールの配置制約の方が優先される。したがって、あくまでもタイミング制約は、指示した配置をしたうえで、条件を満たすかどうかの確認の意味しかない。

一方Alteraの場合は、タイミング制約ドリブンで配置配線が可能である。クロックとデータとの関係をちゃんと制約すれば、それを(入力の場合)内部のレジスタで正しくラッチできるようにレジスタを配置配線してくれる。レジスタはIOにあるものを使用するかもしれないし、そうでないかも知れない。また、動作時にIOのタイミングを変化させることはできないようだ(少なくともCycloneは)。ちなみに、AlteraのIOにも、スタティックに遅延量が決定する遅延ブロックが存在する。この遅延量もタイミング制約を満たせるようにツールが自動設定してくれる。

以上から、自分の印象としては、静的にタイミング制約をすることで動作可能な場合はAlteraが便利で ...

twitter経由で、CycloneVに重大な欠陥がある、というようなものを見つけた。Errata Sheet for CycloneV Devicesによると、重大な問題というのは、2番目のFractional PLL Phase Alignment Errorのようだ。PLLの位相が設定値よりもずれてしまう場合がある、というようなことらしい。影響を受ける事例としてLVDSが挙げられている。例えば、受信クロックをPLLでロックさせてnビットデシリアライズする、といったときに影響するのかも知れない。確かに、ここに問題があるとすれば、用途によっては使い物にならなくなってしまうかも知れない。

PLLの詳しい仕組みには詳しくないが、PLLだけでも本が何冊も書けるくらいだから、アナログ回路の真骨頂なのだろう。それだけに問題も起きやすいところかも知れない。

いずれにせよ、しばらくはXilinx優位ということになりそうだ。

アルテラ、ソフトウェア・プログラマの FPGA 利用を可能にする OpenCL 向け SDK と市販ボードの一般提供を開始

SDKについて詳しく調和したわけではないが、OpenCLではそれほどFPGAのメリットが引き出せないのではないか、と思う。OpenCLは基本的に、メモリとデータを何度かやりとりしながら処理を進めるプログラミングモデルが利用されていると思う。一方、FPGAを用いて処理を高速化したいという場合、一般的にはメモリから一気に回路パイプラインに流し込んで、パイプラインから出てきた結果をまたメモリに書き戻す、というイメージではないかと思う。メモリとのやりとりが多くなると、結局演算よりもそちらがボトルネックになってくるはず。それに、メモリ帯域という事で言えば、ほとんどのFPGAを載せたボードでは、最新のGPUボードのメモリ帯域には太刀打ちできないだろう。

ということで、OpenCLのプログラミングモデルはFPGAの高速化に向くものではない、ということである。それよりは、普通に高位合成でパイプライン処理を合成し、必要なメモリとのやりとりをくっつければ良いのではないだろうか。

最近モチベーションが下がっている。ネットを徘徊していたら、ちょっと面白いネタを見つけた：

文字通り「ネットワークがコンピューター」な金融HFTでのFPGAの使われ方

ここ数年HFTの分野では、FPGAで処理を実装するのがはやってきている、ということ。リンク先の記事からもリンクされている、Parallel Scientific: The Awesome Haskell FPGA Compilerは以前すこし眺めていたが、今回の記事を読んで全体像の理解が少し進んだ。なるほど、こんなところでも回路設計をしてしまう時代になったのね、という感じ。

10Gbpsのネットワークスイッチに入れてしまうというのであれば、当然Alteraで言えばStratixクラスの1個何十万もするFPGAを使うのだろう。外付けメモリもDDRみたいなレイテンシの大きいものではなく、RLDRAMやQDRといった、個人的には使用しているのをあまり見聞きしないタイプのメモリを使っているのではなかろうか。

もしこういったものがTCP/IPで通信をしているとすれば、Ethernet MACのIPから出てくるパケットをステートマシンでTCP/IP部分をデコードしてやり、中身のデータに基づいてガリガリ計算し、その結果に基づいてこれまたステートマシンでEthernet MAC IPに売買パケットを流し込む、というような流れになっているのだろう。そして売買の結果は、メモリに書き込んでおき、ログとして保存。これでソフトウェアは一切介在せずに株式やら為替の売買を実行する、と。もちろん、売買条件の設定などの初期化操作はソフトウェアで行うはずだが。

妄想するとなかなか面白そうな分野だなぁ。クオンツの元でブイブイ(死語)いわせるプログラマのイメージが。なるほど、金融業界は計算機分野でも ...

自分のメモ。

回路
Slave Serialモード。XCF32クロックを接続。

ソフトウェア
ISEプロジェクトにELFファイルを追加すると、bitファイルにELFが埋め込まれる。Generate Programming Fileのプロパティで圧縮オプションを有効にする。iMPACTで、Create PROM Fileでbitからmcsファイルを生成。できたmcsファイルをxcf32pにアサインしてProgram。

Create or Import Peripheralで生成されるuser_logic.vhdでは、データバスがstd_logic_vector(0 to 31)で宣言されている。これはMSBがbit0でLSBがbit31となるというMicroBlazeの仕様のため。http://www.vhdl-online.de/tutorial/englisch/t_58.htm#pgfId-1016798を読んで分かったのは、VHDLでインスタンスを宣言するときの配列ポートは、ビット番号ではなく、ビット並びの順番で接続されるということ。

EDKで自作IPコアの使用を試している。Create or Import Peripheralを使用し、VHDLでuser_logic.vhdを作成する。user_logic.vhdからVerilogで記述された回路を使用したい。PAOファイルにVerilogファイルを記述したり、MPDファイルにVerilogも使用する設定の記述などを行ったが、どうやってもISEでコンパイルできなかった。

結局、IPコアとして埋め込むのはあきらめて、MicroBlazeのxmpがISEでトップレベルファイルになっていたのをやめて、MicroBlazeのstubファイルをトップレベルにし、普通にISEプロジェクトにVerilogのファイルを追加したらOKになった。

後日記


上記の方法でまたおかしくなってしまったのが、もう一度挑戦したら、最初に試みた方法でできるようになった。ただし、verilogのソースを変更したときは、implementationフォルダにあるngcファイルと、その中のcacheフォルダにあるファイルを削除してからgenerate netlistしないと、変更が反映されない。