8

At the heart of the PlayStation 2 were a pair of custom chips, described in https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications

CPU: MIPS III R5900-based "Emotion Engine", clocked at 294.912 MHz (299 MHz on newer versions), with 128-bit SIMD capabilities[4][5] 250 nm CMOS manufacturing (ending with 65 nm CMOS), 13.5 million transistors, 225 mm² die size,[6] 15 W dissipation (combined EE+GS in SCPH-7500x: 86 mm², 53.5 million transistors)[1] (combined EE+GS+RDRAM+DRAM in SCPH-7900x ended with 65 nm CMOS design)[7]

Parallel rendering processor with embedded DRAM "Graphics Synthesizer" (GS) clocked at 147.456 MHz 279 mm² die (combined EE+GS in SCPH-7500x: 86 mm², 53.5 million transistors)

Both custom chips; from a design perspective it would've been as easy – indeed, slightly easier – to merge them into one chip at the start, as was done in a later revision of the hardware. Presumably there was a reason for not doing this at the start.

In the calculation of yield of chips from a wafer, there is an exponential term; basically, if a chip gets too large, it starts becoming exponentially unlikely to get a chip with zero defects.

The initial versions of the CPU and GPU above were over 200 mm², which is quite large. Conjecture: making them initially a single chip would have resulted in substantially diminished yield.

Was that the reason, or was there another factor?

2
  • 4
    If the chips didn't exist yet in their final form, it is faster to develop them separately. Merging two known designs are easier than merging two designs in development. Jan 31, 2020 at 14:51
  • 1
    Plus I bet it's less of a gamble, if you can get by without another custom ASIC, if you don't yet know how well the PS2 is going to do in the market Jan 31, 2020 at 16:18

4 Answers 4

10

The initial versions of the CPU and GPU above were over 200 mm², which is quite large. Conjecture: making them initially a single chip would have resulted in substantially diminished yield.

Being already at the upper end what can be done

A Pentium III (Coppermine) of that time had about 10M transistors and ~100 mm², so a die with more than 200 mm² was most definite at the upper end of what could be done with reasonable expectation of success. Doubling this might have been past what could have done at that time.

Increasing absolute yield rate

Chip fault rate goes not linearly, but exponentially with size. But already when assuming a constant defect rate per wafer, doubling the size will double the fault rate as faults are now be distributed among half the dies.

Example:

  • Let's assume two dies of 250 mm² each or one die of 500 mm²
  • If a wafer offers 25.000 mm², it gives 100/50 dies (*1)
  • If the process has an average of 10 defects, then 10 dies are dead (*2)
  • For the 250 mm² die this gives 90% yield
  • For the 500 mm² die this gives 80% yield

Doing two wafers, one with each, will result in 90+90 good chips enabling the build of 90 machines, while doing the same two with double sized chips gives 40+40 good chips for 80 machines. It's easy to see that doing multiple chips will increase yield and decrease cost per chip.

Was that the reason, or was there another factor?

Reducing development complexity

It saves resources in development to do multiple chips, as that not only reduces complexity a lot but also allows independent schedules for both. This may sound counter-intuitive at first, as they both have to finish before the machine can be built. But it allows each project to advance at their own pace for interim milestones while a common die would need to interlink every step and iteration. A classic problem of complex developments. When looking at development like production, it's much like before: yield is increased by reducing dependence.


*1 - Simplified by ignoring cut areas and the like.

*2 - Simplified by assuming even distribution.

3

One possible reason could be the production discard:

Let's assume 1 of 1000 CPUs produced is defective and the same is the case for the GPUs.

Then 1000 of one million ICs are defective when producing the ICs separately.

If you place the CPU and the GPU on the same IC, there are:

  • One IC in one million that have both a defective CPU and a defective GPU
  • 999 ICs in million that have a working CPU but a defective GPU
  • 999 ICs in million that have a defective CPU but a working GPU

All in all 1999 of one million ICs are defective.

This is nearly twice the number of defective ICs compared to producing CPU and GPU separately.

On the other hand producing one large IC is cheaper than producing two smaller ICs (due to the costs of the IC housing and the soldering costs) if you don't consider the production discard.

If your production line produces many defective ICs, producing two ICs will be cheaper because you have less defective ICs; if your have a production line that only produces a few defective ICs, producing one large chip will be cheaper.

Maybe the quality of the IC production could be improved during the time when the PlayStation was sold, so there were less defective ICs produced.

2

Looking at the figures given, the GS by itself appears to have 40 million transistors @280 mm². That's a density about double that of the EE. This isn't unusual; CPUs are known to have a fairly low transistor density compared to other more regular chips.

But putting an extra 40 million transistors on the EE die, using the same process, would have quadrupled its area, to 900 mm². The accepted answer only assumed a 500mm² die, and that would be bad enough.

2

To develop two parts separately is much easier than to develop one big IC. You can use two more or less independent teams. The development cycle is cheaper and faster with smaller chips.

Once the designs are settled, you can start to manufacture prototypes or the first series, and the "integration process" can run in the background.

1
  • 2
    There is some overhead to designing separate ICs, in that the team need to design the connection between the two (physically, electrically and at the information level). That means that splitting isn't always a win, particularly when iterating an existing design. Jul 27, 2021 at 9:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .