■後藤弘茂のWeekly海外ニュース■ IBMとの共同開発で変わるAMDのCPU

●並列性かクロックかで分かれる方向性

　AMDの次世代CPUアーキテクチャ「K10」では、ラディカルなアーキテクチャが提案されたが、それは採用されなかった。前回のコラムで説明したように、アーキテクトの一人だったAndy Glew氏が提案したのは、マルチスレッド&マルチクラスタの構成で、マイクロアーキテクチャの全レベルでマルチレベル化、さらに投機マルチスレッディングなど先進的なマルチスレッディング技術を織り込むといった、非常に尖ったアーキテクチャだ。それらの採用を避けたということは、AMDは、K10ではコアの複雑化をある程度軽減しようとした可能性が高い。

　CPUコアのシングルスレッドパフォーマンスは、ラフに言えば「周波数×アーキテクチャ」に比例する。アーキテクチャには「IPC(instruction per cycle:1サイクルで実行できる命令数)」や「DLP(Data-Level Parallelism:データレベルの並列性)」の向上などが含まれる。クロック周波数を上げて、より速く命令を実行できるようにするのが1つの解決策。より高度なアーキテクチャにして、1サイクルにより多くの命令またはデータを処理できるようにするのがもう1つの解決策だ。CPUアーキテクチャの開発では、比重を動作周波数の向上に置くか、アーキテクチャの効率性の向上に置くか、あるいはその中間でバランスを取るかの選択肢がある。Pentium 4(NetBurst)のように周波数向上に偏るアーキテクチャもありうる。

　K10が、ラディカルなアーキテクチャ拡張を採らないとすれば、周波数向上の方がどうなのかがポイントになる。パフォーマンスは周波数×アーキテクチャなので、アーキテクチャ上の並列性の拡張をある程度に抑えるなら、周波数を上げる可能性が出てくる。

●IBMとのプロセス共同開発がAMDのアーキテクチャに影響を与える

　Intelが動作周波数を抑え、並列性を上げる方向に向かった最大の理由は、消費電力だ。プロセスの微細化とともに、消費電力のスケールダウンの比率が低くなり、微細化しても消費電力がマッチするほど下がらなくなってしまったからだ。

　この問題は、根本的な部分ではAMDも他のCPUベンダーも同様だ。そのために、CPUが高周波数設計を取れるかどうかのカギは、プロセス技術にある。より低消費電力のプロセス技術を確立できた方が、CPUの周波数を上げやすくなる。回路設計技術や省電力アーキテクチャも重要だが、プロセス技術自体の改良が進む必要がある。

　AMDは現在、この問題については、過去数年間よりも有利な位置にある。それは、IBMとプロセス技術(65/45nmでスタート)の開発で同盟を結んでいるからだ。もし、K10が2008年かそれ以降にずれ込んだとすれば、プロセス技術は45nm世代となる。45nm世代は、IBMとプロセスを最初から開発したテクノロジだ。このアライアンスでは、両社でプロセス技術のコモンベースラインを共同開発(実際にはソニー/SCEI、東芝もIBMと同様のアライアンスを結んでいるため4社のベーステクノロジとなるという)。コモンベースプロセスを、各社のFab(工場)に、それぞれユニークな方法で移植するという。

　アライアンスでは、膨大なプロセス開発費を抑え、導入を迅速化し、場合によってはIBMに製造を委託したり、IBMのチップを製造するといったアロケーションも可能にするといった利点がある。しかし、それ以上に、プロセス技術では明確なリーダーの1社であるIBMの技術がもたらされることはAMDにとって利がある。元IBMの半導体関係者は、IBMはSOI(silicon-on-insulater)などに関するさまざまな特許を押さえているため、非常に有利だと語っていた。

　つまり、IBMとのアライアンスによる技術流入でCPUの消費電力を抑えるメドが立てば、AMDはより高周波数設計のCPUコアにすることができるわけだ。ちなみに、アライアンス相手のIBMの新CPU「Power6」は、ステージディレイが13 FO4(Fanout-Of-4)でオーバー5GHzの高周波数設計を取る。同じIBM系のCellやXbox 360 CPU(どちらも11 FO4)も同様に高周波数設計となっている。

●メモリインターフェイスはCPUダイから分離か

　CPUコアパフォーマンスを引き上げ、ワンチップに入れ込むCPUコア数も増やしてゆくと、当然、それに見合うだけのデータ帯域が必要になる。2005年11月のAnalyst Dayで示された2008年とその先のイノベーションプライオリティリストのシステムサイドのチャート(下のスライド)には、明瞭にそのための方向性が示されている。

AMDs Silicon-Level(System) Innovation Priorities through 2008 (別ウインドウで開きます) PDF版はこちら

　チップ間インターコネクトでは、HyperTransport 3.0へ移行し、さらにその先のHyperTransport 4.0の開発も見込む。メモリインターフェイスは、今年のK8「Revision F」でのDDR2サポートに続いて、DDR3/4、FB-DIMM、FB-DIMM2までの開発を視野に入れる。

　DDR3については、AMDは明確に推進しており、コントローラ側はDDR2とDDR3の両対応の設計が可能であるため、そのまますんなり移行するものと見られる。しかし、DDRインターフェイスと互換性のないFB-DIMMや、まだ仕様が決まっていないDDR4、FB-DIMM2をどうするのかは不鮮明だ。例えば、DDR3とFB-DIMM互換のインターフェイスは、ほぼ不可能であるため、インターフェイスモジュールを変える必要が出てくる。

　ここで興味深いのは、メモリインターフェイスがCPUシリコン側ではなくシステムシリコン側に記載されていることだ。AMDは、メモリインターフェイスを再びCPUのダイ(半導体本体)から分離することも、考慮しているようだ。あるAMD関係者は「(CPU側に)オンダイにするかもしれないし、まだわからない」というが、少なくとも分離の可能性を否定はしない。また、今後のメモリ動向を考えると分離しても不思議ではない。ただし、AMDは、今後もダイレクトコネクトアーキテクチャを継続発展させると言っているため、少なくともCPU同士を直接接続する構成は変えるつもりがなさそうだ。

　CPUへのメモリインターフェイス統合は、FSB(Front Side Bus)を介さないことでメモリ帯域をフルに活かし、メモリアクセスレイテンシを減らすという利点がある。しかし、統合の難しさも多い。

　まず、CPUの開発サイクルの方がチップセットより数倍も長いため、インターフェイスの迅速な変更が難しい。プラットフォーム毎に異なるメモリ規格やモジュール規格に対応することも難しい。また、高速メモリはタイミングマージンなどが少ないため、ソケットに挿すCPUは、オンボードに直づけするノースブリッジチップより不利になる。FB-DIMMのように、シリアル系インターフェイスの場合は、必要なダイエリアも大きく消費電力も多いため、ただでさえクリティカルなCPUの消費電力をさらに押し上げてしまう。さらに、政治的な妨害作業にも弱い。

　最後の政治的な問題については、AMDが、2005年6月に米デラウェア連邦地方裁判所に提出したIntelに対する反トラスト法(Sherman Act)違反の訴状の中で訴えている。AMDによると、DDR3メモリモジュール規格の標準化において、IntelがAMDに対して不利になる働きかけをしたという。IntelはDDR3デスクトップ用モジュールについてはDDR2と互換性の高いピン定義を提案したが、ノートPC用モジュールのピン定義では一転してDDR2と異なる仕様を提案したという。もし、Intelの提案通りになっていた場合は、ノートPC向けのCPUについてはDRAMコントローラの設計を変更しなければならず、そうやってAMDを妨害することがIntelの提案の動機だったとAMDは訴えている。

　Intelが、政治的な意図でこの提案したかどうかはわからない。しかし、CPU統合インターフェイスは、こうした変更に柔軟に対応しにくく、もし政治的に不利にしようと思えば、容易にできることは確かだ。メーカーとしてはCPUのダイの種類はできるだけ絞りたい。モジュール毎に対応するCPUまたはパッケージを作り分ける必要があるなら、柔軟性が失われてしまうわけだ。

　こうして見ると、PC&サーバーという市場の経済性や変化の速い技術動向、そして標準化における企業政治を考えると、分離した方が有利という考え方もありうる。もちろん、レイテンシが重要なPC向けは統合し、スループット重視のサーバーは分離するといった選択もありうる。

●サードパーティのコプロセッサも視野に

　もう1つ、このスライドで面白いのは、サードパーティシリコンのところに「オフチップコプロセッサ(Off-chip coprocessors)」と記載されていることだ。CPUの外に、他社製のコプロセッサがあるという構成も考慮していることになる。しかし、現状で、どこかのベンダーがAMD向けにコプロセッサだけを開発するといったことは考えにくい。また、開発したとしても、普及させるのはもっと難しい。

　ここで浮かぶのはGPUだ。CPU以外で、最大のコンピュテーションパワーを持つプロセッサだからだ。GPUのプログラマブル演算ユニットであるProgrammable Shaderは、DirectX 10世代になれば汎用に使えるだけの柔軟性を持つ。AMDが、GPUやグラフィックス統合チップセットのShaderをCPUのコプロセッサとして連携させるというアイデアを持ち出してきてもおかしくはない。すでにPCに載っているプロセッサをCPUと連携させるとなれば、より話は簡単になる。

　ここで意味深なのは、AMDが、Coherent HyperTransport技術を選択的にライセンスするとしていることだ。プロセッサ間をつなぐCoherent HyperTransportを、例えばGPUベンダーにライセンスして、両プロセッサがプロセッシングで連携できるようにするという可能性もある。HyperTransportを備えたグラフィックス統合チップセットのShaderが、そのまま、CPUと連携して動作もできるといったアーキテクチャだ。GPUを仮想化するなどして、Shaderのある程度のポーションをコプロセッサとして使えるといった方向が考えられる。

　ちなみに、AMDで、K8プログラム全体を担当していたRich(Richard) Heye(リッチ・ハイ)氏(当時Vice President, Platform Engineering & Infrastructure, Computation Products Group, AMD)は、現在、GPUベンダーATI Technologiesでデスクトップビジネスを統括している(Vice President & General Manager, Desktop Business Unit, ATI Technologies)。Heye氏は、ATIに移った理由は、GPUがプログラマブル化しており、さまざまな可能性を秘めているからだと昨年6月のCOMPUTEX時に語っていた。人的な繋がりはある。

●オンチップとオフチップのコプロセッサの関係

　このオフチップコプロセッサでは、以前レポートしたAMDのオンチップコプロセッサとどう関係するのかもクエスチョンになる。AMDは、CPUに特定コードの実行をアクセラレートするコプロセッサを載せた、ヘテロジニアスマルチコア構成も検討している。つまり、PLAYSTATION 3の「Cell」のように、演算処理中心のサブプロセッサコアを混載した構成になる可能性があるわけだ。

　そして、AMDがコプロセッサに言及したのと同じプレゼンテーションで、オフチップコプロセッサが出てきたことは、両コプロセッサで、何らかの連携を考えている可能性がある。推測できる中で一番美しい形は、アクセラレートしたいコードについては、オンチップとオフチップのどちらのコプロセッサでも実行できるようにすることだ。例えば、CPUにコプロセッサが載っていた場合にはそのコアで、CPUに載っていない場合にはオフチップ側で実行するといった具合だ。

　ただ、こうしたシームレス化をもしAMDが構想したとしても、かなりハードルが高い。GPUのShaderは、各社が独自のアーキテクチャで開発することで、最適な性能を引き出してきたからだ。各社のGPUは、各世代毎に、独自の命令セット、独自のマイクロアーキテクチャ、独自のランタイムを持つ。GPUは、グラフィックス処理についてはAPIとドライバによって抽象化されているため、こうしたことが可能だ。GPUベンダーのフィロソフィは、世代毎にアーキテクチャを大胆に変えることで、革新するというものだ。そのため、AMDがコプロセッサの提案をしたとしても、アーキテクチャのすり合わせはかなり大変な作業になる。かといって、抽象化するソフトウェア層を作ろうとすると、パフォーマンスの最適化や標準化が難しい。

　いずれにせよ、このあたりのビジョンはまだ見えていない。明瞭なことは、AMDのアーキテクト達が、かなりラディカルなアイデアを次々と出しているということだ。こうした姿勢からは、AMDが、Intel標準に乗るという段階を経て、積極的にアーキテクチャ面の拡張を行なおうとしていることがわかる。AMD64などの成功で、それだけアーキテクチャ拡張への自信をつけてきたと考えられる。

□関連記事
【2月2日】【海外】謎が多いK10アーキテクチャの方向性
http://pc.watch.impress.co.jp/docs/2006/0202/kaigai238.htm
【1月30日】【海外】ヘテロジニアスマルチコアも視野に入れたAMD
http://pc.watch.impress.co.jp/docs/2006/0130/kaigai237.htm
【1月23日】【海外】市場ごとに仕様を変えるAMDのCPU戦略
http://pc.watch.impress.co.jp/docs/2006/0123/kaigai234.htm
【1月19日】【海外】K8以降大きく変わったAMDのCPU開発サイクル
http://pc.watch.impress.co.jp/docs/2006/0119/kaigai233.htm

□バックナンバー

(2006年2月6日)

[Reported by 後藤 弘茂(Hiroshige Goto)]