Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads

[Tigerick]

As Hot Chips 34 starting this week, Intel will unveil technical information of upcoming Meteor Lake (MTL) and Arrow Lake (ARL), new generation platform after Raptor Lake. Both MTL and ARL represent new direction which Intel will move to multiple chiplets and combine as one SoC platform.

MTL also represents new compute tile that based on Intel 4 process which is based on EUV lithography, a first from Intel. Intel expects to ship MTL mobile SoC in 2023.

ARL will come after MTL so Intel should be shipping it in 2024, that is what Intel roadmap is telling us. ARL compute tile will be manufactured by Intel 20A process, a first from Intel to use GAA transistors called RibbonFET.



Comparison of upcoming Intel's U-series CPU: Core Ultra 100U, Lunar Lake and Panther Lake

Model	Code-Name	Date	TDP	Node	Tiles	Main Tile	CPU	LP E-Core	LLC	GPU	Xe-cores
Core Ultra 100U	Meteor Lake	Q4 2023	15 - 57 W	Intel 4 + N5 + N6	4	tCPU	2P + 8E	2	12 MB	Intel Graphics	4
?	Lunar Lake	Q4 2024	17 - 30 W	N3B + N6	2	CPU + GPU & IMC	4P + 4E	0	8 MB	Arc	8
?	Panther Lake	Q1 2026 ?	?	Intel 18A + N3E	3	CPU + MC	4P + 8E	4	?	Arc	12

Comparison of die size of Each Tile of Meteor Lake, Arrow Lake, Lunar Lake and Panther Lake

	Meteor Lake	Arrow Lake (20A)	Arrow Lake (N3B)	Arrow Lake Refresh (N3B)	Lunar Lake	Panther Lake
Platform	Mobile H/U Only	Desktop Only	Desktop & Mobile H&HX	Desktop Only	Mobile U Only	Mobile H
Process Node	Intel 4	Intel 20A	TSMC N3B	TSMC N3B	TSMC N3B	Intel 18A
Date	Q4 2023	Q1 2025 ?	Desktop-Q4-2024 H&HX-Q1-2025	Q4 2025 ?	Q4 2024	Q1 2026 ?
Full Die	6P + 8P	6P + 8E ?	8P + 16E	8P + 32E	4P + 4E	4P + 8E
LLC	24 MB	24 MB ?	36 MB ?	?	8 MB	?
tCPU	66.48
tGPU	44.45
SoC	96.77
IOE	44.45
Total	252.15

Intel Core Ultra 100 - Meteor Lake



As mentioned by Tomshardware, TSMC will manufacture the I/O, SoC, and GPU tiles. That means Intel will manufacture only the CPU and Foveros tiles. (Notably, Intel calls the I/O tile an 'I/O Expander,' hence the IOE moniker.)

 

[Exist50]

Really they ought to have focused on fixing their ring’s idle power issues as opposed to adding this layer of complexity. How are AMD getting away with 8 big (smaller than Intel’s big by a smidgen but still) cores and reaping low static power draw too with Rembrandt? Firmware changes for one thing, but what engineering compromise makes Alder Lake’s idle and sub-10-15W power consumption so awful, even relative to their own previous 10/7NM products?

Pushing frequencies and Gracemont’s prioritizing of area efficiency over energy efficiency doesn’t help, but that’s not what I’m getting toward here and we know that. Something is rotten with their uncore/fabric.

Intel has a significant uncore problem, I'll agree, but I think that's an oversimplification for Alder Lake in particular. After all, it's not like the uncore regressed from Tiger Lake, and yet battery life did. I think the two biggest hardware problems were switching the mainstream from a 4c to an 8c equivalent config (U->H, sort of), and the area/leakage growth of Golden Cove. Though really, it's Sunny Cove that deserves most of the shaming there.

With the introduction of Infinity Fabric (especially scalable control fabric) AMD introduced the ability to monitor and control ever more distinct areas within the chips. They make use of this for further development by extending the granularity of power gating as well as optimizing for power efficiency all interconnections within the chips.

The mainband fabric has very little to do with power management on an IP level, and in a design like MTL where the ring only connects to a subset of the CPU cores, not much from an SoC-perspective either.

