Intel 18A yields at 20-30%?

[OneEng]

Ming-Chi Kuo and his yield survey are full of manure. 18A yields are on track to what they told us last December. From what I have heard there will be external customer 18A tape-outs in 2H 2025 and I have not heard one complaint about yield. In my opinion packaging is much more likely the cause of delays. Multi die packaging is HARD (thermal issues) and we really have just begun. Just ask Nvidia.

I'm not sure why everyone is getting their clicks by bashing Intel but it is an absolute abuse of media. The whole media landscape seems to have lost their way. I really expect better from tech pubs.

It's pure crap. I agree. Note: I don't think that Intel is an angle who speaks only truth either, but it seems that 18A has gotten more than its share of unfair press. The first "crap" was a 10% yield that we later found out was done using a die size based on the reticle limit. I suspect this 20% is the same which would put a 100mm2 ish size die at around 70-80 I think. If that is the case, 18A is doing just fine.

Now, your comment on packaging is much more valid IMO. When AMD first moved Zen to Zen 2 and started using chiplets and advanced packaging with interconnects, they had some initial issues with latency and performance. Zen 3 freed up some of these critical paths and looked much better. Today, Turin and other DC parts are really showing how well a MCM with advanced interconnects and packaging can perform, all while keeping individual die sizes under control.

Seems to me like Intel is essentially back at the AMD Zen 2 phase of development in this regard. If that is the case, then the next gen should be impressive ..... once they iron out their latency issues through core design and packaging design enhancements.

 

[nghanayem]

It's pure crap. I agree. Note: I don't think that Intel is an angle who speaks only truth either, but it seems that 18A has gotten more than its share of unfair press. The first "crap" was a 10% yield that we later found out was done using a die size based on the reticle limit. I suspect this 20% is the same which would put a 100mm2 ish size die at around 70-80 I think. If that is the case, 18A is doing just fine.

Now, your comment on packaging is much more valid IMO. When AMD first moved Zen to Zen 2 and started using chiplets and advanced packaging with interconnects, they had some initial issues with latency and performance. Zen 3 freed up some of these critical paths and looked much better. Today, Turin and other DC parts are really showing how well a MCM with advanced interconnects and packaging can perform, all while keeping individual die sizes under control.

Seems to me like Intel is essentially back at the AMD Zen 2 phase of development in this regard. If that is the case, then the next gen should be impressive ..... once they iron out their latency issues through core design and packaging design enhancements.

Zen CPUs don't use advanced packaging. It is basic organic MCM. Any major OSAT can fulfill the simple requirements for organic MCM. Intel has been doing it for decades with graphics, chipsets, memory, and SRAM. Others have done it too IBM etc. Funnily enough Intel fab'd advanced packages before Zen through external custom foundry FPGA makers using EMIB. One of those classic instances of TD making some cool thing for Intel products to solve an issue they said they had only for them to not use it because it needed a clean sheet redesign and they didn't want to pay the ramp costs. The same year of Zen+ Intel even did advanced packaging for AMD GPU plus HBM for the Kabbylake G system on package.

The novelty with Zen has very little to do with packaging and very much to do with clever design. Homogeneous disaggregation was something that I can't really think of anyone doing before, as opposed to heterogenous disag which is a dime a dozen. Everyone and there mother can split IO from cores. It isn't generally advisable because it is less efficient (see AMD vs Intel pre nehalihm). From what I see, what is special about Zen is making that split memory controler for Zen 2 and beyond work well enough that it isn't so bad that it looses to much smaller monolithic chips, and splitting the compute into scalable units. From a manufacturing perspective Zen is completely unremarkable. Doubly so with them being slow to adopt the newest TSMC processes.

 

[OneEng]

