Tokyo Institute of TechnologyDepartment 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章 序論 11.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 2章 スーパースカラプロセッサ 32.1 ベースラインプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 命令フェッチ・デコード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 リネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 スケジュール・実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 メモリアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 リオーダバッファ (ROB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 商用プロセッサとベースラインプロセッサの比較 . . . . . . . . . . . . . . . . . . . 9

2.8 実装結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

第 3章 コア融合アーキテクチャ 133.1 コア融合アーキテクチャの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 コア融合アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

第 4章 CoreSymphonyの実装 154.1 命令フェッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 ローカル命令キャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.2 分岐予測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.3 命令フェッチの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 命令ステアリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 リーフノードステアリング . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 ステアリングロジック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.3 命令バッファ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.4 命令ステアリングの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 リネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

目次 iv

4.4 命令ウィンドウ・命令実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4.1 命令ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 コミット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

第 5章 評価 475.1 コア全体の論理合成結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 命令フェッチユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 ステアリングユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 命令ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.5 コミット機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

第 6章 結論 53

参考文献 57

v

図目次

2.1 ベースラインコア．2 命令発行のアウトオブオーダ実行を行う．上：パイプライ

ン構成．下：ブロック図．次のようなブロックから構成される．命令フェッチ

（fetch），命令デコード（decode）, レジスタリネーム（rename），命令ウィンドウ

および実行ユニット（Execution），メモリアクセス（Memory access），リタイア

（retire）． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 命令ウィンドウの構成要素．命令ウィンドウはウェイクアップ論理，セレクト論

理，ペイロード RAMからなる． . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 alpha21264のパイプライン構成．[2]より． . . . . . . . . . . . . . . . . . . . . . 10

4.1 コミット機構のブロック図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 ローカル命令キャッシュの概要． . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Tree-PHTの構造．タグ，予測結果，飽和型カウンタの木構造からなる．ツリーに

おける青い矩形は，2bitの飽和型カウンタを表す． . . . . . . . . . . . . . . . . . 20

4.4 上：tree更新の様子．分岐が成立であった場合はカウンタをインクリメント，不成

立であった場合はカウンタをデクリメントする．下：予測の様子．カウンタの値が

2（2’b10）より大きい場合,分岐が成立すると予測される. . . . . . . . . . . . . . 20

4.5 Tree-based Multiple branch Predictorのブロック図 . . . . . . . . . . . . . . . . . . 21

4.6 treeを更新する論理．各カウンタ毎に，分岐結果と古いカウンタ値から新しいカウ

ンタ値を求める． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7 treeから新たな予測結果を求める論理．i番目の予測結果を，0から i-1番目までの

予測結果を使用して選択する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.8 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の終端を検出． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.10 リーフノードステアリングの例．左は FBのデータフローグラフ（DFG），右はス

テアリング結果である．この例において，DFGは 3つのリーフノードを持ってい

る． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.11 ステアリングユニットのブロック図および，ステアリングロジックの詳細． . . . . 29

4.12 リーフノード選択論理. リーフノードベクトルからラウンドロビンで自コアに割

り当てるリーフノードを選択する．limと記された加算器は，出力の最大値が入力

CoreNumで制限され，(CoreNum-1)+1=0となる． . . . . . . . . . . . . . . . . . 31

4.13 先祖ノード行列（ANC) および steered leaf から，ステアリングベクトル（steer-

ing_vec)を求める論理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.14 エントリ構築フェーズから協調フェッチフェーズに移る際に，パイプラインのバイ

パスを考慮しない例．青で示した命令は，ステアリングが必要な命令．赤で示した

ものは，ステアリングが必要ない命令．図中の吹き出しで示すように，パイプライ

ンのバイパスを考慮しない場合，命令の追い越しが発生する. . . . . . . . . . . . . 33

4.15 ステアリングユニットの検証用テストベンチ．テストベンチの入力には，ソフト

ウェアシミュレータで生成した命令フェッチトレースとステアリング結果を用い

る． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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アーキテクチャを実装し

たプロセッサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3 ステアリングユニットのリソース消費量の比較 . . . . . . . . . . . . . . . . . . . . 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章 序論 2

1.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

RSmulpc if_pc Instmem+8 Dec0Dec1

IdRr

RMTFreeListRRMT

RS0 EX０MUL/DIVPRFreg scoreboardBpred ROBLSQ DatamemEX1

RSmem AGURS1

alignInstruction fetch

IfIdDecode

Rename Execution

Execution

Memoryaccess

Retire

Instruction FetchIF Instruction DecodeID Register RenameRR IssueIS Register FetchRF ExectionEX WriteBackWB RetireRTFront end Back endPipeline Stages

図 2.1 ベースラインコア．2命令発行のアウトオブオーダ実行を行う．上：パイプライン構成．下：ブロック図．次のようなブロックから構成される．命令フェッチ（fetch），命令デコード（decode）,レジスタリネーム（rename），命令ウィンドウおよび実行ユニット（Execution），メモリアクセス（Memory access），リタイア（retire）．

バックエンドでは，命令の実行とリタイアを行う．バックエンドを訪れた命令は，実行順序を決

定する命令ウィンドに投入される．命令ウィンドウは，オペランドの準備ができた命令を,実行ユ

ニットに対して発行（issue）する．その後，実行が完了した命令は，その後パイプラインをリタイ

アする．

リタイアにより命令の実行結果が確定する．リタイアした命令の結果は，取り消すことができな

い．逆に，分岐ミスなどにより誤ったパスをフェッチし，本来実行してはならない命令を実行して

も，リタイア前であれば命令を取り消せる．リタイアのはリオーダバッファ（ROB）が制御し，プ

ログラム順に行われる．

命令実行の順序は，基本的に命令ウィンドウが決定するが，メモリアクセスは，専用の機構（Load

Store Queue:LSQ）によりスケジュールされる．これは，(i)メモリを介した依存解決に，レジスタ間

とは異なる機構が必要な事，(ii)ストアは一度実行すると，取り消すのが一般的に困難な事による．

CoreSymphonyのベースであるアウトオブオーダコアのパラメータを，表 2.1にまとめる．

2.2 命令フェッチ・デコード 5

表 2.1 ベースのアウトオブオーダプロセッサのパラメータ

命令フェッチ 2命令 / cycle

デコード 2命令 / cycle

リネーム 2命令 / cycle

命令発行 2命令 / cycle

物理レジスタ 64エントリ, 4リード・2ライト

実行ユニット 整数 ×2,アドレス計算 ×1,乗除算 ×1

命令ウィンドウ 整数:16エントリ ×2,メモリ:8×1,乗除算:8エントリ ×1

ROB 32エントリ

LSQ 16エントリ

2.2 命令フェッチ・デコード

命令フェッチ・デコードは，インオーダプロセッサと大きな違いは存在しない．プログラム順に

命令をフェッチ・デコードする．

ただし，一般的にアウトオブオーダプロセッサは命令がフェッチされてから実行されるまでのレ

イテンシが長い．そのため，分岐予測ミスペナルティがより大きく，分岐予測の精度が性能に与え

る影響が増大する．また，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

WakeupCAMSelectLogic rdyPay load RAM

issue index

Issue inst. pdst図 2.2 命令ウィンドウの構成要素．命令ウィンドウはウェイクアップ論理，セレクト論理，ペ

イロード 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) 9

