Cell Architecture Explained Version 2

Part 1: Inside The Cell



The Cell concept was originally thought up by Sony Computer Entertainment inc. of Japan, for the PlayStation 3.  The genesis of the idea was in 1999 when Sony’s Ken Kutaragi [Kutaragi] “Father of the PlayStation” was thinking about a computer which acted like Cells in a biological system.  A patent was applied for listing Masakazu Suzuoki and Takeshi Yamazaki as the inventors in 2002 (the first version of this article covered this patent [Patent] ).

The architecture as it exists today was the work of three companies: Sony, Toshiba and IBM.  Sony and Toshiba previously co-operated on the PlayStation 2 but this time the plan was more ambitious and went beyond chips for video games consoles.  The aim was to build a new general purpose processor for a computer.  With that in mind IBM was brought in as their expertise is in computer design.

Though sold as a game console, what will in fact enter the home is a Cell-based computer. ” - Ken Kutaragi

IBM also brought it’s chip design expertise and in this case used a very aggressive approach by producing a fully custom design - the chip’s circuitry was designed by hand instead of with automated tools, very few other companies use this approach.  IBM also has the industry's leading silicon process which will be used in the manufacturing.  Sony and Toshiba bring mass manufacturing capabilities and knowledge.

Each of the three companies produces different products and these have different needs of a CPU.  Consumer electronics requires very power efficient systems, reliability and predictability.  Computer systems on the other hand (sometimes) have multiple processors, and need to be compatible across different generations.  The final Cell design incorporates features to satisfy all these needs.

To turn the ideas into a real product the the companies officially partnered in 2000 and set up a design centre in Austin, Texas in March 2001 with engineers from each of the three companies.  Development was done in 10 centres around the globe by some 400 people.

The amount of money subsequently spent on this project is vast, two 65nm chip fabrication facilities are being built at billions each, Sony has paid IBM hundreds of millions to set up a production line in East Fishkill, New York.  Then there's a few hundred million on development - all before a single chip rolls of the production lines.

Although it’s been primarily touted as the technology for the PlayStation 3, Cell is designed for much more.  Sony and Toshiba, both being major electronics manufacturers buy in all manner of different components.  One of the reasons for Cell's development is they want to save costs by building their own components.  Next generation consumer technologies such as Blu-ray, HDTV, HD Camcorders and of course the PS3 will all require a very high level of computing power and they are going to need the chips to provide it.  Cell will be used for all of these and more, IBM will also be using the chips in servers.  The partners can also sell the chips to 3rd party manufacturers [3rd party] .

The Cell architecture is like nothing we have ever seen in commodity microprocessors, it is closer in design to multiprocessor vector supercomputers.  The Cell developers have taken this kind of technology and for the first time are bringing it to your home.  The aim is produce a low cost system with a massive increase in compute performance over existing systems.  Putting such an architecture on a single chip is a huge, complex project, no other manufacturer appears to have even attempted to do anything this ambitious to date.

So, what is Cell Architecture

Cell is an architecture for high performance distributed computing.  It is comprised of hardware and software Cells, software Cells consist of data and programs (known as jobs or apulets), these are sent out to the hardware Cells where they are computed, the results are then returned.

This architecture is not fixed, if you have a computer, PS3 and HDTV which have Cell processors they can co-operate on problems.  They've been talking about this sort of thing for years of course but the Cell is actually designed to do it.  I for one quite like the idea of watching "Contact" on my TV while a PS3 sits in the background churning through SETI@home, actually this is rather unlikely as I’m not a gamer but you get the picture...

According to IBM the Cell performs 10x faster than existing CPUs on many applications.  This may sound ludicrous but GPUs (Graphical Processors Units) already deliver similar or even higher sustained performance in many non-graphical applications [GPU10] .  The technology in the Cell is similar to that in GPUs so such high performance is certainly well within the realm of possibilities.  The big difference is though that Cell is a lot more general purpose so can be usable for a wider variety of tasks.

The Cell architecture can go further though, there's no reason why your system can't distribute software Cells over a network or even all over the world.  The Cell is designed to fit into everything from (eventually) PDAs up to servers so you can make an ad-hoc Cell computer out of completely different systems.

Scaling is just one capability of the Cell architecture but the individual systems are going to be potent enough on their own.  An individual Cell is one hell of a powerful processor, they have a theoretical computing capability of 256 GFLOPS (Billion Floating Point Operations per Second) [GFLOPS] at 4GHz.  In the computing world quoted figures (bandwidth, processing, throughput) are often theoretical maximums and rarely if ever met in real life.  Cell may be unusual in that given the right type of problem they may actually be able to get close to their maximum computational figure.

