ハード素人が32bit CPUをFPGAで自作して動かすまで読んだ本のまとめ

男子たるもの一度は自分でCPUを作ってみたいものだけど、ICでLEDをピカピカさせた程度の経験しかないハード素人な俺だったので、CPUを自作してる東大生などを遠くから見て憧れてるだけだった。しかしおよそ一年前のこと、「MIPSなんて簡単に作れますよ！」とKさん（←FPGAでLispマシンを自作するような人）に言われて、お、おぅ。。そりゃKさんはそうでしょうよ。。あれ、もしかして俺にもできるかな。。？　と思った。この一言がなければ32bitのCPUを自作しようなんて考えなかっただろう。

それから一年ちょい、とくに今年の正月休みやFPGA温泉でがっつりがんばって、なんとかMIPS Iサブセットの自作CPUが動いた。これはフィボナッチを計算してるところ。

ちなみに、これはこんな感じのフィボナッチのコードをCで書いて、

void main() {
    int i, *r = (int *)0x7f00;
    while (1) {
        for (i = 1; i <= 25; i++) {
            *r = fib(i);
        }
    }
}

int fib(int n) {
    if (n == 1) return 0;
    if (n == 2) return 1;
    return fib(n-2) + fib(n-1);
}

これをgccでMIPSバイナリにクロスコンパイルし、FPGAボードに読み込んで動かしてる。

このCPUは趣味で作ったので、実用性はまったくない。メモリは32KBだしfloatも例外もキャッシュもバスもなくLinuxは動かない。でも、CからコンパイルしたMIPSバイナリを実機で動かすという目標を達成できて感無量である。実装したHDLコードはCPU32という名前で置いといた。そして、ここ一年くらいハードウェアの設計の勉強をしてきた中でこれはとても役に立ったっていう本がいろいろあったので、以下にまとめておきたい。

まずはLチカ、デジタル時計、シリアル通信あたり

一年ほど前になるけど、入門用FPGAボードの定番Terasic DE0を買って、LEDをチカチカさせるたり、デジタル時計を作ったりするところから始めた。

Terasic - FPGA Main Boards - Cyclone III - Altera DE0 Board via kwout

この時期にお世話になったのがこのあたりの本。

超入門！FPGAスタータ・キットDE0で始めるVerilog HDL: すぐ始められる!USB対応・書き込み器不要・大容量FPGA搭載! (トライアルシリーズ)

FPGA ボードで学ぶ組込みシステム開発入門　?Altera編?

上の本はやたら高いし、Verilog HDL（ハードウェア設計用言語）の解説としてはベストとは言えないけど、Terasic DE0を買ってきてまずLチカさせたいって人にはちょうどいい内容。Lチカできたら、定番であるデジタル時計を書いてカウンタや同期回路の書き方を学び、つづいてMIDIに繋いで音を出したり、PCとシリアル通信したり、、って感じだったのが一年前の年末年始。

MIDIキーボードをつないで和音を出す

もっとも、FPGAの学習でまずハードルが高いのは、DE0などのFPGAの実機を1万円くらいで購入して、さらにQuartusなどのベンダーツールが動作する環境を用意するところ。ツールは無償なのだけど、どれもWindowsでしか動かないのがネック。

AlteraのFPGA開発ツールQuartus II Web Edition

一方、以下の本ではIcarus VerilogというMacでも動作するオープンソースのツールを使い、ソフトウェア・エンジニア向けにFPGA開発のことはじめが解説されてるので、まずは実機なしでHDLのHello Worldを体験してみたいという人におすすめしたい。

インターフェースZERO No.04 Hello Worldから始めるFPGA入門: 2大メーカXilinx,Alteraのお手軽ボードでチョコッと体験! (インターフェースZERO (4))

そしてもうひとつ、最近Vengineerさんに教えてもらったのがEDA Playground。ツール等を一切インストールせずにブラウザ上でVerilog HDLのシミュレーターを使いながらの基礎レッスンを進められる。英語が苦にならない人向けだ。

つづいて4bit CPUを作る

つづいては4bit CPUを作ってみた。ここで、神いわゆるゴッドと言えるこの名著にたいへんお世話になった。

CPUの創りかた

この本、前半まるっきりアナログな話だったり、FPGAどころかバラのTTL ICでCPUを組んだりと色々おかしい本（褒め言葉）なのだけど、しかしこれを繰り返し読みながら同じ設計の4bit CPUをHDLで書いていく作業を通じて、はぁ〜つまりCPUってこういうことなんだな！と目からうろこな体験ができた。とりわけ、著者が「迷ったらここに戻ってきてください」と記した1bitフリップフロップのページ、これが真髄だなぁと思うことしばし。自分でHDLで書いた4bit CPUをDE0で動かし、本書の巻末にあるラーメンタイマーのプログラムが動いたときは嬉しかった。。My first CPU!

この時期にお世話になった他の本は、このあたり。

Microprocessor Design Using Verilog HDL

FPGAでCPUを作ろう 〜FPGAで、あなたも自分がデザインしたコンピュータを動かせる〜【電子書籍】

岸本誠
達人出版会
発行日: 2012-03-21
対応フォーマット: EPUB, PDF

詳細を見る

上の本は、ベテランのハード設計者がVerilog HDLでZ80をまるごと実装してみたらどうなるか？　っていう趣旨の本（英語）。こちらも、本格的な8bit CPUをHDLでガリガリ書くためのコーディングスタイルやプラクティス、テスト方法、そして設計手法（まずはステートマシンを表計算で設計する）を紹介してて、なるほどプロはこんなふうに仕事するのか〜と感心。

岸本さんの本はHDLで8bit CPUを作るもので、4bit CPUが動いた後に読むのに適した内容。例えばCPUの各コンポーネントをHDLで書くとどうなるか？　テストベンチはどう書くか？ってイメージを掴むのに役に立った。

Verilog HDLの基礎、シミュレーション、そして検証技法のお勉強

しかしこの辺りで、どうもVerilog HDLのお勉強でカベにつきあたった。例えば代入の構文に「=」（ブロッキング代入）と「<=」（ノンブロッキング代入）という2種類があるのだけど、すべての演算が同時並列で進むデジタル回路なのにブロッキングとかノンブロッキングってどういうこと？　ってしばらく理解できなかった。

答えを言うと、Verilog HDLはそもそも回路合成用の言語じゃなくて「回路シミュレーターのふるまいを記述するための言語」として生まれたものであり、ブロッキングとかノンブロッキングとはシミュレータの逐次処理のふるまいを指定するもの、なのだ。つまり、HDLをきちんと理解するには、シミュレーターの使い方やそれがどう動作しながらデジタル回路の動きを模倣してるのかを意識する必要がある、、ってハリー先生に教えてもらった。

4bit CPUを作る前あたりまでは、ほとんどシミュレーターを使わずに済ませていた。回路をLSIに焼き付けるASICとは違い、FPGAは自分で書いたコードをすぐに実機で試せるし、デバッグしたかったらSignalTapやChipScopeと呼ばれるロジック・アナライザを使えばある程度は信号を追えるからだ。よって、Verilog HDLのシミュレーター用言語としての使われ方も知る由もなかった。実のところ、Verilog HDLには回路合成とシミュレーションという2つの用途（セマンティクス）が存在し、しかも計算パラダイムもいろいろ混在してるので、ある段階になるとそれらの違いを意識しないといけない。