Meanwhile Intel appears to be still using the same static over a decade old ring bus design as well as the same mesh fabric (which actually decreased power efficiency further, so is not a replacement in that regard) since over half a decade. I think/hope we are just seeing outdated designs so far and Intel actually has some progressive design coming, but the wait is quite long already.

I think this argument is particularly weird in the context of MTL, which is the biggest change to Intel's uncore since at minimum Sandy Bridge, and arguably ever. And it's extra weird when you consider that AMD has adopted a ring bus for their 8c CCX. A ring bus isn't inherently bad, but there's an ocean of implementation details that get hidden under that classification.

 

[Exist50]

BTW, I seriously doubt viability of Meteor Lake in the marketplace. A mini Ponte Vecchio is market that values low cost, low power and small size (cost competitive Ultra Portable segment).

Meteor Lake may hold its own in larger, higher performance desktop replacement segment.

AMD already has a good product in this market, Rembrandt. With annual cadence, there will be N4 Phoenix already established in the market before Meteor Lake launches, and another iteration (Strix?) shortly after.

AMD is opportunistic and practical in what advanced packaging is deployed where. As opposed to Intel, which, it seems, issued orders to force march its army to chiplets.

Ponte Vecchio is already the first victim and Meteor Lake may be another...

MTL has essentially nothing in common with Ponte Vecchio. Foveros is a negligible concern for both at this point. Alchemist should show you that manufacturing has nothing to do with its issues (minus the delays from the Intel to TSMC switch).

And I'm not sure why you think Foveros will make MTL large or expensive either. A passive base die isn't particularly expensive for mainstream and up.

 

[Exist50]

Crestmont is possible. I will be more optimistic if it is the case. Idling for streaming video won’t be so much of a big deal, but interactive tasks they’d want to be careful short of compromising UX, and Crestmont would be fine for that. Indeed, the migration policy and heuristics for QoS is where Microsoft also comes into play. I wonder what the timescales are for powering the compute tile on/off with Foveros and migrating a thread. Suppose it depends how this is implemented.

So, I'm pretty skeptical about the implementation of these "LP cores" in MTL. I think putting them on a separate, older node creates all sorts of design tradeoffs that probably aren't worth the effort to address. But the idea of having a couple of power-optimized Atom cores independent of the ring is really interesting, and I hope we see the concept refined better in the future.

 

[jpiniero]

So, I'm pretty skeptical about the implementation of these "LP cores" in MTL. I think putting them on a separate, older node creates all sorts of design tradeoffs that probably aren't worth the effort to address. But the idea of having a couple of power-optimized Atom cores independent of the ring is really interesting, and I hope we see the concept refined better in the future.

It's N6 so it shouldn't be that bad, plus we have no idea the state of Intel 4 quality wise. Being able to shut off the cpu tile completely probally does save quite a bit of power.

 

[Joe NYC]

MTL has essentially nothing in common with Ponte Vecchio.

What it has in common with Ponte Vecchio is that it is over-complicated and over-engineered.

Foveros is a negligible concern for both at this point. Alchemist should show you that manufacturing has nothing to do with its issues (minus the delays from the Intel to TSMC switch).

Alchemist does not use Foveros. I don't think there is not any mass market success story with Foveros.

I am not saying that Foveros can never achieve success. Maybe it can, in larger applications, where cost and overhead are not showstoppers.

But not in small, cost sensitive application.

And I'm not sure why you think Foveros will make MTL large or expensive either. A passive base die isn't particularly expensive for mainstream and up.

I had my answers to both in my original post. That intel will have trouble competing in thin and light, due to cost, power, but could hold its own only in larger, higher performance laptops.

 

[Exist50]

What it has in common with Ponte Vecchio is that it is over-complicated and over-engineered.

By what criteria? Be specific.

Alchemist does not use Foveros. I don't think there is not any mass market success story with Foveros.

By this logic, AMD's Rome should have been a failure. After all, there was no "mass market success story" with a chiplet IO die.

I had my answers to both in my original post. That intel will have trouble competing in thin and light, due to cost, power, but could hold its own only in larger, higher performance laptops.

