Describing System-Level Parallelism 11.4 （後半）

1. Describing System-Level Parallelism11.4（後半） 太原研究室　M1 割田臣一

2. カラム生成プログラムの過程（The Column Generator Process ） • 既に述べたように、イメージフィルタは一般に、動作しているイメージデータの画面に作用する。 • この例では、3×3ウィンドウ上でフィルタを作用させる。 • 処理においては3つの新しい値と、先程のピクセルの計算で用いた6つの同じ値を使う。 • カラム（column）：縦方向の列、数学で列 ⇔ｒｏｗ（横方向の列、数学で行）

3. カラム生成プログラムの過程（The Column Generator Process ） • カラム生成プログラムは左から右に処理を進め、どんなサイクルにおいても3ピクセルの行のストリームを発生させる。 • このストリームは、3つの新しい値に対応する1つの3ピクセル列に相当する。 • 3つの新しい値は、フィルタによって次の処理対象となるピクセルのフィルタ画面において必要とされる。

4. カラム生成プログラムの過程（The Column Generator Process ） • Prep_runプロセスは、オリジナルのアルゴリズム同様3ピクセルの列データを生み出すのに十分なデータ量をバッファリングするが、より簡単な方法でバッファリングを行う。 • オリジナルのアルゴリズムの性能にてネックとなるのが、1つのバッファからピクセルの値を取得する方法であった。 • バッファは全てのピクセルを含んでおり、「前を見る」「後ろを見る」ためにある画像の行全体を必要とした。

5. カラム生成プログラムの過程（The Column Generator Process ） • イメージフィルタの性能を向上させるためには、同じメモリへのアクセス回数を減少させたい。 • そのために、要求された計算を実行する際の繰り返し回数を減らしたい。 ⇒7、10章で述べた配列を分割する技法を用いることで一度のループで同じ配列にアクセスする必要性を失くす。 • その結果、2クロックに1回ピクセルの列を生み出すことで非常に高いスループットを実現できる。 →図11-10参照

6. カラム生成プログラムの過程（The Column Generator Process ） • この過程は • 1つのピクセルのストリームを受け入れる • 配列B,Cに2つのスキャンラインをキャッシュする • オリジナルの例と似た循環バッファ技術を用いることで3つの出力ストリームを生成する。 ※スキャンライン：ディスプレイの走査線、画像の横1列 ⇒同じ配列への不要なアクセスを避けることで、それぞれの列の出力の待ち時間を2クロックにできる。

7. イメージフィルタの処理（The Image Filter Process） • このパイプラインで最も大切な過程はフィルタ自身。　これは図11-11におけるfiltter_runで表される。 • この過程はprep_runプロセスによって生成された3つのピクセルのストリームを受け入れ、オリジナルのアルゴリズムと同様の畳み込みを行う。 • この畳み込みにおいて、多数のステートメントレベルの最適化は入力処理の繰り返し回数を減らすことに繋がる。

8. イメージフィルタの処理（The Image Filter Process） • オリジナルの手法で行われたように、隣接するピクセルは配列から呼び出されること無く、ローカル変数p01,p02,p03等に格納される。 • これにより、1つの配列に同時にアクセスをする必要がなくなる。 • 1つの配列に同時にアクセスをしてしまうと、オプティマイザが単一のステージにて複数の計算を同時に行うことが妨げられる。 • 水平、垂直、斜め方向における座標の違いの計算は、より単純で並列化が可能な計算に置き換えられる。 • これにより、abs(絶対値)機能やマクロの必要性をなくせる。 • この場合、中心のピクセルは繰り返し周辺のピクセルと比較され、平均差が得られる。

9. イメージフィルタの処理（The Image Filter Process） • これらの変化によって、僅か2クロックのスループット率のエッジ検出アルゴリズムが実現される。 • もちろん、この計算は他のタイプの畳み込みを行う様に必要に応じて修正できる。

10. メモリ処理の流れ（TheStream toMemoryProcess） • from_streamは、先の図11-9述べられたto_stream処理と反対の機能を提供する。 • この処理では、入力ピクセルの単一ストリームを読み込み、それに続いて列を読み込み、co_memory_writeblockによって出力メモリに書き込まれる。 • またこの処理では、ストリームから読み込まれ、メモリに置かれたバイトの並びを入れ替えることで、使用される画像形式を反映する。（この場合はTIFF形式） • このストリームからメモリまでの処理,from_streamを図11-12で示す。

11. 構成機能（The Configuration Function） • １１．４で述べたこれら4つのプロセス、対応するストリーム、メモリ、および信号宣言は、Impulse Cによって記述され、図11-13に示される構成機能によって相互接続される。 • この構成機能は、以下に示すような機能を持っている。

12. 構成機能（The Configuration Function） • startsigとdonesigのための信号宣言。 • Startsigがイメージバッファが処理の準備ができていることを示すのに対し、Donesigはイメージのフィルタリングが完了したことを示す。 • これらの信号は、ソフトウェアテストベンチとイメージフィルタハードウェアの間の共有メモリ(イメージバッファ)の使用を調整するのに使われる。 • ピクセルストリームの入出力とprep_runからfilter_runに接続する3つのストリームのためのストリーム宣言 • Shrmemのためのメモリ宣言。 • このメモリはイメージバッファを表す。

13. 構成機能（The Configuration Function） • 4つの必須ハードウェアプロセスと1つの追加ソフトウェアのテストベンチ処理、cpu_procのためのプロセス宣言。 • このソフトウェアのテストベンチ処理はAppendix Eに記載されている。 • 2つの信号startsigとdonesigのためのco_signal_createの呼び出し。 • メモリshrmemのためのco_memory_createの呼び出し。 • メモリは、この例で扱うAlteraプラットホームに対応した位置heapOに作成される。 • heap0は専用ハードウェアとしてFPGA上で作用しているプロセッサとイメージフィルタにアクセスできるオンチップメモリを表す。 • プロセッサには、ソフトウェアのテストベンチが置かれる

14. 構成機能（The Configuration Function） • 入力ストリーム、出力ストリーム、3つの中間的ストリームから成る5つのストリームのためのco_stream_createの呼び出し。 • 3つの中間ストリームが深さ4のストリームを与えられているの対して、入力および出力ストリームの深さは、画像のスキャンラインの半分の数である。 • この処理は、メモリ読み書き時間が予想以上に長くなることによるストールを軽減するために行われる。 • しかし、この様に深いストリームバッファはハードウェア資源において相当な負担となることに気をつける。 • 4つのハードウェアプロセスと1つのソフトウェアテストベンチプロセスのためのCo_process_createの呼び出し。 • 4つのハードウェアプロセスのためのco_process_configの呼び出し。 • これらの4つのプロセスが、ハードウェアブロックとしてFPGAにコンパイルされる。