2.6 リオーダバッファ (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章 スーパースカラプロセッサ 10

図 2.3 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章 コア融合アーキテクチャ 14

3.2 コア融合アーキテクチャ

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

GlobalRe-order

Buffer

LocalRe-order

Buffer

LCB RCB

Local RetireComm.

InstructionWindow

ExecutePRF LRF

LRMT GRMT

Recons. Comm.

Operand Comm.

younger

Decode/Steering

ConventionalI-$

TMPLocal

I-$

Hit/Miss

bank=n?

L/S Comm.

UL

B-L

SQ

D-$

(2)(1)

(4)

(3)

(1)(1)

(2)

(1)

(2)(2)

to filter(1) (1)(3)

(1) (1)

(4)

(2)

(1)(1)

(3)

(2)

(1)

(3)

(2)(3)(2)(3)(4)

(1)

(2)

(3)

(1)

Instruction, Control

Data

Inter-core network

FreeList (5) (4)

(3) (3) filter

CommitCommit/Spec.

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

bpredPayload RAMtagRAM

tag matchinstruction,broadcast flagslot numbernext pc

bpredmatchhit

PCcalc TKN_slot, nextaddr, slotbranch pattern

pc destination vectorbranch numbranch patternHit / Miss detection

steered instructions FB’s control info図 4.2 ローカル命令キャッシュの概要．

4.1.2 分岐予測

すべてのコアで同一のパスをたどるため，CoreSymphonyにおいて分岐予測は，すべてのコアで

多重化している．分岐予測の分散は行われず，協調時の最大フェッチ幅に対応できる分岐予測器を，

すべてのコアが持たなければならない．

CoreSymphonyでは，予測器の複雑性を低減しつつ，性能を向上するため，トレースキャッシュ

向けの予測器の一つである Tree-based Multiple Branch Predictor（TMP）[9]を適用している．TMP

では，トレース（FB）単位で予測器のエントリを割り当てる．先に述べたように，FBの最大長は

協調コア数に比例する．FBの平均長が増すと，プログラムにおける静的な FBの数が減少する．そ

のため，協調コア数が増えると TMPにおけるエントリの競合が減少し，予測性能が向上する．

Tree-based Multiple branch predictorTMPの概要を図 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

treePHT c0c2 c1c4 c3c5c6c14 c10 c12 c8 c13 c9 c11 c7

tag predicted path treecontent of tree

2bit saturating counter図 4.3 Tree-PHTの構造．タグ，予測結果，飽和型カウンタの木構造からなる．ツリーにおける青い矩形は，2bitの飽和型カウンタを表す．

2bit saturating counter

takenuntaken1001 0101 00 01 0000 11 00 00 00 10 11 00

2bit saturating counter

takenuntaken0111 0101 10 01 0000 11 00 01 00 10 11 00branch path = { taken, untaken, untaken, taken}counter to update = {c0, c2, c4, c8}

UPDATEpredicted path = {taken, untaken, untaken, untaken}

図 4.4 上：tree更新の様子．分岐が成立であった場合はカウンタをインクリメント，不成立であった場合はカウンタをデクリメントする．下：予測の様子．カウンタの値が 2（2’b10）より大きい場合,分岐が成立すると予測される.

4.1 命令フェッチ 21fbpc / fb_retire / branch / br_patpattern gen

tag/v RAMfbpcupdate pipe

new_tree / new_result / new_tag

lookupresulttree PHTresult RAM

sghrghrflush

hittree readtree update/ predictwrite back図 4.5 Tree-based Multiple branch Predictorのブロック図

Tree-PHTTree-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 genTree-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 pipeupdate 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

branch pattern

u i sou i so u i so u i sou i so u i so u i so1

c0c1c2c3c4c7c8sat

u si

o

old counter value

new counter value

count element

図 4.6 treeを更新する論理．各カウンタ毎に，分岐結果と古いカウンタ値から新しいカウンタ値を求める．

counter value

predicted result

c0c1c2c3c4c5c6c7c8c9c10c12c13c14 c11

図 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の実装 24

4.1.3 命令フェッチの制御

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 命令ステアリング 25

Next State 0 Next State1inst 0 inst 1

state register

FB end at 1FB end at 0

hit L-cachePB0_0

hit L-cache / PB0_1

miss L-cache && not branch&& !Pblim / PB0_2 PB0_3not branch&& !Pblim / not branch&& !Pblim /

PB1_0 PB1_1 PB1_2 PB1_3branch or PBlimnot branch&& !Pblim / not branch&& !Pblim / not branch&& !Pblim /

branch or Pblim / detect FB end

state diagram of FB detection

図 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

(i)read enable

Local Instruction

cache (L-cache

) and Conv. I-cache (ii) hit Lo

cal Instruction

cache (iii) first 2 instructi

on from L-Cache(iv) stall

signal

(v) next 2 instructi

on from L-Cache,

end of FB

(vi)read enable

to fetch next FB

(vii) L-cahemiss

(vii) fetch from

Conv. I-cache

(ix)detect FB end

cooperative fetch

phasetrace con

struction phase

図 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

Ｉ０Ｉ1Ｉ3

Ｉ4 Ｉ5Ｉ6

Ｉ2Ｉ０Ｉ1Ｉ3

Ｉ5Ｉ6

Ｉ０Ｉ1

Ｉ4Ｉ2

replicated inst.leaf node

leaf node steering

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

ANCDTlsrc0lsrc1 checkintra depldst/ inst_valid

inst_cntslot

inc? leafnode_selector steered_leafsteering_vec

fbendflush ctrl

(2)(3)(1) (4)

図 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]の論理積を求める．