So you honestly believe you know more about Foveros pricing than Intel themselves do? Do you realize how absurd that sounds?

And you don't think it's suitable to thin and light, low power systems? That's literally the only place we have seen Foveros so far.

 

[IntelUser2000]

I wasn't aware there was any "processing" being done on the PCH. At least in a way that was somewhat transparent to an OS.

Yes in the way microcontrollers do. So even Quark might have been a big step up. Seems to be a natural progression. Everything starts needing dedicated cores for it.

Crestmont is possible. I will be more optimistic if it is the case. Idling for streaming video won’t be so much of a big deal, but interactive tasks they’d want to be careful short of compromising UX, and Crestmont would be fine for that. Indeed, the migration policy and heuristics for QoS is where Microsoft also comes into play. I wonder what the timescales are for powering the compute tile on/off with Foveros and migrating a thread. Suppose it depends how this is implemented.

Note that current power management is very sophisticated.

-Speedstep, which is P state and dynamically switches frequency and voltage depending on load. If the task is bursty enough, it may not even reach peak frequency.
-Turbo Boost 2.0(Sandy Bridge): Puts clocks above base to take advantage of the lag between thermal heating and power use. Governed by load, power, and temperature.
-C-State, which is a sleep specific state. C1 to C10 are available. C8 and below hasn't been implemented properly until just less than 5 years ago due to the complexity of implementing it and the blistering rate computers are introduced. C10 was first introduced with Haswell in 2013!
-S0iX, brought by Haswell which brings S0 level responsiveness with S3 levels of power. Which is a requirement to go below C7.
-cTDP, which allows the system to adjust TDP on the fly, depending on the usage(tablet vs clamshell, vs gaming, etc), and now even based on load.
-Speedshift(Or the more technical term EARTH), which moves the control to the CPU, and power use is further determined by power use at the platform level, where previously it was just the CPU. Brought by Skylake.

It's said that Speedshift can mostly replace the roles taken by Speedstep, not just because of that but because of other features introduced such as more C states and faster transitions along with dedicated PMU chip inside the core.

If you watch how the transitions work, sleep state transitions are significant. The deepest C states takes seconds to even over a minute! Remember the CPU is trying to get the ENTIRE system to sleep, which includes SSD, touchpad, mouse, chipset, IO ports like USB and PCI Express, the webcams, fingerprint readers, etc. One feature misbehaving out of a single device can cause all power management features to be out of whack.

Ever since I was 14 years old when I started really reading into computers and they were talking about battery life increases every generation, it didn't pan out as claimed. Then when I started reading about Haswell and the real problem, and the effort Intel was putting into the ecosystem, I knew we had something special coming. It had to be an ecosystem effort anyways. The Haswell jump was equal to more than a decade worth of previous efforts.

So I do not worry too much about it making it more complicated if in practice it can work like Speedshift replacing Speedstep for the most part, or C3/4/5 being skipped and now goes from C2 to C6. Maybe it takes extra 50ms, but if it allows it to reach C7 and deeper in that time period it'll be a huge win vs today, because while it's theoretically possible to reach that, it takes the average user closing tasks and applications beyond what they have a clue about.

Further favoring it if it makes implementation easier for the laptop manufacturers, which is the reason C10 took so long to adopt. Getting all the hardware and the firmware to work together was a monumental task and that's why even big vendors like Lenovo didn't write C10 capable firmware even way after Haswell was introduced. Haswell still was a huge gain, but it took Broadwell to get the 2x originally planned. I think Icelake was the first mass C10 adoption.

 

[IntelUser2000]

I have to respond to this with Scott Adams quote many Civilization players are familiar with:

Normal people... believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet.

It seems to me that Meteor Lake has been designed using this philosophy.

Seems a bit of an unjustified attack on the whole profession considering most do what is asked of them? Their main goal is tackling issues and making it better. Without such people you wouldn't have computers nevermind even the much basic tools we use today? Perhaps he's happy building things all with bare hands? Good for him.

No, mismanagement and human errors explain all of that. And of course not all of an individual's ideas are agreed by the greater population.

Did you forget to mention that guy is a cartoonist?

 

[Joe NYC]

By what criteria? Be specific.

