（2/5）

  FPGA（Field Programmable Gate Array）は、その柔軟性によりいくつかのタイプに分類できるが、このうち論理機能と配線情報を記憶するのに SRAMを用いる方式は、通常の CMOSプロセスを利用できることから 1990年代以降に大発展を遂げ、その速度はいささかも衰えを見せていない。Xilinx社は、同社の初期の代表的な製品である XC4000シリーズを発売した 1991年を SRAM型の構成が確定した年と位置付けており、2005年までに論理回路数で 200倍、速度は 40倍、低消費電力化で 50倍、低コスト化で 500倍を達成したとしている^[3]。

  SRAM型 FPGAの発展と共に、これらの FPGAを多数接続して、大規模演算を高速化するシステムが登場した。初期のシステムで有名なのは 1991年、92年に米国計算機科学センター（旧SRA）で開発された Splash,Splash2^[4] である。このシステムは、Xilinx社の XC4010を 16個直線状に接続し、さらにクロスバスイッチで相互接続して構成したクラスタ 3つをインタフェースボードに接続した構成を持っている。この構成は、データをパイプライン的に流しながら計算していくアルゴリズムに特化しており、このため、主としてシストリックアルゴリズムによるパターンマッチングや画像処理に用いられた。Splashは DNA塩基配列間のマッチングで当時の代表的スーパーコンピュータ CRAX-2の 330倍の性能を発揮して注目された。日本でも神戸大学の RM I-IV^[5] を代表とする実験機が各地で開発され、NTTでは、通信制御用に ATTRACTORなどの大規模システムが開発された。1999年には三菱電機から商用大型機 RASH^[6] が発売された。RASHは、Altera社 FLEX10K100Aを 8チップ 1ボードに搭載し、それぞれを格子状に直結配線し、さらにバスによって SRAMと接続した構造を持つ。FPGA複数に大規模な対象回路を搭載して、SRAMを共有することが可能であり、DESの秘密鍵探索処理や合成開口レーダの画像生成処理に利用された。

  90年代に開発された FPGAを複数用いた大規模システムは、商用化された例はあるものの、いずれも少数生産の実験機レベルであり、用途もパターンマッチング、画像処理、秘密鍵探索処理など、通常のスーパーコンピュータが得意としないアプリケーションに限定されていた。

  2000年代に入り、FPGAはプロトタイピングおよびハイパフォーマンス処理用のハイエンドの製品（Xilinx社の Virtex II,IV,V, Altera社の Stratix-II,III）と組み込み用のローエンドの製品（Xilinx社の SPARTAN 2/3, Altera社の Cyclone-II/III）に分化が進んだ。さらに、Xilinx社は、Virtex IVで論理回路を重視した LX, 演算機能を重視した EX, ハイパフォーマンスリンクと CPUを内蔵してネットワークコントローラを意識した SXの 3シリーズを設け、さらに細かく分けた応用分野に特化した製品を市場に投入した。このハイエンド製品を利用することでハイパフォーマンス処理への可能性はさらに広がった。

  CRAY社は、AMD Opteron 2 Nodeおよび Xilinx社 Virtex II Proを強力なスイッチで接続した構成のボードを多数、高速ネットワーク Rapid Arrayにより結合したシステム CRAY-XD1を開発した。このシステムはクラスタ型のコンピュータの各ノードに FPGAが付いていて特定の演算を加速できる構成であり、FPGAに処理を分散して交通シミュレーション^[9] や画像処理を行う事例が報告されている。また、SGI社の RASC^[10] は、NUMA型マルチプロセッサの各ノードに Virtexを接続したシステムで、Virtexから直接分散共有メモリがアクセスできる。これらのシステムは、汎用のスーパコンピュータの各ノードに FPGAを持ち、処理の一部を分散して高速化を行うもので、数値演算自体は、それぞれのノードで行われ、FPGAはパターンマッチングなど特殊な処理の一部をオフロードする目的で使われている。このようなホストPC と FPGAとの接続をより密にするため、Xilinx社は Intel FSB（Front-Side Bus）に直結する Virtex-5のボードを開発している^[3]。

  これに対して、最近のハイエンド製品を利用して、浮動小数点演算自体を FPGAにより実行させるシステムが開発され始めている。PROGRAPE-3^[7] は、天体を対象とする粒子系シミュレーションを目的として開発され、1ボードに Virtex IIを 4個+接続用 1個を搭載し、これらを多数接続することが可能である。PROGRAPE-3は、浮動小数点演算パイプラインを用いて粒子間の相互作用の演算を専用に実行する。東北大のRAPLAS^[8] もレイトレーシング用に浮動小数点演算を FPGAにより高速化しており、後の章で紹介する我々の ReCSiPプロジェクトでも、細胞シミュレーション用の浮動小数演算を FPGAにより高速化している。Berkeley大学のBEE2^[11] は、Virtex II FPGAを 5個搭載したボードであり、ハイパフォーマンス用リコンフィギャラブルシステム用の汎用テストベッドとして様々な機関で利用されている。BEE2は、将来の大規模並列計算機システムのアーキテクチャを広く研究開発する RAMPプロジェクトで採用されている。このプロジェクトで開発された RAMP-Blueは、BEE2ボードを 8枚接続した大型システムで、FPGA中のソフトプロセッサでマルチプロセッサを構成すると共に、他の論理回路部分を用いてハイパフォーマンス処理を行うことができる。

  他にも、FPGA上で効率の良い浮動小数点演算回路を作る方法、これらを用いた数値演算への応用事例は、最近の FCCM, FPLなどの国際学会で多数発表されている。これら最近のリコンフィギャラブルシステムのハイパフォーマンス処理への応用は、12月11日から北九州国際会議場で開催される FPT2007において GeorgeWashington Univ. の Tarek El-Ghazawi教授によるチュートリアルでより詳しく紹介される予定である^[12]。ご興味のある方はぜひ参加されたい

  かつて FPGA上で浮動小数点演算を行った場合、CPU上の演算器や ASIC上の演算器に比べて 1桁-2桁遅いと言われた。この状況は、FPGA上に整数乗算器、積和演算器の専用回路が搭載されてから改善されたが、それでも FPGA上の浮動小数点演算器は、これらの専用回路とランダムロジックで実装されるため、動作速度の点で専用の浮動小数点演算回路に比べて不利なのは否めない。CPUの浮動小数点演算器が 2-4GHzの周波数で動作するのに対して、FPGA上で浮動小数点演算器を作るとどうしても 200MHz程度の動作周波数となる。もちろんソフトウェアにより動作する CPUの浮動小数点演算器に比べ、FPGA上では、メモリや他の浮動小数点演算器間でデータを直接やりとりすることができる利点はあるものの、やはり単体同士を比較すると数倍は遅いと考えられる。

  さらに、リコンフィギャラブルシステムは、ホストPC のアクセラレータとして用いるため、同程度の動作速度では要求を満足することができない。FPGA数個を用いたシステム上で、通常の PCの最低数倍の性能を実現する必要がある。ハイエンドの FPGAは一チップ数万円するため、上記の性能が実現できなければ、通常のPCや、PCを用いた安価なクラスタに対して性能価格比の点で優位に立つことができなくなり、リコンフィギャラブルシステムによる性能の加速は、現実的ではなくなる。

  そこで、以下の方法が採用されている。

