計算機アーキテクチャ特論

1. 計算機アーキテクチャ特論 東京理科大学 理工学研究科 情報科学専攻 修士1年 6311618 大野 葉月

2. Chapter4.4プロセス、ストリーム、信号、メモリChapter4.4プロセス、ストリーム、信号、メモリ

3. Chapter4.4その1 • Impulse Cプログラムモデルの中心 ＝ プロセス、ストリーム • 前の章において、HelloFPGAで両方の例を見た • プロセスについて • アプリケーションのセグメントの操作により、独自に動く • C言語で記述されている • 仕事 ＝ データの受け入れ → 計算の実行 →出力の生成 • ストリームについて • プロセス間で同期をとる、一方向チャネルのこと • co_stream_createでストリームの特性が指定できる • データはストリームか論理回路の上を流れる

4. Chapter4.4 その2 • プロセスは実行関数（ユーザがC言語で定義）で定義される (HelloFPGAの例では) • プロセス ソフトウェアプロセス ハードウェアプロセス (分類方法：構成サブルーチンで指定) • ソフトウェアプロセスは通常、動きが抑制 • ハードウェアプロセスは、プロセッサが限界になると抑制

5. Chapter4.4 その3 • Impulse C ハードウェアのコンパイラの規制を満たすために、C言語でプロセスを書かなくてはならない • C言語、事前定義関数がソフトウェアプロセス、ハードウェアプロセスで参照される • 事前定義関数：ストリームやシグナル操作で動く関数 • Impulse C のコンパイラ • 統合コンパチブルハードウェア記述を生成 • スケジューリング、パイプライン処理、ストリーム操作などが可能 • ハードウェア記述は目標ハードウェアとの並行関係を利用 （コンパチブル ＝ 互換性がある）

6. Chapter4.5符号のあるImpulse Cと符号なしのデータ型式

7. Chapter4.5 その1 • 提供されているデータ型式　- 1から64bitまでで長さを指定 　　符号あり、なしを指定 　例:co_int1-1ビットの整数型 co_int7 -7ビットの符号あり整数型 co_uint16 -16ビットの符号なし型 co_uint24 -24ビットの符号なし型 co_int32-32ビットの符号あり型 co_uint64-64の符号なし型

8. Chapter4.5 その2 • デスクトップ模擬環境とハードウェア実装では、ビット単位の 振る舞いに差がある ⇒数学的マクロ動作を使用して正確にモデリング可能 　例:UADD4(a,b)-符号なし4ビットの足し算 ISUB7(a,b)-符号あり 7ビット引き算 UMUL24(a,b)-符号なし 24ビット掛け算 UDIV28(a,b)-符号なし28ビット割り算

9. Chapter4.6プロセスの理解

10. Chapter4.6 その1 • プロセス　– Impulse Cでの基本的なユニット計算 ユニットのコードを実行するのが仕事 　　　　 自身を制御できる 独自に同期がとれる メモリリソースにアクセスができる プロセスでプログラムを作る　≒　スレッドでプログラムを作る ∴C言語をImpulse C に変換することは簡単 ・・・とはいえ、違いはある

11. Chapter4.6 その2 スレッドプログラミング Impulse C グローバルはサポートされない プロセスごとのプロセッサか 論理ブロックに割り当てられる 複雑なハードウェアとソフトウェアのサポートをするように設計 プロセスが定義、作成されるのは、初期化、ロードの時 • グローバルとヒープのメモリ が共有 • スレッドは同じプロセッサ上で 　実行 • 共有データ構造とセマフォアを使って交信する • プロセスが定義、作成されるのは作成、呼び出し、破棄する時

12. Chapter4.6 その3 • Impulse C のデスクトップシュミレーション • ライブラリはスレッドに基づく ⇒グローバルとヒープのメモリは共有される • プロセスが実行されるが、これはターゲットプラットホーム上でない 可能性がある • ライブラリの外に割り当てられたグローバルとヒープのメモリの使用は避けるべき

13. Chapter 4.6 その4 • 注意 • デスクトップシュミレーションにおいて、スケジューリングの予測は、 プロセス中でのみ可能 ⇒プロセスの外はスレッドモデルに頼っている • プロセスが始まる前に、すでに別のプロセスが始まり、実行している だろう、と仮定してはいけない ⇒このような同期が必要ならば、 同期信号かストリームのアプリケーションの使用 を考えるべき

14. C言語における、timed、untimedの意味は？（timed、untimed ＝時間制約がある、ない）

15. Chapter 4.6 その5 • timed、untimedとは C言語の系列の中にクロック境界の場所を指定するか否か

