今年のHot Chipsは、最終日の午後の一番最後、というところに"Mobile & Edge Processors"セッションを持ってきた。その中でも前評判が高かったIntelの"Meteor Lake and Arrow Lake : Intel Next Gen 3D Client Architecture Platform with Foveros"であるが、先に書いておけばMeteor LakeあるいはArrow Lakeの話は殆ど無い。では何の話かというと、そのMeteor LakeやArrow Lakeに使われるFoverosの話である。

実をいうと、Hot Chipsに先立って開催されたHot Interconnectsの今年のテーマは"Disaggregation Leading to Reaggregation"(解体と再構築)だったのだが、まるでこれに沿ったかのような説明がこちら(Photo01)。昨今では、ムーアの法則で提供される以上のトランジスタを必要とするアプリケーションが多く、一方で800平方mmというReticle Limitは依然として存在するので、これを超えるMonolithicなダイは物理的に製造出来ない。必然的にChiplet構造にならざるを得ない。ただIntelは以前からこれについて言及していつつ、実装はAMDに後れを取っている、というのが現実ではあるのだが、Sapphire Rapids/Ponte Vecchioに続き、コンシューマ向けにもMeteor Lakeとこの後継のArrow LakeでChiplet構成を取る事にした。

  • Intel Meteor Lake and Arrow Lake - HotChips 34レポート

    Photo01: ペナルティはLatencyやBandwidth、それとLinkに要する消費電力であるが、そうしたペナルティを払ってもまだChiplet構成の方が効果的と言うのは、皮肉にもZen 3以降で明確に証明されたと言える。

さて、Chipletを取るとしてどうやってそれを実現するか、に関してIntelは既にEMIBやFoverosを実用化しており、今後はFoveros OmniやFoveros Directが用意されている(Photo02)という話は2021年7月のIntel Acceleratedで公開されており、更に詳細が昨年のHot Chipsでも紹介されたが、今回はもう少しこれが細かく説明された。まずFoverosだが、Cu Pillarの先にNi層が設けられ、このNi層で上下のダイを接続する方式である(Photo03)。これに続くFoveros Omniであるが、Base Dieの方が小さい事を前提に、Top Dieからの外部信号はそのままCu Pillar経由で底面に通し、中央部はFoverosと同様にDie-to-Die接続するという構成である。ただBump Pitchそのものは第2世代Foverosと同じ25μmなので、Densityそのものは変わらないし、消費電力も当然ほぼ同等ということになる。Die-to-Dieの接続は恐らくFoverosと同じ構成だろう。ではFoveros Directは？ というと、Cu Pillarのピッチが恐らく9μmまで狭められている構成という事の様だ(Photo05)。16倍の密度というのは、要するに間隔を1/4にしたから密度で言えば16倍になるという事で、36μmのFoverosの16倍ということは、9μm間隔ということになる。ここから見ると、Pillarそのものの幅は3μmを切る程度と想像される。

  • Photo02: Foveros Omni/DirectのBump Pitchはこれまでも説明されていたが、通信に要する消費電力は今回初公開だったと思う。

  • Photo03: これはまぁそう珍しい構造ではない。

  • Photo04: Foverosの世代では、Base Dieの側にTSVを設けて底面に信号を逃がす必要があったから、むしろ低価格になるかもしれない。もっともCu Pillar(写真ではCu columnsになっている部分)を作る必要があるから、大幅に低価格化は難しい気もするが。

  • Photo05: Foveros Omniと写真の倍率が恐らく異なっており、高さそのものは相当小さいものと考えられる。

  • Photo06: Lunar LakeはFoveros Omniを利用する模様。

ただこのFoveros Omni/Directは、残念ながらMeteor Lake/Arrow Lakeには採用されない。と言うのは、こちら(Photo06)に示すように、Meteor Lake/Arrow Lakeはどちらも36μm pitchのFoverosと明記されているためだ。そのMeteor Lakeの構成がこちら。CPU/GPU/SoC/IOの4つのTileが、Base Tileの上に載る格好になる(Photo07)。ただこのBase Tileはロジックは一切載っておらず、Chiplet同士の接続と、外部信号のためのTSV、それとパスコンを積層したものになる(Photo08)。そのBase Tileの詳細がこちら(Photo09)。上層にDie-to-Dieの再配線層、下層にパッケージ外への再配線層が入り、その中間は外部への信号を貫通する部分以外は全てコンデンサとして利用されている。GraphcoreのBOW IPUと同じアイディアである。一方でこの上に載るTop Tileに関してはスケーラビリティやフレキシビリティに富んでいる(Photo10～13)というのがIntelの説明であるが、TileのサイズとかBall(というかPillar)の配置の互換性をきちんと保つように設計しないといけない訳で、言うほどスケーラビリティがあるか？ というと疑問ではある。ただFoverosのパッケージは10W未満から100W以上までサポートするとあるので、電源供給に問題が出る可能性は少なそうだが。

  • Photo07: この構造そのものは以前から公開されていた。

  • Photo08: Die-to-Dieは36μm Pitchなので、Foverosで確定である。

  • Photo09: 別にコンデンサではなく、将来はここに回路を入れる事も可能と言うか、本来はActive LogicのダイをFace-to-Faceで接続するのがFoverosの目的だった筈で、ただMeteor LakeではBase TileをSilicon Interposer的に使っている形だ。

  • Photo10: Core CountとかCacheはともかく、Core GenerationとかNodeに関してはちょっと無理がある気が。あと、Tileのサイズが変わるとBase Tileをそのまま使えるかちょっと疑問ではある。

  • Photo11: GPUも基本は同じ。

  • Photo12: SoCに関しては、そもそもこれまでもPCHと言う形で別チップにした上で、Mobile向けではMCMで搭載しており、その意味では本質的に大差ない気がする。また仮にMeteor LakeがDesktopに投入されたとすると、その際にChipsetは統合されるのか？ というとそれも難しい様に思える。

  • Photo13: I/O Extender Tileは何か？ と言うと、PCIeとかUSB4/Thunderboltなどを統合するTileの模様。

