HotChips 17 - More info upcoming on CELL & PS3

In the case of CELL, it has more cores and it's bigger it's not smaller.

 

I think the whole point has been that since each SPE is so much smaller proportionally, and is considered a functional "core", the chances of an SPE getting a defect are lower than the PPE unit, or the equivelent in the Xenon, 3 big cores are more susceptable to a defect proportionally due to their sheer size. The whole redundancy factor favours Cell, hence the 7 out of 8 SPE's to be used in functional PS3 units. Get a defect on the PPE or in one of the Xenon cores and you end up with a dead chip. The best place for a defect is in the cache, since there's always been a lot of redundancy in that area.

 

What's the defect rate of these processors' fabbing processes? 1 per 300 mm^2? 1 per 500 mm^2? We can investigate different situations (assuming perfectly uniform distribution of errors which isn't perfectly accurate but does represent the overall picture)...

At 1 in 300 mm^2:
100 1:8 Cells = 22000 mm^2 ~ 70 defects
That's 30 1:8 dies, 70 1:7 dies - 100 useable in PS3 with redundancy, 30 without redundancy

At XCPU core = 50 mm^2
22000 mm^2 = 440 cores
Tri core XCPUs = 146
Quad core XCPUs = 110

70 defects in 22000 mm^2 =
76 Tri-cores and 70 dual-core XCPUs - 76 useable in XB360
40 Quad core CPUs, 70 Tri-core CPUs or less - 110 useable in XB360 with redundancy, 40 without

​

Now let's consider 1 error per 500 mm^2...

22000 mm^2 = 100 1:8 Cells, 44 defects, producing56 1:8 Cells, 44 1:7 Cells - 100 useable in PS3 with redundancy

22000 mm^2 = 440 XCPU cores, 44 defects, producing
102 Tricores, 44 dual cores - 102 useable in XB360
66 Quad cores, 44 Tri cores - 110 useable in XB360 with redundancy, 60 without

​

And at 1 error per 150 mm^2...

22000 mm^2 = 100 1:8 Cells, 147 defects, producing0 1:8 Cells, 63 1:7 Cells and 47 1:6 or less dies - 63 useable in PS3 with redundancy

22000 mm^2 = 440 XCPU cores, 147 defects, producing
0 Tricores, 145 dual cores and 1 single core XCPU - none useable in XB360
0 Quad cores, 73 Tri cores and 37 dual cores - 73 useable in XB360 with redundancy

​

What this goes to show is that yields are determined by error frequency which is proportional to die size, and including redundancy by allowing the crippling of a core because it's not part of the chip specifications, yields are dramatically improved. If we compare 1:7 Cells (1:8 Cells in brackets) with PC-Engine's desired 4 core XCPUs, we have...

With 1 defect per 150 mm^2,Cells = 63% of yield (0% 1:8s)
XCPUs = 0% of yield

With 1 defect per 300 mm^2,
Cells = 100% of yield (30% 1:8s)
XCPUs = 36% of yield

With 1 defect per 500 mm^2,
Cells = 100% of yield (56% 1:8s)
XCPUs = 54% of yield
​

And without the 4 core design, tri-core XCPU yields are...

With 1 defect per 150 mm^2,
XCPUs = 0% of yield
With 1 defect per 300 mm^2,
XCPUs = 52% of yield

With 1 defect per 500 mm^2,
XCPUs = 70% of yield
​

As I've said, these figures don't factor in clustering of defects, where one core gets lumbered with 5 defects and 5 cores get away scot-free, but as the errors are random there won't be a lot of clustering. There's also no accounting for PPE hits in the above, or overall chip-wide components like memory interfaces that take out the whole chip. That said, all things considered there's no way 4 core XCPU's are looking viable unless defect rates are a good deal lower than 1 per 500 mm^2 (assuming 50% efficiency is too low. I don't know what a chip fab costs per mm^2 to factor in chip cost due to yields), and if that were the case 1:8 Cells would be just as viable.

 

Of course the smaller the chip the more u can fit on a wafer . Also the xenon will have been in production for a number of months before the cell enters mass production.

So the two chips will be in diffrent parts of thier lives and thus there are a slew of other factors to um factor into the problem of which would have better yields .

 

The problem isn't which will have better yields. The 'problem' is viability of a four-core XCPU which PC-Engine is adamant will have better yields than Cell because of having larger cores, to the point MS could have put a 4 core chip to go head-to-head against PS3's 1:7 Cell CPU.

 

Oh

Well in that case why bother talking ? Its pc engine ... just ignore

 

Thanks Shifty,

This thread has been bothering me for days now, I just went and did my own version of your calculations before I saw your reply. I won't reproduce now as you have made the point very well. I was a bit more conservative with cell yields after redundancy than you but even in that case it's quite easy to show that a 4 core XCPU is never likely to have more usable parts per wafer than a 1:7 cell.

 

Inspired by the calculations I went on to run computer simulations for possible gains of a using a 8:th SPE only for redundacy.
I simply randomly put defects on a (square ) 300 mm wafer. For each defect i found which die it hit and what unit of that die.
I assuemd that an infinite amont of defects could be handeled by the cache (if you have a better number please enlighten me).
If a defect hit any other units it would render the units worthless.
Any unit that isn't a SPE or the cache would render the total chip useless.

Defect rate is measured in defects per cm². Petterson & Hennessy claimed that the defect rate had a typical range of 0.4 to 0.8 defects/mm² in 2001.

Code:

defect rate | working 8 SPE | working 7 SPE | working <7 SPE | dead |
0.1         |     319       |      38       |       2        |   29 |
0.2         |     261       |      62       |       7        |   59 |
0.3         |     213       |      77       |      13        |   86 |
0.4         |     174       |      84       |      20        |  109 |
0.5         |     142       |      87       |      27        |  132 |
0.6         |     116       |      86       |      33        |  152 |
0.7         |      94       |      83       |      40        |  172 |
0.8         |      78       |      76       |      45        |  188 |
0.9         |      63       |      71       |      49        |  205 |
1.0         |      51       |      66       |      51        |  220 |

(The total sum doesn't alwas add up to the same number of dies, it is due to rounding errors.)

 

Absolutely.

The argument though that 8 cores is worse for yields than 4 cores is simply incorrect from what the others have been saying. It's not the number of cores per se - just the die size.

 

yea ty didn't get that part

 

What everyone is incorrectly assuming is die size being the sole determining factor of yields...it's not.

 

OK now PC-Engine....Please enlighten (spare no details) us.....

 

There are different types of yield models other than the Poisson Yield Model

There's also the Murphy Yield Model, Exponential Yield Model, and Seed Model.

Then there are other factors like the number of mask layers, design sensitivity, etc. It's not as cut and dry as some people think.

 

Redundancy can increase yield despite increasing die size, and no redundancy with nearly the same critical area and layers will give you lower yields ... some things are simple.

 

Sure but a bigger chip can increase the cost too ie less dies per wafer. One of the factors of yields is related to costs. You want better yields to decrease cost.

 

And you have information showing that the XCPU is using different fab technology than Cell which is why you say it can manage better yields?

All things being equal, with the two chips designed at IBM, and no information suggesting one chip is using different fabbing models, a 4 core XCPU is not viable if a 1:8 Cell isn't. If you're going to use a 'unspecified different fab techniques affects yields' argument one could argue that Cell is produced on the worst 90nm fab and gets yields 1/4 of a 4 core XCPU which is why a 4 core XCPU is possible - an argument not based on any evidence to suggest that is the case.

If you have reason to believe die size is not the only nor substantially most significant reason why XCPU will per die size manage better yields than Cell, please share with us uneducated masses.

 

I did a similar simulation (python code available upon request), but got slightly different results (but I am counting any defect outside of an SPE and on a die as dead):

Code:

defect rate | working 8 SPE | working 7 SPE | working <7 SPE |  dead  |
0.1         |     330       |      25       |       1        |  25.93 |
0.2         |     287       |      42       |       4        |  49.86 |
0.3         |     253       |      50       |       7        |  71.75 |
0.4         |     227       |      55       |      12        |  88.40 |
0.5         |     203       |      56       |      16        | 107.80 |
0.6         |     186       |      54       |      20        | 122.39 |
0.7         |     172       |      51       |      23        | 135.29 |
0.8         |     160       |      47       |      25        | 150.01 |
0.9         |     150       |      44       |      26        | 161.21 |
1.0         |     144       |      39       |      29        | 169.79 |

But the interesting thing is the resulting yields:

Code:

defect rate |  yield 8 SPE  |  yield 7 SPE  |
0.1         |     0.86      |     0.93      |
0.2         |     0.75      |     0.86      |
0.3         |     0.66      |     0.79      |
0.4         |     0.59      |     0.74      |
0.5         |     0.53      |     0.68      |
0.6         |     0.49      |     0.63      |
0.7         |     0.45      |     0.58      |
0.8         |     0.42      |     0.54      |
0.9         |     0.39      |     0.51      |
1.0         |     0.38      |     0.48      |

 

C'mon guys. Why are you feeding PC-E like this? We're up to nine pages now, most of those are filled with his nonsense. Enough is enough, yes?

 

Just admit that it's fun ok?

Anyway nobody else is talking about the hotchips conference anyway.

 

Sure, but no one ever argued that. In fact, the incorrect "cut and dry" argument turned out to be "more cores = less yield"?

But we were discussing yields, not cost per chip. I certainly wouldn't be surprised if CELL turns out to be more expensive than XeCPU but that's irrelevant to the earlier discussion.