16. Chapter 4.6 その6 • クロック境界 ＝各基準クロックの各信号値を出力する サイクル期間ごとの境界を示す • timedについて • クロックの境界が定義されている • 定義上でのC、ソースファイルが異なったクロック周期を表す • プログラマによる制御がかなり可能⇒　プログラマの仕事が多い • 手動で情報を入力 • 自分で管理が必要 • 独自の記述が可能で、untimedとは違う機能を持つことができる

17. Chapter 4.6 その7 • untimedについて • Impulse C はuntimedメソッドを使う • プロセスの中の状態は指示ステージの総数を最小にするという目標のため • オプティマイザに影響を与え、 サイズ/速度要件に合わせられる • 特定のクロックイベントへのC言語で関連づける方法、 低レベルであるハードウェア概念(クロックとして可能であること)を 知らせない　（直接、定義された時は除く）

18. Chapter 4.6 その8 • untimedの利点 • よりソフトウェアプログラミング経験を生かせる • アプリケーションは、より高いレベルで表現して、よりハードウェア中心のコンパイラとC言語レベルで最適化できる • untimedの欠点 • 正確にハードウェアを制御できないかもしれない ⇒アプリケーションを部分的には低レベルHDLプログラムに落とす必要があるかもしれない

19. 作成プロセス

20. Chapter 4.6その9 #define BUFSIZE 4 void my_app_configuration() { co_process procHost1, procPe1, procPe2; co_stream s1, s2; s1 = co_stream_create("s1a, INT_TYPE(16), BUFSIZE); s2 = co_stream_create("s2", INT_TYPE(16), BUFSIZE); procHost1 = co_process _ create("Host1", (co_function)Host1, 1, s1 ); procPe1 = co_process_create("Pe1'', (co_function)Pe1, 2, s1, s2); procPe2 = co_process_create("Pe2", (co_function)Pe2, 1, s2); }

21. Chapter 4.6その10 • プロセスはアプリケーションの構成機能で作成、命名される • my_app_configuration　＝　プロセスと対応する機能が、 関連づけられていることを宣言 • co_process_create＝　ハードウェアとソフトウェア処理の両方を定義 　　引数プロセス名を含む文字列へのポインタ co_functionタイプの機能ポインタ プロセスで定義されるポート(入出力する)の数

22. Chapter 4.6その11 • co_process_create機能について • ポートの数や命令を間違えるとデバッグが難しくなるので注意 • 実行プロセスに指定されたポートの引数は、以下の中からでも可能 • co_stream - データがFIFOバッファインタフェースを通して移される ストリーミングの二地点間インタフェース • co_signal- メッセージが送付プロセスによって掲示されて、受信プロセス によって待たれるかもしれない、バッファリングされた 二地点間インタフェース • co_memory - インタフェースサポートブロックが読み書きする共有メモリ • co_register - 低レベルで、非バッファリングされたハードウェアインタフェース • co_parameter - コンパイル時のパラメタ （宣言、インスタンス作成(co_xxxxx_create機能)をしなければならない）

23. Chapter4.7ストリームの理解

24. Chapter4.7　その1 • ストリーム　＝　プロセスを接続する単方向の通信チャネル • co_stream_create ＝ ストリームの作成 • strm_image_value = co_stream_create("IMG_ VAL", INT _ TYPE(16),BUFSIZE); 引数任意の名前・・・・・・・・・・・・・・・・・・・・① 　　　データ要素のタイプとサイズ・・・・・・② 　　　バッファサイズ・・・・・・・・・・・・・・・・・③

25. Chapter4.7その2 • 引数について • ① : デバッグ、外部からのモニタリング、および後プロセスの目的 のためにストリームに割り当てられるかもしれない任意の名前 この名前に意味も持たない ダウンストリームの統合かシミュレーションツールの役に立つかも しれない • ② : INT TYPE、UINT TYPE、およびCHAR_TYPEを含む特定の ストリーム型を定義するのにマクロを提供 • ③ : 2つのプロセスの間で作成されるFIFOバッファのサイズに関連

26. Chapter4.7　その3 • バッファサイズ • 1の場合 : ストリームが本質的には非バッファリングされることを示す ⇒受信プロセスは送信プロセスがデータをストリームに 移動させるまで妨げる • 大きめの場合 : 生成される追加ハードウェアリソースや、 効率的なプロセス同期をもたらす • 用途に応じて、バッファサイズを選ぼう • なるべく、小さいストリームバッファサイズを選ぶべき

27. Chapter4.7 その4 #define BUFSIZE 4 void my_config_function(void *arg) { co_stream host2controller,controller2pe,pe2host; co process host1 , host2; co_process controller; co_processpe; host2cntrlr=co_stream_create("host2cntrlr", INT_TYPE(32), BUFSIZE); cntrlr2pe=co_stream_create("cntrlr2pe", INT _ TYPE(32), BUFSIZE); pe2host=co_stream_create(''pe2host", INT_TYPE(32),BUFSIZE); host2=co_process_create("host2'., (co_function)host2_run, 1, pe2host); pe=co_process_create(''pe", (co_function)pe1_proc_run, 2, cntrlr2pe, pe2host); cntrlr=co_process_create("cntrlr", (co_function) cntrlr_run, 2, host2cntrlr, cntrlr2pe); host1 =co_process_create("host1", (co_function )host1_run, 2, host2cntrlr, iterations); co_process_config(cntrlr, co_loc, "PEO"); co_process_config(pe, co_loc, "PEO"); }