この結果を，ANCsel[i]とする．次に，すべての ANCsel の論理和により STを計算する．

4.2.3 命令バッファ

リーフノードステアリングは，FBに含まれる命令を逆順に解析し，命令を実行するコアを決定す

る．そのため，FBに含まれる最後の命令が STUに到達するまでステアリング結果はわからない．

この間，命令は命令バッファに保持される．

ステアリングロジックがステアリング結果であるステアリングベクトル（ST）を出力すると，そ

の結果に基づき，命令バッファは命令を次のリネームステージに送る．

CoreSymphonyにおいて，ローカル命令キャッシュからフェッチされた命令は，ステアリング済

である．そのため，ステアリングステージをパイパスできる．このように，パイプラインステージ

のバイパスが存在するため，命令フェッチがエントリ構築フェーズから協調フェッチフェーズに移

行する場合，注意が必要である．この場合のタイミングチャートを図 4.2.3に示す．図に青く示し

た命令列は，従来型命令キャッシュからフェッチした命令であり，ステアリングが必要である．一

方，赤で示した後続の命令は，ローカル命令キャッシュからフェッチした命令であり，ステアリン

4.2 命令ステアリング 31

limlimlimlim

0L[0]L[1]L[2]L[3]

CoreID steered_leaf[0]steered_leaf[1]steered_leaf[2]steered_leaf[3]

CoreNum

図 4.12 リーフノード選択論理. リーフノードベクトルからラウンドロビンで自コアに割り当てるリーフノードを選択する．limと記された加算器は，出力の最大値が入力 CoreNumで制限され，(CoreNum-1)+1=0となる．

グステージをバイパスできる．このとき，後続の命令をそのままバイパスする場合，図に示すよう

に命令の追い越しが発生する．

これを防ぐため，ステアリング中にローカル命令キャッシュからフェッチされた命令が ID ス

テージに到達した場合，IDステージで命令をストールさせる．

ステアリングにおける，ステアリング結果確定フェーズには 1サイクルが割り当てられている．

そのため，後続の命令が連続して従来型命令キャッシュからフェッチされる場合，命令バッファの

エントリが上書きされる．命令バッファがリングバッファで実装されていないため，このような事

態が生じる．

リングバッファで構成し，エントリ数に余裕を持たせることで，上書きは回避できる．この方法

をとった場合，ステアリングベクトルから命令バッファのエントリを求めるときに，変換が必要に

なり，制御が複雑になる．

代わりに本実装では，上書きが生じるタイミングでフェッチが行われた場合，ID ステージをス

トールさせ，FB間に 1サイクルの猶予を入れている．

第 4章 CoreSymphonyの実装 32

leaf_selectsteered_leaf[0]

steering_vec

steered_leaf[1]steered_leaf[2]steered_leaf[3]

図 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

