[Ashraf] 10nm "Lakefield" SoC with Intel big + little cores

Page 21 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

piokos

Senior member
Nov 2, 2018
554
206
86
Alder Lake mobile wouldn't be LGA, so "mostly" still doesn't apply.
I said "LGA1700 so mostly desktops". That's because "consumer" (non-Xeon) LGA chips occasionally appear in other types of devices (laptops, servers).
And no specific Alder Lake is confirmed, but Sharkbay has leaked an entire lineup.
LGA1700 Alder Lake was officially confirmed by Intel.
Mobile Alder Lake (-M, BGA) only appeared in some occasional rumors from anonymous accounts. So as far as I'm concerned, Alder Lake-M doesn't and probably won't exist.

But going back to your comment that triggered me: even if Alder Lake-M does appear after all, it still isn't going to be a replacement for Lakefield.
Lakefield is a separate product series, with some very unique properties (Foveros, POP RAM). Probably no variant of Alder Lake will use POP RAM and utilizing Foveros is extremely doubtful as well.

I mean: you can't say chip "A" is replacing chip "B" just because it uses vaguely similar architecture.
 
  • Like
Reactions: mastercoin

Exist50

Platinum Member
Aug 18, 2016
2,445
3,043
136
I said "LGA1700 so mostly desktops". That's because "consumer" (non-Xeon) LGA chips occasionally appear in other types of devices (laptops, servers).

LGA1700 Alder Lake was officially confirmed by Intel.
Mobile Alder Lake (-M, BGA) only appeared in some occasional rumors from anonymous accounts. So as far as I'm concerned, Alder Lake-M doesn't and probably won't exist.

But going back to your comment that triggered me: even if Alder Lake-M does appear after all, it still isn't going to be a replacement for Lakefield.
Lakefield is a separate product series, with some very unique properties (Foveros, POP RAM). Probably no variant of Alder Lake will use POP RAM and utilizing Foveros is extremely doubtful as well.

I mean: you can't say chip "A" is replacing chip "B" just because it uses vaguely similar architecture.

Even if you doubt the ADL-M leaks for whatever reason, there's still ADL-P. And regarding ADL-M, there aren't that many lakefield designs to replace. We'll see how that all shakes out.
 

DrMrLordX

Lifer
Apr 27, 2000
21,620
10,830
136
I wouldn't be so sure about that either.

Okay. Why not? If you look at the core configs, the simplest one is 2 Golden Cove + 0 Gracemont. That would certainly be the easiest product to launch, even if it wouldn't be the most lucrative. In general, the mobile core counts are lower, so they have more options wrt selling defective dice there than they do with the desktop SKUs.
 

Exist50

Platinum Member
Aug 18, 2016
2,445
3,043
136
Okay. Why not? If you look at the core configs, the simplest one is 2 Golden Cove + 0 Gracemont. That would certainly be the easiest product to launch, even if it wouldn't be the most lucrative. In general, the mobile core counts are lower, so they have more options wrt selling defective dice there than they do with the desktop SKUs.

A couple reasons. We heard about ADL-S first, and I don't think that's just a coincidence. And from Intel's perspective, the desktop market is both their biggest competitive gap and also the most... tolerant... of bugs. If power management or scheduling isn't ideal, ADL-S would still be viable. Hell, push comes to shove, they could disable Gracemont altogether and still have a viable product.

Also, in terms of actual dies, I think Sharkbay's leak makes the most sense, and we know he has a track record.

S:
8+8 flagship desktop, 6+0 volume OEM

P:
6+8 performance/high power mobile, 2+8 lower power, lower cost, and high volume, presumably BGA compatible

M:
2+8 lowest power mobile (reuse of lower end ADL-P die?)

Also, I'm not claiming to know what Intel's doing here, but from a backend design perspective, it's slightly easier to design a superset config and chop it than to extend a lower config. I'd wager that's a greater consideration than 10nm yields in 2021.
 
  • Like
Reactions: Tlh97 and mikk

DrMrLordX

Lifer
Apr 27, 2000
21,620
10,830
136
from a backend design perspective, it's slightly easier to design a superset config and chop it than to extend a lower config. I'd wager that's a greater consideration than 10nm yields in 2021.