- 3 types of cores
- 3+ process technologies
- interposer that is an overkill for the current solution, theoretically able to address possibilities that will never materialize
- changing core count requires redoing interposer
- changing graphics also different interposer.
- the monumental project, yet it still does not have system level cache

By this logic, AMD's Rome should have been a failure. After all, there was no "mass market success story" with a chiplet IO die.

Rome connected somewhere between 1,000 and 1,600 mm2 of silicon that was impossible to produce competitively any other way. And the final product was priced probably from $1,000 to $8,000.

Yet, still has a simpler solution than Meteor Lake

So you honestly believe you know more about Foveros pricing than Intel themselves do? Do you realize how absurd that sounds?

I believe that a highly bureaucratic organization can be set on the wrong path, and as bad decisions are discovered along the way, there is not enough flexibility to undo them.

Jim Keller, in interview with Ian Cutress, Keller said he was scratching his head about how, without much forethought, Intel teams were breaking big chips into chiplets, because orders came it to do chiplets.

Along the way, they forgot why they were breaking up these chips and what benefit was supposed to come out of the exercise.

If these decisions were made 3 years ago, and some of the pieces of the puzzle were underperforming, there is no way to change course.

There was another article or video of Ian Cutress, where he brought up the issue of yields with Foveros. That there were issues with yields, and more chips you add, the probability grows of a bad final product, even though it was composed of all good dies,

Which could be a big problem for Ponte Vecchio. But by extension, also for the mini Ponte Vecchio.

And you don't think it's suitable to thin and light, low power systems? That's literally the only place we have seen Foveros so far.

If you are talking about Lakewood, that ended up as a failure for Intel.

 

[Joe NYC]

Seems a bit of an unjustified attack on the whole profession considering most do what is asked of them? Their main goal is tackling issues and making it better. Without such people you wouldn't have computers nevermind even the much basic tools we use today? Perhaps he's happy building things all with bare hands? Good for him.

No, mismanagement and human errors explain all of that. And of course not all of an individual's ideas are agreed by the greater population.

I think the quote probably was pointing at software engineers, who, at the time had a problem with feature creep creating hard to catch and hard to fix bugs

Did you forget to mention that guy is a cartoonist?

Cartoonist whose main subject is dysfunctional workplace, dysfunctional management.

Apparently, a number of CEOs dreaded the possibility of their project, ideas ending up in a Dilbert Cartoon.

 

[Exist50]

- 3 types of cores

There are two cores. One just happens to be on both dies. But that doesn't double the work, or anything close.

- 3+ process technologies

The entire point of chiplets is that each component doesn't have to worry about what the others are doing. Why would, say, Redwood Cove being on Intel 4 and graphics on N5P be any more complex than both on the same process? Yes, it's a higher number of process technologies, but that doesn't really add complexity, beyond perhaps the supply chain.

- interposer that is an overkill for the current solution, theoretically able to address possibilities that will never materialize
- changing core count requires redoing interposer
- changing graphics also different interposer.

Making a bunch of passive interposers is trivial. I'm really not sure why you're so focused on this point. The general idea has been in use for years now. Moreover, you're wrong about needing new base dies for each config. Superset dies would work just fine.

- the monumental project, yet it still does not have system level cache

Would that not be yet more complexity? Though I could agree that that might have been a better investment than some other design choices.

Jim Keller, in interview with Ian Cutress, Keller said he was scratching his head about how, without much forethought, Intel teams were breaking big chips into chiplets, because orders came it to do chiplets.

I've recounted the story about how mismanaged the MTL definition process was, but looking at it from 2022, the cutlines seem reasonable. In particular, there's no way they'd be able to get away with the limited Intel 4 scope if they needed to build a significant amount of IO on it. Likewise, graphics would certainly not be any better off on an Intel process. Obviously the best would be everything on TSMC, but that's not happening.

There was another article or video of Ian Cutress, where he brought up the issue of yields with Foveros. That there were issues with yields, and more chips you add, the probability grows of a bad final product, even though it was composed of all good dies,