I0I1 I2I3 I4I5 steerID output/ST outputST output (RR input) I0I1

I6-CLK

I0I1 I2I3I0I1 I2I3 I4I5IF output/ID input I6- I0I1 I2I3

ST Bypass (RR input) I0I1I0I1 I2I32nd FB’s inst overtakes1st FB’s inst図 4.14 エントリ構築フェーズから協調フェッチフェーズに移る際に，パイプラインのバイパ

スを考慮しない例．青で示した命令は，ステアリングが必要な命令．赤で示したものは，ステア

リングが必要ない命令．図中の吹き出しで示すように，パイプラインのバイパスを考慮しない場

合，命令の追い越しが発生する.

Steering ModuleInput generator 2 inststall Output Comparatorsteered inst

match or not

Fetch tracefile Steeringtracefileconfiguration・the number of cores・CoreIDSoftware Simulator generategenerate

test bench図 4.15 ステアリングユニットの検証用テストベンチ．テストベンチの入力には，ソフトウェア

シミュレータで生成した命令フェッチトレースとステアリング結果を用いる．

第 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

InstructionWindowissueRegisterFetch stage

ExecutionUnitPhysical Register File

LtagLogical register #Gtag

result from local

3 kinds of wakeup source

operand comm. networkfilter recons. networkresult fromremote

Logical Register File

図 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

Rdy_L LRF_L remote_L tag_LLtag from local coreGtag from remote coreLogical register #from Recovery Logic

Rdy_Lremote_preg

remote_match

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

Rdy_L LRF_L remote_L tag_LLtag from local coreGtag from remote coreLogical register #from Recovery Logic

Rdy_Lremote_preg

remote_match

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 ‘default_nettype none2 ‘include "../define.v"3

4 module lcb #(5 parameter W_DEPTH = ‘W_LCB_DEPTH ,6 localparam DEPTH = 2**W_DEPTH,7 parameter W_FBID = ‘W_FBID,8 localparam W_RET = 2,9 parameter W_FBLEN = ‘W_FBLEN,

10

11 parameter W_PREG = ‘W_PREG,12 parameter W_LREG = ‘W_LREG,13 parameter W_D = ‘W_D,14 parameter W_A = ‘W_A15 )(16 input wire CLK,17 input wire RST_X,18

19 output wire full_o,20 output wire empty_o,21

22 output wire clean_o,23

24 input wire [W_RET -1:0] alloc_i,25

26 input wire [W_FBID -1:0] alloc0_fbid_i ,27 input wire [W_FBLEN -1:0] alloc0_slot_i ,28 input wire [W_LREG -1:0] alloc0_lreg_i ,29 input wire [W_PREG -1:0] alloc0_preg_i ,30 input wire [W_PREG -1:0] alloc0_ppreg_i ,31 input wire alloc0_drain_i ,32 input wire [W_A-1:0] dbg_alloc0_pc_i ,33

34 input wire [W_FBID -1:0] alloc1_fbid_i ,35 input wire [W_FBLEN -1:0] alloc1_slot_i ,36 input wire [W_LREG -1:0] alloc1_lreg_i ,37 input wire [W_PREG -1:0] alloc1_preg_i ,38 input wire [W_PREG -1:0] alloc1_ppreg_i ,39 input wire alloc1_drain_i ,40 input wire [W_A-1:0] dbg_alloc1_pc_i ,41

42 input wire ret_fb_i ,43 input wire [W_FBID -1:0] ret_fbid_i ,44 input wire ret_exc_i ,45 input wire [W_FBLEN -1:0] ret_exc_slot_i ,46

47 input wire stall_commit_i ,48

49 output wire commit0_o ,50 output wire commit0_drain_o ,51 output wire [W_LREG -1:0] commit0_lreg_o ,52 output wire [W_PREG -1:0] commit0_preg_o ,53 output wire [W_PREG -1:0] commit0_ppreg_o ,54 output wire [W_A-1:0] dbg_commit0_pc_o ,55

56 output wire commit1_o ,57 output wire commit1_drain_o ,58 output wire [W_LREG -1:0] commit1_lreg_o ,59 output wire [W_PREG -1:0] commit1_preg_o ,60 output wire [W_PREG -1:0] commit1_ppreg_o ,61 output wire [W_A-1:0] dbg_commit1_pc_o

第 4章 CoreSymphonyの実装 42

62 );63