28. ストリームはハードウェアでどのように実装されますか?ストリームはハードウェアでどのように実装されますか?

29. Chapter4.7 その5 • co_streampixelvalues; pixelvalues = co_stream_creat(“pixval”,UINT_TYPE(24),2); 2の深さのバッファで、幅24ビットのデータ値の、pixvalという名前のストリームを生成 • 稼働しているハードウェアの実際の深さは2でなければならない 　⇒コンパイラは2に近い、切り上げられた値になる • バッファ幅(第2引数)はデータの本質を反映 • ストリームとその対応する(第3引数)の深さの決定は複雑

30. Chapter4.7 その6 • 大きいバッファを使用すると・・・ ⇒稼働しているハードウェアのサイズ上で重要な影響を　　与えうる ＝メモリを浪費 （OS から過度のメモリが取られて 、ページングが発生する場合も） • 小さ過ぎるバッファを使用すると・・・ ⇒何らかの計算を実行する前にデータの複数のパケットを読まなければならないプロセス、 異なったレートで作動する接続プロセスのせいで、デッドロック状態になりうる

31. 入出力ストリーム　

32. Chapter4.7その7 • プロセスの読み書き　は　プロセス実行関数　で実行 • プロセス実行関数(Impulse C では) • 繰り返し1つ以上のストリームを読み込む →　データが利用？ Yes → 処理と実行　 No → 　利用可能になるまでブロック • 非データフロープロセスモデルをサポート(後で説明)

33. Chapter4.7　その8 • co_stream_open　＝　ストリーム内部のリセットを行い、 読み書きのどちらも利用可能にする 例 ： err= co_stream_open(input_stream, O_RDONLY, INT_TYPE(32)); 引数　　　　ストリーム 　　ストリームのタイプ 　　データ型 • co_stream_openで開くストリームがすでに開いていた場合 ⇒エラーコード、co_err_already_openを返す

34. Chapter4.7　その9 • co_stream_close　＝　ストリームを閉じる ストリームの終わり(EOS)のトークンを 出力ストリームに書く 例 : err= co_stream_close(input_stream); • co_stream_read　＝　ストリームを読む(EOSの検出を行う） EOSトークンを受け取ったとき、エラーを返す • 閉じているストリームであれば開かず(または、既に閉じられた)、co_stream_closeの機能がエラーコード、co_err_not_openを返す • co_stream_closeを呼ぶとき、アップストリームプロセスがストリームを 閉じたことを示すために、EOSトークンを受け取るまで、読み込みプロセス をブロック

35. Chapter 4.7　その10 • いったん閉じられると、プロセスは複数のセッションのために再びストリームを開くことができる • 読みこみと書き込みプロセスで適切にすべてのストリームを 終えなければならない • 注意： • プロセス間でのストリーム接続は１対１でなければならない • 複数対１接続もサポートされない • 中間ストリームコレクターや配分プロセスを作ることで、 アプリケーション中の、データ配分パターンを作ることができる

36. Chapter4.8出力ストリームの使用

37. Chapter 4.8　その1 • co_stream_write　＝　出力ストリームの書き込み co_stream_open(output_stream, O_WRONLY, INT _ TYPE(32)); for (i=０; i < ARRAYSIZE; i++) { co_stream_write( output_ stream, &data[i], sizeof(int32) ); } co_stream_close( output_stream);

38. Chapter 4.8　その2 • co_stream_writeの機能 指定された出力ストリームが完全であるかどうか確認 →　完全であるなら、書きこみをするために、 ストリームバッファができるまでブロックする • ストリームが開かれて、プロデューサーとコンシューマーで プロセスを使用していると、ストリームを管理する必要がない 適切に設計されないなら、デッドロック状態のリスクがあり

39. Chapter4.4~4.8のまとめ • Impulse Cプログラムモデルの中心 ＝ プロセス、ストリーム • 符号の有無を指定できるデータ型式を提供 • 数学的マクロ動作を使用してのモデリングが可能 • C言語をImpulse C に変換することは簡単 • co_process_create ＝ プロセスの作成 • co_stream_create＝ ストリームの作成 • 用途に応じつつ、小さいストリームバッファサイズを選ぶべき • co_stream_open、read、close ＝ ストリームの読込みと開閉 • co_stream_write　＝　出力ストリームの書き込み

40. ご清聴ありがとうございました