kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

カテゴリーアーカイブ: FPGA

Vivado HLS で Windows 版バイナリは出ているが


 

C Simulation が使えないので、割と即詰むようだ。

パイプライン化を試そうと #pragma HLS PIPELINE を一行入れたら WARNING: [RTGEN 206-101] がワラワラと

Please use C simulation to confirm this function argument can be read from or written to.

って言われたので C Simulation 動かしたら、WARNING: [SIM 51] HLS only supports CLANG compiler in Linux.

なので、開発環境として Windows は使えないようです。

 

ま、ありがちな事ではありますが、 HLS に続くBitstream生成で割と大量なメモリを要求する事は目に見えているので仮想マシンで用意するのもホストOS分つらくなるし幸いに使用頻度の低いマシンがあるので Linux を物理インスタンスに導入しようそうしようといった感じ。

AWS から FPGA 搭載 IaaS


 

Amazon EC2 F1 Instances (Preview)

https://aws.amazon.com/jp/ec2/instance-types/f1/

いやぁ、Azure が先行するかと思ってたのですが、Amazon の方が先に使える事になるんですかね。

という訳で、自分の中で想定してた諸々と想定して無かった諸々を書いてみたいと思います。

ネットワークトラフィックの前さばきには使えない

https://aws.amazon.com/jp/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/

The New F1 Instance の構成要素を見ると PICe x16 で CPU と接続されている以外は 288bit-wide な 64GiB DDR4 ECC メモリが接続されているとなっていて、それ以外のハードウェア接続は無いようです。

なので GPGPU ソリューションで問題になりがちだった NIC が遠いという問題は依然として存在します。ネットワーク入力に対してのレイテンシ問題に対して CPU で応答処理するのに比べて PCIe で FPGA 側へ転送、FPGA側での処理後 PCIe で CPU 側に転送するわけでオーバーヘッドは大きいです。

メモリの実効帯域幅はこの説明だけでは解りませんが一般的なPCにおけるCPUとの帯域幅の数倍あるように思えます。DDR4のクロックは解らないですが 288bit-wide という事は DDR4 SDRAM DIMM が概ね 64bit-wide(ECC 72bit-wide) なのを 4 並列ですのでちゃんと使い切れば GPU ボード内でのメモリ帯域幅に匹敵する帯域があるように見えます。容量的にも64GiB あるので広帯域+大容量で、すげぇってレベルです。

ハイエンドFPGA UltraScale+ VU9P を搭載

スペックは以下参照

http://www.xilinx.com/support/documentation/selection-guides/ultrascale-plus-fpga-product-selection-guide.pdf

その気になれば 100G Eth 9ch とか Interlaken 150G 9ch とか繋がる化け物(前述のとおり、NIC に FPGA 繋がってないのでもったいない)、DSP ユニット 6840個とか Peak INT8 DSP が 21.3 テラ ops とかDSP側を見ても余裕石です。

開発環境の AMI 提供

これがぶっ飛びで、FPGA の開発環境って、ソフトのライセンスで 3000ドルだ4000ドルだとかするんですが、インストール済みの AMI が提供されるのでインスタンスを起動するだけ、インスタンスのお値段次第ですが 30万円~50万円の開発環境出費は覚悟せずに始められるという事になります。(Azure – Altera – Intel が来るだろうと、Altera に40万円、開発ボードに40万ぐらい、この夏に貢いだ俺まじ涙目です)

いい土俵だ

前述のとおり、NIC に繋がってない FPGA なので、条件はさほど GPU と変わりません、広帯域+大容量のメモリがあるという点でも変わりません。ガッチガチにFPGAとGPUで真っ向勝負するなら「いい土俵だ」ってぐらいに似た条件です。乗せれるアプリの傾向も割と似た傾向になるかもしれません。整数演算が多いなら FPGA が向く、半精度ないし単精度の浮動小数点演算が多いならば GPU が向くとか、GPUでは if が弱いが FPGA は余り影響を受けないとかその辺も出てくるかもしれません。

GPU でもFPGAでもロジックの実装に OpenCL を使っているならコンパイル環境の違いだけでしかないかもしれません。結果早かった方使えばいいじゃないかっていう乱暴な選択ができるかもしれませんね。

今出てる断片的な情報を集めた結果ですがFPGAならではの高速トランシーバー活かしたネットワークパケット処理とか小回りが利きそうな所は割と使えないので残念、逆に GPU並みに簡単に始められる、懐痛まずに始められるのはすごく良い、どっちが良いかは解らない程度に条件はイーブンに見えます。

FPGA 再入門してみた(1)