Altera FPGAの場合、本格的なシミュレーターとしてModelSimが無償で提供されている。このModelSimの使い方をこの本で勉強した。

図解 ModelSim実習 ゼロからわかるディジタル回路シミュレーション

ModelSimを使い始めて気づいたけど、シミュレーターでHDLを書いたほうがQuartus上で直接コーディングするよりもコンパイルが全然速くて生産効率がまるっきり違う。それに、制約の多いSignalTapに縛られることなく、すべての信号の状態をタイミング・チャート上で眺めつつデバッグできる。シミュレーターであらかたのバグを取っておけば、実機のみで出るバグはあまり多くない。ModelSimまじおすすめ。これ以降、ハード設計の時間の8割はModelSim上でのコーディング＆デバッグ作業になった。飛行機乗ってて死ぬほどヒマな時とかにもHDL書ける。ひと通り書いたら、最後にQuartusでビルドして実機テスト＆デバッグ、、という流れ。

ModelSimでシミュレーションしてるところ

もうひとつ避けて通れないのが、検証手法のお勉強。ハード開発の世界は、テストファーストどころか、開発コストの7〜8割が検証に費やされたりする。徹底した検証作業を専業とする検証エンジニアの方もとっても多い。ちょっとバグると数億円が飛んでしまうASICとは違い、FPGAではその場でどんどんバグを直せるのだけど、それでもハードウェアはソフトウェアよりもケタ違いに並列性が高く、どれだけいろいろなパターンと組み合わせでテストしても完全なバグの洗い出しは難しそうである。入門用のごく簡単なHDLを書いてても、検証コードをひととおり書いてテストを通しておかないと、なんだかまったくコードを書けた気がしないのだ。

そうしたハードウェア設計での検証の基本は、この本で勉強した。

Verilog HDL&VHDLテストベンチ記述の初歩 (DESIGN WAVE MOOK)

検証のあたりを勉強すると、Verilog HDLの構文のかなりの割合がテストを書くためにあるんだな〜と分かってきた。もっとも、今回のCPUでは個々の命令実行の検証をHDLで記述してるとものすごく手間がかかるので、代わりに各命令を実行してその後のレジスタ状態をチェックするテストケースをMIPSアセンブラで書き、さらっと通しで流す程度である。CPUの検証を仕事できちっとやるのはものすごく大変そうだ。。

シミュレーション用言語としてのVerilog HDLの使い方、そしてシミュレーターがそれをどう解釈して実行するかの詳細については、あまりよい日本語の本がなさそうなのだけど、YouTubeにあるVerilog Lectureシリーズのビデオで丁寧に解説されている。英語だけど、リスニング教材としてもちょうどいいと思う。

ただし、このビデオの後半に出てくるタイミング検証用のいくつかの構文は、今のFPGA開発ではほとんど使われてないらしい。

それと、HDLの書き方に関して最近おすすめされたのはこの本。

HDL独習ソフトで学ぶCQ Endeavor Verilog HDL―個人レッスン方式でHDL設計完全マスター

Verilog HDLはシンタックスがゆるいので、きちんとしたコードを書くには一定のプラクティスやコーディングスタイルに添って書くことが重要、、と皆さんによく言われる。この本はそのあたりを網羅した本としてnatsutanさんに紹介していただいたので、じっくり読んでみたい。

いよいよMIPSを書く

そんな感じのハード設計修行をだらだらとやりつつ、今年の正月休みからいよいよ本格的に32bit CPUを書き始めた。ここでも、神いわゆるゴッド本の存在によってすっごく助けられた。皆さんご存知のパタヘネ。。ではなく、この本である。