Packaging/assembly losses are always a things. We've heard neither rumors nor purported leaks to suggest they're anything significant with Foveros, much less enough to counteract the benefit from individually binning dies. And the fact that Intel thinks it's suitable for the entire mainstream market suggests that's not a meaningful concern.

If you are talking about Lakewood, that ended up as a failure for Intel.

Lakefield failed because 10+ was garbage, Sunny Cove was garbage, and Intel's SoC design was garbage at low power. The packaging tech was the least of their problems there.

 

[DrMrLordX]

With annual cadence, there will be N4 Phoenix already established in the market before Meteor Lake launches, and another iteration (Strix?) shortly after.

Do you really think AMD is going to be ready with Phoenix?

 

[moinmoin]

The mainband fabric has very little to do with power management on an IP level, and in a design like MTL where the ring only connects to a subset of the CPU cores, not much from an SoC-perspective either.

We were talking about how AMD is "reaping low static power draw". At idle it matters very much how the layout of components is set up that you can completely turn off. For multicore CPUs it's the interconnect and cache hierarchy, especially LLC, that need to stay powered on even if the cores themselves are mostly shut down both to retain the data and to reduce latency once data is requested again.

Since AMD introduced CCX with Zen the interesting part about their interconnect is that it's no longer distinctly visible (to the point that before Zen 3 we never got an official confirmation how the actual routing looks like) but designed as part of the L3 LLC.

Meanwhile Intel keeps spending plenty die area just for the interconnect, with the LLC in some designs as the mesh fabric being situated relatively far off of the actual cores.

I think this argument is particularly weird in the context of MTL, which is the biggest change to Intel's uncore since at minimum Sandy Bridge, and arguably ever.

The MTL compute die shots so far make it look like a direct continuation of the layout used in the previous generations, this time just on a disaggregated die. I asked before about this apparent stagnancy, and the common response seems to be to link it to Intel's corporate structure, IP blocks essentially reflecting distinct working groups that interact too little.

And it's extra weird when you consider that AMD has adopted a ring bus for their 8c CCX. A ring bus isn't inherently bad, but there's an ocean of implementation details that get hidden under that classification.

I'll have to make it clear it's not about the ring bus being bad or something. For a long time Intel had by far the superior idle power usage, their ring bus was and to some degree still is a perfect balance of low latency, low-ish power usage and high bandwidth.

But the old design still used is known to not scale all too well (which is why Intel trialed multiple rings before going with a mesh fabric for higher core counts). And meanwhile, imo visibly starting with Renoir, AMD suddenly passed Intel in low static power draw while Intel's mobile chips for the last couple generations actually manage to get worse there. That for Zen 3 (8c CCX and V-Cache) AMD admitted to be using some form of ring bus just further underlines that execution matters. So far I'm still not seeing Intel investing in research in that particular area.

Do you really think AMD is going to be ready with Phoenix?

Off topic, but: AMD has to launch something to the ODM next January for the next round of laptop models in any case. Dragon Range and Phoenix Point are next in the line. (Actual availability to end consumers will be the same story as every year regardless.)

 

[witeken]

So much FUD...

(1) Alder Lake has longer battery life than Tiger Lake (see the Framework laptop)
(2) Infinity Fabric is the epitome of an overhyped interconnect, it uses over twice as much power (2pJ/bit) as Intel's "decade old" MCM interconnect (1pJ/bit)
(3) People are way too simplistic in thinking that many chiplets == high complexity == high cost. No, Ponte Vecchio and Meteor Lake aren't "over-engineered". The only difference with a monolithic chip is that each chiplet is built on the most suitable node. For example, SRAM has stopped scaling, so why not put a big juicy Rambo cache tile on an older node?
(4) No, Foveros is not significantly higher cost. In a year or so you'll be able to buy Core i3 Meteor Lakes. Intel will produce billions of Foveros CPUs in the next decade.
(5) No, Intel doesn't need a different interposer for every different chiplet config, and even if it did it would be negligible cost overall.
(6) There's a basic concept called KGD (known good die), so again, no, more chiplets don't reduce yield. Intel said Foveros has high yield. Ouch.

@Joe NYC @moinmoin

 

[moinmoin]

(2) Infinity Fabric is the epitome of an overhyped interconnect, it uses over twice as much power (2pJ/bit) as Intel's "decade old" MCM interconnect (1pJ/bit)