さてそのTop Tile同士の接続であるが、FDI(Foveros Die Interconnect)を利用する事になっている(Photo14)。転送速度は2GHzで0.15～0.3pJ/bitだから、そう悪い数字ではない。Meteor Lakeではこれが3か所に使われている(Photo15)が、ここで物議を醸しだしたのがSoCとGraphicsを繋ぐiCXLである。IDI(In-Die Interface)はSilvermont世代から使われているCPU接続用のプロトコル、IOSF(Intel On-die Switch Fabric)はチップセット内部の接続に使われるプロトコル(確かCloverTrail世代ではもう使われていた)だとして、問題なのがGraphics接続用のiCXLである。これは要するにCXLをFDIの上で動く様にしたものだそうだ。CXLはある意味PCIeに依存するプロトコルではあるが、PCIe 6.0ベースのCXL 3.0はともかく、PCIe 5.0ベースのCXL 1.1/2.0であれば移植は比較的楽だったのだろう。

  • Photo14: ちなみにZen 3のInfinity Fabricを利用した接続は、確か2pJ/bit程である。Silicon Interposerを使わずにこの数字も優秀だとは思うが、やはりDie-to-Dieに最適化している＆距離が短いからこその数字であろう。

  • Photo15: SoC TileがいわばHubであり、他のTileは全てSoC Tileにぶら下がる格好になっている。

ちなみに10年前のHaswellとMeteorLakeを比較したのがこちら(Photo16)。性能はほぼ据え置きだが、消費電力が大幅に削減され、かつI/Oの帯域が増えているのが判る。これが10年の進化という訳だ。

  • Photo16: 実際のところ、信号速度はともかくバス幅が大幅に増えている(Photo15を見る限りCPU-SoCは2K本)ので、かなりの帯域増になる。もっとも2K本といっても、Differentialでしかも双方向だから、片方向当たり512bit幅になる計算だが。

ところで発売前の製品ということで性能を示唆するようなスライドは一切無いのだが、消費電力周りで少し面白い話があった。まずはTurbo Power Capability(Photo17)。要するにPL2をどこまで引き上げられるかという話で、Alder Lakeと比べて当初は半分強でしかなかったが、最適化を図ったことで最終的に1割増し程度まで引き上げ出来たそうだ。もっともこれ、Desktop向けのSKUではなくMobile向けのSKUの話な気はする。Core i9-12950HXの場合、PL1が55W、PL2が157Wだが、Meteor LakeではPL2を170W辺りまで引き上げられる目途が立った、ということらしい。この電力増への対応を支えるのは、先にPhoto09で紹介したBase Tile内のコンデンサの数で、最終的には500個に達したとする(Photo18)。消費電力が増えるという事はそれだけ電力変動が激しくなるという事で、より多数のパスコンが必要になる。勿論パスコンだけ配せば良いという単純な話では無いが、パスコンが無いと話にならない。

  • Photo17: ただMeteor LakeのPrevious Generationだと定義的には今年中に投入されるRaptor Lakeになる筈なのだが、多分Alder Lakeの事だろう。

  • Photo18: Alder LakeはIntel 7世代だから凡そ193個。Meteor Lakeでは2.5倍に増やされた訳だ。

ちなみに性能という観点で言うと、Monolithicと比較してFoverosを利用した場合、何もしないと2～3%の低下が見られるが、こちらも最適化を進めたことである程度改善出来たとしている(Photo19)。このうちのいくらかはトランジスタそのものによる話であり(Photo20)、あとはIP Refreshに起因するものとする(Photo21)。

  • Photo19: まぁこれは動作周波数を上げられるように努力した、という話でもある。

  • Photo20: Intel 4のトランジスタの話はこちらの記事で説明している。

  • Photo21: Meteor LakeではP-CoreがRedwood Coveになる予定で、これによる性能向上分も含んでいるという話である。

今回は製品に関わる話は殆ど無かったが、これ(Photo22)で講演を〆られても正直言って困る。Labでは動作している事は判ったが、量産に行けるのか？ という話の答えになっていないのは、何しろ直近でIntel 7を利用して堅実に量産に移れると思われていたSapphire Rapidsが遅延しまくっているからだ。これを考慮すると「Labで動いているから量産に問題は無い」と素直に受け取るのはちょっと困難である。そもそもLabで動いているという話はVLSI Symposiumの発表でも明らかにされており、Updateが一切無いあたりが不安材料である。

  • Photo22: このスライドも、ダイが本当にMeteor Lakeなのかは謎。ただAlder Lakeとは微妙にE-Coreの周りが異なっているので、Alder Lakeの6+8から切り出して持ってきた訳でもなさそうだが。