ディジタル回路設計とコンピュータアーキテクチャ (IT Architects' Archiveクラシックモダン・コンピューティング)

現代のコンピューター・アーキテクチャの教科書といえばパターソン＆ヘネシーであるが、上記の本はパタヘネをもっともっと分かりやすくして、しかも実際に動くCPUを作るために必要になりそうな領域をひととおり網羅してて、かつHDLによる実装例まで載せてくれている、至れり尽くせりの本だ。この本をブログで紹介されていたnatsutanさんに改めて感謝。これを読みながら自分でHDLを書いてMIPS命令を一個づつ実装して、あれこの命令ってどうやって実装するの？　とつまづいたらこの本を読み直して、、という正月を過ごした。

もちろん、教科書であるパタヘネもぜひ手元に置いておきたい。

コンピュータの構成と設計 第4版 上 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

コンピュータの構成と設計 第4版 下 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

パタヘネを買ったのは10年か15年以上前のことで、本棚で永劫の眠りについていたのだけど、まさか今になってこのパタヘネをバサッと自炊して電車の中のiPadで繰り返し読むことになろうとは、本との関わりとは不思議なものだ。

実はMIPSを作り始める前に、ARMの方がいまどきっぽくない？　と思ってARMのアーキテクチャを調べてたのだけど、なかなかに複雑な部分（命令エンコーディングとか）もあったり初期アーキテクチャに基づく教科書や資料の豊富さではMIPSにかなわないので、断念してオーソドックスなMIPSで行くことにした。でも、以下のARM本はARMアーキテクチャを知る上でとても参考になった。

ARMで学ぶ アセンブリ言語入門

自分で実装してみると、MIPSの命令セットや命令エンコーディングがそのまんま素直に回路設計に落とせるようになってるところが結構感動した。なーるほど、コレはここがラクになるからこういう設計になってるんだね、という感じで。

// arithmetic operations
  always_comb begin
    case (cpath[`CP_ALU_CTRL])
      `R_sll:     result = rt_or_imm << inst[`I_SHFT];
      `R_srl:     result = rt_or_imm >> inst[`I_SHFT];
      `R_sra:     result = $signed(rt_or_imm) >>> inst[`I_SHFT];
      `R_sllv:    result = rt_or_imm << rs[4:0];
      `R_srlv:    result = rt_or_imm >> rs[4:0];
      `R_srav:    result = $signed(rt_or_imm) >>> rs[4:0];
      `R_jr:      result = {rs, 32'b0 };        // jump to [rs]
      `R_jalr:    result = {rs, (pc + 32'd8) }; // jump to [rs], $ra = PC + 8 (incl. delay slot)
      `R_mfhi:    result = hilo_q[63:32];
      `R_mthi:    result = {rs, hilo_q[31:0]};
    ...

ALUまわりのHDLコード

一方で、まだパイプライン実装まではたどり着いてないし、例外（システムコールやトラップ）、キャッシュ、バス、MMUといった現代のCPUに不可欠なコンポーネントはどれも実装できていないしできる気がしないので、これを仕事で設計してしかもきっちり検証されている方々との間の超えられないカベを改めて認識。

ちなみに、もし自作MIPSで例外、キャッシュ、MMUなどOSカーネルとのやりとりのあたりをきっちり実装したかったら、この本がさらなる神本となるであろう。

See MIPS Run (The Morgan Kaufmann Series in Computer Architecture and Design)

MIPSとLinuxカーネルとの間の、まー低レベルもいいとこの詳細を話を解説した本だ。しかし、俺の力量ではこの領域には達せないだろうなぁ。。

MIPS GNUツールチェイン、ハード＆ソフト連携、SoC

その他、今回はMIPS版のGNUツールチェインを使ってCコードからアセンブラを生成、そしてELFファイルからバイナリを引っ張ってきてMIPS用マシンコードを生成したので、バイナリまわりのツールの使い方を以下の本でお勉強した。

Binary Hacks ―ハッカー秘伝のテクニック100選

この著者の方々のお名前はどこかで見たことがある気がするぞ。。objdumpやreadelf等のバイナリいじりのためのツールはこれまでまったく触れる機会がなかったし、ELFファイルの構成やアセンブラのマクロの意味、関数呼び出し時のレジスタの使い方、スタックポインタやフレームポインタの動きとか、これを機にいろいろ学べた。

そして今後は、CPU上のソフトウェアとFPGA上のハード間の連携手法をお勉強していきたい。そうしたSoC (System on Chip)の世界ではどんな感じでシステムを設計するのか詳細に解説してるのは、栗元さんのこの本。

FPGAキットで始めるハード&ソフト丸ごと設計―CPUと周辺回路を作り込んでCプログラミング (Design Wave)

CPUで動くソフトウェアとFPGAで動くハードウェアの両方を自作して、それらをバスでつないでSoCを構成する、、という我々が目指すべき世界の詳細が記されているのだけど、今の俺のレベルではまだ手が届いていない。

それともう一冊、Alteraのバスまわりを勉強するためにFPGA技術のVol. 5のおさふねさんの連載をとっても読んでみたいものの、残念ながら在庫切れ。。とりあえずVol. 6は入手したのでこれから読むところ。

CPU自作はおもしろい

というわけで、振り返るとなかなかに密度の濃いお勉強コースであった。途中、長い放置期間もあったので、実質かかった時間は週末×3〜4か月くらいだろうか。ソフトウェア・エンジニアのCPU自作は楽しいなーという話。FPGAに興味のあるソフト屋さんは3/10のFPGAエクストリーム・コンピューティング第5回に来るといいよ！

これまで書いたGoogleクラウド関連ペーパー&サンプルまとめ2013 #gcpja

Google Cloud SolutionsチームにSolutions Architectとして入って1年半くらいが経ちました。仕事の4割くらいは国内外のお客さんへの技術コンサルティング（Platinumサポート）、次の4割はホワイトペーパーの執筆やサンプルコードの実装、そして残り2割はApp Engineのトレーニング教材作成や講師のお仕事をやってきました。

年末ということもあるので、ここではこれまで私が書いたホワイトペーパーやサンプルをまとめてみたいと思います。気に入ったものがあればぜひ+1してくださいね！　するとKazもっとその調子で書けとマネージャから指令が来ますｗ いまのところすべて英語ですが、もしかするといくつか日本語化されるかもです。

An Inside Look at Google BigQuery

Solutionsチームが一番最初に出したペーパー。Dremelのペーパーをベースに、BigQueryがどんな仕組みで動いているのかや、MapReduceとの違いや使い分けを解説。まとめると、1TBのデータを1秒でフルスキャンするには10,000台のディスクが必要で、ならばカラム型DBを横に10,000台並べてみようぜ！っていうのがDremel/BigQueryです。Googleやることが大ざっぱすぎます。速いわけです。Googleがこういうずっしりした（学術論文じゃない）技術ホワイトペーパーを出すのは当時まだあまり例がなかったので、社内で学術論文扱いされてGoogle四天王のUrsにまでレビューがエスカレーションしてしまってビビったのはいい思い出です（謝辞にUrsの名があるのはそうした理由です）。

AngularJS + Cloud Endpoints: a best practice to enable Client-side MVC framework

cloud.google.comで今のところいちばん読まれているペーパー。AngularJSみたいなクライアントサイドMVCやリッチなスマホアプリの時代なのだから、重いサーバーサイドMVCいらなくね？　サーバー側で書いたロジックをREST APIでさくっと公開できるCloud Endpointsと組み合わせとけばよくね？　っていう内容。でも実際にAngularJSとEndpointsのJSライブラリを組み合わせるサンプル書いてみたら、なんだかどっちがどんなふうに初期化されるのか混乱してハマった。そこで、社内のngエキスパートであるFredやえーじさんに手伝ってもらって、初期化部分のベストプラクティスをまとめた...っていう経緯です。

Mobile Backend Starter: API Guide

今のところ、Solutionsチームに入っていちばんこってり参加したプロジェクトはMobile Backend Starterかも。もともとはまだフリーだった3年ほど前に、「REST APIで簡単にアクセスできるJSONストレージがあればサーバー側コーディングいらないだろー」っていう発想（当時はまだBackend as a Serviceって言葉はなかった）から、jsonengineっていうApp Engineアプリをbluerabbitさん、knjさん、Jxckさん、itogさん、kissrobberさんらと作ってた。あんまり流行らなかったけど。。jsonengineでの経験ややり残したこともあったので、Solutionsチーム内でBaaS的なサンプルをつくろうってプロジェクトが立ち上がった時にさっそく参加。最初のバージョンはAndroidとサーバー側の9割方をひとりで書きました。今はMBSチームも大きくなってきて、Android版やiOS版はそれぞれ得意なメンバーが書いてます。

MBSでいちばん達成感あったのは、jsonengineでやり残してたワンクリックデプロイとcontinuous queryを実装できたこと。未来方向の検索（Prospective Search）と過去方向の検索（Datastore Query）、そしてGoogle Cloud MessagingとAPNSを統合して、リロードやポーリングのいらないリアクティブな検索機能を作りました。ごくおおざっぱに言うと、AngularJSのデータバインディングがサーバー上のデータストアとも連携する感じです。詳しくはこのスライドにも書いてあるのでご覧くださいー。

World Wide Maze: Real-time Gaming with Node.js + WebSocket

Chrome ExperimentsのWorld Wide Mazeの開発でCompute Engineまわりのお手伝いをしてたので、Futurekさんが設計されたCompute Engine上のWebSocketサーバー（Node.js/Socket.io）とApp Engineの連携などを解説。クライアント側についてはSaqooshaさんが詳細に解説されてます。端末やPCからのHTTPリクエストはApp Engineでまず受けて、リアルタイム通信に必要なWebSocket接続はCompute Engineに回す、という設計。リリース直後に国内外のメディアで紹介されたため予想外の負荷が集中したのですが、Futurekさんがきっちり負荷テスト等を実施してくれたおかげでWebSocket側もすんなりスケールアウトしてくれました。

Balancing Strong Consistency and Eventual Consistency with Google Cloud Datastore

Datastore（というか、多くのNoSQL）でいちばんのハマりポイントはeventual consistencyではないでしょうか。つまり、いまデータストアに追加した内容がすぐにはクエリに反映されない。Datastoreにはstrong consistencyとトランザクションを提供する機能があるので、それを使っていればeventual consistencyは発生しないのですが、使い方がそう単純ではないのとやはりスケーラビリティやパフォーマンスとのトレードオフになる。これまでの大手のお客様へのコンサルティング事例を通じてeventual consistencyに対処するノウハウもたまってきたので、Datastoreチームともディスカッションしながらベストプラクティスにまとめました。Datastoreでインデックスが古くなる点はこれまでも知られてましたが、値もまれに古いものが返ってくる、、っていうのはあまりきちんと説明されてないので要注意点です。

今、この続編となるペーパーを書いているところで、strong consistencyを提供するentity groupを使いつつも高いスループットを達成するデザインパターンを提案できる見込みです。来年頭に公開されると思いますので、ご期待くださいー。

そんなわけで、来年もこんな調子でGoogleクラウドのお仕事続けていきたいと思ってます。

FPGAエクストリーム・コンピューティング第4回が終わりました。

FPGAエクストリーム・コンピューティングの第4回はニフティで開催されました。今回はこんな内容：

• @yukitaketakeさん：GPU設計者から見たFPGA

GPU設計者の方がFPGAとGPUを比較するというとても貴重な発表でした。均質な浮動小数点演算を大量にこなすという用途においては、GPUの独擅場なのかなという印象です。開発コストも低いですし。JP MorganのFPGAによるHPC事例ではGPUとFPGAを比べた上で両者を併用しているそうですが、どういった点でその違いが現れるのかが知りたいところです。それを理解するには数学とハード両方を知る必要があるわけですが。。また、HPCではなくビッグデータ処理では非均質かつ整数中心の演算や、たくさんの同期を必要とする処理、I/O直結したい処理などが主体となるので、Netezza等がなぜGPUではなくFPGAを使っているのか？　という理由はこの辺りにあるのかな？　と想像してます。

• @marsee101さん：画像ボケ復元用ニューラルネットワークのハードウェア化

C言語によるソフトウェア実装をどのような過程を経てFPGAによるハードウェア実装にしていくかをわかりやすく解説されてて、こちらもとても濃い内容でした。やはりFPGAにとっては数値演算は重荷で、要件に応じてきめ細かにビット精度を落としてくプロセスが最適化のキモのようです。同じ点はJP Morgan事例でも指摘されてますね。しかしmarseeさんのようなエキスパートのスキルがあれば、ニューラルネットの重い演算も古くて安い（たぶん電力性能比も高い）FPGAボードに載せることができる、という見方ができるかと思います。

• たばたさん：Neon light compiler: 書き易い高位合成用言語の試作

高位合成言語を個人で作ってる人って、JavaRockのみよしさんかたばたさんくらいしかいなさそうですｗ たばたさんの指摘のとおり、ハードの人にとってCは高級言語でも、ソフトの人にすれば「なぜ今Cか」って思います。どうせなら、関数型言語やスクリプト言語、宣言型言語のおいしいところや、ハード開発のパラダイムにぴったりあうところ（並列性の表現とか）を持ってきた、真に高級と言える高位合成言語（Bluespecとかそうかもしれませんが高そうで使えない）があっていいと思います。Neon Lightはスクリプト言語の手軽さやプロトタイプOOPの生かしどころとか面白いですね。もうひとつ重要な点は、大手ベンダーではなく個人によるオープンソース開発として高位合成をやるってこと。大規模なASIC開発が難しくなりつつある今後、オープンソース・コミュニティ主導のハード活用や高位合成を使ったお手軽なFPGA開発が盛り上がってくることに期待したいです。

• @kazunori_279：Moving Computation to the Data

MapReduceアプライアンスやOpen Netezzaみたいなものが作れたらいいなあ〜という期待ですｗ

まとめなど

• YMORI805さんのtogetterまとめ（あざっす！）：第4回FPGAエクストリーム
• ust録画：part 1 と part 2

運営など

• 第2回からの繰越：18740円
• ビール＋ピザ代：52804円
• 今回集金：67500円
• 次回繰越：33436円

一人1500円はちょっと多かったようです。次回は1000円で！

今回は日曜日にも関わらず出勤いただきお一人で運営のお手伝いをいただいたニフティの岡田さん、いつもいつもありがとうございます！m(__)m

次回は２〜３月あたりを予定しています！

appengine ja night #26 が開催されました #gaeja

appengine ja night #26はGoogleオフィスでの開催でした。今回は日本に一時帰国している松尾さんがひさびさにajnに登場、同じくdeveloper program engineerのBrian Dorseyさんと二人でのセッションとなりました。

• Brian Dorseyさん：Compute Engine について

Google Compute Engine 担当 Developer Programs Engineer の Brian Dorsey が Compute Engine の最新情報をお伝えします。

• 松尾さん：VM-based backends （VM Runtime） について

VM-based backends という新しいタイプの App Engine Runtime は、今まで Google App Engine が持っていた制約のほとんどを取り除いてしまうすぐれものです。VM-based backends を使えばすべての Python module や Java library を使えるうえ、ネットワークに関しても制約がなくなり、なんと Google App Engine で Websockets を使うこともできます。 VM-based backends について、デモ、開発の動機などを含めてお話しします。

Brianのセッションでは、Google Compute Engineで利用可能なCPUのタイプやストレージのタイプ、それぞれの特性などが紹介されました。GCEは一般公開もされて次第にその実力がじわじわと理解されつつあるようで、例えば最近公開されたHadoop on Google Cloud Platformのページでは、GCE上で動いているMapRのHadoopによってMinutesSortやTeraSortの世界記録が更新されたことなどが紹介されています。

松尾さんのセッションでは、App Engineで提供予定（現在はTrusted Tester向けのみ）の新機能、VM-based Backends（仮称）について解説されました。これは簡単に言うとPaaSであるApp EngineとIaaSであるGCEをいいとこ取りしたサービスで、GCEインスタンスの管理をApp Engineにおまかせでき、かつApp Engineの豊富なAPIサービス群をGCEから利用できる、というもの。 これまでのバックエンド型インスタンスであるBackendsと同様の使い方ができるほか、、Linux上で動作する様々なアプリケーションをインストールして使うことも可能になる予定です。

今回はBeerTalkはなしで、皆でビールやピザをいただきながらたっぷり歓談してました。

皆さんのまとめ

どちらも資料は今のところ公開されていないのですが、@thorikiri さんのとても詳しいレポートappengine ja night #26 #ajn26 に行ってきましたを見ればおおまかな内容は把握できると思います。@sinmetalさんによるTogetterまとめappengine ja night 26も合わせてご覧ください。

今回は準備面で松尾さんにすっかりお願いしてしまいました。ありがとうございます！　セッション参加してくれたBrian、そして運営面でいつもお世話になっている西村さん、横田さん、ありがとうございましたm(__)m

JP Morgan Chaseがデリバティブ専用スパコンをFPGAで作った話 #fpgax

金融系でFPGAというとHFTへの応用が知られてるけど、この事例はリアルタイムトレードの話ではない。金融業務で必要とされるバッチ処理やHPC（High Performance Computing）でもFPGAが本格的に使われ始めてるという話だ。

元ネタは、2011年にJP Morgan Chaseの人がスタンフォード大学で講演した内容。このビデオを見ていたらとっっっても面白かったので、 #fpgax 第3回で使う資料として要点を訳し、俺のコメントや補足を追加してみた。

http://www.youtube.com/watch?v=9NqX1ETADn0 （スライドはこちら）

なお、FPGAも金融も素人なので、勘違いや誤訳があるかもしれない。FPGAとは何かよく知らない人はこちらをどうぞ。

リーマン・ショック対策のスパコン開発

JP Morgan Chaseは、社債やモーゲージ（不動産を担保にした証券）など、膨大な量の有価証券を保有している。それも、例えばひとつの社債をリスクの高い部分と低い部分に切り離して、それをいくつか集めて新しい証券を作ったりするCDOだのCDSだのといった複雑なデリバティブは、いったいそれが現時点でどんなリスクを抱えているのか、刻々と変化する市場動向に応じてつねに再計算しておく必要がある。リーマン・ショックでもCDSのリスクの不透明さが市場を混乱させた要因となっていた。

これらのデリバティブは、リスクごとに切り分けられた「トランシェ」という単位で評価される。こんな式を使うらしい：

...俺にはよく分からないけど、まぁとにかく畳み込みのFFTが計算の中心とのこと。数学が得意な人はこのあたりを読むとわかるのだろう。

JP Morgan Chaseではこれまで、同社が保有するすべてのトランシェに対してこのリスク計算を実施するためにC++で書いたコードと大量のサーバーを用いていたが、計算量が多いため一回あたり8時間ほど要していた。その間にも、自分が持っている証券のリスクがどんどん変化してるかもしれない。もっと速く正確に、もっときめ細かく計算して、リーマン・ショックのようなリスクの不透明性による混乱の再発を避けたい。そこで同社は、Maxeler Technologiesと共同でリスク計算専用のFPGAサーバークラスタを作ることにした、といういきさつである。

ちなみにMaxelerは、SIMDやMIMDなどのコンピュータアーキテクチャの分類で有名なスタンフォード大学のFlynn教授が設立した会社で、金融分野や石油探索分野でのFPGA導入におけるリーディングベンダーだ。このプロジェクトにおけるFPGAサーバーの設計を担当したほか、その上で動くFPGA用OSやコンパイラ、解析ツールなどのコアなテクノロジーをひと通り提供している。プロジェクトへの貢献の大きさとその成功を受けて、JP Morganは後にMaxelerに資本参加までしている。

CPU vs. FPGA

ではなぜ普通のCPUを使わずにFPGAを使ったのか？

• 広いCPUチップの上でも、（リスク計算に必要とされる）数値演算を実行している部分はとても小さい。また、我々はとても深い演算パイプラインを実装したいのだが、CPUにはその能力がない。

たしかにCPUってダイの大半がキャッシュやら制御用に使われてて、実際の演算器に使われてるシリコンの面積ってとても小さい。CPUは実はあんまり計算してないのだ。その少ない演算器に大量の演算をさせるため、とっかえひっかえ高速にデータやプログラムを流しこむ必要があるから、データキャッシュや命令キャッシュにものすごく場所を取られる。

• CPUに比べ、FPGAの動作クロックはあまり速くない。ではなぜFPGAを選ぶのか。それは、FPGAを使うことで数100段といった非常に深い演算パイプラインと、とても細かい粒度での並列化によるストリーム・コンピューティングを実現できるからだ。これにより、CPUに比べ数100倍のスループットを得られるケースもある。

例えば下図のように、x^2 + xっていう式だけをひたすら大量に並列処理するためにたくさん演算器並べたい、と思っても、汎用性が求められるCPUにはそれができない。また、CPUは逐次処理は得意だけど、並列性はあまり高くない。せいぜい8コアとか16コアといった程度で、かつプロセスやスレッドといった粒度の大きい単位での並列性しか得られない。もしCPUで「256個のxについてx^2 + xを並列に計算する」としたら、いちいち256個のスレッド作って、各スレッド間でコンテキストスイッチするのに数10μSかかって、、なんて感じで並列化のオーバーヘッドが鬼のように高くなるので、普通はそんなことせずにループを書くしかない。

FPGAでは、上図のように自分の好きな演算器を書いて横に256個並べられる。演算のひとつひとつをすべて並列化できるという粒度の細かさだ。かつ、コンテキストスイッチやOSのオーバーヘッドがまったくないので、1クロック、つまり数ns〜数10nsですべての計算が終わってる。だから「数100倍のスループット」という表現も決して大げさじゃないのだ。

ストリーム・コンピューティング？

JP Morganの人はFPGA化のもうひとつのメリットとして「ストリーム・コンピューティング」という言葉を使っている。ちなみに、StormやDSMSやCEPなどのビッグデータ界隈でいうストリームと、HPCやGPU/FPGAまわりで言うストリームは、似てるけどちょっと時間／空間のスケールが違う。どちらも大量のデータを「いったんすべて貯めこんでから処理する」のではなく「流れてくるその場でどんどん処理」してスループットを上げるという手法だが、前者はミドルウェアやクラスタ規模の話で、後者はシステム内部の規模の話。

このFPGAによるストリーム・コンピューティングのメリットについては、Hisa Andoさんが書いたMaxelerの石油探査事例のFPGA技術解説で解説されている。

海底油田の探査では、母船からパルス音を発生させ、海底地層からの反射音を曳航する3万個ものマイクで捉える。船を移動させながらこれを10秒ごとに繰り返すので、結果として、1日にテラバイト級のデータが採取されるという。この反射波のデータを使って、得られた反射波と一致するような海底地層を計算で求める。この計算は膨大で、数1000枚のブレードサーバを使っても何日もかかる。Flynn教授は、このような計算をMonolithic Computationと呼んでいる。

拡大画像 001 | 【レポート】スタンフォード大学Flynn教授の特別講義 - FPGAで超高速計算…… | マイナビニュース via kwout

通常のプロセサでは、中間結果をメモリに書き出して、次の処理で読み込むというような処理があり、それに伴ってキャッシュミスなども発生する。しかし、FPGAベースのストリーム処理の場合は、原則、データの受け渡しは直接次の処理ステージに渡され、メモリを経由しない。タイミングを合わせるためにバッファ機能が必要になる場合もあるが、これはFPGAの内部メモリで対応する。このようにFPGA内でデータを受け渡してしまうので、キャッシュミスも発生しない。

拡大画像 003 | 【レポート】スタンフォード大学Flynn教授の特別講義 - FPGAで超高速計算…… | マイナビニュース via kwout

つまり、できるだけキャッシュメモリやメインメモリを介さずに、小さなバッファを挟んで演算器同士でデータをバケツリレーしてクロックごとに受け渡すことで、従来のCPUのようなノイマン型コンピュータにありがちなメモリボトルネックがなくなる、というメリットだ。汎用のCPUでは特定のアプリケーションを前提として演算器間をストリームでつないでおくことはできないが、アプリごとに回路を書き換えできるFPGAなら自由に設計できる。

ただ一方で、ストリーム化があまり効かない用途についてはこの手法の有効性は低くなる。例えば演算器間のバッファで収まらない大きな中間データが生じる用途では、それをメインメモリにまで持っていく必要がありそこがボトルネックになってしまう。はたしてFPGAはストリーム化や大規模並列化に向いたアプリケーションにのみ有効なのか？　それ以外のアプリケーションではCPUに対して勝ち目はあるのか？　については議論が必要だろう。

また、ストリーム・コンピューティングや大規模並列演算といえばGPUの得意分野だ。なぜJP MorganはGPUを使わずにFPGAを使ったのだろうか。

• GPUとの比較：GPUとFPGAそれぞれを用いて試作し、比較した。その結果、どちらにも向き不向きがあることが明らかになった。例えば、トランシェ評価にはFPGAが適し、デフォルト／サバイバルカーブの生成にはGPUが向いている。前者についてはFPGAの方が15倍ほど高速であったため、FPGAを採用した。

GPUはあらかじめアーキテクチャが固定されているため、それにうまくハマる演算ならFPGAより速いし集積度も高い。一方で、HPC分野ではGPUにうまくはまらない用途も少なくないと聞くし、そうした用途ではゼロから自由にアーキを設計できるFPGAに軍配が上がる。既成の高品質なクルマを買うか、ちょっと高いけどクルマの工場を買って自分好みのクルマを作るか、の選択のようなものである。一概にどっちが優れているとは言い難いので、CPU、GPU、FPGAを適材適所で両方使い分けられるのがベストだろう。ちなみにJP Morganでは、GPUとFPGAそれぞれのサーバー・クラスタを併用している。

データセンターの効率を左右する「電力性能比」

そしてJP MorganがFPGAを選んだ決定的な要因のひとつは、消費電力の低さだ。

• JP Morganが運用する計算サーバーにおいて最も重要な要件の一つが電力消費。データセンターのスペースが足りなくなることはないが、電源容量はつねに不足しがち。そのため、サーバーを選択する上では電力性能比がとても重要な指標となる。

FPGAは動作周波数が数100MHzとCPUより一桁くらい低く、そのおかげで消費電力もぐんと少ない。サーバー数台規模ならあまり気にするほどの差ではないけど、それがデータセンター規模にまで積み重なると格段の差異が生じる。そして、一般的なデータセンターの電力容量は数MW程度が上限。どうも変電設備の制約でそれ以上は上げにくいらしい。その限られた電力でどれだけの情報処理をこなせるかは、JP Morganに限らずクラウド規模のデータセンターを運用する企業にとって共通の課題だ。例えば、HP LabsとFacebookとARMが数か月前に発表したmemcachedのFPGA実装に関する論文でも、FPGAの電力性能比の高さが重要なモチベーションとなっている。

FPGAでつくったスパコンで134倍速くなった

では、FPGAでつくったスパコンとは、具体的にはどのようなハードウェア構成で、どの程度のパフォーマンスを達成できたのだろうか。

• FPGA2個と48GBメモリを搭載したFPGAサーバーを40ノード並べた構成のシステムを構築。この規模になるとスーパーコンピューターと言っていいだろう。
• これまで全社規模のポートフォリオ評価に8時間ほどかかっていたが、40ノードのFPGAサーバーによって238秒にまで短縮された。CPU単体とFPGA単体で比べると134倍の高速化となった。
• CPU上では計算量的に実施できなかった複雑な組み合わせのシナリオも計算可能になり、ポートフォリオのリスクについてより深い洞察が得られるようになった。

8時間から4分へ。FPGA速っ。というか、従来のソフトウェア実装ではCPUやOSのボトルネックがそれくらい大きかったということでもある。

C++コードからFPGAへ落とすプロセス

この事例のとても面白いところは、JP Morganがどのようなプロセスを経て既存のリスク計算処理をFPGA化していったのか、苦労話も含めて紹介されている点だ。

• 元のC++コードの解析に始まり、コードの変換、カーネルへの分割、そしてFPGAでの実装、この４つのプロセスを実施し、その結果を踏まえて何度かのイテレーションを実施する。このFPGA化は通常３か月程度で完了する。

最初は既存コードの解析から始まる。従来のシステムにおけるトランシェのリスク評価は、おおざっぱには以下のようなC++コードで計算されていた。

このMaxelerのツールMaxPartonを利用して、既存のC++コードを分析する。

• コードのコントロールフローやデータフロー、依存関係を解析、および実行時間とメモリ消費のプロファイリングを実施。これにより、コードのどの部分がホットスポットなのか、それらがデータを移動してるのか計算してるのか等を明らかにする。

この解析の結果、FPGAに落とすべき「重い部分」が洗い出される。

• CDOトランシェの評価アルゴリズムにおいて重いのは２つの演算ループである。1) コピュラを用いたconditional survival probabilitiesの算出、2) 畳み込みを用いたprobability of loss distributionの算出。
• クオンツが書いた元のC++コードはオブジェクトやテンプレートを多用した複雑なものだが、C++のこれらの機能の多用も、CPU上での演算が遅い原因の一つであった。
• このアルゴリズムに対してMaxPartonによる分析を実施した結果、処理時間の23%がコピュラの計算に、75%が畳み込みに費やされていることが分かった。

コピュラ（copula）ってよく分からないけど、統計で使う関数らしい。このコピュラと畳み込みのFFTが計算の大半を占めている。

ちなみにここで出てくるクオンツとは、金融工学を駆使してデリバティブを設計したり、そのあたりを自分でC++で書いたりできるrocket scientistな人たちだ。給料良さそうだなーっ。。

JP Morganのクオンツが書くC++コードはかなりOOPっぽいコードらしく、そのオーバーヘッドも大きいと指摘している。まあ、コピュラだの複雑な統計的概念がいっぱい出てくるコードなら、どんどん抽象化したくなるよね。上に示したC++コードは、もとの複雑なOOP的コードをCっぽく平らに書きなおしたものだ。

時間軸から空間軸への展開

以上のような分析によって明らかになった重い処理、例えば畳み込み積分の部分などを中心にFPGAで設計していく。

• convoluter（畳み込み積分器）の設計。ここで重要な点は、ループの中で時間軸に並べられていた演算を、空間軸（つまりFPGA上に並べた多数の演算器）に展開している点。
• クオンツは普通、「この時点から始まってこの時点で終わる」といった時間軸にそってコードを書きがちだが、それを空間の並列性に置き換えて設計するという発想の転換に慣れさせるのが難しかった。

時間軸から空間軸への展開、これがFPGAの大きなパラダイム・シフトのひとつで、ソフトウェア・プログラマーにはこれまでなかった発想が求められる。簡単に言うと、ループを回さず演算器を並べろってことだ。GPUのプログラミングもこれに近いけど、自分の好きなように演算器を設計してどんどん深いパイプラインを組んだりストリームを構成できるという自由度の高さが大きく異なる。

「カーネル」間をストリームでつないでいく

こうしてハードウェアとして設計されたコピュラやconvoluterなどの演算器は、FPGA上では「カーネル」と呼ばれる単位で配置され、それらのカーネル間をつなぐデータストリームをソフトウェアで記述する。

• C++で記述された以前の計算モデルを元に、FPGA上にCopulaやConvolutor等の「カーネル」を構成。
• FPGA上のカーネルに流すデータストリームを管理するAPIをMaxelerOS上に作成。

カーネル間をつなぐデータストリームの帯域やどのメモリを使うのかといった判断もこの時点で行う。

• 分析で明らかになった必要なデータの量と帯域に合わせて、システムのリソースを割り当てる。数MB程度の量のデータならFPGAのBRAMを使い、24GB以下ならDDRメモリ、それ以上ならホストメモリ。また、数TB/sの帯域が必要ならBRAM、数10GB/sならDDR、数GB/sならPCIeバス、など。
• この結果を元に、個々の演算をCPUに置くのかFPGAに置くのか決定される。
• FPGA上に実装した場合の演算精度、レイテンシ、およびスループットも、実装前の分析段階で見積もる。

すると、例えば上述のC++コードは以下のようなJavaコードに置き換えられる。

ループを回して演算してたコードを、FPGA上の演算器の間をつなぐストリームを定義するコードに置き換えていくわけだ。また、「このあたりは帯域たっぷりほしいからPCIeバスを4本使っとこう」みたいなハード設計までJavaで書けちゃうのがたいへん愉快である。このあたりはMaxelerのMaxCompilerによる高位合成（高級言語からデジタル回路を生成する技術）の能力に依るところが大きい。

パイプライン化でパフォーマンスを追い込む

そして開発フェーズの後半では、パフォーマンスの追い込みに入る。個々のカーネルをできるだけ深くパイプライン化していくことで、スループットを引き上げていく作業だ。

• カーネルの基本設計がまとまったら、続いては各カーネルについて100段におよぶ深いパイプラインをFPGA上で構成する。パイプライン化によって、個々の演算のレイテンシは伸びるが、スループットは大幅に伸びる。
• 最終的には、コピュラおよびconvoluterのカーネルを1つのFPGAチップ上で100段のパイプラインで構成。

この段階になるとかなりハードウェア設計の職人技が要求される。回路上のどの部分がクリティカル・パスになっているかをナノセカンド単位で追っていったり、その部分をパイプラインに分解してクロック周波数を詰めていったり、といった技能が必要なので、さすがにこれはハードウェア・エンジニアじゃないと難しいはず。

浮動小数点演算の最適化

GPUと比べたFPGAの弱点として時折指摘されるのが浮動小数点演算だ。FPGA上でdoubleを扱う演算器を記述すると場所を取るしクロック数もたくさん使ってしまうので、なるべくならdoubleを使わずに済ませたい。しかし金融のリスク計算に使うとなると計算精度を慎重に考慮する必要がある。

• MaxCompilerでは、IEEE754準拠の単精度・倍精度演算をサポートする。また要件に合わせて指数部と仮数部の精度をビットストリームごとに指定することも可能。すべての演算に倍精度が必要なわけではないので、この機能は大変便利。精度を落とすほどパフォーマンスが向上しFPGA上のリソース消費も抑えられる。最大で20%の速度向上が可能で、精度がある程度低くてもスピードを優先するようなビットストリームに用いている。
• 元のC++コードでは多くの変数がdoubleで定義されているが、倍精度が不要な部分については精度を落としていく。この点をクオンツに納得させるのがとても面倒。クオンツにはすべてを倍精度で計算しないと気が済まない人も多い。一方で、「最終的はセント単位で正しい結果をすばやく出せればいいのだ」という考えのエンジニアも多い。この両者のせめぎあいになる。
• 重要な点は、どの程度の時間をかければどの程度の精度が得られるかのトレードオフを知ること。

要件的なトレードオフだけではなく、クオンツとの文化的衝突が難しい点であったという話がとても面白い。また、さほど気にせずdoubleを富豪的に使えるソフトウェア実装とは異なり、ナノセカンド単位での速度向上が焦点となるFPGA開発ではそのコストと精度のトレードオフを意識する必要が生じる。

FPGA開発はまだ難しい

最後に、FPGA開発の課題と今後についてまとめ。

• FPGA上での同様の設計や最適化を行った研究等は存在していたが、業界でも最大規模の取引を扱う商用サービスのプロダクション環境でこれを実現するのは容易なことではなかった。

大規模なプロダクション環境でのFPGAの投入はJP Morganにとって苦労も多かったらしい。また、CPUやGPUによる開発とはまったく異なるスキルと経験が要求されるため、自社単独での開発は難しく、JP Morganの事例でもMaxelerのツールやエンジニアの能力に大きく依存している様子が伺える。Hisa Andoさんの前述の記事でも、FPGA開発のコストについて以下のように指摘されてる。

このような最適化されたストリーム処理をFPGAに実装するのは簡単ではない。Maxelerでは、通常、2人の専門家がペアで仕事をし、FPGA実装のプロトタイプを作ってデモを行うまでに3カ月、その後、納入する製品レベルに仕上げるのにさらに3カ月程度かかり、全体では1人年程度を必要とするという。＜中略＞このようにFPGAの開発には1人年程度の工数がかかるので、コア処理部がストリーム的に処理でき、かつ、年間を通じて処理時間の長いMonolithicな巨大計算でないとペイしないが、このような条件を満足するケースでは汎用CPUを使用するのに比べて大幅な高速化と低電力化を実現できる手法である。

つまり現状では、JP Morganのように大規模なHPC事例でないとMaxelerのエンジニアを雇ったりツールを買ったりするようなコストはペイしなさそうである。

CPU＋FPGAのSoCでいろいろ変わる

とはいえ、この状況はここ2〜3年で大きく変わると思う。FPGAのコストダウンと高集積化はかなりの勢いで進んでいて、一般的なCPUやサーバーにも普通にFPGAが載りつつあり、FPGA導入のハードルがぐんと低くなってきたからだ。例えばIBMはPOWER8で外部FPGAとCPUとのキャッシュ連携を可能にする機能を載せてきているし、HPも次世代サーバーのHP MoonshotでFPGAカードをサポートする。さらには、ARMコアとFPGAをひとつのチップに混載した、いわゆるSoC（System On Chip）であるXilinx ZynqやAltera SoCを搭載したLinux組み込みボードが最近になっていろいろ出回り始めていて、安いものは2万円ほどで買えるようになった。こうしたSoCの登場で、ソフトウェア・エンジニアにとっては一段とFPGA導入がやりやすくなる。

Zynqでは、ARMとFPGA間でL2キャッシュを共有してて、GPUと同じようにFPGAをARMのコプロセッサとして使える。ARM上のLinuxで動くアプリからFPGAに載せた機能をAPIコールで呼び出せる。よって、すべての機能をFPGA上でゼロから開発するのではなく、既存のソフトウェアの一部分のみFPGA化してアクセラレーションする、といった段階的な導入が可能だ。Xilinxが出しているサンプルには、OpenCVアプリの画像処理部分をFPGA化してケタ違いに高速化というのもある。また画像処理やHPC応用に限らず、例えばZynqのFPGAはGbEにも直結できるから、最近の学会発表で流行ってるFPGAで実装した鬼速のmemcachedのようなネットワークアプリや大規模データ処理アプリも、以前に比べて実装しやすいはずだ。いつかはやってみたい！

あとはMaxelerのMaxCompiler（たぶんすごく高い）やXilinxのVivado HLS（50万円）のような高機能の高位合成ツールが安く、できれば無償で提供されれば、ソフトウェア・エンジニアにとってのFPGA開発のハードルはさらに低くなり、応用範囲も広がるはず。そんな日が来ることを期待しつつ、いまのうちにFPGAの練習をしておかねば、、と思ったのであった。

FPGAエクストリーム・コンピューティング第3回が終わりました #fpgax

FPGAエクストリーム・コンピューティング第3回は大阪で開催でした。ハードウェアは西日本が熱いのか、いつも大阪や京都や福岡から来ていただいてる方が多く、これは大阪でやらねば！　と思いまして。。大阪市と共催で、大阪イノベーションハブの会場をお借りして開催しました。この会場のあるグランフロントという大阪駅となりの新しいショッピングモール＋オフィス施設がでかすぎて、会場にたどり着くまで相当迷いました。。グランフロントなめてました。

今回の内容

• 鈴木圭介さん：FPGAのUIにAndroidを使う

Android上で作ったUIからFPGA上で組んだ回路と通信する方法の解説。私も前に音源作ったときはUIをFPGAで実装するのが面倒で、ChromeのJSで作ったUIとFPGAをシリアル通信で連携させたりしてました。これはUARTを使ったごく単純なしくみでしたが、鈴木さんの方法はFPGA上でAvalonバスを用意して、それとAndroid間をFIFOで結ぶという本格的なもの。なるほど〜FPGA使いの方はこんなふうに設計するのか〜と感心。Alteraの開発ツールQsysの使い所や、AvalonやAXIなどのバスはどんな基準で選べばよいのか？　など、とても参考になりました。

• 栗元憲一さん：mjpeg stream viewer on FPGA（資料）

こちらも、最初にソフトウェアで実装したアルゴリズムを段階的にハードウェアに落としていくところがとても面白い。LEONプロセッサのIPやAHBバスの位置づけや長所短所、例えばGPLで公開されるので無償で使えるし、欧州の宇宙開発で使われてる実績があるから無償といっても高品質、といった背景が理解できて嬉しい内容でした。栗元さんも、私と同じく、リアルタイムストリーム処理へのFPGAの適用可能性にたいへん興味があるようで、懇親会では栗元さん・きしださんと熱く語り合いました。。こんな話題を肴においしいお酒が飲めるなんてとても幸せですｗ

• 夏谷実さん：高速シリアル通信を支える技術（資料）

いまどきの高速シリアル・インタフェースの中身がどんな仕組みで実装されてるのかを解説。PCIeやUSB3.0、SATAといったインタフェースの歴史的背景や、その中で用いられてるテクニック（送信側と受信側のクロックがどうしてもズレてしまうので、その補正とか）が、へぇ〜へぇ〜と思いました。

• きしだなおきさん：一般プログラマはどのようにFPGAを使うか

CPUやGPU、ASICなど他の技術とFPGAのそれぞれの長所や短所を比較して、使い分けを論じたセッション。並列度は高いけどクロックが遅く集積度も低いFPGAはCPUやGPUに比べてどんな使い道が有効なのか？　きしださんと皆さんでディスカッションしてました。この話題は奥が深い。。

• 三好健文さん：JavaRockでBlokusDuoプレーヤを作る話（資料）

三好さんが作っているオープンソースの高位合成ツール、JavaRockでパズルゲームのAIを実装するという、これまた濃い内容のセッションでした。たしかにこの例のような複雑な条件分岐を伴うロジックをHDLで書く気はしないですね。。そう考えると、こうした応用をお金をかけずに実装する方法としてはJavaRock最強かも。無償で使える高位合成ツールが広まれば、とくに検証やテストベッド作成のコストが低くなりそう。

• 吉田幹さん：FPGAでデータフローマシンっぽいもんを作ったで！！（資料）

吉田さんはFPGA歴2週間でいきなりめちゃくちゃかっこいいマシンを作ってきました（デモのビデオ）。データフローマシンやで！　といっても会場の反応の薄さが逆にエクストリーム感を際立たせてましたｗｗまじめな話、あまり皆がピンと来ないくらい既存のノイマン型とはかけ離れたパラダイムの計算モデルをさくっと実装できちゃうのがFPGAのすばらしいところ。もちろんそれが対CPUでどれだけ性能がよいか？　実案件での有効性は？　は未知数ですが、しかしまずは誰得なホビーとしてとても楽しいです。

データフローモデルのメリットは、コントロールフロー（＝マルチスレッド）のように難しい排他やデバッグをせずとも大規模かつ粒度の細かな並列処理を（Excelの式みたいに）簡単に書けるところ。GPUやSIMD命令でも大規模で細粒度の並列処理ができるけど、それらは結局SIMDなので、ひとつのコードで大量のデータを並列処理する用途向け。一方で、データフローはもっとMIMD的な使い方、たくさんの異なるコードがそれぞれ並列にデータ処理する用途に使える。おおざっぱには、アクターモデルやErlangで大量のサーバートラフィックを並列処理する感覚に近いかも。シリコンの並列演算のポテンシャルをがっつり引き出せる可能性のあるパラダイムと思います。

まとめなど

• 栗元さんのブログ記事：第３回FPGA エクストリーム・コンピューティング
• Ustreamのビデオ録画：part 1とpart 2
• Togetterまとめ：FPGAエクストリーム・コンピューティング第3回

運営など

いつもながら時間管理の甘さにより、後半の講演者の皆さんには大変ご迷惑をおかけしました。。m(__)m ついつい議論が熱くなりやすい勉強会なので、次回はもっと余裕をもたせた構成にしたいです！

今回の大阪での開催では、会場の手配から運営、懇親会の手配まで、@keiji_ariyama さんに大変お世話になりました。ありがとうございます！！　また、会場をご提供いただいた大阪市の皆様にもお礼を申し上げます。

次回は秋ごろに東京で、その後は福岡で！って話が出てましたねｗ

appengine ja night #25 を開催しました

appengine ja night #25、今回はGoogleでの開催でした。Atmosphere on Tourに合わせてApp Engineの開発総責任者Peter Magnussonが東京に来てたので、ajnもそれに合わせて7/16に開催、Peterにセッションを担当してもらいました。今回はこんな内容：

• 「App Engine の新機能の話 & Peter と話そう！」by Peter Magnusson, Engineering Director, Google
• 「Android アプリのガチ開発者が Mobile Backend Starter を使ってみた」by あんざいゆき（@yanzm）さん
  • スライド
• 「Google App Engine for PHP」by @vierjpさん
  • スライド
• 「Google App Engine と Google Apps API」by @shin1ogawaさん
  • スライド

Peterがビール飲みながら歓談したいというので今回はめずらしく最初に懇談会を設けてみたのですが、あんまりぱっとしませんでしたね...USのmeetupはたいていセッション始まる前にみんなビール飲んで盛り上がってるんですけどね！

PeterのセッションはModulesやDedicated Memcacheなど、つい先日リリースされたApp Engine 1.8.2の新機能を先取りして紹介する内容でした。さらには世界初公開の○○○のデモもあって、なかなか盛りだくさんでした。あのデモは私も初めて見たので、おぉ〜っとびっくり。Peterいろいろおみやげthanks!

一方、あんざいさんのMBSセッションは、なんというかかなり俺得な内容でしたｗｗ MBSのライブラリ構成や設計の改善点を指摘していただいてて、さらに実際にライブラリプロジェクトやGCMコードを改善したバージョンもシェアしてくれてます。うれしい( ；∀；) 本家MBSの方に随時反映させていきたいと思ってます。続いてのヤマサキ（@vierjp）さんのPHPセッション、こちらも現時点ではおそらくApp Engine for PHPの現状についてもっとも詳しく解説した資料と思われます。WordPressやCakePHP が動くんですね〜。。最後のshin1さんのセッションも個人的に勉強になりました。Cloud Consoleってどんどん機能追加されてて、私もよく把握できてないんです。。App Engineのapp idとAPIs ConsoleのProject id、そしてAppsとの連携状況が分かりやすい。

まとめ

thorikiriさん、いつもまとめありがとうございますーっ。

• appengine ja night #25 Togetterまとめ
• appengine ja night #25 #ajn25 に行ってきました

運営など

運営をお手伝いいただきました、グーグルのふみさん、西村さん、そして横田さんに感謝です！次回ajnはどうやらpycon apac 2013のあたりに松尾さんが帰ってきてやるらしいですぜ！