• IEEE標準のフォーマットに準拠せず、その対象アプリケーションに適合した精度で仮数部と指数部を実現する。また、丸め処理を単純化する。RAPRAS、PROGRAPE,ReCSiP ではいずれもそれぞれ独自のフォーマットを用いている(1)。
  
  (1) ReCSiP における確率モデルシミュレーションでは IEEE標準をフルサポートしたがこのため性能はある程度犠牲にしている
  
  
• 演算パイプラインを細かく設定し、複数のパイプラインが並列に動作するように、演算処理を工夫する。

  このような工夫がうまくいけば、FPGA 1個から4個で PCの数倍から数十倍の性能を実現でき、アクセラレータとしての役割を果たすことができる。

  ちなみに、現在の整数演算器に代わって浮動小数点演算器をハードコアとして搭載した FPGAが発売される予定は今の所は存在しない。これは、開発費を賄うだけの販売量がハイパフォーマンスコンピューティングの市場では望めないこと、高速で動作可能な浮動小数点演算器を搭載したとしても、周辺回路の動作周波数はやはり 200MHz前後となることが予想され、大きな性能向上が見込めないこと。などが理由である。浮動小数点演算器を多数搭載したリコンフィギャラブルデバイスの商用化が望めるとすれば、FPGAの延長線上ではなく、ClearSpeed^[13] などの SIMDアクセラレータに演算器間接続に柔軟性を与えること、あるいは現在でも粗粒度構成要素を用いている動的リコンフィギャラブルプロセッサ^[15] に浮動小数点演算器を搭載することから始まるのではないかと予想される。

  現在のハイパフォーマンスコンピューティング用のリコンフィギャラブルシステムは、HDL（Hardware Description Language）で内部の回路を作り込んでいるのが普通である。これは、上記に述べたように、アクセラレータとして意味のある性能を出すためには、複数の浮動小数点演算器パイプライン間に効率良くデータを流してやらなければならないためである。しかし、この場合はユーザは既に出来上がったシステムのみを用いることになる。PROGRAPEにおける粒子シミュレーション、ReCSiPにおける細胞シミュレーション、RAPLASにおけるレイトレーシングなどがこれに当たり、ユーザによってはこれで十分な場合もある。しかし、このようなユーザであっても、いつプログラムの変更、拡張が必要になるかもしれない。そもそもユーザによってまったく手を入れることのできないシステムは、リコンフィギャラブルシステムの利点の一つである柔軟性を殺してしまうことになる。

  ハードウェアに詳しくないユーザが、簡単にプログラミングする方法がない、という点がリコンフィギャラブルシステムをハイパフォーマンス分野で用いる場合の大きな足かせになっている。これに対してはいくつかの方法が試されている。まず、分野を限定すれば、エンドユーザにプログラムの自由を与える方法をサポートすることができる。我々の ReCSiPプロジェクトでは、後に紹介するようにSDML という反応式記述言語からハードウェアを吐き出すことのできるシステムを構築している。PROGRAPEはアセンブラに似た形式で演算を記述することで、粒子シミュレーションを越えた科学技術計算用の回路を生成できるシステムを提案している^[14]。

  より汎用的な方法としては、マルチメディア処理などでは既に一般的になっているC レベル記述を用いる方法が考えられ、既に Bach-C^[19] などでは浮動小数点演算器を含む回路のC レベル記述から自動生成することができる。現在の所、これらの言語処理系は、機能合成能力が低く、FPGA上で性能を出すための並列化と一定のFPGA 規模に収めるための逐次化は、完全にプログラマがコントロールする必要がある。このため、問題の記述は HDLよりも容易であっても、一般のプログラマにとっては依然として負担が大きい。Cyber^[20] など、ASIC設計用に高度の機能合成能力を持つツールが、FPGA のハイパフォーマンスコンピューティング用にチューンアップしてくれれば、プログラマの負担は減らせる可能性があり、このことは現在でも技術的には不可能ではない。しかし、ハイパフォーマンスコンピューティングにおけるユーザプログラムの市場規模の問題で、現在のツール作成者がこの点に取り組んでくれるかどうかは疑問である。

  もう一つの方法は、並列計算機用の自動並列化コンパイラ、MPIなどの通信ライブラリ、OpenMPなどのプラグマの利用である。しかし、これらのプログラムパラダイムは、仮想化されたメモリと、仮想化された計算資源を仮定している点で、リコンフィギャラブルシステムに適用する場合は FPGAのサイズとメモリに合う回路を吐き出すことが難しいだろう。

  プログラミングは、リコンフィギャラブルシステムをハイパフォーマンス処理に用いる場合、おそらく最大の問題である。しばらくは、対象分野毎にエンドユーザにも利用可能なツールを作り、後々は、ハードウェア記述C、システム記述C の普及と科学技術計算分野への進展を期待しつつ、関連分野で研究を行っていくのが現実的であろう。

  リコンフィギャラブルシステムによるアクセラレータは、対象とする問題に応じて最適な回路構成を実現するのが理想である。しかし、対象の問題に回路が依存するということは、逆に対象問題が大きければ、搭載する FPGAの規模を越えてしまうことが容易に起きうる。多数の FPGAを密結合するシステム上では、一つの FPGAの規模を越えた問題をどのように分割するかも困難な問題である。

  これに対する解決法は、プログラムの問題と関連し、一筋縄では行かない。BEE2などでは、FPGAのサイズは、多くの問題を扱う単一タスクが十分格納できる程大きいと考え、分割されたタスクを FPGA単位に割り当てる。この考え方は最近の FPGAの規模と、その規模を一杯にする回路の配置配線に要する時間などを考えると一定の説得力がある。しかし、この考え方でもタスク数がシステムの FPGA数を越えると問題が生じ、本格的なハイパフォーマンスへの応用の一般的な解決法とはいえない。

  現在の所、もっとも有効は方法は、対象問題を限定してサイズに依存せず問題を解くことのできる回路を搭載することで、ReCSiP、PROGRAPE、RAPLASなどでは基本的にはこの方法を用いている。すなわち、システムに搭載可能なサイズの回路を繰り返し用いて、サイズの大きなアプリケーションを扱う方法で、回路自体を大きなサイズを扱えるように設計するわけである。しかし、これは対象問題を限定し、設計者の努力の結果実現されており（このような手法を見つけること自体が研究の対象である）、一般的な問題に対してこのような回路を実装できるわけではない。

  Bach-Cなどの Cレベル記述では、設計が FPGAのサイズに入るかどうかは、設計者が、配置配線を繰り返し行って調整する必要がある。将来、機能合成ツールによるハードウェア見積りと、最適化のステップが整備されれば、アプリケーションのサイズが決れば、それをリコンフィギャラブルシステムに適合させる設計が容易になるだろう。その場合でも、メモリも計算資源も仮想化されたプロセッサのプログラマにとって、スケーラビリティの問題を考慮しつつ設計することは、かなりの負担になるだろう。

  一方、FPGAなどのリコンフィギャラブルデバイスに対してシステムサイズを意識しないですむように仮想化させる機構を取り付ける研究は、90年代から行われていた。構成情報メモリを複数チップ内に持たせて実行中に利用していないメモリに外部から構成情報をロードする仮想ハードウェア技術^[16] は、1992年に既に提案され、Xilinx社からもこの機能を持ったマルチコンテキストFPGA が提案されている^[3]。しかし、これらの機構は粗粒度の動的リコンフィギャラブルプロセッサでは一般的になったが、FPGAには導入されていない。これは、LUTなどの細粒度構成要素を用いている FPGAの場合、構成情報メモリを複数持たせる場合のメモリに要する面積が、それによって実現される論理回路に対して大きく、マルチコンテキスト化するメリットが小さいためである。これに代わって、FPGAをいくつかの領域に分割して、アプリケーションを稼働させながら、部分的に再構成を行う部分再構成が、特に最近の FPGAにおいて一般的になっている。しかし、この方法は、外部から構成データを設定するのに時間がかかることから、回路構成を仮想化することは、現実的とはいえない。やはり、FPGAのサイズの問題はツールレベルで解決する以外にないように思う。