Intel Clarkdale previewed

[IntelUser2000]

Originally posted by: MODEL3

I just wanted to point, what kind of increase to the die size brings, the integration of the memory controller and the pci-express in addition to the Nehalem architecture in relation with the Core 2 architecture (which is natural...)

Actually, the 32nm Clarkdale CPU die alone (not including the seperate IGP die) should be just a little bit bigger (in size, mm2) than a 32nm 8200 (with 4MB native cache) die.

The major cost increase using a 32nm Core 2 Quad isn't die size, but its about making a whole new die and product out using a shrink.

Anyway if they do a perfect 50% shrink it'll end up to be little less than 100mm2 which makes it 20% larger than supposed die for Clarkdale(80-85mm2).

By the way, it seems Hexus has pulled the earlier benchmark(as Intel's request?)...

 

[Idontcare]

Originally posted by: IntelUser2000

Originally posted by: MODEL3

I just wanted to point, what kind of increase to the die size brings, the integration of the memory controller and the pci-express in addition to the Nehalem architecture in relation with the Core 2 architecture (which is natural...)

Actually, the 32nm Clarkdale CPU die alone (not including the seperate IGP die) should be just a little bit bigger (in size, mm2) than a 32nm 8200 (with 4MB native cache) die.

The major cost increase using a 32nm Core 2 Quad isn't die size, but its about making a whole new die and product out using a shrink.

Anyway if they do a perfect 50% shrink it'll end up to be little less than 100mm2 which makes it 20% larger than supposed die for Clarkdale(80-85mm2).

That was my thinking too, but I assumed I must be misreading model3's post because it (his post, not yours) really doesn't make sense so I didn't post anything on it.

It reads like he is saying a 32nm yorkfield shrink product would be smaller die than a 2C/4T 32nm westmere, which I don't see how anyone could convince themselves of this considering that a 45nm nehalem is about the same size as a 45nm yorkfield, so if just shrink the yorkfield but you shrink and cut in-half the core count of nehalem it stands to reason the cut-down nehalem is likely to be the smaller die.

So I'm thinking I am just misinterpreting Model3's post and he didn't mean to communicate this as his point.

edit: added clarifier as to what wasn't making sense to me in the first sentence.

 

[IntelUser2000]

IDC, the Q8200 part only has 4MB of L2 cache, but even then Nehalem isn't THAT big.

Anyway I did include having only 8MB L2, but Q8200 has 4MB of L2!(It won't be smaller however). They might be able to make a part that's something like 90mm2 but the point still stands. Intel won't shrink for mere few SKUs.

 

[Idontcare]

Originally posted by: IntelUser2000
IDC, the Q8200 part only has 4MB of L2 cache, but even then Nehalem isn't THAT big.

Anyway I did include having only 8MB L2, but Q8200 has 4MB of L2!(It won't be smaller however). They might be able to make a part that's something like 90mm2 but the point still stands. Intel won't shrink for mere few SKUs.

I would say the QED is that it simply isn't on the roadmap, nor has it ever been.

The diesize/cost/etc arguments are, if anything, simply supporting reasons for Intel's decision in that regard.

Clarkdale/Arrandale from above, dual-core Atom from below, what's left in the ASP/SKU space to price/feature differentiate any more SKU's?

I'd say its already well crowded, and any argument you (not you you as in IntelUser2000, but you as in any one person taking that side of the debate) might try and make for a 32nm shrink of penryn is the same argument you would have made for making a 45nm shrink of netburst/cedar mill...and that didn't happen either for all the right reasons as well.

edit: added context to my use of the pronoun "you" to avoid any confusion that I might be trying to say IntelUser2000 is arguing this, that isn't what I mean.

 

[MODEL3]

Originally posted by: IntelUser2000

Originally posted by: MODEL3

I just wanted to point, what kind of increase to the die size brings, the integration of the memory controller and the pci-express in addition to the Nehalem architecture in relation with the Core 2 architecture (which is natural...)

Actually, the 32nm Clarkdale CPU die alone (not including the seperate IGP die) should be just a little bit bigger (in size, mm2) than a 32nm 8200 (with 4MB native cache) die.

The major cost increase using a 32nm Core 2 Quad isn't die size, but its about making a whole new die and product out using a shrink.

Anyway if they do a perfect 50% shrink it'll end up to be little less than 100mm2 which makes it 20% larger than supposed die for Clarkdale(80-85mm2).

By the way, it seems Hexus has pulled the earlier benchmark(as Intel's request?)...

Did i say that the major cost increase using a 32nm Core 2 Quad is about die size?
No.

Did i even say anything about cost?
No.

So to clarify,yes, for the above statement you made, i agree.


If you check when i wrote my original post, it was before Anand & Xbitlabs preview of the Clarkdale architecture.
It was based on what information i had at the time. (Hexus)

If you check my post i said that the Clarkdale 32nm core would be bigger because it will have on the CPU die, the PCI-express and the memory controller, which with that in mind the calculation is absolutely accurate.
(after the IDF and tech sites IDF reports, we found out that it will not have them on the CPU die)

So either you knew all along that info (you work for Intel?) (I didn't knew it before IDF), or
your calculation was wrong.

But if i understand correctly what you are saying, it doesn't seem that you have your own analysis of the die size, it seems that you are saying this because you read somewhere (you said: the supposed die for Clarkdale...) that the Clarkdale CPU die is going to be 80-85mm2 (unless of cource you work for Intel...)

See my reply to IDC, to check my calculation of the die size...

 

[MODEL3]

Originally posted by: Idontcare

Originally posted by: IntelUser2000

Originally posted by: MODEL3

I just wanted to point, what kind of increase to the die size brings, the integration of the memory controller and the pci-express in addition to the Nehalem architecture in relation with the Core 2 architecture (which is natural...)

Actually, the 32nm Clarkdale CPU die alone (not including the seperate IGP die) should be just a little bit bigger (in size, mm2) than a 32nm 8200 (with 4MB native cache) die.

The major cost increase using a 32nm Core 2 Quad isn't die size, but its about making a whole new die and product out using a shrink.

Anyway if they do a perfect 50% shrink it'll end up to be little less than 100mm2 which makes it 20% larger than supposed die for Clarkdale(80-85mm2).

That was my thinking too, but I assumed I must be misreading model3's post because it (his post, not yours) really doesn't make sense so I didn't post anything on it.

It reads like he is saying a 32nm yorkfield shrink product would be smaller die than a 2C/4T 32nm westmere, which I don't see how anyone could convince themselves of this considering that a 45nm nehalem is about the same size as a 45nm yorkfield, so if just shrink the yorkfield but you shrink and cut in-half the core count of nehalem it stands to reason the cut-down nehalem is likely to be the smaller die.

So I'm thinking I am just misinterpreting Model3's post and he didn't mean to communicate this as his point.

edit: added clarifier as to what wasn't making sense to me in the first sentence.

No IDC, with the info we had at the time of writing my post it makes perfect sense. (see below...)

In my original post i said:

"I just wanted to point, what kind of increase to the die size brings, the integration of the memory controller and the pci-express in addition to the Nehalem architecture in relation with the Core 2 architecture."

I didn't see anyone to reply to me that the memory controller and the pci-express will not be on the CPU die this time.

So with the above perspective it makes sense. (actually If you only compare a 45nm Nehalem like Lynnfield and (like you say) cut in-half the core count of nehalem it makes absolute sense)

In my original post I said 32nm 8200 with 4MB native cache
O.K. below are the calculations:

45nm 9400 6MB cache: die size 82mm2*2=164mm2
45nm 9450 12MB cache: die size 107mm2*2=214mm2
6MB cache die size=214mm2 - 164mm2 = 50mm2
2MB cache die size=50mm2/3 = 16,7mm2
die size of 45nm 8200 (with 4MB native cache) = 147,3mm2

45nm Nehalem i5 750 8MB cache=296mm2
296mm2 / 2=148mm2

So same (not less) 45nm die size.

The thing is that the i5 750 die size is:
4 cores die size +8MB cache die size +memory controller die size +PCI-express die size

If you cut the die size in two you have:
2 cores die size +4MB cache die size + 0,5 memory controller die size + 0,5 PCI-express die size

So you have to add to the 148mm2 figure + (0,5 memory controller die size) + (0,5 PCI-express die size)

So for the 32nm shrinks (with the info we had prior IDF), the Clarkdale would have bigger size in relation with the die size of a 32nm 8200 with 4MB native cache.

At the time of writing i guess most of the people (except those that work for Intel or guys like Tech sites reviewers) didn't know that the memory controller isn't on the CPU die but on the GPU die instead (and according to other sites the same is true for the PCI-express also).

So at the time of writing with the info that we had avaliable the calculation is correct.

Later IDF came and along with it came reports from various tech sites that said that the memory controller and the PCI-express is not intergrated to the CPU die but to the GPU die. (this is the only reason that the 32nm Nehalem CPU version die is lower than a 32nm 8200 4MB version die)

So yes, with this new info it is easy for everyone to figure out which die is bigger.
Sadly when i wrote my original post those info was not avaliable.

 

[Idontcare]

Originally posted by: MODEL3
No IDC, with the info we had at the time of writing my post it makes perfect sense. (see below...)

In my original post i said:
.
.
.
So yes, with this new info it is easy for everyone to figure out which die is bigger.
Sadly when i wrote my post those info was not avaliable.

Actually that info was available at the time you made your post, has been available for a few months now.

But again, I withheld from posting because I assumed I was the one misinterpreting what it was that I was reading.

Your post makes perfect sense in the context that you weren't aware of this info, and that is the benefit of the doubt that I was more than willing to give you until I could further determine what the source of my confusion was with your post.

At any rate, you've well established yourself to be a rational thinker, if your posts/conclusions don't match my own I generally default to the assumption that it is me who is missing something. It's all good.

 

[MODEL3]

Originally posted by: Idontcare

Originally posted by: MODEL3
No IDC, with the info we had at the time of writing my post it makes perfect sense. (see below...)

In my original post i said:
.
.
.
So yes, with this new info it is easy for everyone to figure out which die is bigger.
Sadly when i wrote my post those info was not avaliable.

Actually that info was available at the time you made your post, has been available for a few months now.

But again, I withheld from posting because I assumed I was the one misinterpreting what it was that I was reading.

Your post makes perfect sense in the context that you weren't aware of this info, and that is the benefit of the doubt that I was more than willing to give you until I could further determine what the source of my confusion was with your post.

At any rate, you've well established yourself to be a rational thinker, if your posts/conclusions don't match my own I generally default to the assumption that it is me who is missing something. It's all good.

I must have missed this info.

But i guess many others must have missed this info also, since nobody replied me that the memory controller was on the GPU die.
Do you know if the new info, regarding PCI-express being on the GPU die also, is true?

 

[Idontcare]

Originally posted by: MODEL3
I must have missed this info.

But i guess many others must have missed this info also, since nobody replied me that the memory controller was on the GPU die.
Do you know if the new info, regarding PCI-express being on the GPU die also, is true?

Its ok, I think it is safe to assume we are all here to share what we know and learn about things we don't. In your case you thought you were doing one thing and it turned out you were doing the other, I stopped counting the number of times this has happened to me long long long times ago.

I've no doubt many other folks did not know either, it happens. I assure you guys like ilkhan, inteluser, and many others here, do know. If you read their posts and don't understand where they are coming from then that is the time to ask them to explain for your betterment, not the time to assume they don't know. (not that you do this, more just trying to give props to these guys who tend to know what they are talking about)

At any rate, yeah the PCIe being on-die was also well-known from a while ago, long enough ago that I can't recall when that became "known" but at the same time who cares? So what if it was knowledge before you posted, you didn't know that so no one worth engaging is going to take you to task over it.

So now you know, and now I know where you were coming from, its all cool. And no doubt many other lurkers now know too, either because of your bringing it up from IDF or our bringing it up from Feb past.

That's why we are here, share what we know, learn about things we don't.

 

[ilkhan]

Originally posted by: MODEL3
I must have missed this info.

But i guess many others must have missed this info also, since nobody replied me that the memory controller was on the GPU die.
Do you know if the new info, regarding PCI-express being on the GPU die also, is true?

Well if youd like to do your own analysis, we have a few die shots to help you along.
bloomfield: http://img12.imageshack.us/img...emdiecallout715523.jpg
lynnfield: http://img193.imageshack.us/im...ynnfielddie7164463.jpg
clarkdale (CPU): http://img33.imageshack.us/img33/7448/core7183260.jpg

I made some lines on the die to separate some stuff. http://img85.imageshack.us/img85/7448/core7183260.jpg Top middle is cache, lower middle are the cores. The right seems to be the mem controller. The left...not sure about. But it looks a WHOLE lot like a QPI link to me. (look/compare at the QPI0 on the bloomfield shot).

 

[IntelUser2000]

I actually am the one that disagreed that Clarkdale will end up near 80mm2 rather than 100mm2. Some info came that refuted me that turned me around, but I'm pretty sure about this. Anyway I can't find it so its still speculative.

Q8200 die info is from Hans: http://www.chip-architect.com/...19_Various_Images.html

According to Hans, the cores take 22mm2 each and L2 SRAM takes 6.0mm2/MB, but the core size isn't really useful except for figuring out the not-so-common info like the "misc".

In Penryn, core: 22.0mm2(but for the sake of this conversation isn't very useful), L2 SRAM: 6.0mm2/MB

Yorkfield: 214mm2

The 8MB of additional cache over Q8200 means we can deduct 48mm2 out of the total die, leaving us with 166mm2.

I didn't see anyone to reply to me that the memory controller and the pci-express will not be on the CPU die this time.

I did not know. By the time it was pretty widely known so I assumed you did. I'm sorry.

 

[MODEL3]

Originally posted by: ilkhan

Originally posted by: MODEL3
I must have missed this info.

But i guess many others must have missed this info also, since nobody replied me that the memory controller was on the GPU die.
Do you know if the new info, regarding PCI-express being on the GPU die also, is true?

Well if youd like to do your own analysis, we have a few die shots to help you along.
bloomfield: http://img12.imageshack.us/img...emdiecallout715523.jpg
lynnfield: http://img193.imageshack.us/im...ynnfielddie7164463.jpg
clarkdale (CPU): http://img33.imageshack.us/img33/7448/core7183260.jpg

I made some lines on the die to separate some stuff. http://img85.imageshack.us/img85/7448/core7183260.jpg Top middle is cache, lower middle are the cores. The right seems to be the mem controller. The left...not sure about. But it looks a WHOLE lot like a QPI link to me. (look/compare at the QPI0 on the bloomfield shot).

Thanks for the photos.
It is very difficult with these photos to figure out everything (unless it is my old CRT :laugh: oh, my eyes )
About the QPI comment that you made, i think it is possible the IGP die to communicate with the CPU die with a QPI link, but with these photos it's hard to tell exactly where it is.

 

[Idontcare]

Originally posted by: ilkhan
The right seems to be the mem controller.

That wouldn't be present in clarkdale die, right? I'm guessing its the PCU among other Misc IO.

The uncore to core area ratio is crazy in clarkdale, core area is a mere 44% of the total die area.

 

[MODEL3]

Originally posted by: IntelUser2000
I actually am the one that disagreed that Clarkdale will end up near 80mm2 rather than 100mm2. Some info came that refuted me that turned me around, but I'm pretty sure about this. Anyway I can't find it so its still speculative.

Q8200 die info is from Hans: http://www.chip-architect.com/...19_Various_Images.html

According to Hans, the cores take 22mm2 each and L2 SRAM takes 6.0mm2/MB, but the core size isn't really useful except for figuring out the not-so-common info like the "misc".

In Penryn, core: 22.0mm2(but for the sake of this conversation isn't very useful), L2 SRAM: 6.0mm2/MB

Yorkfield: 214mm2

The 8MB of additional cache over Q8200 means we can deduct 48mm2 out of the total die, leaving us with 166mm2.

I didn't know about this site.
The thing is that Intel is saying in their site that:

6MB cache Q9400 die size=4MB cache Q8400 die size=164mm2.
So the Q8200 must be based on the same Q9400 die with 2MB cache disabled.

Like I said in my earlier post the 12MB cache Q9450 die size=214mm2.
I suppose the difference between Q9450 & Q9400 is the cache.

So 6MB cache=50mm2. (or very close to that figure)
So 2MB cache=16,7mm2. (1MB cache=8,3mm2)
So a 45nm Q8200 with only 4MB cache (instead of 6MB cache with 2MB cache disabled) will be 147,3mm2.

If you check older 65nm Core 2 the analogy is the same.

4MB cache E6600=143mm2
2MB cache E4600=111mm2
So 2MB cache=32mm2 (1MB 16mm2)
So for 1MB the scaling is correct (65nm 16mm2 and 45nm 8,3mm2, Intel nearly achieved the theoritical possible scaling since it's cache)

Originally posted by: IntelUser2000

I didn't see anyone to reply to me that the memory controller and the pci-express will not be on the CPU die this time.

I did not know. By the time it was pretty widely known so I assumed you did. I'm sorry.

Sorry, my mistake, i didn't know this info, that's why i wrote that: the Clarkdale will have bigger CPU die than a 32nm 8200 because of the memory controller and the PCI-express.

 

[IntelUser2000]

Let me take a guess.

Left Side: MISC I/O at bottom and PCU at top(The PCU is a pure guess. Only part that doesn't seem to have a replica and has to be either I/O or something else)
Right Side: QPI

The memory controller, PCI Express controller, FDI link, QPI link(another one to communicate with CPU), DMI link is all on the GMCH.

It has to include QPI as information leaked earlier said there's a communication link between the CPU die and GMCH die. Sure its not going to be 2GB/s DMI. XD

It looks like the I/O portion didn't scale as well as the SRAM. Which is expected as the scaling is supposed to be even worse than CPU core logic.

 

[IntelUser2000]

Originally posted by: MODEL3

4MB cache E6600=143mm2
2MB cache E4600=111mm2
So 2MB cache=32mm2 (1MB 16mm2)
So for 1MB the scaling is correct (65nm 16mm2 and 45nm 8,3mm2, Intel nearly achieved the theoritical possible scaling since it's cache)

The SRAM logic itself isn't that big. There might have been additional area optimizations Intel has done on the 2MB part. The 90nm Prescott had L2 cache size that's 16mm2/MB.

It depends on Intel engineers I guess. If they do a rush job either can end up bigger.

Originally posted by: Idontcare

Originally posted by: ilkhan
The right seems to be the mem controller.

That wouldn't be present in clarkdale die, right? I'm guessing its the PCU among other Misc IO.

The uncore to core area ratio is crazy in clarkdale, core area is a mere 44% of the total die area.

The funny thing is even that's nothing compared to Nehalem EX.

 

[MODEL3]

Originally posted by: IntelUser2000

Originally posted by: MODEL3

4MB cache E6600=143mm2
2MB cache E4600=111mm2
So 2MB cache=32mm2 (1MB 16mm2)
So for 1MB the scaling is correct (65nm 16mm2 and 45nm 8,3mm2, Intel nearly achieved the theoritical possible scaling since it's cache)

The SRAM logic itself isn't that big. There might have been additional area optimizations Intel has done on the 2MB part. The 90nm Prescott had L2 cache size that's 16mm2/MB.

It depends on Intel engineers I guess. If they do a rush job either can end up bigger.

Why are you saying this? ("There might have been additional area optimizations Intel has done on the 2MB part")
Is it because the E6600 is E6XXX series and the E4600 is 4XXX series?

 

[ilkhan]

IDC: good point. Not sure what else it could be though. PCU is only a million transistors, thatd be pretty small on the die 300-400+M transistor die (do we have a transistor count yet?).
Intel: DMI probably falls under the PCI-E controller portion, as DMI is a PCI-E link. The rest of your analysis looks good though.
Whats the "queue" portion of the bloomfield die for?
Anybody else wondering why they spent the transistor budget on 2 QPI links (one per die) instead of putting the whole thing on one die? edit: Id guess it has to do with timing and being a first gen fusion part, but still seems silly to me. Maybe they tried to do a 32nm design and couldn't get it done in time? AFAIK the 45nm die is a direct copy from their havendale/auburndale efforts.

I worked this up in paint, just copy/paste from the other pictures. The core sizes are roughly the same, so if its not exactly to scale it should be fairly close. http://img38.imageshack.us/img...ynnfielddie7164463.jpg

 

[Idontcare]

Originally posted by: IntelUser2000
It looks like the I/O portion didn't scale as well as the SRAM. Which is expected as the scaling is supposed to be even worse than CPU core logic.

Yeah, IO scales poorly but its kind of a self-fulfilling prophecy because the IO components themselves tend to receive very little priority or resources in a node development to further their shrinkage versus other more high-profile components like sram and M1 min pitch.

So the perception over time becomes "IO doesn't scale well" when the reality on the ground at the node development level is "there is negligable priority to emphasize IO scaling...so the IO isn't going to scale well for this node because of our priorities".

Its a cart before the horse kind of thing, not that any of it matters, the bottom line is that regardless the fundamental reasoning why it is this way you can generally always count on IO circuits scaling less aggressively than just about every other circuit component on the chip.

Originally posted by: IntelUser2000
It depends on Intel engineers I guess. If they do a rush job either can end up bigger.

Rush job (meaning timeline constraint), or could be routine job with relaxed risk initiative (low-risk to timeline for deliverables being prioritized), or could be intentionally low-resourced (get done whatever you can with 10 man-yrs worth of labor resources) from the outset.

We never really know what tradeoffs were intentionally made that set the initial conditions and boundary conditions which resulted in any given IC's final specs at the market, heck even the individual engineers working on the very project in question would not likely have been in the meetings where the tradeoffs were discussed and downselected. You are familiar with the engineers and mushrooms joke, are you not?

(Q: How are engineers and mushrooms alike?
A: They are both kept in the dark and fed shit for nourishment...)

 

[IntelUser2000]

Originally posted by: MODEL3

Why are you saying this? ("There might have been additional area optimizations Intel has done on the 2MB part")
Is it because the E6600 is E6XXX series and the E4600 is 4XXX series?

If you take a look at the Penryn dual core die, you'll notice some empty spots. http://www.chip-architect.com/...19_Various_Images.html

This is same with most processors. It might be done to add more features later on(like on a die shrink).

The difference between E6600 and E4600 does make it look like each 1MB of cache takes 16mm2, but if one assumes that's true for every processor and estimates the die size, it'll never come even remotely close to the actual size.

You know, the half cache parts sometimes have for example less associativity(4 way instead of 8 way). That would make it smaller than if they didn't change the associativity.

But if you look at NOTHING ELSE other than just the size of the SRAM, each MB of cache takes much less than die size differences suggest.

 

[Idontcare]

Originally posted by: ilkhan
IDC: good point. Not sure what else it could be though. PCU is only a million transistors, thatd be pretty small on the die 300-400+M transistor die (do we have a transistor count yet?).

We don't but it wouldn't be too far off from simple xtor count of the relevant components in a bloomfield, right? Since we aren't looking at any major (and not many minor) architecture or ISA changes and no cache changes.

Here's Hans de Vries' Shanghai and Nehalem annotated diemaps, for some reason they aren't linked to his frontpage. (<- that's more for Model3, I've no doubt you've got your own tucked away somewhere )

Originally posted by: ilkhan
IDC: good point. Not sure what else it could be though. PCU is only a million transistors, thatd be pretty small on the die 300-400+M transistor die (do we have a transistor count yet?).
Intel: DMI probably falls under the PCI-E controller portion, as DMI is a PCI-E link. The rest of your analysis looks good though.
Whats the "queue" portion of the bloomfield die for?
Anybody else wondering why they spent the transistor budget on 2 QPI links (one per die) instead of putting the whole thing on one die? edit: Id guess it has to do with timing and being a first gen fusion part, but still seems silly to me. Maybe they tried to do a 32nm design and couldn't get it done in time? AFAIK the 45nm die is a direct copy from their havendale/auburndale efforts.

I worked this up in paint, just copy/paste from the other pictures. The core sizes are roughly the same, so if its not exactly to scale it should be fairly close. http://img38.imageshack.us/img...ynnfielddie7164463.jpg

I'm thinking we got the QPI deal mixed up here guys...its not 2 QPI links, we are looking at the uplink being located in a physically seperate part of the die from the QPI downlink. Look at Hans' nehalem diemap linked above.

 

[ilkhan]

gar. I need a 3rd monitor and all to be bigger! You're bloomfield link is better than mine, but the differences in the very center of the bottom (between the two cache blocks) is a significant difference. I wonder which is correct.
Nobody here is saying theres two QPI links, we're saying one on the CPU die and one on the GPU die.
The bottom left structure is significantly differently sized than the uppper right structure. If one was in and the other out, they'd be about the same size, no? And what would be the benefit to having them at different locations? That just seems...off to me.

I think we agree on the cache and core structures, they're obvious. The size and number and function of the other 3/4/5 structures are whats confusing us.

Anybody want/able to jump onto skype/MSN/AIM/IRC and throw some ideas around?

 

[MODEL3]

Originally posted by: IntelUser2000

Originally posted by: MODEL3

Why are you saying this? ("There might have been additional area optimizations Intel has done on the 2MB part")
Is it because the E6600 is E6XXX series and the E4600 is 4XXX series?

If you take a look at the Penryn dual core die, you'll notice some empty spots. http://www.chip-architect.com/...19_Various_Images.html

This is same with most processors. It might be done to add more features later on(like on a die shrink).

The difference between E6600 and E4600 does make it look like each 1MB of cache takes 16mm2, but if one assumes that's true for every processor and estimates the die size, it'll never come even remotely close to the actual size.

You know, the half cache parts sometimes have for example less associativity(4 way instead of 8 way). That would make it smaller than if they didn't change the associativity.

But if you look at NOTHING ELSE other than just the size of the SRAM, each MB of cache takes much less than die size differences suggest.

If i had to guess, the 6mm2 figure (Penryn case) is for 1MB L2 cache only.
Don't you have to add in the L2 die space, the transistor space of the write buffers?

But anyway let's focus on the Nehalem diagram that IDC provided.

In the diagram of the Nehalem architecture that IDC gave, it is 5.7mm2 L3 die size per MB and this does not include the die size of the write buffers per tile imo.

So if you add the die size of the write buffers (it's per tile) it seems to me that it is around 7mm2/MB.

Now in addition to the write buffers, there may be additional transistors that we must add in the design in order the design to take advantage of the extra cache (just a guess) (or even communicate with the extra cache).

So the 8mm2 die space/MB could be a possible scenario for L3 die+write buffer die+die of additional transistors.

IDC what do you think?

 

[Idontcare]

Originally posted by: ilkhan
gar. I need a 3rd monitor and all to be bigger! You're bloomfield link is better than mine, but the differences in the very center of the bottom (between the two cache blocks) is a significant difference. I wonder which is correct.

Naturally they both are...what we are undoubtedly looking at are two dieshots of nehalem at different stages in the process flow.

Different metalization levels (or even possible somewhere in the FEOL) having been last added to the top of the chip prior to the photo being taken.

Originally posted by: ilkhan
Nobody here is saying theres two QPI links, we're saying one on the CPU die and one on the GPU die.

Doh! I failed at reading. I see what you meant now.

Let me address - the IMC and PCIe components entail a reasonable amount of customized SOC circuitry that actually takes quite a bit of effort (manpower and time) to validate when implemented in new process tech...this is true for AMD as well which is why their IMC tends to dominate the headlines anytime a new node release approaches...so it really stands to reason that if you can get away with recycling known-valid IC layouts for the PCIe and IMC as implemented in 45nm process tech then your time to market for the 32nm chips would be all the less jeopardized come silicon validation time for Clarkdale.

Less things to go wrong, less thing to need to allocate budget to properly resource for addressing in advance so they don't go wrong, etc.

Somewhere in the depths of Intel sits a computer folder full of FEMA's on implementing IMC and PCIe on 32nm Clarkdale versus the costs/risks benefits analysis of keeping it in 45nm silicon off-die and adding the expense of a QPI link on both MCM'ed ICs.

Apparently the end results of those FEMAs was that doing the latter was a better risk/benefits ratio than doing the former for Clarkdale timeline.

Consider for instance that while we know gulftown silicon is already out in the wild, generating leaked benches and what not, it won't be thoroughly validated and market ready till about 3 months after Clarkdale's release.

Originally posted by: ilkhan
The bottom left structure is significantly differently sized than the uppper right structure. If one was in and the other out, they'd be about the same size, no? And what would be the benefit to having them at different locations? That just seems...off to me.

Let me look at it more in depth, my evening coffee hasn't thoroughly eliminated the effects of afternoon cocktail hour.

Originally posted by: ilkhan
Anybody want/able to jump onto skype/MSN/AIM/IRC and throw some ideas around?

See above

edit: fixed numerous spelling and grammar errors, once again, see above

 

[Idontcare]

Originally posted by: ilkhan
I think we agree on the cache and core structures, they're obvious. The size and number and function of the other 3/4/5 structures are whats confusing us.

How's this looking?

http://i272.photobucket.com/al...o_bucket/clarkdale.jpg

I'm pretty sure I butchered your nomenclature as to the designations of structures 3/4/5...I couldn't quite figure out which die photo you were referencing in which this labeling scheme was used.

Feel free to cut'er up and repost the image if it helps to do so.

The QPI is definitely on the upper-right in that clarkdale dieshot. I'm guessing the mass of NB circuitry is what we are looking at all along the left hand side (areas 2 and 3 as I labeled them) and the fusebank and gen IO is in the lower right (labeled 1 in that photo above)?