Zen CPUs don't use advanced packaging. It is basic organic MCM. Any major OSAT can fulfill the simple requirements for organic MCM. Intel has been doing it for decades with graphics, chipsets, memory, and SRAM. Others have done it too IBM etc. Funnily enough Intel fab'd advanced packages before Zen through external custom foundry FPGA makers using EMIB. One of those classic instances of TD making some cool thing for Intel products to solve an issue they said they had only for them to not use it because it needed a clean sheet redesign and they didn't want to pay the ramp costs. The same year of Zen+ Intel even did advanced packaging for AMD GPU plus HBM for the Kabbylake G system on package.

The novelty with Zen has very little to do with packaging and very much to do with clever design. Homogeneous disaggregation was something that I can't really think of anyone doing before, as opposed to heterogenous disag which is a dime a dozen. Everyone and there mother can split IO from cores. It isn't generally advisable because it is less efficient (see AMD vs Intel pre nehalihm). From what I see, what is special about Zen is making that split memory controler for Zen 2 and beyond work well enough that it isn't so bad that it looses to much smaller monolithic chips, and splitting the compute into scalable units. From a manufacturing perspective Zen is completely unremarkable. Doubly so with them being slow to adopt the newest TSMC processes.

I wasn't sure how "advanced" AMD's packaging and inter-chiplet connects were, but I was quite certain that Zen has done some heavy design lifting in making the over-all performance suffered by the end product minimal despite the limitations in the connections between the chiplets.

I once did a system design on a database app where I was forced to have very high latency between the DB server and the client (racks and stacks at a major automotive OEM). The trick was designing a custom interface that moved data in a compressed format across the network in real time (well, at least one of the tricks). Oracle (as it turns out) moves query data across the network in small packets (around 350 bytes by its default settings) to avoid clobbering the network .... but the latency kills you.

Anyway, if your system design starts off with "I have this terrible limitation in the critical performance pathway" and ends with "here are all the clever ways we are getting around this limitation", then things are OK. Where you get into trouble is when these limitations are NOT understood in the beginning design and they sneak up and surprise you .... generally when the bulk of the design in other areas is already (supposed to be) finished.

Arrow Lake has the appearance of a design where Intel either:

1) Thought manufacturing was going to give them miraculous tile interconnect properties and therefore didn't need to allow for any serious limitations between tiles.

2) Underestimated the extent of the core architectural changes needed to deal with the limitations the tile interconnects would require.

Since the current trend in Intel is to blame everything on the foundry, and the delays to CWF are being blamed on the "packaging" issues, I am guessing more #1 than #2.

I have long believed that Intel's design team has leaned too heavily on the fact that manufacturing would provide them with large advantages over the rest of the industry.

 

[blueone]

I wasn't sure how "advanced" AMD's packaging and inter-chiplet connects were, but I was quite certain that Zen has done some heavy design lifting in making the over-all performance suffered by the end product minimal despite the limitations in the connections between the chiplets.

I agree.

I once did a system design on a database app where I was forced to have very high latency between the DB server and the client (racks and stacks at a major automotive OEM). The trick was designing a custom interface that moved data in a compressed format across the network in real time (well, at least one of the tricks). Oracle (as it turns out) moves query data across the network in small packets (around 350 bytes by its default settings) to avoid clobbering the network .... but the latency kills you.

Anyway, if your system design starts off with "I have this terrible limitation in the critical performance pathway" and ends with "here are all the clever ways we are getting around this limitation", then things are OK. Where you get into trouble is when these limitations are NOT understood in the beginning design and they sneak up and surprise you .... generally when the bulk of the design in other areas is already (supposed to be) finished.

Agree again.

Arrow Lake has the appearance of a design where Intel either:

1) Thought manufacturing was going to give them miraculous tile interconnect properties and therefore didn't need to allow for any serious limitations between tiles.

I can't believe the chip designers were this clueless.

2) Underestimated the extent of the core architectural changes needed to deal with the limitations the tile interconnects would require.

I don't believe this one either. My feeling is that the design teams were too risk averse to do the deep redesign work necessary to do tiled dies "properly".

