pincount for kentsfield

[Aexoth]

ok, According to TGDaily The upcoming Kentsfield processor will work on current Conroe motherboards. If I'm not mistaken the current Conroe motherboards sport socket 775, which is appropriately named as it has a pincount of 775.

My question is, will this not pose a serious bottleneck for the kentsfield processor? 775/4=193.75, So this should mean that each core can't have more than 193 pins routed to it.

The Athalon processors used 462 pins since the 500mhz era, and the Pentium IIIs had 370.

For a core this advanced and fast, something seems fishy with only having 193 pins.

Is there something I'm not considering or is this potentially a problem for the Kentsfield generation of processors?

-tenobu

 

[Newf]

...My question is, will this not pose a serious bottleneck for the kentsfield processor?...Is there something I'm not considering or is this potentially a problem for the Kentsfield generation of processors?
-tenobu

Nope. Should not be a problem. Plenty of bandwidth is available.

 

[Mex]

ok, According to TGDaily The upcoming Kentsfield processor will work on current Conroe motherboards. If I'm not mistaken the current Conroe motherboards sport socket 775, which is appropriately named as it has a pincount of 775.

My question is, will this not pose a serious bottleneck for the kentsfield processor? 775/4=193.75, So this should mean that each core can't have more than 193 pins routed to it.

The Athalon processors used 462 pins since the 500mhz era, and the Pentium IIIs had 370.

For a core this advanced and fast, something seems fishy with only having 193 pins.

Is there something I'm not considering or is this potentially a problem for the Kentsfield generation of processors?

-tenobu

I disagree.

First: Kentsfield is actually two Conroe cores on one die. Since Conroe is two cores linked together, they can be counted as one core. Therefore, by your logic the four cores (the two Conroe cores) actually have 387 pins to them.

However, that's not the point. I'm going to look for a pinout diagram to make sure that I am right is saying this, but most of the pins in the arrays aren't even used. The CPU needs some pins for power and data transfer, but most of the pins are actually grounding pins to prevent crosstalk between individual pins. In a LGA, gounding pins would be even more important, sice the pins are closer together.

That's all I have to say.

EDIT: I found my pinout diagram. Zoom down to page 43.
http://download.intel.com/design/Pe...f#search="775 Land Grid Array Pinout Diagram"

When you look at the diagram, a significant portion of the pins are marked as 'VSS.' On page 73, these pins are defined:

VSS - VSS are the ground pins for the processor and should be connected to the system ground plane.

 

[Aexoth]

If they are daisy chained, then correct me if I'm wrong but, in an intense multi-threaded application core 1 would be sent all the data, determine it could process about 25% of it, then send the remaining to core 2, which would be able to process 33% of the remaining 75% (25% of the original 100%) and then this pattern would continue down the chain. This would resolve the potential pincount issue.

However now it becomes a bandwidth issue of the bus. In multi-threaded applications we can expect a theoretical linear increase in speed. 2 cores of the same speed, in best case scenario, can run the application twice as fast (I know this isn't exactly the case.) This would mean that 4 2.67Ghz cores could function as well as a single (4x2.67=) 10.67Ghz processor.

This means the bus speed is about 1/10th of the effective processor speed, and would be the same as running a Pentium III 1Ghz on a 100Mhz fsb. I know the bus was becoming a serious issue for high speed PIIIs as well as Athalon XPs (the thoroughbreds and bartons,) and they had buses that were a greater fraction of the CPU speed than 1/10th.

Now I know that the frequency of a data line does not directly translate into data bandwidth, so the 1066Mhz bus of a Conroe is probably more efficient than the bus of the Athalon XP. However the efficiency of the Conroe has also been greatly increased since Athalon XP days, and if they scaled at the same rate we have the same problem on our hands that the earlier generations of processors had.

I am not saying that I firmly believe Kentsfield will be bus limited, I am just questioning at the issue.

I suppose the only way we will see it is Monday when the Kentsfield benchmarks are released.

 

[joset]

If they are daisy chained, then correct me if I'm wrong but, in an intense multi-threaded application core 1 would be sent all the data, determine it could process about 25% of it, then send the remaining to core 2, which would be able to process 33% of the remaining 75% (25% of the original 100%) and then this pattern would continue down the chain. This would resolve the potential pincount issue.

However now it becomes a bandwidth issue of the bus. In multi-threaded applications we can expect a theoretical linear increase in speed. 2 cores of the same speed, in best case scenario, can run the application twice as fast (I know this isn't exactly the case.) This would mean that 4 2.67Ghz cores could function as well as a single (4x2.67=) 10.67Ghz processor.

This means the bus speed is about 1/10th of the effective processor speed, and would be the same as running a Pentium III 1Ghz on a 100Mhz fsb. I know the bus was becoming a serious issue for high speed PIIIs as well as Athalon XPs (the thoroughbreds and bartons,) and they had buses that were a greater fraction of the CPU speed than 1/10th.

Now I know that the frequency of a data line does not directly translate into data bandwidth, so the 1066Mhz bus of a Conroe is probably more efficient than the bus of the Athalon XP. However the efficiency of the Conroe has also been greatly increased since Athalon XP days, and if they scaled at the same rate we have the same problem on our hands that the earlier generations of processors had.

I am not saying that I firmly believe Kentsfield will be bus limited, I am just questioning at the issue.

I suppose the only way we will see it is Monday when the Kentsfield benchmarks are released.

Actually, four 2.66GHz cores don't add up to a single 10.68GHz core (much like adding up more outboard motors with identical HP to a boat, do not increase the boat's speed... I believe you already know this, anyway).
I just wanted to stress this point up, since it's important for the bus-dependent latency, regarding the current chip (& any n-core chip).
In my opinion, as long as Intel can keep its latency-hiding shared cache and advanced prefetchers working as planned (http://download.intel.com/technology/architecture/sma.pdf), they will not need to implement a new memory interconnect so soon. The biggest problem I can see with this implementation (a two dual-core die in a MCM package), is the contention between the two chips' non-shared L2 cache (and non-"linked" L1), even if DIB & 1333MHz FSB are to be implemented in upcoming versions of Kentsfield/Clovertown...

As a side note (and more related to the subject), most package substrate pins are used as power/ground and to avoid "crosstalk" between them; certainly, this will become a major issue as pins become closer together.

(Outdated but worth reading: IDF EMEA, Cairo 2006: http://idfemea.intel.com/2006/cairo/download/DE03.pdf#search="kentsfield clovertown bus width").


Cheers!