Infinity Fabric is not an interconnect, it's the protocol for any implementation of an interconnect. So by itself it can't have a specific power usage.

 

[jpiniero]

Keeping this related to Meteor/Arrow, what I want to know how the timing is going to work. If Meteor's going to be an EOY 23/24 product now, should we just assume that Arrow will be pushed back to EOY 24/25? They could just fill the rest of 14th Gen with Raptor Lake rebrands if need be.

 

[lobz]

Intel has a significant uncore problem, I'll agree, but I think that's an oversimplification for Alder Lake in particular. After all, it's not like the uncore regressed from Tiger Lake, and yet battery life did. I think the two biggest hardware problems were switching the mainstream from a 4c to an 8c equivalent config (U->H, sort of), and the area/leakage growth of Golden Cove. Though really, it's Sunny Cove that deserves most of the shaming there.

The mainband fabric has very little to do with power management on an IP level, and in a design like MTL where the ring only connects to a subset of the CPU cores, not much from an SoC-perspective either.

I think this argument is particularly weird in the context of MTL, which is the biggest change to Intel's uncore since at minimum Sandy Bridge, and arguably ever. And it's extra weird when you consider that AMD has adopted a ring bus for their 8c CCX. A ring bus isn't inherently bad, but there's an ocean of implementation details that get hidden under that classification.

IF is not just the mainband fabric.

 

[lobz]

So much FUD...

(2) Infinity Fabric is the epitome of an overhyped interconnect, it uses over twice as much power (2pJ/bit) as Intel's "decade old" MCM interconnect (1pJ/bit)
@Joe NYC @moinmoin

We get that you're eternally in love with all things Intel, but I mean... if you're so annoyed by the FUD, could you please get a clue first about what IF actually is, before pouring oil onto the campfire?

 

[Joe NYC]

There are two cores. One just happens to be on both dies. But that doesn't double the work, or anything close.

Do we know for certain that it is the same generation of e-core? Even if it is, it will have different performance characteristics and different location (and L3 cache) for scheduler to consider the e-cores interchangeable.

Also, I will grant Intel that having very efficient, minimalistic e-core, sufficient in low CPU utilization, while shutting the rest of CPU die off, is probably a good idea.

But then, why in the world would Intel duplicate them on CPU die, just to get a better Cinebench score?

Seems like decisions made by committee, where you want to have a pie and also eat it too. No concept of trade offs.

The entire point of chiplets is that each component doesn't have to worry about what the others are doing. Why would, say, Redwood Cove being on Intel 4 and graphics on N5P be any more complex than both on the same process? Yes, it's a higher number of process technologies, but that doesn't really add complexity, beyond perhaps the supply chain.

I think the correct starting point is that Intel 4 process does not cover all use cases well, only the high performance core case.

This limitation was the necessity drove the partition decisions. Whether it turns out to also be a virtue as well remains to be seen.

Making a bunch of passive interposers is trivial. I'm really not sure why you're so focused on this point. The general idea has been in use for years now. Moreover, you're wrong about needing new base dies for each config. Superset dies would work just fine.

Remains to be seen. It may need additional steps to fill the gap, or add support to the die. Bigger core chiplet may need additional power delivery to the rest of the die.

Let's compare this with client Zen 3, for example, where there is one type of substrate, it does not have to change to accommodate a 2nd chiplet, 2nd chiplet is identical replica of the 1st.

Intel has to redesign the chiplet to get more cores and also, possibly redesign the interposer. So the re-use is quite limited.

Would that not be yet more complexity? Though I could agree that that might have been a better investment than some other design choices.

It would be more conceptual / design complexity, but there would be a payoff to compensate for increased manufacturing complexity and cost.

I've recounted the story about how mismanaged the MTL definition process was, but looking at it from 2022, the cutlines seem reasonable. In particular, there's no way they'd be able to get away with the limited Intel 4 scope if they needed to build a significant amount of IO on it. Likewise, graphics would certainly not be any better off on an Intel process. Obviously the best would be everything on TSMC, but that's not happening.

Yup, definitely agree on this part.