I have long believed that Intel's design team has leaned too heavily on the fact that manufacturing would provide them with large advantages over the rest of the industry.

Agreed. I think the biggest advantage the intel design teams got from Intel manufacturing is that manufacturing promised to get to sufficient volumes and yields with massive single dies, apparently longer than AMD was willing to pay for. Nothing beats a big die for achieving performance objectives. Ask Nvidia. Or Cerebras...

There is also process tuning for the circuits the CPU guys need, but that stuff is probably in the noise compared to using a single die approach.

 

[OneEng]

My feeling is that the design teams were too risk averse to do the deep redesign work necessary to do tiled dies "properly".

I don't know, the latency figures on ARL are truly awful. It's amazing that it performs as well as it does.

On the flip side, we know these issues CAN be overcome (AMD seems to have a pretty good handle on it), and while I think that Intel has had bad strategy getting them where they are now, I have deep respect for the design engineers and believe that, given time, they will also get around the problems..... they are just a little late to the party .

 

[Xebec]

I don't believe this one either. My feeling is that the design teams were too risk averse to do the deep redesign work necessary to do tiled dies "proper

I think this is the right answer; some evidence:

- The latency issues of Zen 1 (and 2) were already known before Arrow Lake was likely even a paper diagram
- Arrow Lake is Intel's 3rd generation chip using tiles. Meteor Lake (Dec 2023), and Lakefield (June 2020) preceeded this design.
- There don't appear to be any flaws with the cores themselves (general application performance @ power levels are good)
- Arrow Lake supports higher (usable) memory bandwidth than Zen 4/5. Arrow Lake gets benefits from 8000+ DDR5 speeds, while Zen 4/5 receives no benefit above 6400.

On the flip side, we know these issues CAN be overcome (AMD seems to have a pretty good handle on it), and while I think that Intel has had bad strategy getting them where they are now, I have deep respect for the design engineers and believe that, given time, they will also get around the problems..... they are just a little late to the party .

I think "can be improved" might be a little better description. The truly latency sensitive applications (games) were still slower on AMD until they added (at cost) 3D cache. Even Intel's 13th gen chips (Intel 7) usually outperform Zen 5 (TSMC N5) on latency sensitive software.

See 13700K (Core i7 class) beating 9950X in games: https://www.techpowerup.com/review/amd-ryzen-9-9950x/27.html
(9950X even has a higher max boost clock than 13700K too - 5.7 GHz vs 5.4 GHz).

That said, Zen 6 is supposed to get a new I/O die - which will raise the bar again in another 18 months on what tiles/chiplets can do in terms of latency and performance.

 

[OneEng]

Agreed. I think the biggest advantage the intel design teams got from Intel manufacturing is that manufacturing promised to get to sufficient volumes and yields with massive single dies, apparently longer than AMD was willing to pay for. Nothing beats a big die for achieving performance objectives. Ask Nvidia. Or Cerebras...

True. I think the new reality in desktop/laptop/consumer CPU products is that all-out performance designs can't be achieved in a profit making window. Intelligent compromises (like chiplets/tiles) are needed to maximize performance within a cost target.

For other markets where all-out performance will be paid for at nearly any cost, it really does come down to milking every last ounce of performance out of the equipment and process available.

From a personal point of view, it must be nice to be in charge of a design where "cost is not a consideration" . Haven't had that since my days in the service .

 

[siliconbruh999]

Does anyone here trade Forex? I've been doing it for about a year now, and I can confidently say that choosing the right time for trading is a crucial aspect of successful trading. Different trading sessions affect market volatility and liquidity, so knowing the optimal time can help make more informed decisions. If you're also from India and interested in Forex trading in India, I recommend learning about the main trading sessions, their characteristics, and tips for traders.

What trading hours do you prefer? Share your thoughts!

this forum only does wafer trading not forex