Well there's the issue of the graphics "cores". Alder Lake-P has 2, -S has 1. So is everything going to be 8+8+2 and cut down from there, or is graphics on a separate chiplet? Otherwise I agree, 8+8 is going to be the main design with everything coming from that common base. But looking at IceLake and TigerLake (both mobile-only products), Intel has yet to get anything to yield well enough for desktop duty on 10nm, so it's a stretch to assume that Alder Lake will be ideally-situated for desktop use and problematic for mobile. I expect a lot of failed dice, and maybe some voltage/clockspeed/power problems at the higher ranges of its clocks (though TigerLake does show that SuperFETs may make that less likely). 2+8, 2+4, and 2+0 configs will likely be the easiest things for them to yield, and those fit Alder Lake-P perfectly.

Alder Lake (-S or -P) will be a watershed moment for Intel, of sorts. It's the first time they'll actually try to yield more than 4c with Core on 10nm. They may screw it up, or suffer some ugly delays on the parts best-suited to desktop.
 

Exist50

Platinum Member
Aug 18, 2016
2,445
3,043
136
Well there's the issue of the graphics "cores". Alder Lake-P has 2, -S has 1. So is everything going to be 8+8+2 and cut down from there, or is graphics on a separate chiplet?

I'm working under the theory that the configs that Sharkbay mentioned are all separate dies, with the possible exception of 2+8 P vs M.

Alder Lake (-S or -P) will be a watershed moment for Intel, of sorts. It's the first time they'll actually try to yield more than 4c with Core on 10nm

There's also TGL-H.
 

IntelUser2000

Elite Member
Oct 14, 2003
8,686
3,785
136
That's a lot of different dice.

Not that surprising. Atoms in 2010 had 5 different dies. And the volumes and ASPs were fraction of Core.

You need a common design, but it seems relatively easy to proliferate configurations.

By the way, saying Gracemont adds to defect issues don't make a lot of sense. Area-wise, it should be again a quarter or less of its Core counterpart.

Also, this thread is for Lakefield, so let's start making a u-turn.
 

DrMrLordX

Lifer
Apr 27, 2000
21,620
10,830
136
By the way, saying Gracemont adds to defect issues don't make a lot of sense.

No, but Golden Cove might. And I don't think the defect issues would be as prominent in 2+x+2 configurations anyway. Intel seems to struggle with more than 4c Sunny Cove/Willow Cove. If Intel is going to scrape Lakefield-R (or Alder Lake-M) out of dice intended for Alder Lake-S or Alder Lake-P, Lakefield-R/Alder Lake-M will be the SoC with the least yield issues.
 

Exist50

Platinum Member
Aug 18, 2016
2,445
3,043
136
By the way, saying Gracemont adds to defect issues don't make a lot of sense. Area-wise, it should be again a quarter or less of its Core counterpart.

I'm talking about logical/architectural bugs, not manufacturing defects. Bringing things back to Lakefield, it's not yield that caused them to disable SMT on Sunny Cove.
 

NTMBK

Lifer
Nov 14, 2011
10,232
5,013
136
I'm talking about logical/architectural bugs, not manufacturing defects. Bringing things back to Lakefield, it's not yield that caused them to disable SMT on Sunny Cove.

I presumed that had more to do with software. Scheduling threads between two asymmetrical CPU clusters is tricky enough, without trying to balance SMT as well. Do you want two threads on the big core, so you don't need to wake up the small cores? Do you put one on the big core and one on the small cores, to maximise performance? Is two threads on the small cores actually going to give better throughput than two on the big SMT core?
 

LightningZ71

Golden Member
Mar 10, 2017
1,627
1,898
136
If you look at it like the second thread on the big core being roughly equivalent to a third of a big core in performance, and accept that, for the big core running in the first place, at least one or more small cores will already be running, then it realy makes no sense to even enable SMT on the big core, especially when it's understood that it does give a slight perforhit in single thread situations and also increases power draw on an already hungry core.

When you fire up the big core, you want it to provide maximum thread benefit and finish that task as soon as possible, not hang around and wait for secondary threads to resove or migrate.