64 wire [W_DEPTH -1:0] head_ptr;65 wire [W_DEPTH -1:0] head_next_ptr = head_ptr+1;66 wire [W_DEPTH -1:0] tail_ptr;67 wire [W_DEPTH -1:0] tail_next_ptr = tail_ptr+1;68

69 localparam W_FIFO = W_FBLEN + W_LREG + W_PREG + W_PREG + 1;70

71 wire [W_FBLEN -1:0] commit0_slot;72 wire [W_FBLEN -1:0] commit1_slot;73 wire commit0_drain;74 wire commit1_drain;75

76 wire [1:0] commit;77 fifo_2i2o #(.W(W_FIFO), .DL2(W_DEPTH))78 preg_fifo(.CLK(CLK), .RST_X(RST_X),79 .ENQ0(alloc_i[0]),80 .I0({alloc0_slot_i , alloc0_lreg_i , alloc0_preg_i , alloc0_ppreg_i ,81 alloc0_drain_i}),82 .ENQ1(alloc_i[1]),83 .I1({alloc1_slot_i , alloc1_lreg_i , alloc1_preg_i , alloc1_ppreg_i ,84 alloc0_drain_i}),85 .DEQ0(commit[0]),86 .O0({commit0_slot , commit0_lreg_o , commit0_preg_o , commit0_ppreg_o ,87 commit0_drain}),88 .DEQ1(commit[1]),89 .O1({commit1_slot , commit1_lreg_o , commit1_preg_o , commit1_ppreg_o ,90 commit1_drain}),91 .HEAD(head_ptr),92 .TAIL(tail_ptr)93 );94 // for debug95 reg [W_A-1:0] pcram[DEPTH -1:0];96 always @(posedge CLK)begin97 if(alloc_i[0]) pcram[tail_ptr] <= dbg_alloc0_pc_i;98 if(alloc_i[1]) pcram[tail_next_ptr] <= dbg_alloc1_pc_i;99 end

100 assign dbg_commit0_pc_o = pcram[head_ptr];101 assign dbg_commit1_pc_o = pcram[head_next_ptr];102

103 // wakeup104 reg valid[DEPTH -1:0];105 reg commit_rdy[DEPTH -1:0];106 reg drain[DEPTH -1:0];107 reg [W_FBID -1:0] fbid[DEPTH -1:0];108 integer i;109 always @(posedge CLK)begin110 if(!RST_X)begin111 for(i = 0 ; i < DEPTH ; i=i+1)begin112 valid[i] <= 1’b0;113 end114 end115

116 // allocate LCB entry117 if(alloc_i[0])begin118 valid[tail_ptr] <= 1’b1;119 commit_rdy[tail_ptr] <= 1’b0;120 fbid[tail_ptr] <= alloc0_fbid_i;121 drain[tail_ptr] <= alloc0_drain_i;122 end123

124 if(alloc_i[1])begin125 valid[tail_next_ptr] <= 1’b1;126 commit_rdy[tail_next_ptr] <= 1’b0;127 fbid[tail_next_ptr] <= alloc1_fbid_i;128 drain[tail_next_ptr] <= alloc1_drain_i;129 end130

131 // commit wakeup132 if(ret_fb_i)begin133 for(i = 0 ; i < DEPTH ; i=i+1)begin134 if(fbid[i]==ret_fbid_i && valid[i]) commit_rdy[i] <= 1’b1;

4.5 コミット 43

135 end136

137 if(ret_exc_i)begin138 for(i = 0 ; i < DEPTH ; i=i+1)139 drain[i] <= 1’b1;140 end141 end142