Intel が Xeon に FPGA を統合する話ってのが去年の今頃出てたのを受けて、「データーセンター向けだ」と言ってるIntelの言い分は「聞いてないふり」して、市場に出てきたら相手できるようにという事でFPGAでハードウェアロジックを作る方に「再」入門してみています。

広義のプログラミングロジックは PLD/PAL とか触ったことがあったような気もするレベルの過去なので完全な初心者のような気もします。

 

開発環境

OpenCL でさっくり高位合成とか行きたかったですが、予算的に手の出る開発ボードだと「やっすい」ので「しょっぱい」具体的には FPGA の LE 数やIOの為のトランシーバー数が少ないので絶対的にできる事が少ない。LE数やトランシーバー数考えて何ができるものって線から手が出る物選ぶとちょっと世代が前の物なので OpenCL とかが使えない。

結局安いけど OpenCL で高位合成でさっくりかける物と、OpenCL サポートされてないけどそこそこ機能性はある物を組み合わせて勉強って感じです。

完全な初心者としては割と贅沢な環境ですが以下。

  • PC: Windows 10 Pro (Core i7 / RMA 32GB / SSD / HDD )
  • FPGA 開発ボード Terasic DE4-230 (OpenCL非対応) / Terasic DE1-SoC Board (OpenCL 対応)
  • 開発ソフト Quartus Prime 16.0

FPGA ボードの DE4-230 が約30万円、Quartus Prime が年間15万円ぐらいという事で普通に PC のソフト開発を始めるのに比べればコストはまぁかかります。

Visual Studio 2015 の Community Edition がタダとかに比べればハードルたけぇなオイです。

 

なんでFPGA? GPGPU でいいんじゃないの?

GPGPUでいける事やるんならそれでいいんです。単純に言えば、GPU ボードに NIC ポートが乗ってて、LANケーブル刺せるならGPGPUでも良いかもしれません。あと SATA コネクタついてて SSD を GPU に直結できるとうれしいですね。そんなもん無いけど。

GPU を使った SSL アクセラレーションとかなんで流行らなかったのかの話と一緒なのですが、NIC側から何か要求が入ってきて、この要求をGPUに処理させようとすると NIC から OSに割り込みかかって OS がカーネルモードでNICからの入力データをユーザー空間にコピー、それをGPU に渡すと OS に組み込まれたドライバが PCI-e 経由で GPU 側のメモリに DMA、GPUでそれを処理、戻りも似たり寄ったりの面倒くささで NIC まで応答を流すわけです。結局 GPU とNICの間の転送に数マイクロ秒~数ミリ秒は普通にかかりGPU側での処理がCPUの数十倍早くても転送に食われる時間考えるとGPUでの処理がデメリットになる事はあります。

対する FPGA は NIC や DRAM に対して直接のインターフェースをもっていますので、NIC から入ってきたデータを OS やCPUを介さずに直接処理して応答を直接NICに投げ返す事ができる。NICを通して流れるパケットそのままが見えるので、受信が完了する前にパケットに書かれてる事で処理して応答を送り始めるとかできちゃうので普通にソフト処理してる時の計測基準をそのまま使うと応答時間がマイナスになる事もある。(要求転送の終わり時刻と応答転送の開始時刻の差を応答時間としてますよね普通だと)

要するにGPGPU はスループット志向で大量データの一括処理、FPGAはレイテンシ志向で入ってきたデータの即時処理、それぞれ向き不向きがあって使い分けるべき素材なのです。

もう2年前の記事だったりしますけど、10GbE 来たら普通のNIC に普通のOSではパケット小さいと死ねます。 http://codezine.jp/article/detail/7631

そこから2年、CPU や NIC 、OS 何が進化したかというと「何も変わってねぇ」感はあります。 CPU のシングルスレッド性能はすでに5年前から頭打ちしてます、NICからの割り込み処理はシングルスレッド性能の影響下にありますので最新鋭のメニーコア Xeon を投入したところで効き目は限定的です。NICは10GbE 対応NICは安くなりましたがオフロードできるものの選択肢は増えてません。OSは Windows だと 2012 R2 がまだ現役で当時と変わりません。

んで、オフロードNICのエンジンチップがですね、 FPGA だったり FPGA ベースで開発された ASIC だったりして10GbE にまともに対応できているプログラマブルな何かというと FPGA ぐらいしか現状では選択肢が無いので FPGA に行ってみたって形ですね。

GPGPUも自分はやってないわけじゃないけど、GPGPUでのスループット志向とは違うレイテンシ重視な方が元々通信系のエンジニアとしてはやりたい領域って事で。

 

日本人すくねぇ

FPGA-NICで10GbEとか割とまだ誰も動いてない感あって、日本人少ないし日本語情報とか割と無い感じなので、だれかやってるー?お友達なろうぜー?的な blog でした。