Packaging/assembly losses are always a things. We've heard neither rumors nor purported leaks to suggest they're anything significant with Foveros, much less enough to counteract the benefit from individually binning dies. And the fact that Intel thinks it's suitable for the entire mainstream market suggests that's not a meaningful concern.

You would want much less in terms of packaging losses than to counteract the gains from individual binning of good dies. Because if you just break even, you could have made a monolithic chip. Which Intel could not.

So arguing from the other end, that since Intel chose the approach, it must be good ignores the fact that Intel had no other choice..

 

[Joe NYC]

Do you really think AMD is going to be ready with Phoenix?

It is a big leap:
- new CPU core
- new GPU
- new process node

The optimistic timeline is beginning of 2023. Even if there is a minor slip, it should still launch before Meteor Lake.

 

[RTX]

Can Tiles be defined as fused silicon/functionally monolithic/low die to die latency?

AMD MI250 / IBM Z16 / Intel Ponte Vecchio

Chiplets as unfused silicon such as Ryzen/EPYC ( high die to die latency? )

 

[Joe NYC]

So much FUD...

(1) Alder Lake has longer battery life than Tiger Lake (see the Framework laptop)

That is disputed, as you know from your tweet:

https://twitter.com/x/status/1559478127218286593

(2) Infinity Fabric is the epitome of an overhyped interconnect, it uses over twice as much power (2pJ/bit) as Intel's "decade old" MCM interconnect (1pJ/bit)

As a SerDes implementation, it fulfilled its role. And it continues to evolve.
Since it is a protocol, it can have other implementations.

(3) People are way too simplistic in thinking that many chiplets == high complexity == high cost. No, Ponte Vecchio and Meteor Lake aren't "over-engineered". The only difference with a monolithic chip is that each chiplet is built on the most suitable node. For example, SRAM has stopped scaling, so why not put a big juicy Rambo cache tile on an older node?

You know what other thing Ponte Vecchio and Meteor Lake aren't? Shipping.

Which is one of the things chiplets should be helping with. Each smaller chiplet with limited functionality should have a faster time to market than a large monolithic die that combines functionality of all elements.

So far, it is not happening for Intel.

(4) No, Foveros is not significantly higher cost. In a year or so you'll be able to buy Core i3 Meteor Lakes. Intel will produce billions of Foveros CPUs in the next decade.

There is a circular argument:
- Intel chose it because it is good
- It is good because Intel chose it.

It remains to be seen.

But clearly, future is hybrid bond link, and it is nowhere on any of Intel roadmaps, not on any of the products we know of.

(5) No, Intel doesn't need a different interposer for every different chiplet config, and even if it did it would be negligible cost overall.

Negligible in a $1,000 product. We will see how negligible the cost will be in $100 product.

 

[jpiniero]

Which is one of the things chiplets should be helping with. Each smaller chiplet with limited functionality should have a faster time to market than a large monolithic die that combines functionality of all elements.

But the chiplets themselves need to work. Intel probably needs another year+ to get Intel 4 yielding high enough for the tiny 40 mm2 chiplet. If it wasn't for the chiplet strategy, it'd be 10 nm all over again.

 

[Joe NYC]

Can Tiles be defined as fused silicon/functionally monolithic/low die to die latency?

AMD MI250 / IBM Z16 / Intel Ponte Vecchio

Chiplets as unfused silicon such as Ryzen/EPYC ( high die to die latency? )

Chiplet is more of an industry naming, while Tile is Intel naming (when Intel employees don't slip and call them chiplets as well).

With "tiles", one might think that a tile can communicate only with adjacent tile. But in case of Meteor Lake, using interposer, any "tile" can communicate with any other.

 

[Joe NYC]

But the chiplets themselves need to work. Intel probably needs another year+ to get Intel 4 yielding high enough for the tiny 40 mm2 chiplet. If it wasn't for the chiplet strategy, it'd be 10 nm all over again.

There may be a plan B (C, D, E) in place to move the CPU chiplet at TSMC as well, if "Intel 4" is not ready. Which would be another advantage of chiplet approach.

But, given how much the expectations for Intel 4 has been scaled down, Intel might just be able to make it this time.