This isn’t by luck or fluke, it’s by design.  The Cell’s hardware has been specifically designed to provide sufficient data to the computational elements to enable such performance.  This is a rather different approach from the usual way which is to hide the slower parts of the system.   All systems are limited by their slowest components [Amdahl's law] , Cell was designed not to have any slow components!


An individual hardware Cell is made up of a number of elements:

  1.  1 Power Processor Element (PPE).

  1.  8 Synergistic Processor Elements (SPEs).

  1.  Element Interconnect Bus (EIB).

  1.  Direct Memory Access Controller (DMAC).

  1.  2 Rambus XDR memory controllers.

  1.  Rambus FlexIO (Input / Output) interface.


The final specifications haven't been given out yet but this is what we know so far:

  1.  Capable of running at speeds beyond 4 GHz.

  1.  Memory bandwidth: 25.6 GBytes per second.

  1.  I/O bandwidth: 76.8 GBytes per second.

  1.  256 GFLOPS (Single precision at 4 GHz).

  1.  256 GOPS (Integer at 4 GHz).

  1.  25 GFLOPS (Double precision at 4 GHz).

  1.  235 square mm.

  1.  235 million transistors.

Power consumption has been estimated at 60 - 80 Watts at 4 GHz for the prototype but this could change in the production version.

Chip manufacturing is a complex process and the chips that appear at the end of the production line vary in capabilities and some have errors.  While they can go higher, because of the vagaries of manufacturing, economics and heat dissipation the Cell which will be used in the PS3 is clocked at 3.2 GHz and will have only 7 SPEs.  Cells with 6 SPEs will be used in consumer electronics.

The Power Processor Element (PPE)

The PPE is a conventional microprocessor core which sets up tasks for the SPEs to do.  In a Cell based system the PPE will run the operating system and most of the applications but compute intensive parts of the OS and applications will be offloaded to the SPEs.

As an example lets say I was running an audio synthesiser application.  The OS and most of the application would run on the PPE but the highly intensive audio generation and processing would be off-loaded to the SPEs.

The PPE is a 64 bit, "Power Architecture" processor with 512K cache.  Power Architecture is a catch all term IBM have been using for a while to describe both PowerPC and POWER processors. This type of microprocessor is not used in PCs but compatible processors are found in Apple Macintosh systems.  The PPE is capable of running POWER or PowerPC binaries.

While the PPE uses the PowerPC instruction set, it is not based on an existing design on the market today.  That is to say, it is NOT based on the existing 970 / G5 or POWER processors.  It is a completely different architecture so clock speed comparisons are completely meaningless.

The PPE is a dual issue, dual threaded, in-order processor.  Unlike many modern processors the hardware architecture is an “old style” RISC design, i.e. the PPE has a relatively simple architecture.  Most modern microprocessors devote a large amount of silicon to executing as many instructions as possible at once by executing them "out-of-order" (OOO).  This type of design is widely used but it requiring hefty amounts of additional circuitry and consumes large amounts of power.  With the PPE, IBM have not done this and have instead gone with a much simpler design which uses considerably less power than other PowerPC devices - even at higher clock rates.

This design will however have the downside of potentially having rather erratic performance on branch laden applications.  Such a simple CPU needs the compiler to do a lot of the scheduling work that hardware usually does so a good compiler will be essential.  That said, the Cell's high bandwidth memory and I/O subsystems and the PPE's high clock speed and dual threading capability may well make up for these potential performance deficiencies.

Some of the technology in the PPE has been derived from IBM's high end POWER series of CPUs, Like POWER5 the PPE has the ability to run 2 threads simultaneously.  When one thread is stalled and is waiting for data the second thread can issue instructions keeping the instruction units busy.  IBM's hypervisor technology [Hyper] is also used allowing the Cell to run multiple operating systems simultaneously.  According to IBM the Cell can run a normal OS alongside a real time OS with both functioning correctly.

Another interesting point about the PPE is that it includes support for the VMX vector instructions, (also known as "AltiVec" or "Velocity Engine").  VMX can speed up anything from financial calculations to operating system functions though it (or its PC equivalents) don't appear to be that widely used currently.  One company which does use VMX extensively is Apple who use it to accelerate functions in OS X, it would not have been a huge job for Apple to utilise the PPE in the Cell.

A lesser known feature which appears to be present is memory tags required by some of IBM's "big iron" operating systems.  I don’t know the purpose of these tags (they are optional in power architecture) but the Cell is said to be capable of running OS/400 [The400] and this requires them.  It is not confirmed these are present but if so it looks like IBM could have some interesting plans for the Cell which involve rather more than gaming...  IBM’s Unix variant, AIX is also said to be running on Cell.  (Note: none of this is confirmed).

The PPE is an interesting processor and it looks likely that similar cores will turn up in systems other than the Cell.  The CPU cores used in the XBox360 while different, appear to be derived from the same original design.

As mentioned above the PPE has been simplified compared to other desktop processors, I discuss the reasons behind this and their implications in part 4.

A 4GHz PowerPC sounds like a pretty potent processor until you realise that the PPEs are really just used as controllers in the Cell - the real action is in the SPEs:

Synergistic Processor Elements (SPEs)

Each Cell contains 8 SPEs.

An SPE is a self contained vector processor which acts as an independent processor.  They each contain 128 x 128 bit registers, there are also 4 (single precision) floating point units capable of 32 GigaFLOPS* and 4 Integer units capable of 32 GOPS (Billions of integer Operations per Second) at 4GHz.  The SPEs also include a small 256 Kilobyte local store instead of a cache.  According to IBM a single SPE (which is just 15 square millimetres and consumes less than 5 Watts at 4GHz) can perform as well as a top end (single core) desktop CPU given the right task.

*This is counting Multiply-Adds which count as 2 instructions, hence 4GHz x 4 x 2 = 32 GFLOPS.

32 X 8 SPEs = 256 GFLOPS

Like the PPE the SPEs are in-order processors and have no Out-Of-Order capabilities.  This means that as with the PPE the compiler is very important.  The SPEs do however have 128 registers and this gives plenty of room for the compiler to unroll loops and use other techniques which largely negate the need for OOO hardware.


Vector Processing

The SPEs are vector (or SIMD) [Vector] processors.  That is, they do multiple operations simultaneously with a single instruction.  Vector computing has been used in supercomputers since the 1970s (the Cray 1 was one of the first to use the technique) and modern CPUs have media accelerators (e.g. MMX, SSE, VMX / AltiVec) which work on the same principle.  Each SPE is capable of 4 X 32 bit operations per cycle (8 if you count multiply-adds).  In order to take full advantage of the SPEs, the programs running will need to be "vectorised", this can be done in many application areas such as video, audio, 3D graphics, scientific calculations and can be used at least partially in many other areas.

Some compilers can “autovectorise” code, this involves analysing code for sections which can utilise a vector processor and needs no involvement from he developer.  This can deliver considerable performance improvements and as such is an area of active research and development, v4.0 of the open source GCC compiler includes some of this functionality [GCC] .


The SPE's instruction set is similar to VMX / AltiVec but not identical.  Some instructions have been removed and others added, the availability of 128 registers also makes a considerable difference in what is possible.  Some changes are the addition of 64 bit floating point operations and program flow control operations as well as the removal of integer saturation rounding.

Another one of the differences is between the double and single precision capabilities.  The double precision calculations are IEEE standard whereas the single precision are not.  By not using IEEE standards the single precision calculations can be calculated faster, this feature appears to have been derived from the PS2 which did the same.

Despite these differences, according to IBM, by making some relatively minor changes and taking into account the SPE's local stores, software should compile to either an SPE or PowerPC (+ VMX) target.  That said the binary code used is different so existing AltiVec binaries will not work.

Double Precision FLOPS

Double precision (64 bit) floating point data types are used when dealing with very large or small numbers or when you need to be very accurate.  The first version of Cell supports these but the implementation shares the computation area of the single precision floating point units.  Sharing these means the designers have saved a lot of room but there is a performance penalty, the first generation Cell can "only" do around 25 dual precision GFLOPS at 4 GHz.  The first generation however are designed for the PS3 where high double precision operations are not necessary.  IBM have alluded to the possibility that a later generation will include full speed dual precision floating point units from which you can expect a very sizeable performance boost.

SPE Local Stores

One way in which SPEs operate differently from conventional CPUs is that they lack a cache and instead use a “Local Store”.  This potentially makes them (slightly) harder to program but they have been designed this way to reduce hardware complexity and increase performance.  That said, if you use vector units and take account of the cache when you program a conventional CPU, developing optimised code for the SPE may actually be easier as you don’t need to worry about cache behaviour.

Conventional Cache

Conventional CPUs perform all their operations in registers which are directly read from or written to main memory.  Operating directly on main memory is hundreds of times slower than using registers so caches (a fast on chip memory of sorts) are used to hide the effects of going to or from main memory.  Caches work by storing part of the memory the processor is working on.  If you are working on a 1/2 MB piece of data it is likely only a small fraction of this (perhaps a couple of thousand bytes) will be present in cache.  There are kinds of cache design which can store more or even all the data but these are not used as they are too expensive, too slow or both.

If data being worked on is not present in the cache, the CPU stalls and has to wait for this data to be fetched.  This essentially halts the processor for hundreds of cycles.  According to the manufacturers, It is estimated that even high end server CPUs such as POWER, Itanium and PA-RISC (all with very large, very fast caches) spend anything up to 80% of their time waiting for memory.

Dual-core CPUs will become common soon and desktop versions have a cache per core.  If either of the cores or other system components try to access the same memory address, the data in the cache may become out of date and thus needs updated (made coherent).  Supporting this requires logic and takes time and in doing so this limits the speed that a conventional system can access memory and cache.  The more processors there are in a system the more complex this problem becomes.  Cache design in conventional CPUs speeds up memory access but compromises are required to make it work.

SPE Local Stores - No Cache?

To solve the complexity associated with cache design and to increase performance the Cell designers took the radical approach of not including any.  Instead they used a series of 256 Kbyte “local stores”, there are 8 of these, 1 per SPE.  Local stores are like cache in that they are an on-chip memory but the way they are constructed and act is completely different.  They are in effect a second-level register file.

The SPEs operate on registers which are read from or written to the local stores.  The local stores can access main memory in blocks of 1Kb minimum (16Kb maximum) but the SPEs cannot act directly on main memory (they can only move data to or from the local stores).

By not using a caching mechanism the designers have removed the need for a lot of the complexity which goes along with a cache and made it faster in the process.   There is also no coherency mechanism directly connected to the local store and this simplifies things further.

This may sound like an inflexible system which will be complex to program but it’ll most likely be handled by a compiler with manual control used if you need to optimise.

This system will deliver data to the SPE registers at a phenomenal rate.  16 bytes (128 bits) can be moved per cycle to or from the local store giving 64 Gigabytes per second, interestingly this is precisely one register’s worth per cycle.  Caches can deliver similar or even faster data rates but only in very short bursts (a couple of hundred cycles at best), the local stores can each deliver data at this rate continually for over ten thousand cycles without going to RAM.

One potential problem is that of “contention”.  Data needs to be written to and from memory while data is also being transferred to or from the SPE’s registers and this leads to contention where both systems will fight over access slowing each other down.  To get around this the external data transfers access the local memory 1024 bits at a time, in one cycle (equivalent to a transfer rate of 0.5 Terabytes per second!).  

This is just moving data to and from buffers but moving so much in one go means that contention is kept to a minimum.

In order to operate anything close to their peak rate the SPEs need to be fed with data and by using a local store based design the Cell designers have ensured there is plenty of it close by and it can be read quickly.  By not requiring coherency in the Local Stores, the number of SPEs can be increased easily.  Scaling will be much easier than in systems with conventional caches.

Local Store V’s Cache

To go back to the example of an audio processing application, audio is processed in small blocks so to reduce any delay as the human auditory is highly sensitive to this.  If the block of audio, the algorithm used and temporary blocks can fit into an SPE’s local store the block can be processed very, very fast as there are no memory accesses involved during processing and thus nothing to slow it down.  Getting all the data into the cache in a conventional CPU will be difficult if not impossible due to the way caches work.

It is in applications like these that the Cell will perform at its best.  The use of a local store architecture instead of a conventional cache ensures the data blocks can be hundreds or thousands of bytes long and they can all be guaranteed to be in the local store.  This makes the Cell’s management of data fundamentally different from other CPUs.

The Cell has massive potential computing power.  Other processors also have high potential processing capabilities but rarely achieve them.  It is the ability of local stores to hold relatively large blocks of data that may allow Cells to get close to their maximum potential.

Local stores are not a new invention, in the early 1990s the AT&T DSP Commodore were planning on using in a never released Amiga included a “visible cache”.  They go back further though, a local store type arrangement was used in the 1985 Cray 2 supercomputer.

Locking Cache

The PPE as a more conventional design does not have a local store but does include a feature called a “locking cache”.  This stops data in parts of the cache being overwritten allowing them to act like a series of small local stores.  This is used for streaming data into and out of the PPE or holding data close that is regularly needed.  If the locked part acted like a normal cache the data being held could get flushed out to main memory forcing the PPE to stall while it was being retrieved, this could cause performance to plummet in some instances (a memory read can take hundreds of cycles).

Locking caches are common in embedded processors, Intel’s XScale and the XBox360’s [Xbox360] CPUs include them as do modern G3 and G4s. They are not generally included in desktop processors due to their more general purpose nature.  Using cache locking in a desktop environment could prove catastrophic for performance as applications working on data close to that locked would not be able to use the cache at all.  It is possible to achieve similar results with clever programming tricks and this is a much better idea in a multitasking environment.

In Part 2...

SPEs can also be chained, that is they can be set up to process data in a stream using multiple SPEs in parallel.  In this mode a Cell may approach its theoretical maximum processing speed of 256 GigaFlops.

In part 2 I shall look at this, the rest of the internals of the Cell and other aspects of the architecture.

Introduction and Index

Part 1: Inside The Cell

Part 2: Again Inside The Cell

Part 3: Programming the Cell

Part 4: Revenge of the RISC

Part 5: Conclusion and References

© Nicholas Blachford 2005.