Transcript Wakeup

CMPにおけるオンチップルータの
細粒度パワーゲーティングの評価
松谷 宏紀
(東京大学)
鯉渕 道紘 (国立情報学研究所)
池淵 大輔
(慶應義塾大学)
宇佐美 公良
(芝浦工業大学)
中村 宏
(東京大学)
天野 英晴
(慶應義塾大学)
Number of PEs (caches are not included)
最近のマルチコア・メニーコア
picoChip PC102
256
picoChip PC205
ClearSpeed CSX700
128
64
Intel 80-core
TILERA TILE64
ClearSpeed CSX600
Intel SCC
32
MIT RAW
16
UT TRIPS (OPN)
STI Cell BE
8
Sun T1
Fujitsu SPARC64
Intel Core, IBM Power7
AMD Opteron
4
2
Sun T2
2002
2004
2006
2008
2010
Number of PEs (caches are not included)
最近のマルチコア・メニーコア
picoChip PC102
256
picoChip PC205
ClearSpeed CSX700
シンプルな PE を大量に接続
128
64
Intel 80-core
TILERA TILE64
ClearSpeed CSX600
Intel SCC
32
MIT RAW
16
UT TRIPS (OPN)
STI Cell BE
8
Sun T1
Sun T2
Fujitsu SPARC64
Intel Core, IBM Power7
AMD Opteron
4
2
高性能 CPU を
複数接続
2002
2004
2006
2008
2010
共有メモリ型 CMP: Network-on-Chip
• 8-CPU CMP の構成例
– プロセッサ (プライベート L1 キャッシュ内蔵)
– 共有 L2 キャッシュ、バンク分割 (non-uniform cache arch)
[Beckmann, MICRO’04]
UltraSPARC
L1キャッシュ (I & D)
(各 16kB)
L2キャッシュバンク
(各 256kB, 4-way)
共有メモリ型 CMP: Network-on-Chip
• 8-CPU CMP の構成例
– プロセッサ (プライベート L1 キャッシュ内蔵)
– 共有 L2 キャッシュ、バンク分割 (non-uniform cache arch)
– プロセッサと L2 バンクの結合  Network-on-Chip (NoC)
[Beckmann, MICRO’04]
NoC は CMP の通信インフラストラクチャーなので、
いつでもパケット転送できる状態でなければならない。
UltraSPARC
でも、それだと NoC が常にリーク電力を消費してしまう。。
L1キャッシュ (I & D)
そこで、NoC にランタイム・パワーゲーティングを適用して、
(各 16kB)
L2キャッシュバンク
リーク電力を最小限に抑えよう！(各 256kB, 4-way)
オンチップルータ
発表の流れ: 細粒度 PG ルータの評価
• オンチップルータの細粒度パワーゲーティング
– 入力バッファ、 出力ラッチ
– クロスバMUX、仮想チャネルMUX
35個のパワードメイン
(ルータ1個あたり)
• パワードメインのハードウェア評価
– 回路設計 @ Fujitsu 65nm
– 面積、ウェイクアップ遅延、On/Off エネルギー
• 早期ウェイクアップ手法
オーバヘッドをちゃんと評価します
– ウェイクアップ遅延の隠ぺい
• CMP システムレベル評価
– アプリケーション性能 (早期ウェイクアップ付き)
– リーク電力の削減量 (On/Off エネルギー込み)
パワーゲーティング: 粗粒度 vs. 細粒度
• 粗粒度なアプローチ
– IPコア (モジュール) 単位
– VGND リングで囲む
– VGND と GND の間にパ
ワースイッチを挿入
• 細粒度なアプローチ
– スタセル単位
– セルごとに VGND ポート
– 同じドメインのセルは、同じ
VGND ラインを共有
[宇佐美, ICCD’06]
Virtual GND (VGND)
IP Core
On/Off
GND ring
Power
Switch
IP Core
パワーゲーティング: 粗粒度 vs. 細粒度
• 粗粒度なアプローチ
– IPコア (モジュール) 単位
– VGND リングで囲む
– VGND と GND の間にパ
ワースイッチを挿入
Virtual GND (VGND)
• 細粒度なアプローチ
– スタセル単位
– セルごとに VGND ポート
– 同じドメインのセルは、同じ
VGND ラインを共有
[宇佐美, ICCD’06]
Power
Switch
VDD
OR AND
IP Core
On/Off
GND
VGND
On/Off
GND ring
Power
Switch
GND
INV
VDD
DFF
パワーゲーティング: 粗粒度 vs. 細粒度
• ルータ内の細かい部品 (入力バッファ、マルチプレクサ)
は、互いに独立して動作する
– 細粒度 PG のほうがスリープできるチャンスが多い
ARBITER
X+
X+
Packet#1
X-
X-
Y+
Y+
Packet#2
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
Packet
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
細粒度ランタイム PG ルータ
• 各ルータは、多数のマイクロパワードメインに分割
– 入力 VC バッファ、 出力ラッチ
– 仮想チャネルMUX、クロスバMUX
35個のパワードメイン
(ルータ1個あたり)
ARBITER
X+
X+
X-
X-
Y+
Y+
Y-
Y-
CORE
5x5
CROSSBAR
CORE
各パワードメインは本当に使われるときだけ起こされる (リークを消費)
発表の流れ: 細粒度 PG ルータの評価
• オンチップルータの細粒度パワーゲーティング
– 入力バッファ、 出力ラッチ
– クロスバMUX、仮想チャネルMUX
35個のパワードメイン
(ルータ1個あたり)
• パワードメインのハードウェア評価
– 回路設計 @ Fujitsu 65nm
– 面積、ウェイクアップ遅延、On/Off エネルギー
• 早期ウェイクアップ手法
– ウェイクアップ遅延の隠ぺい
• CMP システムレベル評価
– アプリケーション性能 (早期ウェイクアップ付き)
– リーク電力の削減量 (On/Off エネルギー込み)
細粒度ランタイムPGルータ: 設計フロー
• Verilog ネットリスト
Synopsys DesignCompiler
• Holdセル挿入 (スリープ
時に不定値伝搬を防ぐ)
By hand
• 自動配置配線
Synopsys Astro
• パワースイッチ挿入
Sequence Design CoolPower
• 自動配置配線 (再び)
module FIFO (in, out);
input [127:0] in;
output [127:0] out:
DFF reg0 (in0, out0, clk);
DFF reg1 (in1, out1, clk);
Synopsys Astro
• SPICE ネットリスト抽出
Cadence Assura (QRC)
• SPICE シミュレーション
Synopsys HSIM
endmodule
細粒度ランタイムPGルータ: 設計フロー
• Verilog ネットリスト
Synopsys DesignCompiler
• Holdセル挿入 (スリープ
時に不定値伝搬を防ぐ)
By hand
• 自動配置配線
Synopsys Astro
• パワースイッチ挿入
Sequence Design CoolPower
• 自動配置配線 (再び)
module FIFO (in, out);
input [127:0] in;
output [127:0] out:
DFF reg0 (in0, out0, clk);
DFF reg1 (in1, out1, clk);
Synopsys Astro
• SPICE ネットリスト抽出
Cadence Assura (QRC)
• SPICE シミュレーション
Synopsys HSIM
HOLD (out0);
HOLD (out1);
endmodule
細粒度ランタイムPGルータ: 設計フロー
• Verilog ネットリスト
Synopsys DesignCompiler
• Holdセル挿入 (スリープ
時に不定値伝搬を防ぐ)
VDD
OR AND
By hand
• 自動配置配線
DFF
GND
Synopsys Astro
• パワースイッチ挿入
GND
Sequence Design CoolPower
INV
• 自動配置配線 (再び)
Synopsys Astro
• SPICE ネットリスト抽出
Cadence Assura (QRC)
• SPICE シミュレーション
Synopsys HSIM
DFF
AND OR NOR
VDD
Domain#0
Domain#1
細粒度ランタイムPGルータ: 設計フロー
Power
Switch
• Verilog ネットリスト
Synopsys DesignCompiler
• Holdセル挿入 (スリープ
時に不定値伝搬を防ぐ)
VDD
OR AND
By hand
• 自動配置配線
Synopsys Astro
• パワースイッチ挿入
DFF
GND
VGND
GND
Sequence Design CoolPower
INV
• 自動配置配線 (再び)
Synopsys Astro
• SPICE ネットリスト抽出
Cadence Assura (QRC)
• SPICE シミュレーション
Synopsys HSIM
DFF
AND OR NOR
VDD
Domain#0
Domain#1
パワードメインの評価: 面積オーバヘッド
Power
Switch
• Hold セル
– ゲート数 2.6% 増
– ドメインの出力ポート数に
応じて増える
• パワースイッチ
– ゲート数 1.7% 増
– ウェイクアップ速度に応じ
て増える
VDD
OR AND
GND
VGND
GND
INV
• スタセルの改造
– 各セルに VGND ポートを
取り付ける
– 全セルの高さを 10/9 倍
DFF
DFF
AND OR NOR
VDD
Domain#0
Domain#1
Holdセル&パワースイッチで 4.3%増、スタセル改造を含めると15.9%
パワードメインの評価: ウェイクアップ遅延
Correct output
FIFO
OUT[1]
2.8nsec
Wakeup &
Initialization
FIFO
OUT[0]
• ウェイクアップ遅延
– 電源オフの回路に電源を
投入し、動作するまで
– パケット通信遅延が増える
入力 VC バッファの例
Clock
VDD
FIFO
FIFO
Wakeup
Power ON
Fujitsu 65nm CMOS (1.20V, 75C)
VGND
Wakeup
GND
Switch
パワードメインの評価: ウェイクアップ遅延
Correct output
1.3nsec
Wakeup
MUX
OUT[1]
MUX
OUT[0]
• ウェイクアップ遅延
– 電源オフの回路に電源を
投入し、動作するまで
– パケット通信遅延が増える
クロスバ MUX の例
Clock
VDD
MUX
Wakeup
Power ON
VGND
Wakeup
GND
Switch
パワードメインの電源オンして動作するまで
3nsec (3-cycle@1GHz)
Fujitsu 65nm CMOS (1.20V, 75C)
パワードメインの評価: On/Off エネルギー
FIFO
OUT[1]
Clock is stopped to clearly
show On/Off energy FIFO
OUT[0]
• On/Off エネルギー
– パワースイッチの駆動
– ウェイクアップ信号の配線
– スリープ期間が短いと、
“元” が取れなくなる
入力 VC バッファの例
Power
Off
On/Off energy
Wakeup
VDD
FIFO
FIFO
Current
VGND
Wakeup
Switch
GND
60～99nsec以上のスリープなら、On/Off
エネルギーを償却できる
Fujitsu 65nm CMOS (1.20V, 75C)
発表の流れ: 細粒度 PG ルータの評価
• オンチップルータの細粒度パワーゲーティング
– 入力バッファ、 出力ラッチ
– クロスバMUX、仮想チャネルMUX
35個のパワードメイン
(ルータ1個あたり)
• パワードメインのハードウェア評価
– 回路設計 @ Fujitsu 65nm
– 面積、ウェイクアップ遅延、On/Off エネルギー
• 早期ウェイクアップ手法
– ウェイクアップ遅延の隠ぺい
• CMP システムレベル評価
– アプリケーション性能 (早期ウェイクアップ付き)
– リーク電力の削減量 (On/Off エネルギー込み)
ウェイクアップ遅延の影響: 評価環境
• CMPシミュレータ: GEMS/Simics
– 3サイクルルータ [RC] [VSA] [ST]
– ウェイクアップ遅延: 2, 3, 4 cycles
– SPLASH-2 ベンチマーク (8スレッド)
[Martin,CAN’05]
radix, lu, fft, barnes,
ocean, raytrace, volrend,
water-ns, water-sp, fmm
(10種類のアプリ)
UltraSPARC
L1キャッシュ (I & D)
(各 16kB)
L2キャッシュバンク
(各 256kB, 4-way)
オンチップルータ
ウェイクアップ遅延の影響: 評価環境
• CMPシミュレータ: GEMS/Simics
– 3サイクルルータ [RC] [VSA] [ST]
– ウェイクアップ遅延: 2, 3, 4 cycles
– SPLASH-2 ベンチマーク (8スレッド)
[Martin,CAN’05]
radix, lu, fft, barnes,
ocean, raytrace, volrend,
water-ns, water-sp, fmm
(10種類のアプリ)
Token coherence プロトコル
[Martin,ISCA’03]
• 仮想チャネル0
– リクエスト (L1 ⇔ L2) 用
• 仮想チャネル1
– リクエスト (L2 ⇔ 主記憶) 用
• 仮想チャネル2
– リプライ用
• 仮想チャネル3
– スタベイション回避用
ウェイクアップ遅延の影響: 評価結果
SPLASH-2 ベンチ (10個の並列アプリ) の実行時間
アプリの実行時間 (正規化)
2-cycle ウェイク
(667MHz)
3-cycle ウェイク
(1000MHz)
4-cycle ウェイク
(1333MHz)
パワーゲーティングしないときの実行時間 = 1.00
アプリの実行時間が平均 23.2% ～ 46.3% 増加
Barnes Ocean Ray- Vol- Water Water Fmm Ave
trace rend NS
SP
実行時間の増加はエネルギ増  ウェイクアップ遅延の隠蔽が必須
Radix
Lu
Fft
早期ウェイクアップ: Look-ahead method
• 2ホップ先のルータモジュールを事前にウェイクアップ
– Look-ahead ルーティングを使用
CPU
Wakeup
1ホップ目
[松谷,ASPDAC’08]
Wakeup
2ホップ目
L2キャッシュ
Wakeup
3ホップ目
4ホップ目
5ホップ目
ルータ(1)が、ルータ(2)の出力ポートを決める  ルータ(3)の入力ポートが判明
ルータ(1)
ルータ(2)
ルータ(3)
HEAD NRC VSA ST NRC VSA ST NRC VSA ST
DATA 1
DATA 2
SA
SA ST
ST
SA
ST
SA
ST
SA ST
ST
SA
ST
ST
ST
DATA 3
SA
SA
SA
ところで、、1ホップ目はどうやって事前にウェイクアップさせるの??
早期ウェイクアップ: LA + CPU ever-on
• 2ホップ先のルータモジュールを事前にウェイクアップ
– Look-ahead ルーティングを使用
CPU
Wakeup
Wakeup
[松谷,ASPDAC’08]
L2キャッシュ
Wakeup
Ever-on
1ホップ目
2ホップ目
3ホップ目
• Ever-on ドメイン
– 電源を落とさない
– ウェイクアップ遅延無し
NoCのトラフィック量を解析
4ホップ目
5ホップ目
• 仮想チャネル0
– リクエスト (L1 ⇔ L2) 用
• 仮想チャネル1
– リクエスト (L2 ⇔ 主記憶) 用
• 仮想チャネル2
– リプライ用
– CPU隣接ポートの VC0、VC2
• 仮想チャネル3
のみ Ever-on に設定
Ever-on チャネルは全体の4.7%  最小コストで遅延を大幅に削減
– スタベイション回避用
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
Write
5x5
CROSSBAR
CORE
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
Write
5x5
CROSSBAR
CORE
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
Write
5x5
CROSSBAR
CORE
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
Write
5x5
CROSSBAR
CORE
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
Write
5x5
CROSSBAR
CORE
早期ウェイクアップ: LA + Buffer window
• FIFO バッファの先頭を予め電源オン
[Chen,ISLPED’03]
– Window size = 常にオンにしておくバッファ量
– 短いパケット (window size 以下)  ウェイクアップ遅延無し
ARBITER
X+
Window size = 3
XY+
Y+
YRead
5x5
CROSSBAR
CORE
Write
遅延は隠蔽できるが、window
size分PGできないリーク削減量(少)
発表の流れ: 細粒度 PG ルータの評価
• オンチップルータの細粒度パワーゲーティング
– 入力バッファ、 出力ラッチ
– クロスバMUX、仮想チャネルMUX
35個のパワードメイン
(ルータ1個あたり)
• パワードメインのハードウェア評価
– 回路設計 @ Fujitsu 65nm
– 面積、ウェイクアップ遅延、On/Off エネルギー
• 早期ウェイクアップ手法
– ウェイクアップ遅延の隠ぺい
• CMP システムレベル評価
– アプリケーション性能 (早期ウェイクアップ付き)
– リーク電力の削減量 (On/Off エネルギー込み)
CMP シミュレータ: GEMS/Simics
• フルシステムシミュレーション
– CPU 8個、L2バンク64個、4x4メッシュ
– Sun Solaris 9、Sun Studio 12
– SPLASH-2 ベンチマーク (8スレッド)
[Martin,CAN’05]
radix, lu, fft, barnes,
ocean, raytrace, volrend,
water-ns, water-sp, fmm
(10種類のアプリ)
UltraSPARC
L1キャッシュ (I & D)
(各 16kB)
L2キャッシュバンク
(各 256kB, 4-way)
オンチップルータ
CMP シミュレータ: GEMS/Simics
• フルシステムシミュレーション
[Martin,CAN’05]
– CPU 8個、L2バンク64個、4x4メッシュ
– Sun Solaris 9、Sun Studio 12
– SPLASH-2 ベンチマーク (8スレッド)
radix, lu, fft, barnes,
ocean, raytrace, volrend,
water-ns, water-sp, fmm
(10種類のアプリ)
Token coherence プロトコル
[Martin,ISCA’03]
• 仮想チャネル0
– リクエスト (L1 ⇔ L2) 用
• 仮想チャネル1
– リクエスト (L2 ⇔ 主記憶) 用
• 仮想チャネル2
– リプライ用
• 仮想チャネル3
– スタベイション回避用
評価環境: アプリケーション性能
• フルシステムシミュレーション
– CPU 8個、L2バンク64個、4x4メッシュ
– Sun Solaris 9、Sun Studio 12
– SPLASH-2 ベンチマーク (8スレッド)
radix, lu, fft, barnes,
ocean, raytrace, volrend,
water-ns, water-sp, fmm
(10種類のアプリ)
• 早期ウェイクアップ手法(3種)で、アプリ性能を比較
SRC
DST
Wakeup
SRC
DST
Window size = 2
Wakeup
Read
Ever-on
Look-ahead
LA + CPU ever-on
Write
LA + Buffer window
• ウェイクアップ遅延: 3nsec (3-cycleウェイクアップ@ 1GHz)
評価結果: アプリケーション性能
SPLASH-2 ベンチの実行時間 (3-cycle ウェイクアップ@ 1GHz)
Look-ahead +
CPU ever-on
Look-ahead
Look-ahead +
Buffer window
アプリの実行時間 (正規化)
(1.00 = パワーゲーティングしないときの実行時間)
早期ウェイクアップ手法がないときの実行時間 (+35.3%)
CPU ever-on のときの性能オーバヘッドは +4.0%
Barnes Ocean Ray- Vol- Water Water Fmm Ave
早期ウェイクアップ手法によって、性能オーバヘッドを大幅に緩和
trace rend NS
SP
Radix
Lu
Fft
評価環境: リーク電力 (On/Offエネルギー込)
• On/Off エネルギーのモデリング
1. 各ドメインの On/Off エネルギー (SPICE シミュレーション)
2. ウェイクアップ信号の配線エネルギー (リピータ付き3mm配線)
 GEMS/Simics には、上記 1. と 2. をパラメータとして与える
• 細粒度パワーゲーティングを3段階で適用 (Level 1～3)
Level-1 power gating
ARB
入力バッファのみ
Level-2 power gating
ARB
入力バッファ+クロスバ
Level-3 power gating
ARB
入出力バッファ+クロスバ
評価結果: リーク電力 (On/Offエネルギー込)
Level 1 PG: 入力バッファのみ
Look-ahead +
CPU ever-on
Look-ahead
リーク電力 (オーバヘッド込、正規化)
(3-cycleウェイクアップ@1GHz)
On/Offエネルギー
Look-ahead +
Buffer window
パワーゲーティングしないときのリーク電力
Level 1 PG によって、リーク電力を 51.8% 削減
Radix
Lu
Fft
Barnes Ocean Raytrace
Vol- Water Water Fmm
rend NS
SP
Ave
評価結果: リーク電力 (On/Offエネルギー込)
Level 2 PG: 入力バッファ、クロスバ (3-cycleウェイクアップ@1GHz)
Look-ahead +
CPU ever-on
リーク電力 (オーバヘッド込、正規化)
Look-ahead
On/Offエネルギー
Look-ahead +
Buffer window
パワーゲーティングしないときのリーク電力
Level 2 PG によって、リーク電力を 55.8% 削減
Radix
Lu
Fft
Barnes Ocean Raytrace
Vol- Water Water Fmm
rend NS
SP
Ave
評価結果: リーク電力 (On/Offエネルギー込)
Level 3 PG: 入力バッファ、クロスバ、出力ラッチ
Look-ahead +
CPU ever-on
リーク電力 (オーバヘッド込、正規化)
Look-ahead
On/Offエネルギー
Look-ahead +
Buffer window
パワーゲーティングしないときのリーク電力
Level 3 PG によって、リーク電力を 59.3% 削減
Radix
Lu
Fft
Barnes Ocean Raytrace
Vol- Water Water Fmm
rend NS
SP
Ave
まとめ: CMP向け細粒度 PG ルータの評価
• パワードメインの実装 @ Fujitsu 65nm
– 入力バッファ、 出力ラッチ
– クロスバMUX、仮想チャネルMUX
35個のパワードメイン
(ルータ1個あたり)
• パワードメインのオーバヘッド (SPICE シミュレーション)
– 面積オーバヘッド: 4.3～15.9% 増
– ウェイクアップ遅延: 3nsec 以下
– On/Off エネルギー: 60～99nsec のスリープで償却可能
• CMP を想定した評価 (フルシステム・シミュレーション)
– アプリの性能オーバヘッド: 35.3% (早期ウェイクアップ無し)
– アプリの性能オーバヘッド: 4.0% (早期ウェイクアップ有り)
– リーク電力の削減量は 59.3% (On/Off エネルギー込み)
今後の課題: さらなるオーバヘッド削減
• Return wakeup: 性能オーバヘッドのさらなる削減
– リプライ (L2  CPU) の1ホップ目遅延を隠ぺい
– 宛先(L2)到着時に、リプライで使われるポートをウェイクアップ
CPU
L2キャッシュ
Ever-on
Return
wakeup
• パワードメイン統廃合: 面積オーバヘッドのさらなる削減
– クロスバMUXと出力ラッチを統合
ARBITER
X+
X+
X-
X-
ご清聴ありがとうございました
オンチップルータ: 消費電力の解析
• 消費電力の分類
– スイッチング電力: 回路がスイッチングする際に消費
– リーク電力:
電源が入っている限りちょっとずつ消費
• Fujitsu 65nmで配置配線し、500MHzでシミュレーション
スタンバイ時の消費電力の 35.7% がリーク電力 (動作時75℃のとき)
評価結果: アプリケーション性能
SPLASH-2 ベンチの実行時間 (2-cycle ウェイクアップ@ 667MHz)
Look-ahead +
CPU ever-on
Look-ahead
Look-ahead +
Buffer window
アプリの実行時間 (正規化)
(1.00 = パワーゲーティングしないときの実行時間)
早期ウェイクアップ手法がないときの実行時間 (+23.2%)
CPU ever-on のときの性能オーバヘッドは +3.2%
Radix
Lu
Fft
Barnes Ocean Raytrace
Vol- Water Water Fmm
rend NS
SP
Ave
評価結果: アプリケーション性能
SPLASH-2 ベンチの実行時間 (4-cycle ウェイクアップ@ 1333MHz)
Look-ahead +
CPU ever-on
Look-ahead
Look-ahead +
Buffer window
アプリの実行時間 (正規化)
(1.00 = パワーゲーティングしないときの実行時間)
早期ウェイクアップ手法がないときの実行時間 (+46.3%)
CPU ever-on のときの性能オーバヘッドは +6.7%
Radix
Lu
Fft
Barnes Ocean Raytrace
Vol- Water Water Fmm
rend NS
SP
Ave