CHAPTER3 A Programming Model for FPGA-Based Applications 後半 6311676 三浦 盛生 3.2(残り) Adding Soft Processors to the Mix 3.2-ソフトプロセッサと FPGAについて FPGAベースの計算機をそれぞれが個別の計算能力を 持つ並列機械の集合とみなすことで、マイクロプロセッサ として扱う事が出来る 「ソフト」プロセッサにFPGAベースの広い利用可能性を 与えると、古いC言語の必要性とアプリケーション独自の ハードウェアの高速化の必要性のバランスをとるのに妥 当な実践的な方法となる FPGAベースのプロセッサについて FPGAベースのプロセッサは以下のような様々な理由から 役立つと言える 古典的なコードを実行することが可能 ソフトウェアテスト生成プログラム[software test generators]として開発の 間で使うことが可能 コストの掛かる基本入出力[standardizing I/O]や埋め込み型のステート マシンのハードウェア構造と置換可能 OSを実行させることや、ハードウェアとして構築すると巨大なも のになるが重要でない計算を実行することも可能 グリッドコンピューティング[grid]として使われたとき、プロセッサは 相互に並列計算プラットフォームを形成することが可能 FPGAベースのプロセッサは、低レベルのFPGAゲート（おそ らく論理ゲートの事）で構成されている ソフトウェアプロセッサとFPGAについて 最近のソフトウェアプロセッサ利用の革新（激増?）[explosion] はFPGAが完全な「プログラマブルなチップシステム」に 対して順応性が高く、強力なハードウェア基盤に適用で きることを証明している FPGAの売り手は今、ごく低コストかあるいはコスト無しで、 必要なプロセッサ全てと、シングルコンピュータ基板をア センブリに翻訳する必要のある周辺機器を提供しており、 それらのプラットフォームはハードウェアの高速化と高度 なパラレルソフトウェア等のカスタマイズを含んでいる FPGAの利点 このように使われてきたFPGAは粗粒度並列プロ グラムを実行するのに良いプラットフォームであ る 他の並列計算機モデルと比較して、このアプロー チはプロセス間のやりとりのオーバーヘッドが より少ない もし各プロセスがローカルメモリと明示された タスクを持っていると、アプリケーションは異なる FPGAのエリアと独立したFPGAデバイスとして分 割することができる FPGAの利点 （FPGAによって得られる）多くの種類の計算は次のよう な粗粒度並列処理に提供される ベクトル配列計算 パイプラインによる画像や音声処理 他の多段式[multistage]シグナルフィルタリング その他 3.3 Programming For Parallelism 並列処理のためのプログラミング 3.3-1 C言語の問題点 C言語で汎用ハードウェア(又は非ノイマン型コンピュータ)を プログラムするには問題が存在する 並列処理[Parallelism processing]と並列システムのプログラミングは 使用する言語の並列処理へのサポート プログラマの複数の半独立コンピュータの要素[multiple quasi-independent computational element] の扱い方に関する理解 が必要 しかしスタンダードなC言語はこれらの特徴を全く含んでいな い 3.3-1 C言語の問題点 VHDLとベリログは抽象度が低いレベルであったにも関 わらず、正しく並列処理のために設計されていた これらは、別のハード上の接続されたハードウェア構成要素 [hardware components]の高度な並列システムを記述するために作ら れている 3.3-2 MPI C言語プログラミングの文脈で並列処理プログラミング のモデルに最も近い物はスレッドへサポートであり、C言 語の基本的な特徴ではないが、ポピュラーでアドオン (OSの特殊なライブラリ)という形で容易に利用出来る 正直訳しててよく分からなかったが、次のスライドの「このタイ プ」というのはこの文章が該当すると思われる。 3.3-2 MPI ほとんど存在しないこのタイプのプログラムのための一般的 なライブラリにMessage-Passing Interface (MPI) がある MPIは複数の一般的なデスクトップPCを集めてより大きな スーパーコンピュータとするアプリケーションや、その他の強 力なプラットフォームの意図して設計されている Wikipedeiaによると MPIとは、 並列コンピューティング利用するための標準化された規格 複数のCPUが情報をバイト列からなるメッセージとして送受信すること で協調動作を行えるようにする 3.3-3 妥協案 もしC言語(又はC言語を拡張した物やその他のフォン・ノ イマン型計算機の為に作られたプログラミング言語)が ハードウェアのプログラミングにふさわしくなかったら もしハードウェア(例えばHDLs)の為に特別に作られた言 語が低レベルなものだったら このような場合、どうすればいいか 結局は妥協案[compromise solution]がベスト 3.3-3 妥協案 ハードウェア側では 全てのハードウェア要素(プログラム可能なゲートとFPGAを作 るフリップフロップ回路)を高度なプログラミングにふさわしい 抽象的な構造としてアセンブリで記述する必要がある 幸運なことに、コンパイラはアプリケーションと低レベルFPGA ハードウェアの知識を用いて自動的にこの構造を創ることが 出来る 3.3-3 妥協案 ソフトウェア側では アセンブリで記述しなくてはならない抽象的な並列処理計算 機のプログラミングのサポートのために言語の選択を広げる 必要がある ＊PE：Processing Element S/W process S/W process PE PE S/W process S/W process PE PE Parallel Software model Parallel machine model Figure: Multinode parallel machine model and multiprocess programming model 3.3-4 まとめ[To summarize] FPGAベースのハードウェアを(ゼロからそれを設計する ことに対して)プログラミングする感覚を理解するために は、抽象的な計算機モデルを作成し、そのモデルにふさ わしいソフトウェアプログラミングモデルを選択する必要 がある 3.3-5 CSP 並列処理プログラミングの研究では一般的に、以下のよ うな物を作ることは粗粒度並列処理を表現するのに良い 方法だと見出されてきた 抽象[an abstract](的なモデル？) 複数から構成されるMultinode Machine (Multicomputerとも呼ぶ) 半自律処理ノード[semi-autonomous processing nodes] (Processing Elements (PEs)とも呼ぶ) 3.3-5 CSP この抽象的な計算機を対象とすることで、(基盤とな るハードウェアが実際にそのようなシステムを使うか どうか)使用可能なプログラミングモデルを構成する ことは容易である communicating sequential process (CSP)プログラミン グモデルはよく研究されてきており、実際の アプリケーションをビルドするのと同様にFPGAデザ インのための形式的なメソッドを適用するのに使わ れてきている 3.4 Communicating Process Programming Models 3.4-1 CSPの歴史 この章で注目するプログラミングモデルは 1978年Sir Anthony Hoareによって作られた。 その後Communicating Sequential Processes という 題目の本で1985年に発表 Hoareによって作られたSCPは以下の2つから成り 立っていた プログラミングモデル プロセスから呼ばれる独立したオペレーティングコンポーネ ント[operating components]の相互作用のパターン記述の為の言語 3.4-1 CSPの歴史 このシステムの各プロセスは過去のソフトウェアプログラ ム(内部動作で連続して動作するモノ)だと言えるかもし れない だが、プロセスは明確なチャンネルを経由して他のプロ セスと情報をやり取りすること[communicating]を制限されてい た 3.4-2 CSPについて CSPアプリケーションの各プログラムは、独立した ハードウェアプロセスとして実行されることもできるし、 伝統的なフォン・ノイマン型計算機として動作するこ ともできる アプリケーション全体としては、サブルーチンとして 他のプロセスを呼び出すメインのプロセス[main controling process]を持つよりはむしろ、バッファ用のデータチャン ネルを経由してシステムを通してデータを移動させる ように設計されている 3.4-2 CSPについて それぞれの実行中のプロセスがローカルメモリ資源にア クセスしている間、ストリームと呼ばれるデータチャンネ ルを経由する物を除いて、独立したプロセスのやりとり [communication]はほとんど、あるいはまったくない 3.4-3 CSPについて 理想的なCSPアプリケーションでは、時間的なディレ イや他のオーバーヘッドは、それらのロケーションに 関係なく(比較的小さな容量のペイロードから成ると みなされている)データの2つのノード間の移動に関 係している ペイロード：通信するデータのヘッダ等の付加情報を除 いたデータ本体の事 特にもしアプリケーションがFPGAハードウェアや 埋め込み型プロセスのように大きく異なるタイプの プロセスの要素に分割されたら、かなりの帯域幅と 待ち時の問題が存在するかもしれない 3.4-3 CSPについて 純粋なCSPの実行[A “pure” implementation of CSP] には、データとプ ロセスを同期させる考えに違反するため、データチャン ネル、データストリームを用いないやりとりは全く含まれ ない （2つのプロセスが同じメモリにアクセスする等） 3.4-4 ローカリティ CSPモデルの重要な特徴はローカルメモリへのアクセスがリ モート(ノード外の)メモリやデータチャンネルを用いたデータ バッファへのアクセスよりコストが掛からない事 そのため、CSPのシステムをプログラミングする時、パフォー マンスを最大限に活かすためには、外部へのアクセスより、 可能ならばローカルのデータにアクセスすることが重要であ る この並列処理プログラミングのコンセプトはローカリティ[locality]呼 ばれており、高いパフォーマンスの並列処理アプリケーション を作成する方法の基本的な理解である 3.4-5 CSPについて CSPをベースにした計算機モデルはC言語の粗粒度並列 処理アプリケーションのコンパイルにとって理想的な目 標[target]である CSPアプリケーションのプロセスコンポーネントは、コンパ イラが比較的容易に基本的なC言語の文章から生成す ることが出来るハードウェアやソフトウェアにとって扱い やすい計算ブロックを含んでいる 3.4-5 CSPについて システムレベルでは、(ライブラリのフォームで提供され た)C言語の拡張はストリーム指向型並列[streams-oriented parallel] プログラミングモデルを表現するのに必要とされる inter-process communication channels を提供することが 出来る 3.4-6 モデルの適切な利用 結果として出来上がる、(全くソフトウェアというわけ でもなく、全くハードウェアというわけでもない)ハイブ リッドプログラミングモデルは全てのアプリケーション にとって正しい選択なのか？ 高度なパラレルプラットフォームにより適したFPGA ベースの高速化により最大の利益を得ることが出来 るアプリケーションを除いて確実にNOである 3.5 The Impulse C Programming Model インパルスCプログラミングモデル 3.5-1 ストリーム指向型ハードウェア ソフトウェア混合アプリケーション インパルスCのプログラミングモデルはストリーム指向型ハー ドウェアソフトウェア混合アプリケーション[stream-oriented, mixed hardware/software application]のために意図されたCSPモデルである これらのアプリケーションは非常に一般的になっており、ハードウェ そのようなアプリケーションの例 アの高速化を必要とするコンピュータの内包的な問題の大きな割 合を占めている。 (セキュリティやテレビ会議と同様な消費者製品のための)画像処理 データの圧縮や暗号化、復号化などのデータのやり取り ワイヤレス通信[communications] 地球物理学や生物遺伝学、医療などの解析 その他諸々を含む多くの分野 3.5-2 インパルスCについて インパルスCプログラミングモデルの中心はプロセスとス トリームにある。 Shared memory C language process Signal Controlling C language process C language process Signal C language process Shared memory C language process Streams Figure: The data processed by an application flows from process to process by means of streams, or in some cases by means of signals and/or shared memories 3.5-2 インパルスCについて プロセスは独立して同期しており、同時にアプリケー ションのコンポーネントを操作している これらのプロセスを データストリームかメモリやその他のシステム資源への 書き込みかのどちらかの出力の発生 明確な計算の実行 様々なデータの受け入れ などの永続的なサブプログラムとして考えることは 有用ある 3.5-2 インパルスCについて 伝統的なソフトウェアのサブルーチンと違って、これ らのプロセスは「呼び出される」(プログラムの動作の 進行の間、繰り返し呼び出される)のではなく、代わ りに「常に動作して」おり、それらのインプットのデー タに常に返答している プロセスは永続的であり、データの受け入れや 計算の実行、出力の生成などを行うことによって アプリケーションの仕事を行なっている 3.5-4 CSPモデルに適する条件 CSPプログラミングモデルはデータの移動、処理と同 期にストリーム指向のアプローチを使った高度な並 列処理アプリケーションの作成を簡単にするために 設計されている 上記のような表現をできるアプリケーションは数多く 存在するかもしれないが、具体的には次に挙げる特 性のいくつか、又はすべてがあるアプリケーションは CSPモデルに最も適切である 3.5-4 CSPモデルに適する条件 アプリケーションの特徴として、処理要素とデータ源の間の データ信号速度が速い物 パケットサイズが固定で、ストリームの ペイロードが比較的小さい物 複数が関連しているが、独立した計算が、 同じデータストリーム上で実行されることを 必要としている データが 低精度又精度固定の値 典型的な固定幅の整数型 固定小数点の値 のどれかで構成されている 3.5-4 CSPモデルに適する条件 溜まっている計算結果[deposit results of computations]や配列データや、 係数[coefficients]、その他の定数が保管の為に使われているかも しれないローカル又は共有メモリへの参照がある 複数の独立したプロセスが、メッセージ経由で必要な同期を 伴い、渡されるデータを通して更新を行なっている 3.5-4 CSPモデルに適する条件 インパルスCは特にaddress streaming application や大量 のデータを比較的激しい動作を通して処理しなくてはな らないアプリケーションのために設計された (Celoxicaによって提供されているHandle-C言語を含むその他 のCベースのハードウェアデザイン言語も同様の能力を提供 している) 3.5-5 インパルスCの仕様 インパルスCでは、小さなデータタイプセットと、平凡なC プログラムから呼ぶことが出来る固有のライブラリの機 能の中でCSPモデルが具体化されている インパルスCで定義された固有のライブラリの機能は、プ ロセス間でシグナルデータとストリームをやりとりするこ とや、共有メモリやローカルメモリのデータを出し入れし て移動することに使われる C言語と互換性のある拡張部分は、ストリームやシグナ ルなど、共有メモリを経由したプロセスのやりとりの集合 としてアプリケーションを記述する[specify]のに使われる 3.5-5 インパルスCの仕様 プロセスは追加されたインパルスCのライブラリの 機能を使うことで、実際の目的のプログラム可能 プラットフォームのリソースに割り当てられる 3.5-6 ストリームについて ストリームは複数のプロセスがお互いにやり取りしたり、 それぞれの動作を同期するための最重要なメソッドである ストリームのインターフェースで上手く設計されたアプリケー ションは実際のハードウェアとソフトウェアとして作られた[mapped] とき効率的に処理される それゆえ、そのようなアプリケーションをつくるための多大な 努力はデータの移動を最大限利用した時と、ストリームのイ ンターフェースの設計で見ることができる 3.6 SUMMARY まとめ 3.6 3章まとめ この章では、高度な並列処理を記述のためのプログラミング モデルや、ソフトウェア、ハードウェア混同のアプリケーション について曖昧に説明してきた このプログラミングモデルは、プログラム可能ハードウェアプ ラットフォームに最も適したアプリケーションや、アルゴリズム のタイプを記述する効率のよい方法であることを証明してき た 次の章では例を通して、C言語の文脈の中でこのプログラミ ングモデルを使う方法を学習する
© Copyright 2024 ExpyDoc
