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

1
計算機アーキテクチャ特論
東京理科大学理工学研究科
情報科学専攻修士1年 6311618
大野葉月
2
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_process pe;
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_stream pixelvalues;
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
ご清聴ありがとうございました

Download Report