143 if(commit0_o)begin144 valid[head_ptr] <= 1’b0;145 end146 if(commit1_o)begin147 valid[head_next_ptr] <= 1’b0;148 end149 end150

151 reg exc_handling;152 reg [W_FBLEN -1:0] eslot;153 reg [W_FBID -1:0] efbid;154 always @(posedge CLK)begin155 if(!RST_X)begin156 exc_handling <= 0;157 efbid <= 1;158 eslot <= 0;159 end160 else if(ret_exc_i)begin161 exc_handling <= 1’b1;162 efbid <= ret_fbid_i;163 eslot <= ret_exc_slot_i;164 end165 else if(ret_fb_i || empty_o)begin166 exc_handling <= 1’b0;167 end168 end169

170 // check commit171 assign commit0_o = !stall_commit_i && valid[head_ptr]172 && (commit_rdy[head_ptr] || commit0_drain || exc_handling);173 assign commit1_o = !stall_commit_i && valid[head_next_ptr] && commit0_o174 && (commit_rdy[head_next_ptr] || commit1_drain || exc_handling);175

176 // check condition177 wire head0_do_not_drain = (fbid[head_ptr] == efbid) && (commit0_slot < eslot)178 || (fbid[head_ptr] != efbid) && commit_rdy[head_ptr];

// preceeding FB’s inst179 wire head1_do_not_drain = (fbid[head_next_ptr] == efbid) && (commit1_slot < eslot)180 || (fbid[head_next_ptr] != efbid) && commit_rdy[head_next_ptr];

// preceeding FB’s inst181

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 // fifo entry counter189 wire alloc_two = &alloc_i;190 wire alloc_one = (alloc_i==2’b10) || (alloc_i==2’b01);191 wire commit_one = (commit==2’b10) || (commit==2’b01);192 wire commit_two = &commit;193

194 reg [W_DEPTH -1:0] ent_cnt;195 always @(posedge CLK)begin196 if(!RST_X)begin197 ent_cnt <= 0;198 end199 else begin200 if(alloc_two)begin201 if(commit_one) ent_cnt <= ent_cnt+1;202 if(!commit_two && !commit_one) ent_cnt <= ent_cnt+2;203 end204 else if(alloc_one)begin205 if(commit_two) ent_cnt <= ent_cnt -1;

第 4章 CoreSymphonyの実装 44

206 if(!commit_two && !commit_one) ent_cnt <= ent_cnt+1;207 end208 else begin209 if(commit_one) ent_cnt <= ent_cnt -1;210 if(commit_two) ent_cnt <= ent_cnt -2;211 end212 end213 end214

215 localparam FULL_CNT = DEPTH -2;216 assign full_o = (ent_cnt == FULL_CNT);217 assign empty_o = (ent_cnt == 0);218 assign clean_o = !lcb_dirty;219

220 reg [W_FBID -1:0] current_fbid;221 reg lcb_dirty;222

223 wire [W_FBID -1:0] head_fbid = fbid[head_ptr];224 wire clean_cond = (head_fbid != current_fbid) || empty_o;225

226 always @(posedge CLK)begin227 if(!RST_X)begin228 lcb_dirty <= 0;229 end230 else if(ret_fb_i)begin231 lcb_dirty <= 1’b1;232 current_fbid <= ret_fbid_i;233 end234 else if(clean_cond)begin235 lcb_dirty <= 1’b0;236 end237 end238

239 endmodule240 ‘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およ

び Is が存在するとする．I fは Is に先行するとする．このとき，ブロードキャストされるのは Is の

結果のみである．ここで I fと Is の間で例外が発生すると，再開時には I f の結果が必要になる．し

かし，ブロードキャストのフィルタリングにより，その結果は I f を実行したコアにしか存在せず，

他のコアで使用できない．ブロードキャストされてきた結果を破棄した場合も同様に, 必要な値が

存在しないコアが生じる可能性がある．

このような状態を防ぐため，CoreSymphonyは例外からの実行再開時，コア間で通信を行い，正

