第892回
Hot Chipsで明かされた「Wildcat Lake」の全貌 Foverosを捨てMCPを選んだインテルの舞台裏
2026年09月07日 12時00分更新
Hot Chips解説の第2弾はインテルのWildcat Lakeである。Wildcat Lakeは今年4月に正式に発表され、8月に入ってからは搭載マシンのレビュー(その1、その2)も掲載されるなど、本格的に流通が進んでいるプロセッサーである。
製品の位置付けもジサトライッペイ氏の記事にあるように、Core Ultra Series 3の下(だが、Intel Processorよりは上)であり、メインストリームの廉価モデル~バリューの高価格モデルあたりを狙ったと考えるのが妥当だろう。
Foverosを捨てMCPを採用したパッケージ構成とプロセスの選定
さて、そんなCore Series 3の特徴がこちら。絶対性能重視ではなく、性能を確保しつつ消費電力を下げることに振った感がある。もっとも絶対性能そのものが下がっていることは否めず、例えばAI性能が2.7倍の40TOPSはCPU/GPU/NPU全部を足しての数字なので、どこまで意味があるのか? と言われるとやや疑問ではある。
Core Series 3の特徴。ちなみに比較対象はRaptor Lake U RefreshベースのCore 7 150Uだそうだ
興味深いのがパッケージ構成。Panther LakeではFoverosを利用してベースダイの上に複数のタイルが搭載される形を取っていた。Meteor Lake以降のプロセッサーで採用されている構成だ。ただこれは当然高コストになる。そもそもベースダイが必要だし、Foveros構成の歩留まりも100%ではないからだ。
そこでモノリシック(全部を1ダイ)にするか、以前のインテルのモバイル向けのように、CPUダイとI/OダイをMCP(Multi-Chip Package)の形で実装するかの二択になる。そして今回はMCPを利用することにしたという話だ。
質疑応答でなぜモノリシックにしなかったのか? に対する回答で「正確な数値は明かせないが、MCPにすることでD2D PHYの面積増加があっても、コスト面では有利な結果となった。モノリシックな設計も検討した。この場合D2D PHYは不要になるが、ダイ面積が大きくなり、これは歩留まり低下につながる。またプロセススケーリングに不向きなI/Oバッファをより高コストなプロセスノードに移行させることになる。要するにさまざまな要因が絡んでおり、このプロジェクトにおいては(MCPにすることが)正しい判断だった」という返答であった。
次がプロセスの選択である。Wildcat Lakeの製造にあたってはIntel 3とIntel 18A、それとTSMC N6の3つが選択肢に入っていたとする。より高速な、例えばTSMC N5/N4/N3/N2などは価格および生産量の観点から不適当と判断したのだろう。
それはともかく、CPU&GPUタイルはIntel 18Aでほぼ決まりとなった。これはPコアはPanther Lakeと同じCougar Coveで構築されており、これはIntel 18Aでの実装だったから、これを再利用しようとするとIntel 3やTSMC N6は不適当だ。
一方でPlatform Controller Tile、つまり従来SCHなどの名称で提供されてきた部分は、Intel 3やIntel 18Aでは不適当(無駄にダイサイズが大型化して高コスト)であり、TSMC N6に任せるのが無難という判断である。
したがって、全体的には低コスト向けに手堅く構成されたのがWildcat Lakeだが、唯一冒険をしたのがUCIeである。
上の画像でUCIeへの対応が項目に入っていたが、Wildcat LakeではCPU&GPU TileとPlatform Controller Tileの間をUCIeで接続することになった。昔、つまりMeteor Lakeの前はDMIベースとなるOPIO(On Package IO)が使われていたが、このあたりは一度Foverosベースになったことで方式が変わったと聞いている。
今回それをFoverosなしで利用するにあたり、I/FとしてUCIe Standardを利用するように変更された。ただUCIeを製品に採用するのはインテルとしても初めてということで、いろいろ気を使ったらしい。
UCIeの信号転送速度は8Gbpsに抑えられている。UCIe Standardの場合、帯域はx8ないしx16で信号転送速度は4/8/12/16/24/32Gbpsが選べるが、あえて8Gbpsに抑えている。
この理由について質疑応答では「データ転送速度を速くして、UCIeの幅を狭くすることは検討したが、8GT/sを超えると、許容範囲を超えてビット誤り率が増加してしまう。これはリトライやFECなどの技術で対処可能だが、これにより複雑さや面積の増大、およびスケジュール上のリスクが増大する。今回はUCIeの初採用であったため、非標準のx8リンクなどと比べて多少面積が増加するとしても、安全策を講じた」と説明されている。
週刊アスキーの最新情報を購読しよう
本記事はアフィリエイトプログラムによる収益を得ている場合があります




