修士論文 CoreSymphony アーキテクチャの実装に関する研究 提出者

Tokyo Institute of Technology
Department of Computer Science
修士論文
CoreSymphony アーキテクチャの実装に関する研究
指導教員: 吉瀬 謙二 准教授
平成 24 年 1 月
提出者
大学院情報理工学研究科 計算工学専攻
10M38160
坂口 嘉一
i
概要
１つのチップに複数のコアを集積するチップマルチプロセッサ（CMP）がプロセッサアーキテク
チャの主流になっている．CMP はプログラムのスレッドレベル並列性（TLP）を利用し，複数のス
レッドを同時に実行することで，高い性能を達成する．チップあたりのコア数は，半導体技術の持
続的な進歩により今後も増加する見通しである．
抽出できるスレッド数はプログラムにより異なる．プログラムの TLP 次第では十分なスレッド
数が得られず，コア数の増加が性能向上につながるとは限らない．一方，十分なスレッドが得られ
る並列プログラムにおいても，並列化が困難な処理（逐次処理）が存在する．アムダールの法則に
よれば，並列プログラムに含まれる逐次処理が全体の性能を制限する．以上のように，CMP におい
ても逐次処理の高速化は重要といえる．
そこで，コア数の増加と逐次処理の高速化を両立するアーキテクチャとして，コア融合アーキテ
クチャが提案されている．コア融合アーキテクチャは，複数のコアが融合し１つの仮想的なコアと
して動作可能なアーキテクチャである．融合した仮想的なコアは，複数のコアのキャッシュや演算
器を利用することで，逐次処理を高速に実行できる．
このようなアーキテクチャの１つとして CoreSymphony アーキテクチャが提案されている．
CoreSymphony は通常のアウトオブオーダ実行プロセッサをベースに拡張を施し，コアの融合を実
現する．2 命令発行のコアが最大 4 つ融合することで，仮想的な 8 命令発行のコアとして動作する．
性能評価はソフトウェアシミュレータを利用し行われているが，実現可能性や有用性を評価するた
めには，CoreSymphony アーキテクチャのハードウェア量や動作周波数の検討が必要となる．
本研究では，CoreSymphony をハードウェア記述言語（HDL）で記述し，FPGA に実装する．こ
れにより，CoreSymphony プロセッサのハードウェア量を明らかにする．論理合成結果のハード
ウェア量は，CoreSymphony のベースとなる標準的なアウトオブオーダ実行プロセッサの 2 倍程度
であり，現実的なハードウェア量で実装できることが明らかになった．
iii
目次
第1章
序論
1
1.1
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
スーパースカラプロセッサ
3
2.1
ベースラインプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
命令フェッチ・デコード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
リネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
スケジュール・実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.5
メモリアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.6
リオーダバッファ (ROB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.7
商用プロセッサとベースラインプロセッサの比較 . . . . . . . . . . . . . . . . . . .
9
2.8
実装結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
コア融合アーキテクチャ
13
第2章
第3章
3.1
コア融合アーキテクチャの背景
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2
コア融合アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
CoreSymphony の実装
15
命令フェッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
第4章
4.1
4.2
4.3
4.1.1
ローカル命令キャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.1.2
分岐予測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.1.3
命令フェッチの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
命令ステアリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.1
リーフノードステアリング . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.2
ステアリングロジック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.3
命令バッファ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.2.4
命令ステアリングの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
リネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
iv
目次
4.4
命令ウィンドウ・命令実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1
4.5
35
命令ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
コミット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.5.1
ローカルリオーダバッファ（LROB）
. . . . . . . . . . . . . . . . . . . . .
39
4.5.2
グローバルリオーダバッファ（GROB） . . . . . . . . . . . . . . . . . . . .
39
4.5.3
ローカルコミットバッファ（LCB） . . . . . . . . . . . . . . . . . . . . . .
40
4.5.4
リモートコミットバッファ（RCB） . . . . . . . . . . . . . . . . . . . . . .
44
4.6
インオーダステートの復帰 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.7
実装のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
評価
47
5.1
コア全体の論理合成結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
命令フェッチユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3
ステアリングユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4
命令ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.5
コミット機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
結論
53
第5章
第6章
参考文献
57
v
図目次
2.1
ベースラインコア．2 命令発行のアウトオブオーダ実行を行う．上：パイプライ
ン構成．下：ブロック図．次のようなブロックから構成される．命令フェッチ
（fetch），命令デコード（decode）, レジスタリネーム（rename），命令ウィンドウ
および実行ユニット（Execution），メモリアクセス（Memory access），リタイア
（retire）．
2.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
命令ウィンドウの構成要素．命令ウィンドウはウェイクアップ論理，セレクト論
理，ペイロード RAM からなる． . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
alpha21264 のパイプライン構成．[2] より． . . . . . . . . . . . . . . . . . . . . .
10
4.1
コミット機構のブロック図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
ローカル命令キャッシュの概要． . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.3
Tree-PHT の構造．タグ，予測結果，飽和型カウンタの木構造からなる．ツリーに
おける青い矩形は，2bit の飽和型カウンタを表す．
4.4
. . . . . . . . . . . . . . . . .
20
上：tree 更新の様子．分岐が成立であった場合はカウンタをインクリメント，不成
立であった場合はカウンタをデクリメントする．下：予測の様子．カウンタの値が
2（2’b10）より大きい場合, 分岐が成立すると予測される.
. . . . . . . . . . . . .
20
4.5
Tree-based Multiple branch Predictor のブロック図 . . . . . . . . . . . . . . . . . .
21
4.6
tree を更新する論理．各カウンタ毎に，分岐結果と古いカウンタ値から新しいカウ
ンタ値を求める． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7
4.8
23
tree から新たな予測結果を求める論理．i 番目の予測結果を，0 から i-1 番目までの
予測結果を使用して選択する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
FB 検出論理．左：FB 検出用の状態遷移図．右：FB 検出論理のブロック図 . . . .
25
vi
図目次
4.9
命令フェッチの HDL シミュレーション波形．(i)FB をフェッチするために，ロー
カル命令キャッシュと従来型命令キャッシュの read enable をアサート．(ii) ロー
カル命令キャッシュにヒット．(iii) ローカル命令キャッシュのヒットしたラインに
含まれる最初の 2 命令を出力．(iv) ストールシグナルがアサートされたため，命令
フェッチを停止．(v) ラインの次の２命令を出力．１つ目の FB のフェッチが完了．
(vi) 次の FB をフェッチするために，read enable をアサート．(vii) ローカル命令
キャッシュにミス．(viii) 従来型命令キャッシュから命令をフェッチ．(ix)FB 検出
論理が FB の終端を検出． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10
26
リーフノードステアリングの例．左は FB のデータフローグラフ（DFG），右はス
テアリング結果である．この例において，DFG は 3 つのリーフノードを持ってい
る． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.11
ステアリングユニットのブロック図および，ステアリングロジックの詳細． . . . .
29
4.12
リーフノード選択論理. リーフノードベクトルからラウンドロビンで自コアに割
り当てるリーフノードを選択する．lim と記された加算器は，出力の最大値が入力
CoreNum で制限され，(CoreNum-1)+1=0 となる． . . . . . . . . . . . . . . . . .
4.13
先祖ノード行列（ANC) および steered leaf から，ステアリングベクトル（steer-
ing_vec) を求める論理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.14
31
32
エントリ構築フェーズから協調フェッチフェーズに移る際に，パイプラインのバイ
パスを考慮しない例．青で示した命令は，ステアリングが必要な命令．赤で示した
ものは，ステアリングが必要ない命令．図中の吹き出しで示すように，パイプライ
ンのバイパスを考慮しない場合，命令の追い越しが発生する. . . . . . . . . . . . .
4.15
33
ステアリングユニットの検証用テストベンチ．テストベンチの入力には，ソフト
ウェアシミュレータで生成した命令フェッチトレースとステアリング結果を用い
る． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.16
命令ウィンドウの周辺 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.17
ウェイクアップ論理の構成．LRF ビット，remote ビットにより，三種類ある比較
器の内，どの結果によりウェイクアップされるかが決まる．Gtag によりウェイク
アップされる場合，束縛される予定の物理レジスタ番号（remote_preg) を取り込む
36
4.18
コミット機構のブロック図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.19
コミット機構のブロック図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.1
配置配線結果. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2
配置配線後のハードウェア規模．Lookup table(LUT) と Flip-Flop(FF)．inorder-SS
はインオーダ実行の２命令発行プロセッサ．out of order は 2 命令発行のアウトオ
ブオーダプロセッサ，CoreSymphony は CoreSymphony アーキテクチャを実装し
5.3
たプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
ステアリングユニットのリソース消費量の比較 . . . . . . . . . . . . . . . . . . . .
49
vii
5.4
ステアリングユニットのリソース消費量の比較 . . . . . . . . . . . . . . . . . . . .
50
5.5
命令ウィンドウのリソース消費量の比較 . . . . . . . . . . . . . . . . . . . . . . . .
51
5.6
コミット機構のリソース消費量の比較 . . . . . . . . . . . . . . . . . . . . . . . . .
52
ix
表目次
2.1
ベースのアウトオブオーダプロセッサのパラメータ . . . . . . . . . . . . . . . . .
5
2.2
アウトオブオーダプロセッサの実装結果 . . . . . . . . . . . . . . . . . . . . . . . .
11
1
第1章
序論
1.1
はじめに
１つのチップに複数のコアを集積するチップマルチプロセッサ（CMP）がプロセッサアーキテク
チャの主流になっている．CMP はプログラムのスレッドレベル並列性（TLP）を利用し，複数のス
レッドを同時に実行することで，高い性能を達成する．チップあたりのコア数は，半導体技術の自
足的な進歩により今後も増加する見通しである．
抽出できるスレッド数はプログラムにより異なる．プログラムの TLP 次第では十分なスレッド
数が得られず，コア数の増加が性能向上につながるとは限らない．一方，十分なスレッドが得られ
る並列プログラムにおいても，並列化が困難な処理（逐次処理）が存在する．アムダールの法則に
よれば，並列プログラムに含まれる逐次処理が全体の性能を制限する．以上のように，CMP におい
ても逐次処理の高速化は重要といえる．
そこで，コア数の増加と逐次処理の高速化を両立するアーキテクチャとして，コア融合アーキテ
クチャが提案されている．コア融合アーキテクチャは，複数のコアが融合し１つの仮想的なコアと
して動作可能なアーキテクチャである．融合した仮想的なコアは，複数のコアのキャッシュや演算
器を利用することで，逐次処理を高速に実行できる．
このようなアーキテクチャの１つとして CoreSymphony アーキテクチャが提案されている．
CoreSymphony は通常のアウトオブオーダプロセッサをベースに拡張を施し，コアの融合を実現す
る．2 命令発行のコアが最大 4 つ融合することで，仮想的な 8 命令発行のコアとして動作する．性
能評価はソフトウェアシミュレータを利用し行われているが，実現可能性や有用性を評価するため
には，CoreSymphony アーキテクチャのハードウェア量や動作周波数の検討が必要となる．
本研究では，CoreSymphony をハードウェア記述言語（HDL）で記述し，FPGA に実装する．こ
れにより，CoreSymphony プロセッサのハードウェア量を明らかにする．
第 1 章 序論
1.2
2
本論文の構成
本論文の構成は次の通りである．2 章では，CoreSymphony のベースであるアウトオブオーダプ
ロセッサについて述べる．3 章は CoreSymphony を含めたコア融合アーキテクチャについて述べ
る．4 章では，CoreSymphony の実装の詳細について述べる．5 章では，HDL 記述を論理合成し，
評価する．最後に 6 章で本論文をまとめる．
3
第2章
スーパースカラプロセッサ
本章では，CoreSymphony のベースとなっているアウトオブオーダ実行を行うスーパースカラプ
ロセッサについて述べる．
2.1
ベースラインプロセッサ
パイプライン化されたプロセッサの実行方式の分け方の 1 つとして，命令をプログラム順に実行
するインオーダ実行か，動的に命令スケジューリングを行うアウトオブオーダ実行か，に分けるこ
とができる．
インオーダ実行のプロセッサ（インオーダプロセッサ）では，プログラムをフェッチした順に実
行する．
一方，アウトオブオーダプロセッサ [1] では，命令の実行順序を実行時に決定する．スケジュー
ルを行う機構が存在するため，インオーダプロセッサに比べ，ハードウェアは複雑になる．しかし，
アウトオブオーダ実行を行うことで，演算ユニットの利用効率を向上やキャッシュミスのレイテン
シを隠蔽が期待できる．
また，プログラム中の命令には，出力依存（WAW ハザード）と逆依存（WAR ハザード）と呼ば
れる，論理レジスタの数が足りないために生じる依存関係がある．これらは，偽の依存の呼ばれる．
レジスタが十分に存在すれば，これらは独立に実行できたはずである．一般的なアウトオブオーダ
プロセッサでは，レジスタリネーミングにより，これらの依存関係を解消する．
アウトオブオーダプロセッサには，Alpha21264[2] や Mips R10000[3] のように複数の実現方式
が存在する．以下では，CoreSymphony アーキテクチャ実装のベースとしているアウトオブオーダ
コア（以下ではベースラインコアと呼ぶ）のアーキテクチャについて述べる．図 2.1 にブロック図
を示す．図上部はパイプライン構成である．フロントエンド 3 段，バックエンド 5 段（整数）から
なる．ベースラインコアのアーキテクチャは，FPGA への実装を考慮している．
アウトオブオーダプロセッサのハードウェアは，大きくフロントエンドとバックエンドに分けら
れる．フロントエンドは命令をフェッチ，デコード，リネームを行う．フロントエンドでは，フェッ
チ順に処理が行われる．
第 2 章 スーパースカラプロセッサ
4
Pipeline Stages
Back end
Front end
Instruction Fetch
IF
Instruction
Decode
ID
Register
Rename
RR
Register Fetch
RF
Issue
IS
Exection
WriteBack
EX
WB
Retire
RT
Decode
p
c
IfId
+
8
i
f
_
p
c
Execution
IdRr
Dec
Inst
EX
RS0
0
mem
Dec
０
RSmul
1
MUL/
DIV
Retire
Bpred
RMT
reg score
board
ROB
PRF
Data
mem
LSQ
Instruction fetch
Free
List
RSmem
RRMT
Rename
図 2.1
align
AGU
EX
1
RS1
Memory
access
Execution
ベースラインコア．2 命令発行のアウトオブオーダ実行を行う．上：パイプライン構成．
下：ブロック図．次のようなブロックから構成される．命令フェッチ（fetch），命令デコード
（decode）, レジスタリネーム（rename），命令ウィンドウおよび実行ユニット（Execution），メ
モリアクセス（Memory access），リタイア（retire）
．
バックエンドでは，命令の実行とリタイアを行う．バックエンドを訪れた命令は，実行順序を決
定する命令ウィンドに投入される．命令ウィンドウは，オペランドの準備ができた命令を, 実行ユ
ニットに対して発行（issue）する．その後，実行が完了した命令は，その後パイプラインをリタイ
アする．
リタイアにより命令の実行結果が確定する．リタイアした命令の結果は，取り消すことができな
い．逆に，分岐ミスなどにより誤ったパスをフェッチし，本来実行してはならない命令を実行して
も，リタイア前であれば命令を取り消せる．リタイアのはリオーダバッファ（ROB）が制御し，プ
ログラム順に行われる．
命令実行の順序は，基本的に命令ウィンドウが決定するが，メモリアクセスは，専用の機構（Load
Store Queue:LSQ）によりスケジュールされる．これは，(i) メモリを介した依存解決に，レジスタ間
とは異なる機構が必要な事，(ii) ストアは一度実行すると，取り消すのが一般的に困難な事による．
CoreSymphony のベースであるアウトオブオーダコアのパラメータを，表 2.1 にまとめる．
2.2 命令フェッチ・デコード
表 2.1
2.2
5
ベースのアウトオブオーダプロセッサのパラメータ
命令フェッチ
2 命令 / cycle
デコード
2 命令 / cycle
リネーム
2 命令 / cycle
命令発行
2 命令 / cycle
物理レジスタ
64 エントリ, 4 リード・2 ライト
実行ユニット
整数 ×2, アドレス計算 ×1, 乗除算 ×1
命令ウィンドウ
整数:16 エントリ ×2, メモリ:8×1, 乗除算:8 エントリ ×1
ROB
32 エントリ
LSQ
16 エントリ
命令フェッチ・デコード
命令フェッチ・デコードは，インオーダプロセッサと大きな違いは存在しない．プログラム順に
命令をフェッチ・デコードする．
ただし，一般的にアウトオブオーダプロセッサは命令がフェッチされてから実行されるまでのレ
イテンシが長い．そのため，分岐予測ミスペナルティがより大きく，分岐予測の精度が性能に与え
る影響が増大する．また，1 度にフェッチする命令数が増えるほど，分岐予測器は複雑になる．
2.3
リネーム
レジスタリネーミングは，論理レジスタをプロセッサ内の物理レジスタにリネームし，偽の依存
関係である，出力依存（WAW ハザード）と逆依存（WAR ハザード）を取り除く．
リネーミに使用するハードウェアは，使用されていない物理レジスタのリストを管理するフリー
リスト，および，論理レジスタと物理レジスタのマッピングを保存するレジスタマッピングテーブ
ル（RMT）である．
フリーリストは，一般的に FIFO で構成され，使用されていない物理レジスタの番号が格納され
ている．デスティネーションレジスタに物理レジスタを割り当てるとき，内容が取り出される．逆
にある物理レジスタが不要になると，フリーリストに返却される．
RMT は，論理レジスタ番号をインデックスとするテーブルであり RAM で構成される．その論
理レジスタに，もっとも最近割り当てられた物理レジスタの番号が格納されている．
リネームの動作は次のようになる．
（1）デスティネーションの割り当て
リネームステージに到着した命令が，結果を論理レジスタに
書き込むものの場合，その命令のデスティネーションレジスタ（ldst）に割り当てるため，フ
第 2 章 スーパースカラプロセッサ
6
リーリストから，使用されていないエントリの番号（pdst）を取り出す．
（2）ソースのリネーム リネームステージに到着した命令のソースレジスタの番号（lsrc）を使用
して RMT を参照し，ソースレジスタに割り当てられている物理レジスタ（psrc）を求める．
（3）pdst の登録
取り出した番号は，RMT の ldst のエントリに書き込まれる．また，書き込みと
同時に，RMT の ldst のエントリを読みだす．このとき得られる物理レジスタの番号は，直
前まで ldst に割り当てられていた物理レジスタの番号である．この番号（ppreg）は，物理レ
ジスタの解放のため，命令のリタイア時に使用される．
複数の命令を同時にリネームする場合，それらの命令間の依存も考慮する必要がある．2 つの命
令 I0, I1 を同時にリネーム場合を考える．I0 の ldst と I1 の ldst が同一である場合，I1 の ppreg は
RMT から読みだされた番号ではなく，I0 の pdst を使用しなければならない．
また，I1 の lsrc が I0 の ldst と等しい場合も，I1 の psrc には，RMT から読み出した値でなく，I0
の pdst を使用しなければならない．
実現に必要なハードウェアについてみる．RMT は，pdst を登録するためのライトポート，ppreg
を読み出すためのリードポート，psrc を読み出すためのリードポートが必要になる．psrc は 1 命令
に 2 つ存在する．そのため，2 命令を同時にリネームするには，2W6R の RAM で RMT を構成す
る必要がある．
フリーリストは，物理レジスタの割り当てと解放のため，それぞれ 2 のポートが必要である．
2.4
スケジュール・実行
リネームされた命令は，バックエンドにディスパッチされる．この時，命令ウィンドウと後で述
べる ROB, LSQ に登録される．
命令ウィンドウは分散型の構成で，１つのウィンドウは 1 サイクルに，1 命令を受け入れ，1 命
令を発行できる．1 つの入力と１つの出力を構造にすることで, FPGA の RAM を効率よく使用で
きる．
命令ウィンドウの構成を 2.4 に示す．命令ウィンドウは大きく分けると，次の 3 つの要素から構
成される．
ウェイクアップ論理 wakeup 論理は，Content Addressable Memory(CAM) により構成される．実
行される命令を監視し，命令ウィンドウ内の命令の状態を管理する．
ウェイクアップ論理のエントリは，エントリが有効かを示す valid ビット，2 つの psrc（psrc0,
psrc1)，およびそれらの値が利用可能かを示すビット (rdy0, rdy1) からなる．
wakeupCAM には入力として，発行された命令の pdst が与えられる．
wakeup CAM の各エントリは，この入力とエントリの情報から，命令が発行可能かを示す
rdy を求め，Select Logic に出力する．
Select Logic Select Logic は wakeup 論理の出力を受け，オペランドがそろい，発行可能な命令の
中から，実際に発行する命令を決定する．
2.5 メモリアクセス
7
Select
Logic
rdy
Wakeup
CAM
issue index
Pay load RAM
Issue inst.
図 2.2
pdst
命令ウィンドウの構成要素．命令ウィンドウはウェイクアップ論理，セレクト論理，ペ
イロード RAM からなる．
Payload RAM 命令の種類や pdst，ROB のエントリ番号などの命令に関する情報を格納する．
Select Logic の結果を受けて，これらの情報を次段のレジスタフェッチステージに出力する．
wakeup 論理の実装には，多数の比較器が必要になる．比較器の数は，命令ウィンドウのエントリ数
とプロセッサの発行幅で決まる．発行幅が 2 命令/cycle，エントリ数 16 の場合，64 個の比較器が
必要である．
命令ウィンドウから発行された命令は，レジスタフェッチステージで物理レジスタを読み出し，
オペランドを得る．また，オペランドを生成するのが，1 つ前のサイクルに発行された命令であれ
ば，フォワーディングによりその結果を受け取る．
次に実行ステージで，命令を実行する．命令がメモリアクセス命令でない場合，実行が完了後，
実行完了を ROB に通知し，必要であれば結果を物理レジスタに結果をライトバックする．
実行されたのがメモリアクセス命令の場合，命令はまだ完了しておらず，ROB への通知やライト
バックは行われない．代りに，実行ユニットで計算したメモリアドレスや，ストア命令であれば，
ストアデータを次に述べる LSQ に登録する．
2.5
メモリアクセス
レジスタを介した依存は，命令ウィンドウで解決できる．一方，ストアからロードの間やストア
同士に存在する，メモリを介した依存の解決には別の機構が必要になる．また，ストア命令は取り
第 2 章 スーパースカラプロセッサ
8
消しが困難なため，命令が確定するリタイア時に行う必要がある．これらを考慮したメモリアクセ
スのスケジューリングは，Load Store Queue（LSQ）が行う．
ロード命令やストア命令といったメモリアクセス命令は，フェッチ順に LSQ のエントリが割り
当てられる．実行ユニットでメモリアドレス，ストアであればさらにストアデータが求まると，そ
のことが LSQ に通知される．
このとき，ロード命令は，同じアドレスを持ち，フェッチ順で自分より古いストアがに存在する
か, LSQ を探索する調べる．そのようなストアが存在するとき，ロードはメモリアクセスを行えな
い．そのロードはストアに依存している．ロードが読むべき値は，メモリにはまだ書かれておら
ず，依存しているストアの実行を待つ必要がある．また，フェッチ順で古く，アドレスがまだ計算
されていないストアが存在する場合，ロードはそのストアに依存している可能性がある. この場合
も，ロードは実行されない．依存するストアが存在しないと判明した場合，ロードはその場で実行
される．それ以外の場合，ロードは LSQ の先頭に到達したとき実行される．
ストアは，アドレスとデータが求まり, ROB の先頭に到達したとき，リタイアと同時に LSQ から
発行される．
LSQ の探索は，命令ウィンドウでのウェイクアップのように CAM により行われる．これまでに
述べた LSQ の場合，アドレスの全ビットを比較する必要は無い．アドレスの一部を比較する場合，
偽陽性は存在するが，偽陰性は無い．そのため，ロードが誤った値を読むことはない．しかし，本
来一致しないはずの命令が探索にかかることは，ロードの実行を遅らせ，性能低下につながる．
以上のような，スケジューリングとメモリアクセスのため，LSQ のエントリは次のフィールドを
持つ．
op
命令のタイプを示す．
address valid アドレスが判明していることを示す．
address 計算されたアドレス．
issued ロード命令である場合，すでにメモリアクセスが発行されたことを示す．
pdst ロード命令のデスティネーションレジスタ．
data ストアがメモリに書き込む値．
rob index 命令に割り当てられた，リオーダバッファのエントリを示すインデックス．
これまでに述べた LSQ は，低機能，保守的である．フォワーディングや投機的な発行により，性
能向上の可能性がある．フォワーディングは，ロードが依存関係のあるストアを発見した場合，メ
モリアクセスを行わず LSQ 内のストアから値を受け取る手法である．この手法を用いる場合，LSQ
の探索では，アドレスの全ビットを比較する必要がある．投機的な発行は，アドレスの不明な先行
ストアを発見した場合に，依存関係を予測する．依存関係がないと予測された場合，ロードはその
場で実行される．このとき，予測に失敗する可能性がある．そのため，予測の正誤を確認するため
の機構が必要になる．以上のような手法は，性能向上の可能性があるが，ハードウェア量の増大も
招く．
2.6 リオーダバッファ (ROB)
2.6
9
リオーダバッファ (ROB)
リオーダバッファ（ROB）は正確な例外を実現する [1]. ROB は First in, First out(FIFO) 構造を持
つ．命令はプログラム順に ROB に登録され，プログラム順に ROB から出る．命令の結果は ROB
からリタイアするときに確定する．
ROB の動作は 3 つのステップに分けることができる．
エントリ割り当て
エントリの割り当てはディスパッチ時に行う．このとき，ROB 末尾のエントリ
が命令に割り当てられる．
実行完了 命令の実行が完了すると，そのことが通知され，ROB は完了した命令をマークする．ま
た，分岐ミスなどの例外が発生した場合も ROB に通知される．
リタイア
実行が完了した命令が ROB の先頭に到達すると，命令はパイプラインをリタイアし，
実行が確定する．このとき，命令が例外を発生させていた場合，ROB はパイプライン全体を
フラッシュする．このフラッシュにより，プロセッサ内に存在する, 例外が生じたものより
後ろの命令は取り消される．誤った分岐予測によりフェッチされた命令は取り消される．
リタイア時，命令は ppreg をフリーリストに返却し，物理レジスタを解放する．ppreg は，リタ
イアする命令 Ii の以前に，Ii が書き込む論理レジスタにマップされていた物理レジスタの番号であ
る．Ii がリタイアすることで，論理レジスタの上書きが確定する．すると以降の命令で，ppreg で
示される物理レジスタの値を必要とする命令は存在しないと保証される．そのため，ppreg を解放
し，再利用することができる．
フロントエンドに存在する RMT は，フェッチされた命令により更新されていく．そのため，プ
ロセッサがフラッシュされる場合，RMT は例外を発生させたもの以降の命令により，エントリが
更新されている．正しく実行を再開するためには，例外を発生させた命令をリネームする直前の状
態に，RMT を復元する必要がある．
これを行うため，Retirement Regisiter Map Table(RRMT) を使用する．RRMT は RMT と同様の
機構である．異なる点は，更新されるタイミングである．RMT はリネームステージに到達した命
令が更新するが，RRMT はリタイアする命令が更新する．フラッシュ時，RRMT の内容を RMT に
コピーすることで，例外を発生させた命令をリネームする直前の状態に復元できる．
2.7
商用プロセッサとベースラインプロセッサの比較
CoreSymphony のベースとするため実装したプロセッサについてまとめ商用プロセッサの比較す
る．図 2.7 に代表的な商用アウトオブオーダ実行プロセッサの１つである，Alpha21264 のパイプラ
イン構成を示す．
ベースラインコアは，Alpha21264 を参考にしているためパイプライン構成は類似している．し
かし，CoreSymphony のベースであり，また，FPGA を実装対象としているベースラインコアとカ
第 2 章 スーパースカラプロセッサ
図 2.3
10
alpha21264 のパイプライン構成．[2] より．
スタム CMOS ロジックで設計され，高い性能を志向している Alpha には，多くの相違点がある．
最大の相違点は発行幅である．Alpha は 4 命令発行のパイプラインだが，ベースラインコアは 2
命令発行である．CoreSymphony のベースには，小規模なアウトオブオーダコアが望ましいためで
ある．
実装対象の違いが表れている相違点に，命令ウィンドウの構成がある．Alpha の命令ウィンドウ
は古い命令を優先して発行できる．選択論理で優先すべき命令を容易に判別するため，ウィンドウ
内で命令は古い順に整列している．この命令ウィンドウは，シフトレジスタのようなキューで構成
されている．先頭以外の命令を発行した場合，その命令の後続エントリを先頭に方向にシフトし，
隙間を埋める. 一方，FPGA でこのような実装を行う場合，RAM を使用できない．LUT と FF だ
けでウィンドウを構成する必要があり，シフトも必要なため，非常に多くのリソースを消費する．
ベースラインコアでは，リソース消費量を抑えるため古い命令の優先を行わない，異なる方法で命
令ウィンドウを実装している．フリーリストにより空きエントリを管理している．命令の割り当て
はフリーリストから空きエントリを取り出し行う．命令が発行されエントリが空いた場合，フリー
リストに空きエントリが返却される．そのため，ウィンドウ内で命令の順序に規則性が存在しない．
このような場合，古い命令を優先的に発行するには，追加のハードウェアが必要であり，リソース
や遅延的に困難である．しかし，エントリの部分的なシフトを行わないため，FPGA の RAM を実
装に使用できる．結果，リソースの消費を抑制できる．
2.8
実装結果
最 後 に ベ ー ス ラ イ ン コ ア の 実 装 結 果 に つ い て ま と め る ．Xilinx 社 の Spartan-6 シ リ ー ズ の
XC6SLX45 をターゲットに論理合成・実装を行った．FPGA の実装リソースであるルックアッ
プテーブル (LUT) の占有量，動作周波数，ベンチマークソフトである Dhrystone2.1 の実行結果を
2.8 実装結果
11
表 2.2 にまとめる．動作周波数は，FPGA 上で動作が確認できた値である．記述は Verilog HDL で
行い，コード行数は約 5000 である．
表 2.2
アウトオブオーダプロセッサの実装結果
LUT 使用量
8978(キャッシュ・IO を除く)
動作周波数
50 MHz
Dhrstone
34.25 DMIPS
13
第3章
コア融合アーキテクチャ
この章では，コア融合アーキテクチャについて述べる．ここでは，複数個のコアの協調動作によ
り，強力な仮想コアを構成するものをコア融合アーキテクチャと呼ぶ．CoreSymphony もコア融合
アーキテクチャに属する．
コア融合アーキテクチャの背景
3.1
コア融合アーキテクチャの前提であるチップマルチプロセッサ (CMP) は，多数のスレッドを同
時に実行することで高い性能を達成する．CMP における課題として次のようなものが挙げられて
いる．
並列プログラムに含まれる逐次処理による制限
並列プログラムであっても，並列化の困難な部分
（逐次処理）が存在する．アムダールの法則 [4] を用いて述べられるように，逐次処理が CMP
の性能を制限する．例として，プログラムの 90% が並列化可能なプログラムについて考え
る．アムダールの法則によれば，このプログラムを 100 個のスレッドに分割し並列実行した
としても，性能向上は 10 倍に制限される．
ワークロードよるスレッド数とコア数のミスマッチ
ポラックの法則 [5] で示されるように，コア
1 つあたりの面積とその性能の間には正の相関が存在する．それゆえ，コア数と逐次性能は
トレードオフの関係にあると考えられる．プログラムから得られるスレッド数は，プログ
ラムにより異なる．最適なコア数と逐次性能のバランスはプログラム毎に異なる．しかし，
CMP のコアのアーキテクチャとコア数は設計時に決定される．そのため，CMP が性能を発
揮できるプログラムの幅には限りがある．例えば，スレッド数に対してコア数が少なければ，
TLP を有効に生かせず，
これらを解決する手法としてコア融合アーキテクチャが提案されている．コア融合アーキテクチャ
は，複数のコアが融合し１つの仮想的なコアとして動作可能なアーキテクチャである．融合した仮
想的なコアは，複数のコアのキャッシュや演算器を利用することで，逐次処理を高速に実行できる．
第 3 章 コア融合アーキテクチャ
3.2
14
コア融合アーキテクチャ
Core Fusion[6] はアウトオブオーダをベースとしたコア融合機構である．2 命令発行のコアを最
大 4 個融合させて 8 命令発行を実現する．Core Fusion はクラスタ型アーキテクチャと非常に近い
構成をとる．そのため，多くのクラスタ型アーキテクチャと同様，ステアリング，リネームといっ
たフロントエンドの制御を集中化しておこなう必要がある．また，協調動作のため多くの通信を
行う．
Anaphase[7] はコンパイラのサポートによりコア融合を実現する．逐次プログラムをコンパイル
時に細粒度のマルチスレッドプログラムに分割し，複数コアで実行する．各コアはメモリアクセス
のコヒーレンスを保つための特別な HW を備える．コンパイラのサポートを利用することで HW
の変更を小規模に抑え，高い面積効率を実現している．
Composable Lightweight Processors[8] はデータフロー型の命令セットを利用するプロセッサであ
り，スーパースカラを対象とする CoreSymphony とは方向性が異なる．
CoreSymphoy は，次の 3 点を満たすコア融合アーキテクチャを目指している．
コアの独立性維持
各コアが高い独立性を持つことで，設計の容易性が得られる．また，不良コア
や故障が生じたコアの影響を限られた範囲に抑えることができる．それゆえ，複数のコアを
またぐ，集中した制御機構の存在は望ましくない．
アーキテクチャ技術の連続性
コア融合を実現するため，従来のプロセッサに変更を加える必要が
ある．CoreSymphony ではアウトオブオーダプロセッサをベースアーキテクチャとして変更
点をなるべく小さく留める．これにより，従来のアーキテクチャ技術からの連続性，実現可
能性を高める．
バイナリ互換性の維持
[7] や [8] のように，コンパイラや命令セットによる支援は，コアの融合に
より生じる各種制御の複雑さを緩和する有効な手段である．しかし，CoreSymphony では従
来型の RISC 命令セットによるコア融合を目指す．これより，既存のコンパイラ最適化技術
の利用とバイナリの連続性を維持できる.
15
第4章
CoreSymphony の実装
この章では，CoreSymphony アーキテクチャの実装について述べる．CoreSymphony 全体のブ
ロック図を 4.7 に示す．ベースの標準的なアウトオブオーダコアとの大きな違いとして，
• 協調して命令フェッチを行うため，ローカル命令キャッシュの追加
• ステアリングステージの追加
• 2way-リネーミングの採用
• 命令ウィンドウの機能拡張
• グローバルリオーダバッファ (GROB) 追加などのコミット機構の拡張
が挙げられる．以下では，CoreSymphony のモジュール毎に実装について述べる．
4.1
命令フェッチ
CoreSymphony の命令フェッチは
• 分散可能な命令キャッシュ
• パイプライン後段における命令間の依存解決に必要な情報の供給
• 協調動作しているコアのコントロールフローの同期
協調による性能向上のため，２種類の命令キャッシュを持つ．1 つは従来型の命令キャッシュで
ある．もう 1 つは，ローカル命令キャッシュと呼ばれるものである．
CoreSymphony は，フェッチブロック（FB）と呼ばれる命令トレース単位で, フェッチやステア
リングを行う．FB の長さは，
（協調コア数）× 4 命令もしくは，基本ブロック２つ，いずれか短いも
のである．
第 4 章 CoreSymphony の実装
16
Local
I-$
TMP
Instruction, Control
Conventional
I-$
(1)
Data
(1)
Hit/Miss
Decode/Steering
Inter-core network
(2)
(2)
Free
List
(3)
LRMT
GRMT
(5) (4) (1)
(1)
(3)
to filter
younger
(1)
(1)
(1)
(2)
Global
Re-order
Buffer
Local
Re-order
Buffer
(4) (3) (2)
(3)
Instruction
Window
(2)
(1)
(3)
(4)
L/S Comm.
(1)
bank=n?
LRF
(2) (4)
(2) (3)
Execute
LCB RCB
(3)
Commit/Spec.
Comm.
PRF
(3)
filter
(1)
(2)
Recons. Comm.
Commit
D-$
(2)
(3)
(1)
ULB-LSQ
Local Retire
(1)
Comm.
(1)
Operand Comm.
図 4.1
4.1.1
コミット機構のブロック図
ローカル命令キャッシュ
ローカル命令キャッシュは，FB の内で自コアにステアリングされた命令と，FB 間の依存解決に
必要な情報を格納する．トレースキャッシュの１種といえる．ローカル命令キャッシュの 1 つのラ
インは，基本的に１つの FB に対応する．
FB を分割してフェッチするには，次の２つのフェーズを経る必要がある．
エントリ構築フェーズ
ローカル命令キャッシュにミスした場合，フェッチはエントリ構築フェー
ズに移行する．従来型命令キャッシュから FB に含まれる全命令を読み出し，デコードとス
テアリングを行う．その後，ローカル命令キャッシュの当該エントリに，自コアにステアリ
ングされた命令を格納する．
協調フェッチフェーズ
ローカル命令キャッシュにヒットした場合，協調フェッチが行われる．こ
の場合，各コアは自身にステアリングされた命令のみをフェッチするため，フロントエンド
のスループットは，N コア協調時，最大で N 倍になる．
4.1 命令フェッチ
17
ローカル命令キャッシュのエントリは次に示すフィールドを持つ．１ラインは 254bit である．
TKN branch slot(4bit) FB 内において，分岐成立と予測されている１つ目の命令の位置を示す.
next addr(32bit) TKN branch slot で示された命令の分岐先を示す．PC の計算に使用する．
branch pattern(2bit) FB に含まれる分岐の分岐パターンである．ローカル命令キャッシュの
hit/miss 判定は，タグの一致に加え，後述する TMP による分岐予測結果と，この branch
pattern の一致を必要とする．
branch num(2bit) FB に含まれる分岐の数を示す．TMP における GHR の投機的な更新に使用
する．
next pc(32bit) この FB の次にフェッチすべき命令のアドレスを示す．BTB の一部と考えること
ができる．次に述べる line over flag がセットされている場合，このフィールドには，溢れた
命令を格納しているエントリを示す PC が格納される．
line over flag(1bit) ステアリング結果によっては，4 を超える命令が割り当てられる．その場合，
この flag をセットし，次のエントリに溢れた命令を格納する．
destination vector(33bit) FB が結果を生成する論理レジスタを示すベクトル．長さは論理レジス
タの数に依存する．n ビット目が１であることは，n 番目の論理レジスタに結果を書き込む
命令がこの FB に含まれることを表す．FB 間の依存解決などに使用する．
steered instruction(4 × 32bit) 自コアに割り当てられた命令を格納するフィールド．
bradcast flag(4 × 1bit) 各命令が，協調中の他のコアに結果を放送する必要があるか示すフラグ．
slot number(4 × 4bit) 各命令が，FB において何番目の命令かを示す．
実装したローカル命令キャッシュの構成を図 4.1.1 に示す．ローカル命令キャッシュへのフィル
に関する信号は，省略している．ローカル命令キャッシュが，実装において通常のキャッシュと異
なる点は，次の３点である．
• ヒット/ミスの判定に，タグだけでなく，分岐予測結果を使用する（図 4.1.1 における Hit/Miss
detection で示される部分）
• 命令の PC を計算する必要がある．コンベンショナルな命令キャッシュでは，命令の PC は，
フェッチ時の PC とフェッチ幅から分かる．ローカル命令キャッシュには，ステアリング
された命令のみが格納されているため，ラインに含まれる命令間オフセットは一定ではな
く，分岐を跨いでいる可能も存在する．そのため PC は，TKN slot, next addr, 各命令の slot
number から求める必要がある．計算のため，32bit 程度の加算器や，マルチプレクサが必要
になる．
• フィルデータは，メモリや下位のキャッシュではなく，ステアリングステージが与える．ミ
ス時の動作や，フィル制御が簡略化される．
FB の制御情報などは，従来型命令キャッシュでは保持されない．しかし，これらはキャッシュ
の Payload RAM のサイズには影響を与えるが，それ以外では，ハードウェア構成にほぼ影響を与
えない．
第 4 章 CoreSymphony の実装
18
PC,
read enable
tag
RAM
Payload RAM
branch pattern
bpred
TKN_slot,
nextaddr, slot
tag match
PC
bpred
Hit / Miss
detection
calc
match
next pc
hit
slot number
destination vector
branch num
branch pattern
steered instructions
FB’s control info
instruction,
broadcast flag
図 4.2
4.1.2
pc
ローカル命令キャッシュの概要．
分岐予測
すべてのコアで同一のパスをたどるため，CoreSymphony において分岐予測は，すべてのコアで
多重化している．分岐予測の分散は行われず，協調時の最大フェッチ幅に対応できる分岐予測器を，
すべてのコアが持たなければならない．
CoreSymphony では，予測器の複雑性を低減しつつ，性能を向上するため，トレースキャッシュ
向けの予測器の一つである Tree-based Multiple Branch Predictor（TMP）[9] を適用している．TMP
では，トレース（FB）単位で予測器のエントリを割り当てる．先に述べたように，FB の最大長は
協調コア数に比例する．FB の平均長が増すと，プログラムにおける静的な FB の数が減少する．そ
のため，協調コア数が増えると TMP におけるエントリの競合が減少し，予測性能が向上する．
Tree-based Multiple branch predictor
TMP の概要を図 4.1.2 に示す．TMP は，分岐予測における複雑な動作を，フロントエンドでの
予測時ではなく，予測器の状態更新時に行う．そのため，複数の分岐について予測を行いつつ，フ
ロントエンドでの予測レイテンシを削減できる．
TMP は，Tree-based Pattern History Table（Tree-PHT）を参照し予測する．Tree-PHT の参照に使
用するインデックは，PC とグローバル分岐履歴を保持するグローバル分岐履歴レジスタ（GHR）
の値の排他論理和により求める．図 4.1.2 に，Tree-PHT の示す．Tree-PHT のエントリは，次の
4.1 命令フェッチ
19
フィールドを持つ．
タグ（tag）
キャッシュにおけるタグと類似した役割をする．エントリの内容が，入力に対する
ものかの判定に用いる．
予測結果（predicted path） 複数の分岐に関する測結果である．フロントエンドでの予測時に読
み出される．値は，エントリの更新時に変更される．
2bit 飽和型カウンタのツリー（tree） 予測結果フィールドの計算に使用する．2bit の飽和型カウ
ンタからなる木構造で，この tree をトレースし，予測結果を求める．
tree は，ある PC から始まる命令トレースがたどる可能性のあるパスを示す．１つの飽和型カウ
ンタは，トレース中の１つの分岐に対応する．カウンタの値が 2（2’b10）より大きい場合, 分岐が
成立すると予測される．成立である場合に現れる次の分岐は左のエッジを進んだノードが，成立し
ない場合の次の分岐は右のエッジを進んだノードが，それぞれ対応する．
tree の更新と予測結果の更新，およびフロントエンドでの予測は以下のように行う．図 4.1.2 を
使用して説明する．
tree の更新 更新には実際にプログラムがたどったパスを使用する．そのときのパスが{成立，不
成立，不成立，成立}であったとする．このパスを使用してツリーをたどり，更新すべきカ
ウンタを得る．4.1.2 に示した，カウンタの番号で表現すると，このとき更新するのは，{c0,
c2, c4, c8}である．それぞれの分岐について，成立であればカウンタをインクリメント，不
成立であればカウンタをデクリメントする．
予測結果フィールドの更新
ルートにあたるカウンタを参照し，トレース中の初めの分岐について
の予測をえる．図 4.1.2 では，カウンタの値が 2 であるので，１つ目の分岐は成立と予測され
る．成立であるので左のエッジにつながったカウンタを使用し，次の分岐予測を行う．この
ように図 4.1.2 に示したツリーをトレースすると，{c0, c2, c4, c8}を辿る．予測結果として，
{成立，不成立，成立，不成立}が得られる．この予測結果を，Tree-PHT の予測結果フィール
ドに格納する．
フロントエンドでの予測
フロントエンドでの分岐予測は，PC と GHR の排他論理和により Tree-
PHT を参照する．まず，PC と GHR に対して，参照したエントリが有効かを確認する．こ
れは Tree-PHT の参照に使用したインデックスの下位ビットとタグを比較して行う．一致す
れば，分岐予測結果は有効である．有効ならば，予測結果フィールドを予測結果として使用
する．一致しない場合は実装によるが，すべて分岐成立など，前もって決められた値を使用
する．
TMP の実装
ここでは，TMP の実装について述べる．
TMP の構成要素は次のように分かれる，Tree-PHT，Tree-PHT の更新を行う update pipe，およ
び，update pipe への入力をまとめる，pattern gen から構成される．
第 4 章 CoreSymphony の実装
20
tree
predicted path
tag
treePHT
c0
content of tree
c1
c2
c6
c14
c4
c10
c12
c3
c5
c13
c8
c9
c11
c7
2bit saturating counter
図 4.3
Tree-PHT の構造．タグ，予測結果，飽和型カウンタの木構造からなる．ツリーにおける
青い矩形は，2bit の飽和型カウンタを表す．
taken
branch path = { taken, untaken, untaken, taken}
counter to update = {c0, c2, c4, c8}
untaken
01
01
11
01
11
00
01
10
01
00
00
00
10
11
00
2bit saturating counter
UPDATE
taken
predicted path
= {taken, untaken, untaken, untaken}
untaken
10
01
01
01
00
01
00
11
00
00
00
00
10
11
00
2bit saturating counter
図 4.4 上：tree 更新の様子．分岐が成立であった場合はカウンタをインクリメント，不成立で
あった場合はカウンタをデクリメントする．下：予測の様子．カウンタの値が 2（2’b10）より大
きい場合, 分岐が成立すると予測される.
4.1 命令フェッチ
21
fbpc / fb_retire / branch / br_pat
flush
pattern
gen
sghr
ghr
fbpc
update pipe
tag/v RAM
tree read
tree PHT
tree update
result RAM
lookup
hit
result
/ predict
write back
new_tree / new_result / new_tag
図 4.5 Tree-based Multiple branch Predictor のブロック図
Tree-PHT
Tree-PHT は，RAM で構成される．各フィールドは読みだされるタイミング・インデックスが異
なるため，それぞれ別の RAM として実装される．
tag RAM タグを格納する．この RAM は，更新の開始時と完了時，およびフロントエンドでの予
測時に参照されるため，3 つのポートを持つ．
result RAM 予測結果を格納する．更新完了時とフロントエンドでの予測時に使用され，2 つの
ポートを持つ．
tree RAM tree を格納する．tree は，飽和型カウンタ自体としてではなく，カウンタ値の列として
格納されている．このフィールドの i 番目には，図 4.1.2 におけるカウンタ ci の値が格納さ
れる．tree RAM は更新の開始時と完了時に使用され，2 つのポートを持つ．
更新開始，更新完了，フロントエンドでの予測は，それぞれ短くとも, 2 サイクル毎にしか発生しな
い．これは，CoreSymphony において，フェッチやリタイアのスループットが最大で 1 サイクルに
1FB に限られるのに対し，TMP は，2FB 単位で更新や予測を行うためである．このような理由の
ため，3 種類の要求の間でポートを共有することで，必要なポート数を削減できる可能性がある．
ポートを共有する場合，使用要求間の調停論理が必要になる．また，一方を待たせるための記憶容
量も必要である．
第 4 章 CoreSymphony の実装
22
FPGA への実装においては，ハードマクロとして用意されている RAM の数に余裕があるため，
ポートの共有は行わない．
ポート共有を行う場合，ポートの種類に注意が必要である．ポート種類には，読み出しのみ (リー
ドポート)，書き込みのみ (ライトポート)，および読み書き両方可能 (リードライトポート) の３種
類が考えられる．例えば，更新の開始と完了に使用するポートを共有する場合，開始時は RAM の
読み出し，完了時は書き込みを行うため，リードライトポートが必要である．
GHR および pattern gen
Tree-PHT の参照には，GHR を使用する．Tree-PHT の更新時と，フロントエンドでの予測時で
は別の GHR を使用する．
更新時は，投機的でない GHR（ghr）を使用する．この ghr は，パイプラインをリタイアする分
岐命令によって更新され，プログラムの真の分岐履歴を保持している．
フロントエンドで使用する GHR は投機的な GHR（speculative ghr : sghr）である．これは，通常
はフロントエンドでの予測結果に基づき更新される．パイプラインがフラッシュされるとき，sghr
はそのときの ghr の値で上書きされる．
pattern gen は，分岐履歴の蓄積と，update pipe の起動を行う．CoreSymphony において，TMP に
対する分岐結果の供給は，FB のリタイア時に行う．Tree-PHT の更新には FB ２つの分岐履歴を必
要とする．そのため，pattern gen はリタイアした FB の分岐履歴を一時的に保存し必要な数集まっ
たところで，update pipe の渡す．
update pipe
update pipe では，tree の更新と予測を行い，Tree-PHT の予測結果フィールドに格納する．update
pipe は，Tree-PHT を読みだすツリーリードステージ，tree を更新し，予測を行うツリー更新・予測
ステージ，Tree-PHT を更新するライトバックステージの３段からなる．
ツリーリードステージ
このステージでは，pattern gen から与えられた Tree-PHT のインデックス
を使用して，tag RAM および tree RAM を読みだす．読みだしたタグが一致する場合，tree
RAM の値を次のステージに渡す．一致しない場合，予め決められたツリーの初期値を渡す．
ツリー更新・予測ステージ
このステージの動作は更新と予測に分かれる．古い tree の値から，新
しい tree の値を計算する論理を図 4.1.2 に示す．tree のカウンタ毎に，count element が存在
する．count element の詳細を図の右側に示す．この論理は，3 つの入力（s,i,u) を取る．
s
s は，対応するカウンタが，更新対象であるかを示す．tree のルートである c0 は，s が
常に１である．tree において，深さが n であるノードの s 入力は，分岐結果の下位 (n-1)
ビットから決まる．
i
i は, 古いカウンタの値である．
u
u は，カウンタが更新対象であった場合に，インクリメントするか，デクリメントする
かを決める．深さが n であるノードの u 入力は，n 番目の分岐結果である．
4.1 命令フェッチ
23
old counter value
branch pattern c8
c4
c7
c2
c3
count element
c0
c1
u
1
u i s u i s
o
u i s u i s
u i s
u i s
o
o
o
o
o
o
u i s
i
s
sat
o
new counter value
図 4.6
tree を更新する論理．各カウンタ毎に，分岐結果と古いカウンタ値から新しいカウンタ値を求める．
counter value
c14
c13
c12
c11
c10
c9
c8
c7
c6
c5
c4
c3
c2
c1
c0
predicted result
図 4.7
tree から新たな予測結果を求める論理．i 番目の予測結果を，0 から i-1 番目までの予測
結果を使用して選択する
出力は，s が 0 であれば i，そうでないときは，i をインクリメントがデクリメントした値で
ある．
図に 4.1.2 に新しいカウンタの値から予測を行う論理を示す．2 対 1，4 対 1, 8 対 1 の３種の
マルチプレクサ１つずつからなる．各マルチプレクサは，2 番目，3 番目，４番目の分岐を
予測する．i 番目の予測結果は，0 から i-1 番目までの予測結果により選択される．
ライトバックステージ
このステージでは，計算された tree の各カウンタ値と予測結果，および新
しいタグの値をそれぞれの RAM に書き戻す．
第 4 章 CoreSymphony の実装
4.1.3
24
命令フェッチの制御
CoreSymphony における命令フェッチは，エントリ構築フェーズと協調フェッチフェーズの 2
フェーズからなる．命令フェッチユニットは，これらのフェーズの開始と終了を検出し，ローカル
命令キャッシュおよび，従来型命令キャッシュを適切に制御する．この制御のため，２つの制御
論理が存在する．１つは，命令フェッチ全体を制御する PC 制御論理，もう一つは，エントリ構築
フェーズを制御する FB 検出論理である．
命令フェッチユニットには，ローカル命令キャッシュ，TMP，従来型命令キャッシュおよび従来型
命令キャッシュからのフェッチ時に使用する，分岐ターゲットバッファ（Branch Target Buffer:BTB）
が存在する．PC 制御ユニットは，これらのモジュールに与える PC と，読み出し信号（read enable
signal）を制御する．
FB 検出論理の概要を図 4.1.3 に示す．図の左は，FB の終端を検出するためのステートマシン状
態遷移図である．フェッチブロックの長さは，最大で (融合コア数) × 4 と述べてきた．正確には，
(融合コア数) × 2 命令もしくは分岐命令を終端とする命令ブロック（以下ではフィジカルブロッ
ク:PB と呼ぶ）2 つが FB の長さである．ステートマシンは，従来型命令キャッシュからフェッチ
された命令と，ローカル命令キャッシュのヒット/ミスにより状態を遷移させる．状態遷移図おける
状態名 PBi_j は，次にフェッチする命令がフィジカルブロック i の j 番目の命令であることを示す．
図 4.1.3 の状態遷移図では，PB0_4 から PB0_7 と PB1_4 から PB1_7 を省略している．
初期状態は，1 つ目の PB 最初の命令を待つ PB0_0 である．この状態でローカル命令キャッシュ
にミスすると，状態遷移を開始する．このとき，命令フェッチはエントリ構築フェーズに移行する．
現在ステートが，初期状態でないとき，状態遷移は以下のように発生する．
• フェッチした命令が分岐命令である場合，PBi+1_0 に遷移する．ただし，i が 1 の場合，
PB0_0 に遷移する．
• フェッチした命令が分岐命令でなく，かつ，j が融合コア数に等しい場合（PBlim），PBi+1_0
に遷移する．ただし，i が 1 の場合，PB0_0 に遷移する．
• フェッチした命令が分岐命令でなく，かつ，j が融合コア数より小さい場合，PBi_j+1 に遷移
する．
命令が分岐命令であるかの判定は，BTB にエントリが存在するか否かで判定する．
CoreSymphony では，従来型命令キャッシュから最大で 2 命令を 1 サイクルでフェッチできる．
そのため，1 サイクルの２回の状態遷移が起こることがある．この場合，状態遷移図を修正し，２
つの命令を入力として次の状態を求める論理を実装することで，FB 終端の検出ができる．しかし，
実際の実装では，図 4.1.3 右のように，1 つの命令を入力として次の状態を求める論理 (図中の Next
state) を直列に接続している．この方法は，回路の規模や遅延が，遷移図を修正する場合に比べて増
加する可能性がある．しかし，記述やデバッグが容易であること，2 つ実装しても回路規模は，他
のモジュールに比べ小さいことから，前述の方法で実装した．
4.2 命令ステアリング
state diagram of FB detection
hit L-cache /
miss L-cache
not branch
&& not branch not branch
&& !Pblim /
&& !Pblim /
&& !Pblim /
PB0_2
PB0_1
PB0_0
PB0_3
25
inst 0
inst 1
Next State 0
Next State1
hit L-cache
branch or PBlim
not branch
not branch
not branch
&& !Pblim /
&& !Pblim /
&& !Pblim /
PB1_2
PB1_1
PB1_0
PB1_3
FB end at 1
FB end at 0
branch or Pblim / detect FB end
state register
図 4.8 FB 検出論理．左：FB 検出用の状態遷移図．右：FB 検出論理のブロック図
2 命令ずつフェッチする場合，1 つ目の命令が FB 終端になる場合が存在する．この場合，注意
が必要である．２つ目の命令は次の FB に含まれる命令であるが，その FB はローカル命令キャッ
シュからフェッチできる可能性がある．そのため，1 命令目が FB 終端である場合，２命令目を無
効化し，次のサイクルに無効化した命令のアドレスで，フェッチを行う．
命令フェッチの動作例
図 4.1.3 に，HDL シミュレーションによって得られた，命令フェッチユニット動作時の波形を
示す．
この例では，最初のフェッチで，ローカル命令キャッシュにヒットしている (図の (ii))．協調
フェッチフェーズに移行する．2 つ目の FB をフェッチするときでは，ローカル命令キャッシュにミ
スしている（図の (vii))．エントリ構築フェーズに移行し，従来型命令キャッシュから命令をフェッ
チしている．
4.2
4.2.1
命令ステアリング
リーフノードステアリング
CoreSymphony ではステアリングアルゴリズムに，リーフノードステアリングを使用する．
このアルゴリズムによるステアリングの例を，図 4.2.1 に示す．図の左側は FB のデータフローグ
ラフ（DFG），右側はステアリング結果である．リーフノードステアリングは，FB のデータフロー
グラフ (DFG) におけるリーフ命令に着目する．図 4.2.1 の DFG では，リーフ命令を赤く示されて
いる．
まず，リーフ命令 (図では I3, I4, I6) を各コアにラウンドロビンで割り当てる．そして，リーフ命
令の先祖となる命令をすべて，リーフ命令を同じコアに割り当てる．ここで，ある命令の先祖とは，
DFG 中において，その命令からルートに至るまでのパスに含まれる命令である．例えば，図 4.2.1
における I4 の場合，先祖は I2, I1, I0 である．このアルゴリズムでは，同一 FB 内での通信を一切
発生させず，また，ある程度の負荷分散が期待できる．
第 4 章 CoreSymphony の実装
26
dne BF tceted)xi(
BF fo dne ,ehcaC-L
morf
ehcaC-L
morf
noitcurtsni 2 tsrif )iii(
ehcac-I .vnoC
)i(
dna )ehcac-L(
elbane daer
ehcac noitcurtsnI lacoL
ehcac
noitcurtsnI lacoL tih )ii(
esahp hctef evitarepooc
noitcurtsni 2 txen )v(
ehcac-I .vnoC
morf hctef )iiv(
esahp noitcurtsnoc ecart
ssim ehac-L )iiv(
BF txen hctef ot
elbane daer)iv(
langis llats )vi(
図 4.9
命令フェッチの HDL シミュレーション波形．(i)FB をフェッチするために，ローカル命
令キャッシュと従来型命令キャッシュの read enable をアサート．(ii) ローカル命令キャッシュに
ヒット．(iii) ローカル命令キャッシュのヒットしたラインに含まれる最初の 2 命令を出力．(iv)
ストールシグナルがアサートされたため，命令フェッチを停止．(v) ラインの次の２命令を出力．
１つ目の FB のフェッチが完了．(vi) 次の FB をフェッチするために，read enable をアサート．
(vii) ローカル命令キャッシュにミス．(viii) 従来型命令キャッシュから命令をフェッチ．(ix)FB
検出論理が FB の終端を検出．
4.2 命令ステアリング
27
replicated inst.
leaf node
Ｉ０
Ｉ０
leaf node
steering
1
Ｉ
Ｉ
3
2
Ｉ
4
Ｉ
Ｉ
1
3
5
Ｉ
6
Ｉ
5
1
Ｉ
6
Ｉ
Ｉ
Ｉ
Ｉ０
Ｉ
2
Ｉ
4
no dependency
図 4.10
リーフノードステアリングの例．左は FB のデータフローグラフ（DFG），右はステア
リング結果である．この例において，DFG は 3 つのリーフノードを持っている．
リーフノードステアリングは，２つのフェーズに分割して行う．1 つめのフェーズでは DFG を解
析し，先祖ノード行列 (Ancestor-node matrix) とリーフノードベクトル (Leaf-node vector) を構築す
る．2 つめのフェーズは，構築した行列とベクトルを基に，コアに割り当て，ステアリング結果を
確定する．
(1) 先祖ノード行列，リーフノードベクトル構築フェーズ
以降では，FB において i 番目の命令を Ii と表す．まず，先祖ノード行列とリーフノードベクト
ルを定義する．
先祖ノード行列は，16 × 16bit のビット行列である（16 は FB の最大長）．先祖ノード行列の i 行
目を ANC[i] と表し，Ii の先祖ベクトルと呼ぶ．ANC[i] の j ビット目が１のとき，I j は Ii の先祖で
ある．
命令 Ii が I j と Ik に真のデータ依存を持つ場合，ANC[i] は次のように計算できる．ei は基本ベク
トルを意味し，| はビット論理和演算子である．
ANC[i] = ei |ANC[ j]|ANC[k]
リーフノードベクトル L は，FB 中のリーフノードを表すベクトルである．Ii がリーフノードで
あるとき，L の i ビット目である L[i] は１である．
第 4 章 CoreSymphony の実装
28
図 4.2.1 の FB を例に，本フェーズの動作を解説する．命令は 2 命令/cycle でステアリングステー
ジに訪れる．
初期化
リーフノードベクトルは，全要素を１で初期化しておく．
1 サイクル目（cycle t) (I0 , I1 ) がステアリングステージに訪れる．I0 は依存する命令が無いため，
ANC[0]=e0 とする．続く I1 は I0 に依存しているため，ANC[1] = e1 |ANC[0] と計算できる．
I0 の結果は I1 に利用されるため，I0 はリーフノードではない．よって L[0] = 0 とする．
2 サイクル目 (cycle t+1) (I2 と I3 ) が訪れる．I2 は I1 に依存するため，ANC[2] = e2 |ANC[1] であ
る．同様に，ANC[3] = e3 |ANC[1] と計算できる．I1 の結果は，I2 と I3 が利用するため，I1
はリーフノードではない．L[1]=0 とする．
以上のステップを FB の終わりの命令（この例では I6 ) まで続けると FB 中の全命令の解析が終了
し，ANC と L が求まる．
(2) ステアリング結果確定フェーズ
本フェーズでは，構築した先祖ノード行列をもとにステアリング結果を確定する．L[i]=1 となる
リーフ命令 Ii が自コアに割り当てられた場合とき，先祖ノード行列の第 i 行を読みだすことで，自
コアにステアリングされた命令群が得られる．
以降では，命令ステアリングを行う，命令ステアリングユニット（STU）の実装について述べる．
ステアリングユニットでは，命令のステアリングと並行し，FB の制御情報の生成を行う．STU は，
先に述べたステアリングアルゴリズムを実装するステアリング論理（Steering Logic），ステアリン
グを行っている間，命令を保持する命令バッファ（inst buffer）からなる．
4.2.2
ステアリングロジック
Steering logic は，STU において実際にステアリングを行うモジュールである．図 4.2.2 にステ
アリングロジックの内部を示す．ステアリングロジックは，ステアリングユニットの中心となるモ
ジュールであり，自コアで実行する命令を決定する．
先祖ノード行列とリーフノードベクトルの構築
ステアリングロジック内には，先祖ノード行列（ANC）とリーフノードベクトル L，デスティ
ネーションテーブル（DT）が存在する．ANC，L は，4.2.1 で述べた先祖行列とリーフノードベク
トルである．
デスティネーションテーブルは，命令の依存検出に使用する．エントリは論理レジスタの数に等
しい. また，各エントリは有効ビットを持つ．以降では，DT の i 番目のエントリを D[i] と表記す
る．FB において i 番目の命令 Ii が論理レジスタ j に結果を書くとき，DT[j] = i とする．ある命令
が，論理レジスタ j を読むなら，DT[j] として依存先の命令がわかる．ただし，CoreSymphony では
2 命令ずつ処理するため注意が必要である．DT のような，記憶素子への書き込みはクロックに同期
4.2 命令ステアリング
29
(3)
check
intra dep
lsrc0
DT
lsrc1
(2)
(4)
ldst
/ inst_valid
(1)
ANC
steering_vec
slot
inc
inst_cnt
?
fbend
flush
steered_leaf
leafnode_selector
ctrl
図 4.11 ステアリングユニットのブロック図および，ステアリングロジックの詳細．
して行われる．そのため，同時にフェッチした 2 命令の間の依存関係（以降では，intra-dep と呼ぶ)
が存在する場合，DT だけでは依存関係を正しく検出できない．そのため，DT とは別に intra-dep
を検出するための論理を用意する．1 つ目の命令のデスティネーションレジスタと 2 つ目の命令の
ソースレジスタを比較することで，intra-dep を検出できる．
ANC, L の構築の流れを，4.2.1 と同じ例で示す．ただし，I0 と I1 は，論理レジスタ m に結果を
書き込み，I1 , I2 , I3 は論理レジスタ m を読むとする．
初期化
L と DT を初期化する．L は全要素を１で，DT は全エントリの有効ビットを 0 とする．
１サイクル目 (1)：依存の検出
(I0 , I1 ) が訪れる．DT を読み出し依存の検出を行う (図 4.2.2(1)).
しかし，DT は 2 つの命令で同時に参照するため，I0 , I1 は，DT では依存を検出できない．
このため，intra-dep 検出ロジックが I0 と I1 の間の依存を検出する．
I0 , I1 ともに DT[m] に書き込むが，I1 の方が新しい命令のため優先される．よって，DT[m]
= 1 となる．
I0 と I1 の intra-dep が検出されたため，L[0]=0 とする．
1 サイクル目 (2) : ANC 読み出し/書き込み ANC を読みだし，論理和によって先祖ベクトルを求
める (図 4.2.2(2))．ANC の読み出しには，先ほど DT から読みだした値を使用する．
DT によるチェックでは，I0 , I1 ともに依存命令が無いと判断されたため，ANC の値を使用し
ない．この時点での先祖ベクトルは計算中途中の値である．これらを ANC[0]mid , ANC[1]mid
とすると，ANC[0]mid = e0 , ANC[1]mid = e1 となる．
次に，intra-dep に関する処理を行う（図の (3))．I1 は I0 に intra-dep を持つので，ANC[1] =
ANC[1]mid |ANC[0]mid とする．
以上のように得られた先祖ベクトルを ANC に書き戻す．すなわち，ANC[0] = e0 , ANC[1] =
第 4 章 CoreSymphony の実装
30
e1 |e0 とする．これで 1 サイクル目の処理は完了する．
2 サイクル目 (1) 次のサイクルでは，(I2 , I3 ) が訪れる．それぞれ DT[m] を読み出し，依存先とし
て I1 を得る．DT の読み出し値を使用して，L を更新する．L[1] = 0 となる．
2 サイクル目 (2) DT から読み出した値で ANC にアクセスする．2 命令はそれぞれ ANC[1] を読
み出し，ANC[2]mid = e2 |ANC[1], ANC[3]mid = e3 |ANC[1] となる (図の (2))．この 2 命令間
に intra-dep は存在しないため (図の (3))，ANC[2] = ANC[2]mid , ANC[3] = ANC[3]mid とし
て，ANC を更新する．
以上のステップを繰り返し，ANC と L を求める．
ステアリング結果の決定
ステアリング結果の決定は，自コアに割り当てられるリーフノードの選択と先祖ノード行列
（ANC）を読み出し，自コアに割り当てられる命令を表すステアリングベクトル（steering vector:ST)
を求める操作に分かれる．ST[i]=1 であることは，Ii が自コアにステアリングされたことを示す．
図 4.2.2 にリーフノード選択論理を示す. リーフノード選択論理は，入力として L，協調中のコア
数 (CoreNum), および自コアに設定された番号 (CoreID) を受け取り，自コアに割り当てられるリー
フノード（steered leaf) を出力する．図中の lim と記された加算器は，CoreNum により出力の最大
値が制限される．この加算器においては，
(CoreNum − 1) + 1 = 0
が成立する．
次に ST を求める．ST は ANC に steered leaf を右から掛けることで求まる．この計算を行う論
理を，図 4.2.2 に示す．まず，ANC の各行について，ANC[i] と steered leaf[i] の論理積を求める．
この結果を，ANC sel [i] とする．次に，すべての ANC sel の論理和により ST を計算する．
4.2.3
命令バッファ
リーフノードステアリングは，FB に含まれる命令を逆順に解析し，命令を実行するコアを決定す
る．そのため，FB に含まれる最後の命令が STU に到達するまでステアリング結果はわからない．
この間，命令は命令バッファに保持される．
ステアリングロジックがステアリング結果であるステアリングベクトル（ST）を出力すると，そ
の結果に基づき，命令バッファは命令を次のリネームステージに送る．
CoreSymphony において，ローカル命令キャッシュからフェッチされた命令は，ステアリング済
である．そのため，ステアリングステージをパイパスできる．このように，パイプラインステージ
のバイパスが存在するため，命令フェッチがエントリ構築フェーズから協調フェッチフェーズに移
行する場合，注意が必要である．この場合のタイミングチャートを図 4.2.3 に示す．図に青く示し
た命令列は，従来型命令キャッシュからフェッチした命令であり，ステアリングが必要である．一
方，赤で示した後続の命令は，ローカル命令キャッシュからフェッチした命令であり，ステアリン
4.2 命令ステアリング
31
CoreNum
0
CoreID
L[0]
steered_leaf[0]
lim
L[1]
steered_leaf[1]
lim
L[2]
steered_leaf[2]
lim
L[3]
steered_leaf[3]
lim
図 4.12
リーフノード選択論理. リーフノードベクトルからラウンドロビンで自コアに割り当て
るリーフノードを選択する．lim と記された加算器は，出力の最大値が入力 CoreNum で制限さ
れ，(CoreNum-1)+1=0 となる．
グステージをバイパスできる．このとき，後続の命令をそのままバイパスする場合，図に示すよう
に命令の追い越しが発生する．
これを防ぐため，ステアリング中にローカル命令キャッシュからフェッチされた命令が ID ス
テージに到達した場合，ID ステージで命令をストールさせる．
ステアリングにおける，ステアリング結果確定フェーズには 1 サイクルが割り当てられている．
そのため，後続の命令が連続して従来型命令キャッシュからフェッチされる場合，命令バッファの
エントリが上書きされる．命令バッファがリングバッファで実装されていないため，このような事
態が生じる．
リングバッファで構成し，エントリ数に余裕を持たせることで，上書きは回避できる．この方法
をとった場合，ステアリングベクトルから命令バッファのエントリを求めるときに，変換が必要に
なり，制御が複雑になる．
代わりに本実装では，上書きが生じるタイミングでフェッチが行われた場合，ID ステージをス
トールさせ，FB 間に 1 サイクルの猶予を入れている．
第 4 章 CoreSymphony の実装
32
steered_leaf[0]
steered_leaf[1]
leaf_select
steered_leaf[2]
steered_leaf[3]
steering_vec
図 4.13 先祖ノード行列（ANC) および steered leaf から，ステアリングベクトル（steering_vec)
を求める論理
4.2.4
命令ステアリングの検証
ここでは，命令ステアリングユニットの検証について述べる．図 4.2.4 に命令ステアリングの検
証環境を示す．
ステアリング結果が正しいことを確認するため，ステアリングユニットの出力をソフトウェア
シミュレータのステアリング結果と比較する．検証には，ソフトウェアシミュレータによる命令
フェッチ/ステアリングのトレース，Verilog HDL で記述されたテストベンチを使用する．
これらを使用して，RTL レベルのシミュレーションを行い，実装したステアリングユニットのス
テアリング結果を検証する．
テストベンチは，検証対象であるステアリングユニット，命令フェッチトレースを基にステア
リングユニットの入力を生成する Input generator，ステアリングユニットの出力とソフトウェアシ
ミュレータが生成したステアリング結果を比較する Output Comparator から構成される．
ステアリングユニットの出力には，前段をストールさせるための信号が存在する．Input generator
はストール信号を監視し，ステアリングユニットが命令を受け入れ可能な場合に限り命令を出力
する．
4.2 命令ステアリング
33
CLK
IF output
/ID input
I0
I2
I4
I6
I0
I2
I1
I3
I5
-
I1
I3
I0
I2
I4
I6
I0
I2
I1
I3
I5
-
I1
I3
ID output
/ST output
steer
I0
ST output (RR input)
I1
I0
I0
I2
I1
I1
I3
ST Bypass (RR input)
nd
2
FB’s inst overtakes
1
st
FB’s inst
図 4.14 エントリ構築フェーズから協調フェッチフェーズに移る際に，パイプラインのバイパ
スを考慮しない例．青で示した命令は，ステアリングが必要な命令．赤で示したものは，ステア
リングが必要ない命令．図中の吹き出しで示すように，パイプラインのバイパスを考慮しない場
合，命令の追い越しが発生する.
configuration
generate
・the number of cores
・CoreID
generate
Software
Simulator
Fetch trace
file
2 inst
Input generator
test bench
図 4.15
steered inst
Steering Module
stall
Steering
trace
file
Output
Comparator
match or not
ステアリングユニットの検証用テストベンチ．テストベンチの入力には，ソフトウェア
シミュレータで生成した命令フェッチトレースとステアリング結果を用いる．
第 4 章 CoreSymphony の実装
34
検証結果
4.3
リネーム
2way リネーミングでは，2 種類のタグを使用する．1 つ目は，コア内における依存を表す Ltag
である．Ltag は自コアの物理レジスタ番号である．
もう一つは，コア間の依存解決に用いる Gtag である．Gtag は結果を生成する命令の FBid と，
論理デスティネーションレジスタを連結したものである．Gtag は，依存先の命令ではなく，依存先
の FB を特定する．これは，コア間をまたがる依存関係を表現するための情報としては十分である．
これは，他の FB から結果を受け取る場合，ある FB において結果を他のコアに送信する可能性が
ある命令は，各論理レジスタについて 1 つに限られ，同じ FB 内の命令から通信によって結果を受
け取ることは無いためである．これらのことは，通信のフィルタリングと，リーフノードステアリ
ングの，依存関係のある命令は１つのコアにステアリングされるという性質により保証される．
これらのタグは，それぞれ別のテーブル（LRMT および GRMT）で管理される．
LRMT は通常の RMT と大きく変わらない．異なるのは，エントリの内容が{物理レジスタ番号，
生産者の FB 番号}になる点である．
一方の GRMT は，論理レジスタ番号を入力とし，その論理レジスタに最後に書いた FB の番号を
出力する．
また，LRMT と GRMT は，ともに各エントリ毎の有効ビットを持つ．分岐や例外によってパイ
プラインがフラッシュされるとき，全エントリの有効ビットがクリアされる．エントリに書き込み
を行うときビットが立てられる．
CoreSymphony において，命令が使用する値の供給元は大きく 3 つのタイプに分けられる．1 つ
目は，自分が割り当てられているコアである．このとき，ソースレジスタは Ltag にリネームされ
る．2 つ目は，他のコアである．ソースレジスタは Gtag にリネームされる．3 つ目は，論理レジス
タファイル（LRF）である．これは，LRF からの供給はパイプラインフラッシュからの復帰時に発
生する．ソースレジスタはリネームされず，LRF を読む (readLRF) とマークされる．
リネーミングにおける処理は，GRMT の更新，デスティネーションのリネーム，ソースのリネー
ムに分けられる．
GRMT の更新は，FB 単位で行われる．FB のデスティネーションベクタを使用し，結果を書き込
む論理レジスタのエントリを更新する．
デスティネーションのリネームは通常のアウトオブオーダコアとほぼ同じである．物理レジスタ
番号だけでなく，所属する FB の番号を書き込む点が異なる．
ソースのリネームには，2 つのステップが必要になる．まず，論理レジスタ番号で LRMT と
GRMT を読み出す．次に，LRMT から読み出したエントリの FB 番号と，GRMT の出力を比較す
る．このとき，LRMT の FB 番号が若いか GRMT と等しい場合，論理レジスタは Ltag（LRMT か
ら読み出した物理レジスタ番号）にリネームされる．逆の場合，Gtag にリネームされる．Gtag は
論理レジスタ番号と GRMT の FB 番号を連結して得る．
4.4 命令ウィンドウ・命令実行
35
3 kinds of wakeup source
Logical register #
Gtag
Instruction
Window
Ltag
issue
Register
Fetch stage
Physical
Register
File
Execution
Logical
Register
File
Unit
result from local
filter
result from
recons. network
remote
operand comm. network
図 4.16 命令ウィンドウの周辺
LRMT と GRMT のいずれのエントリも有効ビットが立っていない場合，ソースのリネームは行
われず，LRF を読み出すとマークされる．
4.4
4.4.1
命令ウィンドウ・命令実行
命令ウィンドウ
命令ウィンドウ周辺の構成を図 4.4.1 に示す．
リネームで述べたように，CoreSymphony においてソースレジスタのリネーム結果には，3 つの
種類が存在する．命令ウィンドウはリネーム結果に応じ，命令の状態を管理する必要がある．
ウェイクアップ論理を図 4.4.1 示す．図には，ソースオペランド 1 つについての論理を示してい
る．実際には，これと同じものが 1 エントリにつき，もう一つ存在する．
ウェイクアップ論理はソース毎に，レディビット (Rdy_L, Rdy_R)，LRF ビット (LRF_L, LRF_R)，
remote ビット (remote_L, remote_R) およびタグフィールド (tag_L, tag_R) を持つ．
レディビットはオペランドが準備できていることを示す．LRF ビット，remote ビットはそれぞ
第 4 章 CoreSymphony の実装
36
remote_match
remote_preg
Rdy_L
LRF_L remote_L
tag_L
Rdy_L
Ltag from local core
Gtag from remote core
Logical register #
from Recovery Logic
remote_match
図 4.17 ウェイクアップ論理の構成．LRF ビット，remote ビットにより，三種類ある比較器の
内，どの結果によりウェイクアップされるかが決まる．Gtag によりウェイクアップされる場合，
束縛される予定の物理レジスタ番号（remote_preg) を取り込む
れ，オペランドの供給元が LRF，他のコアであることを示す．タグフィールドは Gtag と同じ幅を
持ち，レディビット，LRF ビット，remote ビットの値により，異なる解釈を受ける．
以下では，LRF/remote ビットの値別に，ウェイクアップの動作について述べる．
コア内からのウェイクアップ (LRF = remote = 0) LRF および, remote が 0 のとき，タグフィー
ルドは，下位ビットが Ltag として解釈される．放送された Ltag とタグフィールドが一致し
た場合に，ウェイクアップされる．
他コアの結果によるウェイクアップ (LRF = 0, remote = 1)
LRF が 0, remote が 1 のとき，タグ
フィールドが Gtag として解釈される．他コアの結果に先立って送信される Gtag と，タグ
フィールドが一致した場合にウェイクアップされる．
CoreSymphony の命令ウィンドウは，オペランド値を保持しない．そのため，他コアで生成
される命令を使用する場合，オペランドがレディになったことに加え，値が格納される物理
レジスタのエントリを知る必要がある．
そこで，Gtag を放送するとき，放送された値がローカルのコアで束縛する予定の物理レジス
タ番号（remote_preg）が共に放送される．Gtag がマッチした場合，この番号をタグフィール
ドに取り込む．命令実行時は，こうして得られた物理レジスタ番号を使用し，値を読みだす．
LRF によるウェイクアップ (LRF = 1, remote = 0) 動作は，コア内からのウェイクアップとほぼ
同じである．タグフィールドが論理レジスタ番号として解釈され，Recovery Logic が通知す
4.5 コミット
37
るレジスタ番号と比較される．
以上のように，LRF・remote ビットにより，異なるウェイクアップを行うため，命令ウィンド
ウは，3 種類のウェイクアップポートを備えている．図 4.4.1 では，各種類 1 つずつ示されている
が，実際には，Ltag によりウェイクアップを行うポート（ローカルウェイクアップポート）が 2 つ，
Gtag により行うポート（リモートウェイクアップポート）が１つ，論理レジスタ番号により行う
ポート（リカバリウェイクアップポート）が 2 つ存在する．
セレクト論理に，通常のアウトオブオーダコアと大きな違いは存在しない．異なる点として，ブ
ロードキャストポートの調停が挙げられる．本の実装では，ブロードキャストポートは 1 つに限ら
れている．セレクト論理は，ブロードキャストが必要な命令が，1 サイクルに最大 1 つになるよう，
発行する命令を選択する．
レジスタファイルの実装
CoreSymphony の物理レジスタファイルは 6 つのリードポートと 3 つのライトポート（6R3W）
持つ. 論理レジスタファイルのポート数は 6R2W である．
レジスタファイルは 32bit 幅であり，32 もしくは 64 のエントリを持つ．FPGA において，この
ようなモジュールを FF と LUT により実装するのは，ハードウェアリソースの大幅な増加につなが
るため，望ましくない．このような場合，FPGA がもつハードマクロの RAM ブロックを使用する
のが望ましい．ところが RAM ブロックは，2 つのポートしか持たない．そのため，RAM ブロック
を使用してレジスタファイルを構成するには工夫が必要である．
本実装では，LVT[10] と呼ばれる手法によりレジスタファイルを構成する．nRmW のレジスタ
ファイルの実装に，この手法を適用すると，n × m の RAM ブロックを使用する代わりに，必要な
FF と LUT の数を削減することができる．
4.5
コミット
複数のコアで協調動作中であっても，プログラム順でのコミットと正確な例外を実現するため，
CoreSymphony は，次の 4 つのハードウェアを備えている．
• ローカルリオーダバッファ（LROB）
• グローバルリオーダバッファ（GROB）
• ローカルコミットバッファ（LCB）
• リモートコミットバッファ（RCB）
LROB は，自コアで実行した命令を格納するリオーダバッファ（ROB）．その役割は，ベースであ
るアウトオブオーダコアに近い．GROB は，必要な情報を全コアで共有するための ROB であり，
FB 毎にエントリを割り当てる．このとき，FB に GROB の内容は，すべてのコアで基本的に同じ
である．
第 4 章 CoreSymphony の実装
38
remote_match
remote_preg
Rdy_L
LRF_L remote_L
tag_L
Rdy_L
Ltag from local core
Gtag from remote core
Logical register #
from Recovery Logic
remote_match
図 4.18 コミット機構のブロック図
これらのハードウェアの役割と動作について述べる．以下では，ある FB について，自コアに割
り当てられた命令の内，プログラム順で最も古い命令を FB start 命令，最も若い命令を FB end 命
令と呼ぶ．
1. 命令がディスパッチされると，LROB のエントリが割り当てられる．この時，命令が FB start
命令であれば，新たな GROB のエントリを FB に割り当てる．
2. ロードストア以外の命令が実行ユニットで命令が完了すると，LROB にそのことが通知され
る．このときの動作は，通常の ROB と同様である．
3. 実行完了した命令が LROB の先頭に到達すると， 命令は LROB からリタイアする．これ
をローカルリタイアと呼ぶ．ローカルリタイアした命令は，LCB にエントリが割り当てら
れる．
4. ブロードキャストによって，物理レジスタが確保された場合，RCB のエントリをその命令に
対して割り当てる．このとき，命令の論理デスティネーションレジスタ，FB 番号，割り当て
られた物理レジスタ番号，および，ppreg を RCB に格納する．
5. ローカルリタイアした命令が FBi の FB end 命令であるとき，このコアにおいて FBi が完了
したと呼ぶ．このとき，自コアを含めた協調中の全コアの GROB に FB の完了を通知する．
ローカルリタイアした命令が分岐ミスなどの例外を含む場合も，FB の完了である．このと
き，FB の完了と当該 FB が例外を含むこと，実行を再開する PC，および，例外を発生させ
た命令のスロット番号が GROB に通知される．例外が分岐ミスのとき，分岐の成否も同時
に通知される．
4.5 コミット
39
6. GROB では，各コアの FB の完了を監視する．例外を含む完了が通知されたとき，それ以前
に同一の FB の例外が通知されていなければ，通知された例外を FB の例外として採用する．
このとき，例外が生じた命令のスロット番号と再開 PC を格納する．
それまでに FB で例外が発生している場合，格納されている例外のスロット番号と，今通知
された例外のスロット番号を比較する．スロット番号が小さい例外を FB で発生した例外と
して記憶する．
すべてのコアで完了した FB が，GROB の先頭に到達したとき，FB は GROB をリタイアす
る．GROB のリタイアは，LCB および RCB に通知される．
7. LCB および RCB は GROB から通知を受けると，リタイアした FB に含まれる命令をコミッ
トする．このとき，物理レジスタファイルから結果をよみ，論理レジスタファイル (LRF) に
その値を書き込む．また，物理レジスタを解放するため，LCB と RCB に格納された ppreg
をフリーリストに返却する．
以降では，LROB, GROB, LCB および RCB の実装について述べる．
4.5.1
ローカルリオーダバッファ（LROB）
LROB と，ベースのアウトオブオーダコアにおける ROB との違いは，エントリのフィールドで
ある．LROB には，次のフィールドが追加される．
• FB 番号 (4bit)
• スロット番号 (4bit)
LROB を RAM で構成するには，エントリの割り当てに 2 つの書き込みポート (2R)，ローカルリ
タイアに 2 つの読み出しポート (2W) が必要である．FPGA に 2R2W の RAM を実装するには，レ
ジスタファイルの実装で述べたように工夫が必要になる．LVT による方法では，2 ポートの RAM
を 4 つ消費する．しかし，ROB のような First in, First out(FIFO) 構造は，ランダムアクセスが発生
せず，読み出しは先頭とその次のエントリ，書き込みは末尾とその次のエントリに限られる．この
ような性質のため，RAM のバンク分けと相性がよい．FIFO 構造を，偶数番目のエントリを保持す
るものと基数番目のエントリを保持するものの 2 つの RAM で構成する．すると先に述べた性質の
ため，2 つの RAM はそれぞれ 1R1W で十分である．
4.5.2
グローバルリオーダバッファ（GROB）
GROB の構造は，基本的にベースの ROB と同じである．異なる点は，格納する情報とポート数
である．
以下に GROB のフィールドを示す．1 エントリあたりの容量は，146bit である．
FBPC(32bit) FB 先頭の PC.
第 4 章 CoreSymphony の実装
40
nextaddr ローカル命令キャッシュの nextaddr と同じもの.
destination vector ローカル命令キャッシュの destination vector と同じもの．
branch num ローカル命令キャッシュの branch num と同じもの．
branch pattern ローカル命令キャッシュの branch pattern と同じもの．
TKN branch slot ローカル命令キャッシュの TKN branch slot と同じもの．
complete (4bit) FB の完了を示す．complete の i ビット目が 1 であることは，コア i で FB が完了
したことを示す．
exception flag(1bit) FB 内で例外が発生したことを示す．
exception slot(4bit) 例外を発生させた命令のスロット番号．
exception tkn(1bit) 例外が分岐ミスである場合，分岐の成否を示す．
exception tpc(32bit) 例外発生時の実行再開 PC．
FB のディスパッチ，リタイアは 1 サイクルあたり 1 つに限られるため，GROB は 2 ポートの
RAM で構成している．ただし，完了と例外にかかわるフィールドは，ディスパッチ・リタイアに加
え，FB の完了通知を受け取ったときもアクセスされる．例外受入れ時に比較を行う，exception flag
と exception slot はリードとライトのポートを 1 つずつ，他の complete, exception tkn, exception tpc
はライトポートが 1 つ，追加で必要である．
4.5.3
ローカルコミットバッファ（LCB）
LCB は，コミットに必要な情報をローカルリタイアから FB のリタイアの間，保持する．ロー
カルリタイアおよび LCB からのコミットは，最大で 1 サイクルあたり 2 命令である．そのため，
LCB は 2 リードポート，2 ライトポートのリングバッファにより構成される．
LCB は，コミットに必要な情報（論理デスティネーションレジスタ，物理デスティネーションレ
ジスタ，ppreg）の他に，FB 番号，スロット番号，commit ready ビット，drain ビットを持つ．これ
らのフィールドは，CAM で構成する．commit ready は，当該エントリが LCB から抜ける準備がで
きたことを示す．drain は，当該エントリが例外によるパイプラインフラッシュにより，削除される
べき命令であることを示す．
LCB は次のように動作する．
エントリの割り当て 命令がローカルリタイアすると，LCB の末尾にエントリが確保される．
FB のリタイア FB がリタイアするとき，LCB の各エントリで，リタイアする FB の番号とエント
リの FB 番号を比較する．一致する場合，commit ready をセットする．
リタイアした FB が例外を含むものである場合，エントリの FB 番号と，スロット番号を比
較する．FB 番号が一致し，例外のスロット番号がエントリのスロット番号より大きいとき
drain をセットする．
コミット，命令取り消し
先頭エントリの commit ready がセットされているとき，LCB は先頭の
エントリを解放する．このとき，drain ビットがセットされていなければ命令のコミットと
4.5 コミット
41
物理レジスタの解放を行う．
drain ビットがセットされている場合，コミットおよび物理レジスタの解放は行われず，命令
は実行されなかったことになる．
リスト 4.1 に LCB のソースコードを示す．
リスト 4.1 LCB のソースコード
1
2
‘default_nettype none
‘include "../ define .v"
3
4
5
6
7
8
9
module lcb #(
parameter W_DEPTH = ‘W_LCB_DEPTH ,
localparam DEPTH = 2** W_DEPTH ,
parameter W_FBID = ‘W_FBID ,
localparam W_RET = 2,
parameter W_FBLEN = ‘W_FBLEN ,
10
parameter
parameter
parameter
parameter
11
12
13
14
15
16
17
W_PREG = ‘W_PREG ,
W_LREG = ‘W_LREG ,
W_D = ‘W_D ,
W_A = ‘W_A
)(
input wire CLK ,
input wire RST_X ,
18
19
20
output wire full_o ,
output wire empty_o ,
21
22
output wire clean_o ,
23
24
input wire [W_RET -1:0]
alloc_i ,
input
input
input
input
input
input
input
wire
wire
wire
wire
wire
wire
wire
[W_FBID -1:0]
[W_FBLEN -1:0]
[W_LREG -1:0]
[W_PREG -1:0]
[W_PREG -1:0]
alloc0_fbid_i ,
alloc0_slot_i ,
alloc0_lreg_i ,
alloc0_preg_i ,
alloc0_ppreg_i ,
alloc0_drain_i ,
dbg_alloc0_pc_i ,
input
input
input
input
input
input
input
wire
wire
wire
wire
wire
wire
wire
[W_FBID -1:0]
[W_FBLEN -1:0]
[W_LREG -1:0]
[W_PREG -1:0]
[W_PREG -1:0]
input
input
input
input
wire
wire [W_FBID -1:0]
wire
wire [W_FBLEN -1:0]
25
26
27
28
29
30
31
32
[W_A -1:0]
33
34
35
36
37
38
39
40
[W_A -1:0]
alloc1_fbid_i ,
alloc1_slot_i ,
alloc1_lreg_i ,
alloc1_preg_i ,
alloc1_ppreg_i ,
alloc1_drain_i ,
dbg_alloc1_pc_i ,
41
42
43
44
45
ret_fb_i ,
ret_fbid_i ,
ret_exc_i ,
ret_exc_slot_i ,
46
47
input wire
stall_commit_i ,
output
output
output
output
output
output
wire
wire
wire
wire
wire
wire
[W_LREG -1:0]
[W_PREG -1:0]
[W_PREG -1:0]
[W_A -1:0]
commit0_o ,
commit0_drain_o ,
commit0_lreg_o ,
commit0_preg_o ,
commit0_ppreg_o ,
dbg_commit0_pc_o ,
output
output
output
output
output
output
wire
wire
wire
wire
wire
wire
[W_LREG -1:0]
[W_PREG -1:0]
[W_PREG -1:0]
[W_A -1:0]
commit1_o ,
commit1_drain_o ,
commit1_lreg_o ,
commit1_preg_o ,
commit1_ppreg_o ,
dbg_commit1_pc_o
48
49
50
51
52
53
54
55
56
57
58
59
60
61
第 4 章 CoreSymphony の実装
62
42
);
63
64
65
66
67
wire
wire
wire
wire
[W_DEPTH -1:0]
[W_DEPTH -1:0]
[W_DEPTH -1:0]
[W_DEPTH -1:0]
head_ptr ;
head_next_ptr = head_ptr +1;
tail_ptr ;
tail_next_ptr = tail_ptr +1;
68
69
localparam W_FIFO = W_FBLEN + W_LREG + W_PREG + W_PREG + 1;
70
71
72
73
74
wire [W_FBLEN -1:0]
wire [W_FBLEN -1:0]
wire
wire
commit0_slot ;
commit1_slot ;
commit0_drain ;
commit1_drain ;
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
wire [1:0] commit ;
fifo_2i2o #(.W( W_FIFO ), .DL2( W_DEPTH ))
preg_fifo (. CLK(CLK), . RST_X ( RST_X ),
.ENQ0( alloc_i [0]) ,
.I0({ alloc0_slot_i , alloc0_lreg_i , alloc0_preg_i , alloc0_ppreg_i ,
alloc0_drain_i }),
.ENQ1( alloc_i [1]) ,
.I1({ alloc1_slot_i , alloc1_lreg_i , alloc1_preg_i , alloc1_ppreg_i ,
alloc0_drain_i }),
.DEQ0( commit [0]) ,
.O0({ commit0_slot , commit0_lreg_o , commit0_preg_o , commit0_ppreg_o ,
commit0_drain }),
.DEQ1( commit [1]) ,
.O1({ commit1_slot , commit1_lreg_o , commit1_preg_o , commit1_ppreg_o ,
commit1_drain }),
.HEAD( head_ptr ),
.TAIL( tail_ptr )
);
// for debug
reg [W_A -1:0]
pcram [DEPTH -1:0];
always @( posedge CLK) begin
if( alloc_i [0]) pcram [ tail_ptr ] <= dbg_alloc0_pc_i ;
if( alloc_i [1]) pcram [ tail_next_ptr ] <= dbg_alloc1_pc_i ;
end
assign dbg_commit0_pc_o = pcram [ head_ptr ];
assign dbg_commit1_pc_o = pcram [ head_next_ptr ];
102
103
104
105
106
107
108
109
110
111
112
113
114
// wakeup
reg
valid [DEPTH -1:0];
reg
commit_rdy [DEPTH -1:0];
reg
drain [DEPTH -1:0];
reg [W_FBID -1:0]
fbid[DEPTH -1:0];
integer i;
always @( posedge CLK) begin
if (! RST_X) begin
for(i = 0 ; i < DEPTH ; i=i+1) begin
valid[i] <= 1’b0;
end
end
115
116
117
118
119
120
121
122
// allocate LCB entry
if( alloc_i [0]) begin
valid [ tail_ptr ]
commit_rdy [ tail_ptr ]
fbid[ tail_ptr ]
drain [ tail_ptr ]
end
<=
<=
<=
<=
1’b1;
1’b0;
alloc0_fbid_i ;
alloc0_drain_i ;
123
124
125
126
127
128
129
if( alloc_i [1]) begin
valid [ tail_next_ptr ]
commit_rdy [ tail_next_ptr ]
fbid[ tail_next_ptr ]
drain [ tail_next_ptr ]
end
<=
<=
<=
<=
1’b1;
1’b0;
alloc1_fbid_i ;
alloc1_drain_i ;
130
131
132
133
134
// commit wakeup
if( ret_fb_i ) begin
for(i = 0 ; i < DEPTH ; i=i+1) begin
if(fbid[i]== ret_fbid_i && valid[i]) commit_rdy [i] <= 1’b1;
4.5 コミット
43
end
135
136
if( ret_exc_i ) begin
for(i = 0 ; i < DEPTH ; i=i+1)
drain[i] <= 1’b1;
end
137
138
139
140
end
141
142
if( commit0_o ) begin
valid [ head_ptr ]
end
if( commit1_o ) begin
valid [ head_next_ptr ]
end
143
144
145
146
147
148
149
<= 1’b0;
<= 1’b0;
end
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
reg
exc_handling ;
reg [W_FBLEN -1:0]
eslot ;
reg [W_FBID -1:0]
efbid ;
always @( posedge CLK) begin
if (! RST_X) begin
exc_handling <= 0;
efbid <= 1;
eslot <= 0;
end
else if( ret_exc_i ) begin
exc_handling
<= 1’b1;
efbid
<= ret_fbid_i ;
eslot
<= ret_exc_slot_i ;
end
else if( ret_fb_i || empty_o ) begin
exc_handling <= 1’b0;
end
end
169
170
171
172
173
174
// check commit
assign commit0_o = ! stall_commit_i && valid[ head_ptr ]
&& ( commit_rdy [ head_ptr ] || commit0_drain || exc_handling );
assign commit1_o = ! stall_commit_i && valid [ head_next_ptr ] && commit0_o
&& ( commit_rdy [ head_next_ptr ] || commit1_drain || exc_handling );
175
176
177
178
179
180
// check condition
wire head0_do_not_drain = (fbid[ head_ptr ] == efbid ) && ( commit0_slot < eslot )
|| (fbid[ head_ptr ] != efbid) && commit_rdy [ head_ptr ];
// preceeding FB ’s inst
wire head1_do_not_drain = (fbid[ head_next_ptr ] == efbid) && ( commit1_slot < eslot )
|| (fbid[ head_next_ptr ] != efbid ) && commit_rdy [ head_next_ptr ];
// preceeding FB ’s inst
181
182
assign commit0_drain_o = ( exc_handling && ! head0_do_not_drain ) || commit0_drain ;
183
184
assign commit1_drain_o = ( exc_handling && ! head1_do_not_drain ) || commit1_drain ;
185
186
assign commit = {commit1_o , commit0_o };
187
188
189
190
191
192
// fifo entry counter
wire alloc_two = & alloc_i ;
wire alloc_one = ( alloc_i ==2 ’ b10) || ( alloc_i ==2’ b01 );
wire commit_one = ( commit ==2’ b10) || ( commit ==2’ b01 );
wire commit_two = & commit ;
193
194
195
196
197
198
199
200
201
202
203
204
205
reg [W_DEPTH -1:0] ent_cnt ;
always @( posedge CLK) begin
if (! RST_X) begin
ent_cnt <= 0;
end
else begin
if( alloc_two ) begin
if( commit_one )
if (! commit_two && ! commit_one )
end
else if( alloc_one ) begin
if( commit_two )
ent_cnt <= ent_cnt +1;
ent_cnt <= ent_cnt +2;
ent_cnt <= ent_cnt -1;
第 4 章 CoreSymphony の実装
if (! commit_two && ! commit_one )
end
else begin
if( commit_one )
if( commit_two )
end
206
207
208
209
210
211
ent_cnt <= ent_cnt +1;
ent_cnt <= ent_cnt -1;
ent_cnt <= ent_cnt -2;
end
212
213
44
end
214
215
216
217
218
localparam FULL_CNT = DEPTH -2;
assign full_o
= ( ent_cnt == FULL_CNT );
assign empty_o = ( ent_cnt == 0);
assign clean_o = ! lcb_dirty ;
219
220
221
reg [W_FBID -1:0]
reg
current_fbid ;
lcb_dirty ;
222
223
224
wire [W_FBID -1:0]
head_fbid = fbid[ head_ptr ];
wire clean_cond = ( head_fbid != current_fbid ) || empty_o ;
225
226
227
228
229
230
231
232
233
234
235
236
237
always @( posedge CLK) begin
if (! RST_X) begin
lcb_dirty <= 0;
end
else if( ret_fb_i ) begin
lcb_dirty
<= 1’b1;
current_fbid
<= ret_fbid_i ;
end
else if( clean_cond )begin
lcb_dirty
<= 1’b0;
end
end
238
239
240
endmodule
‘default_nettype wire
4.5.4
リモートコミットバッファ（RCB）
RCB の役割は，LCB と似ている．しかし，エントリの割り当てとコミットのタイミングが異な
るため，構造は異なる．
RCB は，ブロードキャストにより，他コアの命令が自コアの物理レジスタを束縛する場合に，エ
ントリを割り当てる．RCB はこの時点から，FB のリタイアのまでの間，コミットに必要な情報を
保持する．
RCB は，コミットに必要な情報のほかに，FB 番号，commite ready ビットを持つ．LCB に存在
した，スロット番号と drain ビットは RCB に必要ない．これは，例外を含む FB がリタイアした場
合，RCB がフラッシュされることによる．
RCB の動作を述べる．
エントリの割り当て 先述のように，ブロードキャストされた命令が自コアで物理レジスタを束縛
する場合にエントリを割り当てる．
FB のリタイア FB がリタイアするとき，例外を含まなければ，LCB と同様に commit ready を
セットする．FB が例外を含むとき，RCB はフラッシュされる．
コミット
RCB は，commit ready がセットされているエントリが存在すれば，そのうちの 1 つを
選択する．その後，選択した命令をコミットし，命令に割り当てていた RCB のエントリを
4.6 インオーダステートの復帰
45
解放する．
LCB は，ローカルリタイア時にエントリを割り当て，FB リタイアでコミットする．どちらもプ
ログラム順に発生する．そのため，エントリの割り当てと解放が同じ順序で行える．
一方 RCB は，ブロードキャスト受信時にエントリを割り当てるため，プログラム順に格納され
るとは限らない．RCB からのコミットは，FB のリタイアをトリガとするため，プログラム順で発
生する．割り当てと解放の順序が異なるため，空きエントリの管理にフリーリストが必要になる．
また，コミット時には，コミット可能な命令から１つを選択しなければならない．この動作のため，
プライオリティエンコーダが必要になる.
4.6
インオーダステートの復帰
CoreSymphony では，オペランド通信を削減するため，ブロードキャストの送信をフィルタする．
また，不要な物理レジスタの束縛を避けるため，ブロードキャストされてきた結果を破棄すること
がある．このようなフィルタリングの結果，例外からの復帰時に困難が生じる．例外は，FB の途
中や，後続の投機的にフェッチされた FB が論理レジスタを上書きした後にも発生することがある．
FB の途中で例外が発生した場合を考える．ある FB で論理レジスタ i に結果を書き込む命令 I f およ
び I s が存在するとする．I f は I s に先行するとする．このとき，ブロードキャストされるのは I s の
結果のみである．ここで I f と I s の間で例外が発生すると，再開時には I f の結果が必要になる．し
かし，ブロードキャストのフィルタリングにより，その結果は I f を実行したコアにしか存在せず，
他のコアで使用できない．ブロードキャストされてきた結果を破棄した場合も同様に, 必要な値が
存在しないコアが生じる可能性がある．
このような状態を防ぐため，CoreSymphony は例外からの実行再開時，コア間で通信を行い，正
しいレジスタの内容を復元する．正しい値を持つコアが，その値を他のコアにブロードキャストし，
レジスタを復元する．このとき値は, 物理レジスタファイル（PRF）ではなく，論理レジスタファイ
ル（LRF）に書き込む．
復元時，あるコアの論理レジスタには３つの状態が考えられる．これらの状態を INVALID，
BROADCAST, VALID と呼ぶことにする．
• INVALID. 自コアには有効な値が存在しない．リタイアする FB のデスティネーションベク
タにより遷移する．
• BROADCAST. 自コアに有効な値が存在し，他コアにブロードキャストする必要がある．
LCB から命令がリタイアする際に，遷移する．
• VALID. 自コアに有効な値が存在するが他コアにブロードキャストする必要がない．RCB か
ら命令がリタイアする際に，もしくはパイプラインフラッシュ時に遷移する．
これらのステートは LRF マネージャにより管理される．LRF マネージャは，コミットされる FB
および命令列を監視し，論理レジスタのステート変更する．
第 4 章 CoreSymphony の実装
46
Local
I-$
TMP
Instruction, Control
Conventional
I-$
(1)
Data
(1)
Hit/Miss
Decode/Steering
Inter-core network
(2)
(2)
Free
List
(3)
LRMT
GRMT
(5) (4) (1)
(1)
(3)
to filter
younger
(1)
(1)
(1)
(2)
Global
Re-order
Buffer
Local
Re-order
Buffer
(4) (3) (2)
(3)
Instruction
Window
(2)
(1)
(3)
(4)
L/S Comm.
(1)
bank=n?
LRF
(2) (4)
(2) (3)
Execute
LCB RCB
(3)
Commit/Spec.
Comm.
PRF
(3)
Commit
filter
Recons. Comm.
(1)
(2)
D-$
(2)
(3)
(1)
ULB-LSQ
Local Retire
(1)
Comm.
(1)
Operand Comm.
図 4.19 コミット機構のブロック図
4.7
実装のまとめ
最後に CoreSymphony 全体のブロック図を 4.7 に示す．Verilog HDL のコード行数は，約 14,000
行である．
47
第5章
評価
この章では，CoreSymphony の FPGA をターゲットとした実装を評価する．
CoreSymphony を Verilog HDL で記述し，論理合成する．論理合成には Xilinx 社の ISE 13.2 を
使用し，ターゲットの FPGA は，Virtex-6 シリーズ [11] の XC6VLX240T とする．
ハードウェア規模，および動作速度を評価する．2 命令発行のアウトオブオーダプロセッサと比
較する．
5.1
コア全体の論理合成結果
パイプライン全体の実装に要する，FPGA のリソース量を図 5.2 に示す．横軸はリソースの種類
で，Lookup-Table(LUT) と Flip-Flop(FF) である．縦軸はそれぞれのリソースの消費量（個）であ
る．out of order は CoreSymphony のベースである 2 命令発行のアウトオブオーダプロセッサ (以
下ベースライン），CoreSymphony は CoreSymphony アーキテクチャを実装したプロセッサ (以下
CoreSymphony) である．参考として 2 命令発行のインオーダプロセッサのリソース消費量を示す．
また，図 5.1 に FPGA への配置配線結果を示す．CoreSymphony は，LUT で約 2.1 倍，FF では
約 1.9 倍のリソースを消費することがわかる．ハードウェアの増加量は，小さいとはいえないが，
CoreSymphony は現実的なハードウェア量で実現可能といえる．以降では，主要なモジュール毎の
リソース消費量についてみる．
5.2
命令フェッチユニット
図 5.6 に命令フェッチユニット (IFU) のリソース消費量の比較を示す．従来型命令キャッシュ
(conv), TMP, PC 制御論理 (pccon), ローカル命令キャッシュ (lc), FB 検出論理 (detec) および BTB
は，命令フェッチユニットの他のハードウェアと分けている．ただし，HDL 記述の関係によりアウ
トオブオーダのリソース消費量には，デコードステージとの間のパイプラインレジスタおよび，pc
を制御する論理のリソース消費量が含まれていない．
CoreSymphony の IFU は，ベースラインと比較し，FF で約 4 倍，LUT で約 4.2 倍のリソース
第 5 章 評価
48
Fetch
Decode
Rename
Inst window
Load store
commit
Steering
other
CoreSymphony
図 5.1
conventional Out of Oder
配置配線結果.
を消費している．CoreSymphony 全体に占める割合でみると，それぞれ 9% と 7% になる．また，
ベースラインに対する増加量の 13% を占めている．ローカル命令キャッシュが最もハードウェア
を消費していることがわかる．LUT の消費量が多い原因の１つとして，PC の計算が考えられる．
ローカル命令キャッシュからフェッチした命令の PC は，フェッチに使用した PC から直接求める
ことができない．計算自体は複雑ではないが，扱うアドレスが 32bit 幅であること，複数の命令に
ついて計算する必要があることから，消費する LUT が増えたと考えられる．
また，多くの FF を消費する原因として，ローカル命令キャッシュに対して命令をフィルする論
理が考えられる．この論理では，少なくともローカル命令キャッシュ 1 ライン分のデータを保持す
る必要がある．そのため，消費量が多いと考えられる．
5.3
ステアリングユニット
図 5.4 にステアリングユニットのリソース消費量を示す．leaf はステアリング論理を，disb は命
令バッファを示す．ステアリングユニットに対応するモジュールは，ベースラインに存在しない．
LUT で見みると，ステアリングユニットの内 81% 強のリソースをステアリング論理が使用してい
る．ステアリングユニット自体，CoreSymphony 全体の約 13% を占める比較的，規模の大きいモ
5.3 ステアリングユニット
49
25000
no20000
it
p
m
us 15000
m
oc
ec 10000
ru
os
e
R 5000
0
2issue inorder
out of order
CoreSymphony
LUT
FF
resource
図 5.2
配置配線後のハードウェア規模．Lookup table(LUT) と Flip-Flop(FF)．inorder-SS はイ
ンオーダ実行の２命令発行プロセッサ．out of order は 2 命令発行のアウトオブオーダプロセッ
サ，CoreSymphony は CoreSymphony アーキテクチャを実装したプロセッサ
1600
s
e
c 1400
r
u
o
s 1200
e
r
d 1000
e
i
p 800
u
o
o 600
c
f
o 400
r
e
b 200
m
u
0
n
e
h
t
other
conv
TMP
pccon
lc
detec
BTB
図 5.3
ステアリングユニットのリソース消費量の比較
第 5 章 評価
50
3000
s
e 2500
c
r
u
o
s
e
r 2000
d
e
i
p
u
c 1500
c
o
f
o
r
e 1000
b
m
u
n
h 500
t
0
other
leaf
disb
FF:CoreSymphony
図 5.4
FF:out of order
ステアリングユニットのリソース消費量の比較
ジュールである．ステアリング論理のより効率的な実装，もしくは小規模なハードウェアで実装で
きるアルゴリズムが必要と考えられる．
命令バッファのハードウェアが小規模とは言い切れない．図 5.4 には示していないが，8 つのブ
ロック RAM を使用している．これらは，デコードされた命令の格納に使用されていると考えられ
る．デコード済みの命令は，PC や分岐予測器により予測された分岐先を含むためも含め 132bit に
なる．16 のエントリを持つので，小容量とは言えない．
5.4
命令ウィンドウ
図 5.6 に命令ウィンドウのリソース消費量の比較を示す．CoreSymphony の命令ウィンドウは
ベースラインと比較して，FF で約 31% の増加，LUT は約 62% の増加である．FF の増加は，ウェ
イクアップ論理おけるタグが物理レジスタ番号 (6bit) から Gtag の幅 (9bit) に広がったためと考え
られる．LUT の増加は，ウェイクアップ論理の CAM ポートが，2 つから 5 つに増加し，比較器の
数が増えたことが主な理由と考えられる．ハードウェア量削減には，ウェイクアップポートの共有
などにより，比較器を削減する必要があるといえる．
5.5 コミット機構
51
1400
e
c
r
u 1200
o
s
e
r 1000
d
e
i 800
p
u
c
c 600
o
f
o
r 400
e
b
m 200
u
n
0
e
h
t
図 5.5
5.5
命令ウィンドウのリソース消費量の比較
コミット機構
図 5.6 にコミット機構のリソース消費量の比較を示す．RCB, LROB, LCB, GROB, 論理レジスタ
復帰機構（lrfmane, cb) とその他のハードウェアで分けている．
CoreSymphony のハードウェア量は，LUT で見た場合，約 2.5 倍に増加している．ベースライン
に対する増加量に占める割合は，約 10% である．CoreSymphony のコミット機構において，最もリ
ソースを消費しているのは LROB である．ROB とベースラインの ROB の消費量を比較した場合，
その差は 12% 程度と小さい．
コミット機構全体での消費量を押し上げているのは，GROB や LCB などのモジュールである
ことがわかる．これらのモジュールは，それぞれを見ると LUT の使用量は 250 から 400 である．
LROB および ROB に比べると小規模といえる．
第 5 章 評価
52
3000
s
e
c
r
u 2500
o
s
e
r 2000
d
e
i
p 1500
u
c
c
o
f 1000
o
r
e
b 500
m
u
n
0
h
t
other
rcb
lrob
lrfmane
lcb
grob
cb
図 5.6
コミット機構のリソース消費量の比較
53
第6章
結論
本研究では，CoreSymphony アーキテクチャを FPGA に実装するため，Verilog HDL による記述
を行った．各モジュールの実装に述べ，論理合成を行った．これにより，CoreSymphony プロセッ
サのハードウェア量を明らかにした．
論理合成結果のハードウェア量は，ルックアップテーブル（LUT）に関して，ベースラインとし
たアウトオブオーダ実行プロセッサの 2 倍程度であり，CoreSymphony が現実的なハードウェア
量で実装できることを明らかにした．HDL 記述のコード行数は 14,000 行であり，ベースラインの
2.5 倍以上であった．
主要なモジュールのハードウェア量について考察したところ，命令フェッチユニットは，ベース
ラインの 4 倍程度であった. これは，ハードウェア増加量全体の約 10% を占めている．ベースライ
ンに存在しないステアリングステージは，増加量全体の約 26% 占めることが分かった. コミット機
構の拡張は，増加量の約 14% を占めるという事が分かった．また，3 つのウェイクアップポートを
追加した命令ウィンドウのハードウェア量は，ベースラインの命令ウィンドウの約 1.6 倍であるこ
とが明らかになった．今後の課題として，FPGA 上での動作，およびハードウェア量削減のための
アーキテクチャの改良が挙げられる．
55
謝辞
本研究を進めるにあたり，終始熱心な御指導を賜りました吉瀬謙二准教授に深く感謝の意を表し
ます. また，吉瀬研究室の皆様には討論及び多くの貴重なご意見を頂きました．永塚智之氏に頂い
た意見および議論は，実装にあたり必要不可欠なものであり，ここに深く感謝の意を表します．若
杉祐太氏には非常にお世話になりました．深く感謝致します．高前田伸也氏からは，FPGA や HDL
の記述について多くの貴重なご意見をいただきました．藤枝直輝氏による MipsCore は，学習題材
として，プロセッサ実装のベースとして，大変お世話になりました．松村貴之氏との議論は，プロ
セッサの実装にあたり大変有意義なものでした. 研究室の皆様とのコーヒータイムは研究に欠かす
ことのできない休息でした．また，佐野伸太郎氏および佐藤真平氏には，適度な緊張感と息抜きを
提供していただき，大変お世話になりました．歴代吉瀬研店長およびストリームヌードルショップ
には大変お世話になりました．感謝致します．
本研究の一部は科学研究費補助金（課題番号:22700046 若手研究 (B)）による．
57
参考文献
[1] 安藤秀樹. 命令レベル並列処理-プロセッサアーキテクチャとコンパイラ-. コロナ社, 2005.
[2] R. E. Kessler. The alpha 21264 microprocessor. IEEE Micro, Vol. 19, pp. 24–36, 1999.
[3] Kenneth C. Yeager. The mips r10000 superscalar microprocessor. IEEE Micro, Vol. 16, pp.
28–40, April 1996.
[4] Gene M. Amdahl. Validity of the single processor approach to achieving large scale computing
capabilities. In Proceedings of the April 18-20, 1967, spring joint computer conference, AFIPS
’67 (Spring), pp. 483–485, New York, NY, USA, 1967. ACM.
[5] Fred J. Pollack. New microarchitecture challenges in the coming generations of cmos process
technologies (keynote address)(abstract only). In Proceedings of the 32nd annual ACM/IEEE
international symposium on Microarchitecture, MICRO 32, pp. 2–, Washington, DC, USA, 1999.
IEEE Computer Society.
[6] David Tarjan, Michael Boyer, and Kevin Skadron. Federation: repurposing scalar cores for outof-order instruction issue. In DAC ’08: Proceedings of the 45th annual Design Automation Conference, pp. 772–775, New York, NY, USA, 2008. ACM.
[7] Carlos Madriles, Pedro López, Josep M. Codina, Enric Gibert, Fernando Latorre, Alejandro Martinez, Raúl Martinez, and Antonio Gonzalez. Boosting single-thread performance in multi-core
systems through fine-grain multi-threading. In Proceedings of the 36th annual international symposium on Computer architecture, ISCA ’09, pp. 474–483, New York, NY, USA, 2009. ACM.
[8] Changkyu Kim, Simha Sethumadhavan, M. S. Govindan, Nitya Ranganathan, Divya Gulati, Doug
Burger, and Stephen W. Keckler. Composable lightweight processors. In MICRO ’07: Proceedings of the 40th Annual IEEE/ACM International Symposium on Microarchitecture, pp. 381–394,
Washington, DC, USA, 2007. IEEE Computer Society.
[9] Ryan Rakvic, Bryan Black, and John Paul Shen. Completion time multiple branch prediction for
enhancing trace cache performance. In Proceedings of the 27th annual international symposium
on Computer architecture, ISCA ’00, pp. 47–58, New York, NY, USA, 2000. ACM.
[10] Charles Eric LaForest and J. Gregory Steffan. Efficient multi-ported memories for fpgas. In
Proceedings of the 18th annual ACM/SIGDA international symposium on Field programmable
gate arrays, FPGA ’10, pp. 41–50, New York, NY, USA, 2010. ACM.
参考文献
58
[11] Xilinx inc. Virtex-6 ファミリ概要. http://japan.xilinx.com/support/documentation/
data_sheets/j_ds150.pdf.
59
研究業績
口頭発表
1.
坂口 嘉一, 松村 貴之, 永塚 智之, 吉瀬 謙二: CoreSymphony の実現に向けたコアアーキテク
チャの検討, 情報処理学会研究報告 2011-ARC-194, 於 高知工科大学 2011 年 3 月 11 日発表,
pp.1-4 (March 2011).
2.
坂口 嘉一, 高前田 伸也, 吉瀬 謙二：ScalableCore システム 2.0 の実装と評価, 電子情報通信学
会研究報告 RECONF, 於 静岡大学 2010 年 9 月 17 日発表, pp. 121-126 (September 2010).
3.
坂口 嘉一, モッハマドアスリ, 高前田 伸也, 金子 晴彦, 吉瀬 謙二：誤り訂正符号を用いた軽量
な高速シリアル通信機構の実装と評価, 電子情報通信学会研究報告 CPSY2010-19, 於 金沢市
文化ホール 2010 年 8 月 4 日発表, pp. 67-72 (August 2010).
全国大会等
4.
坂口嘉一, 松村貴之, 吉瀬謙二：スーパースカラ版 MIPSCORE の実装と評価, 情報処理学会
第 73 回全国大会, 東京工業大学 大岡山キャンパス (2011 年 3 月 2 日発表), Vol.1, No. 1H-2,
pp. 53-54 (March 2011).
5.
坂口嘉一, 若杉祐太, 三好健文, 吉瀬謙二：コア融合アーキテクチャのためのプログラムの振
舞いに着目した融合コア数の制御, 情報処理学会第 72 回全国大会, 東京大学 本郷キャンパス
(2010 年 3 月 10 日発表), Vol.1, No. 3M-3, pp. 183-184 (March 2010).
受賞
6.
坂口嘉一： 情報処理学会第 72 回全国大会 学会推奨卒業論文「プログラムの振る舞いに着目
したコア融合プロセッサの動的最適化」 (March 2010).
第 6 章 研究業績
60
共著
雑誌論文
7.
若杉祐太, 坂口嘉一, 吉瀬謙二：協調可能スーパースカラ CoreSymphony, 情報処理学会論文
誌コンピューティングシステム, Vol.3, No.3, pp. 67-87 (September 2010).
国際シンポジウム（査読付き）
8.
Shinya Takamaeda, Shintaro Sano, Yoshito Sakaguchi, Naoki Fujieda, and Kenji Kise: ScalableCore System: A Scalable Many-core Simulator by Employing Over 100 FPGA, The 8th
International Symposium on Applied Reconfigurable Computing (ARC2011) (March 2012).
9.
Tomoyuki Nagatsuka, Yoshito Sakaguchi, Takayuki Matsumura, and Kenji Kise: CoreSymphony: An Efficient Reconfigurable Multi-core Architecture, International Workshop on HighlyEfficient Accelerators and Reconfigurable Technologies (HEART2011), pp. 29-34 (June 2011).
10.
Shinya Takamaeda, Ryosuke Sasakawa, Yoshito Sakaguchi, and Kenji Kise: An FPGA-based
Scalable Simulation Accelerator for Tile Architectures, International Workshop on HighlyEfficient Accelerators and Reconfigurable Technologies (HEART2011), pp.
35-40 (June
2011).
国内シンポジウム（査読付き）
11.
若杉祐太, 坂口嘉一, 吉瀬謙二：CoreSymphony アーキテクチャ, 先進的計算基盤システムシ
ンポジウム SACSIS2010 論文集, 於 奈良県新公会堂 (2010 年 5 月 27 日発表), pp.53-62 (May
2010).
口頭発表
12.
永塚智之, 坂口嘉一, 松村貴之, 吉瀬謙二：CoreSymphony の実現に向けた高性能フロントエン
ドアーキテクチャ, 情報処理学会研究報告 2011-ARC-195, 於 沖縄県立博物館・美術館 (2011
年 4 月 13 日発表), pp.1-8 (April 2011).
13.
若杉祐太, 坂口嘉一, 三好健文, 吉瀬謙二：CoreSymphony アーキテクチャのための物理レジス
タ管理手法, 情報処理学会研究報告 2009-ARC-188, 於 福岡システム LSI 総合開発センター,
2010 年 3 月 1 日発表, pp. 1-10 (March 2010).
14.
若杉祐太, 坂口嘉一, 三好健文, 吉瀬謙二：CoreSymphony アーキテクチャの高効率化, 情報処
61
理学会研究報告 2009-ARC-184, 於 フォレスト仙台, 2009 年 8 月 4 日発表, pp. 1-12 (August
2009).
講演，ポスター
15.
Takayuki Matsumura, Yoshito Sakaguchi, and Kenji Kise: Performance comparison of processors with different micro architectures, in International Symposium on Low-Power and HighSpeed Chips (COOL Chips), 於 Yokohama Japan(2011 年 4 月 21 日発表), p.1 (April 2011).