しいレジスタの内容を復元する．正しい値を持つコアが，その値を他のコアにブロードキャストし，

レジスタを復元する．このとき値は,物理レジスタファイル（PRF）ではなく，論理レジスタファイ

ル（LRF）に書き込む．

復元時，あるコアの論理レジスタには３つの状態が考えられる．これらの状態を INVALID，

BROADCAST, VALIDと呼ぶことにする．

• INVALID.自コアには有効な値が存在しない．リタイアする FBのデスティネーションベク

タにより遷移する．

• BROADCAST. 自コアに有効な値が存在し，他コアにブロードキャストする必要がある．

LCBから命令がリタイアする際に，遷移する．

• VALID.自コアに有効な値が存在するが他コアにブロードキャストする必要がない．RCBか

ら命令がリタイアする際に，もしくはパイプラインフラッシュ時に遷移する．

これらのステートは LRFマネージャにより管理される．LRFマネージャは，コミットされる FB

および命令列を監視し，論理レジスタのステート変更する．

第 4章 CoreSymphonyの実装 46

GlobalRe-order

Buffer

LocalRe-order

Buffer

LCB RCB

Local RetireComm.

InstructionWindow

ExecutePRF LRF

LRMT GRMT

Recons. Comm.

Operand Comm.

younger

Decode/Steering

ConventionalI-$

TMPLocal

I-$

Hit/Miss

bank=n?

L/S Comm.

UL

B-L

SQ

D-$

(2)(1)

(4)

(3)

(1)(1)

(2)

(1)

(2)(2)

to filter(1) (1)(3)

(1) (1)

(4)

(2)

(1)(1)

(3)

(2)

(1)

(3)

(2)(3)(2)(3)(4)

(1)

(2)

(3)

(1)

Instruction, Control

Data

Inter-core network

FreeList (5) (4)

(3) (3) filter

CommitCommit/Spec.

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

CoreSymphony conventional Out of Oder

FetchDecodeRenameInst windowLoad storecommitSteeringother

図 5.1 配置配線結果.

を消費している．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

0500010000150002000025000

LUT FFResource comsumption

resource2issue inorderout of orderCoreSymphony

図 5.2 配置配線後のハードウェア規模．Lookup table(LUT)と Flip-Flop(FF)．inorder-SSはインオーダ実行の２命令発行プロセッサ．out of orderは 2命令発行のアウトオブオーダプロセッサ，CoreSymphonyは CoreSymphonyアーキテクチャを実装したプロセッサ

02004006008001000120014001600the number of cooupied resources otherconvTMPpcconlcdetecBTB

図 5.3 ステアリングユニットのリソース消費量の比較

第 5章 評価 50

050010001500200025003000

FF:CoreSymphony FF:out of orderth number of occupied resources otherleafdisb

図 5.4 ステアリングユニットのリソース消費量の比較

ジュールである．ステアリング論理のより効率的な実装，もしくは小規模なハードウェアで実装で

きるアルゴリズムが必要と考えられる．

命令バッファのハードウェアが小規模とは言い切れない．図 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

0200400600800100012001400the number of occupied resource

図 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

050010001500200025003000th number of occupied resources otherrcblroblrfmanelcbgrobcb

図 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 out-

of-order instruction issue. In DAC ’08: Proceedings of the 45th annual Design Automation Con-

ference, pp. 772–775, New York, NY, USA, 2008. ACM.

[7] Carlos Madriles, Pedro López, Josep M. Codina, Enric Gibert, Fernando Latorre, Alejandro Mar-

tinez, 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 sym-

posium 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: Proceed-

ings 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: Scal-

ableCore 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: CoreSym-

phony: An Efficient Reconfigurable Multi-core Architecture, International Workshop on Highly-

Efficient 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 Highly-

Efficient 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 proces-

sors with different micro architectures, in International Symposium on Low-Power and High-

Speed Chips (COOL Chips),於 Yokohama Japan(2011年 4月 21日発表), p.1 (April 2011).