kazuk は null に触れてしまった

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

月別アーカイブ: 12月 2016

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 を物理インスタンスに導入しようそうしようといった感じ。

広告

Vivado HLS での高位合成を業務系バッチに適用できるか試してみる


 

Amazon の FPGA F1 インスタンスでは、Xilinx の Vivado および Vivado HLS で設計を行う事になる。

Vivado が Velilog 等 RTL でのハードウェア記述で FPGA へ投入するBitstreamを生成するのに対して、Vivado HLS が C / C++ でのロジック記述から高位合成を行うという事でソフトウェアエンジニアとしては多少記述の抽象度が低いとは言え C /C++ で記述できるのはうれしいことだ。

Vivado HLS についての記述例やサンプルを色々眺めてみても bitmap を扱う例だったり業務データの扱いによくあるレコード的な物が無かったりしたので、とりあえず構造体使えるの?程度に試してみたのが以下。

#include <hls_stream.h>

struct OrderLine
{
    int itemId;
    int amount;
    int unitPrice;
};

long foo( hls::stream<OrderLine> indata, int count)
{
    long totalPrice =0;

    for( int i=0;i<count;i+=4 )
    {
        OrderLine line0;
        indata.read(line0);
        totalPrice += line0.unitPrice * line0.amount;
    }
    return totalPrice;
}

よくあるっちゃよくある、注文明細行なめて、単価x個数を集計するようなバッチ処理。

image

3クロックごとに1行を処理するロジックに落ちたみたい。

hls の stream を使ったので、struct の各要素の各ビットを入れる為の pin があるハードウェアが作られた!(ちゃんと構造体がパラメータとして使えてる!)

image

メモリにマップしてそれを読み込んで処理して回るロジックにしてみたりとかは、また今度ですが一応とっかかりとしては普通にCで構造体とか作ってレコード定義してそれ処理して回るハードウェアアクセラレータは普通に作れるようだってところ。

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並みに簡単に始められる、懐痛まずに始められるのはすごく良い、どっちが良いかは解らない程度に条件はイーブンに見えます。