Welcome to the most recognisable and innovative part of this console.
Introduction
The PS3's CPU is massively complex, but it's also a very fascinating work of engineering that intersects complex needs and unusual solutions, prominent in an era of change and experimentation. So, before we step into the internals of the PS3's CPU, I wrote the following paragraphs to bring some historical context into the article. That way, we'll be able to decompose the chip from top to bottom in a way that not only will you understand how this chip works, but also get the reasoning behind major design decisions.
The state of progress
The PS1's CPU (1994). Designed by LSI and Sony, using MIPS' technology.
The PS2's Emotion Engine (2001). Designed by Toshiba, with MIPS' technology, again.
Almost ten years after the introduction of the original MIPS-powered PlayStation, we find ourselves in the early noughties, and things are not looking good for SGI/MIPS. Nintendo recently ditched them for a low-end PowerPC core with IBM as their new supplier while Microsoft, the newcomer in this market, chose Intel and their x86 empire.
Sony has a history of grabbing existing low-end designs (cheap MIPS cores) and moulding them to achieve acceptable 3D performance at a reduced cost, a process that involved other companies like LSI (for the PS1's CPU) and Toshiba (for the PS2's Emotion Engine). This methodology carried on until 2004 with the release of the PlayStation Portable. So, what new MIPS amalgamation were they going to build for the PlayStation 3?
Well, it turns out the development of the PlayStation 3 predates the PlayStation Portable one . In 2000, months after the PS2's release, Sony formed an alliance with IBM and Toshiba called 'STI' with the sole goal to deliver the next chip that could power the next generation of supercomputers . If this didn't sound extravagant enough, the next chip would also be used on the successor of the PS2. In the end, in 2004, IBM unveiled the Cell Broadband Engine (also known as 'Cell BE' or just 'Cell') .
New design philosophies
The Cell Broadband Engine chip. Unfortunately too shiny for my camera.
To understand Cell's radical proposal, we must first take into account the problems affecting that era (late 90s-early 00s).
Every year, consumers ask for more speed. That's always been the case. However, the last approach used to solve that (pipeline the datapath and step up the clock frequency) is now failing to scale. Intel's NetBurst can't evolve any further and its promised successor is nowhere to be seen. Similarly, IBM's PowerPC 970/G5 can't deliver its '3 GHz' promise nor their low-power CPU (hence Apple can't ship any laptop carrying their last-gen CPU) . All in all, it looks like engineers have a new scalability crisis on their hands.
So, the focus turns to distributed computing . In other words, why obsess with cranking up the performance of a single machine where you could instead have multiple smaller machines distributing their workload? Conversely, this approach is anything but new, considering all of the consoles analysed on this website contain more than one processor. However, it's the development of a 'single processor with multiple cores' that opens up new opportunities for CPU design (which are not necessarily limited to the console market).
These developments are, at the same time, marred by a marketing-driven fixation on breaking the 3 GHz barrier. I presume IBM feels the pressure after watching Intel surpass it with the Pentium 4. However, the two will eventually pay with severe tradeoffs, both technical and business-wise.
In any case, Cell is part of this new wave of research and development. This new CPU combines a multi-core design with a special focus on vector processing. If you remember, vector computing is optimal for simulations (physics, lighting, etc) and it was previously materialised in the form of the Geometry Transformation Engine or the Vector Units, but you'll soon see why Cell's design is a huge step forward from the previous two.
A new multicore era
Example of heterogeneous design.
This has been the de-facto architecture of many powerful consoles to this date.
Example of homogeneous design.
Each core can carry the same tasks as before, but they are not necessarily restricted to such task.
If you stop to think about it, both the PS1's CPU and the Emotion Engine were already multi-core processors. So why was there so much fanfare about Cell? Well, the previous two chips were composed of one general-purpose core and several application-specific cores (i.e. audio processor, image decompression, etc) mixing different architectures, where the general-purpose core is in charge of commanding the others.
This type of CPU design is called Heterogeneous computing and it's been the de-facto choice for building machines that are specialised in a particular set of applications (gaming, in this case). Its counterpart, Homogeneous computing, is more predominant on the PC market, where CPUs are required to perform a wider range of tasks (and they all have the same priority). Hence, the latter type may house multiple cores, but of the same type.
Back on topic, Cell combines both models: there are two types of cores in this CPU, one general-purpose 'leader' and eight vector 'assistants'. These vector cores may take up various roles, and in doing so, they fulfil previous tasks that were originally solved by heterogeneous designs, but since Cell's vectors are not limited to a single type of task, their cores provide the flexibility of homogeneous computers. All in all, this design is not perfect and will inherit some compromises, but throughout this writing, you'll see the different problems that Cell will attempt to solve and how it managed to do so.
A glance at Cell
Having explained all that history and theory, I think we are ready to bring forward the protagonist of this section. This is Cell...
The Cell Broadband Engine (PS3 variant).
Designed by IBM for supercomputing and scientific simulation. The crossed out 'SPE' means it's disabled (unusable). The other 'SPE' on the left is reserved to the operating system.
... and by the end of this section, you'll know what each component does.
Overall structure
Cell runs at a mighty 3.2 GHz and it's composed of a multitude of components. So, for the sake of this analysis, this CPU can be divided into three main areas :
- The leader: this is the part of Cell that directs the rest of the circuitry. Here we find a component called PowerPC Processor Element (PPE).
- The assistants: these are as crucial as the PPE, but their capabilities are limited to an assistant/accelerator role. This group comprises eight Synergistic Processor Elements (SPEs).
- The interfaces: As the need for bandwidth surges exponentially, newer interfaces are implemented to move data around without producing bottlenecks. In the interfaces group, we find a handful of protocols: the Element Interconnect Bus (EIB), the Broadband Engine Interface Unit (BEI), the Memory Interface Controller (MIC) and the Flex I/O buses.
This information will be revisited throughout the article in more depth, so you don't have to memorise these names. The main goal of this section is to let the reader get a mental image of the nature of Cell and familiarise themselves with all the components we'll be discussing in due time.
How this study is organised
Seeing the previous structure, I had to organise this so you don't get fed up with lots of information. Thus, we are going to analyse Cell by studying each component in this order:
- The bus connecting all components, the Element Interconnect Bus (EIB).
- The PowerPC Processor Element (PPE) and its core element, the PowerPC Processing Unit (PPU).
- What general-purpose memory is available in this console.
- The Synergistic Processor Elements (SPE) and their core element, the Synergistic Processor Unit (SPU).
- The programming model devised to program Cell efficiently.
That being said, let's begin the real analysis.
Inside Cell: The heart
Since its announcement, Cell has been referred to as a Network-on-Chip (NoC) instead of the traditional System-on-Chip (SoC) definition; this is attributed to Cell's unorthodox data bus, the Element Interconnect Bus (EIB). We've seen so far how demanding CPU components can be, in addition to how susceptible a system is to bottlenecks. Well, to tackle this for the eleventh time, IBM has devised a new design... and has documented it using terms analogous to road driving.
Simplified diagram of the Element Interconnect Bus (EIB).
Each arrow between 'Ramps' (nodes) represents two unidirectional buses, thus, each node is connected to the next one using four channels.
The EIB is made of twelve nodes called Ramps, each one connecting one component of Cell. Ramps are interconnected using four buses, two of them travel clockwise and the other two do so anti-clockwise. Each bus (or channel) is 128-bit wide. Having said that, instead of resorting to single bus topologies (like the Emotion Engine and its precursor did), ramps are inter-connected following the ring topology, where data packets must cross through all neighbours until they reach the destination (there's no direct path). Considering the EIB provides four channels, there're four possible routes (rings).
Now, you may think, what's the point of a ring if data may end up travelling longer paths (compared to a single direct bus)? Well, a single bus is highly susceptible to congestion. Hence, EIB's engineers decided on this topology to tackle large amounts of concurrent traffic (keep reading if you want to know how the ring helped).
Data is transferred in the form of 128-bit packets . Each ring can carry up to three concurrent transfers as long as the packets don't overlap. The EIB operates with the use of command credits, in other words, whenever a component needs to initiate a transfer, it sends a request to the EIB's Data Arbiter, which manages the traffic within the rings. The moment the request is approved, packets enter the ring and receive a 'token', which the data arbiter uses as meta-data to supervise the transfer. Moreover, some components have preferential priority over others, like the Memory Interface Controller (MIC) component, which is where main RAM is located. Finally, the data arbiter will never place packets at rings whose path is longer than half of the ring.
Each ramp plays a part in the transfer: they read the destination address of the packet to know whether to post data to their respective component or forward it to the next Ramp. During each clock cycle, ramps can receive and send 128-bit (16 Bytes) packets at the same time. So, considering there are four channels and the EIB operates at 1.6 GHz (half of Cell's speed), the theoretical maximum transfer rate is 16 Bytes x 2 transfer/clock x 4 rings x 1.6 GHz = 204.8 GB/s. This value is of course too optimistic and there are many other external factors (i.e. origin/destination path, state of the bus, etc.) conditioning performance. In any case, many research papers made by IBM and other authors compiled more realistic speeds using practical experiments .
Now that you've seen how every component of Cell is interconnected, it's time to check out the first component of this chip...
Inside Cell: The leader
Here we will take a look at the 'main part' of Cell. That is the part of the silicon that is in charge of commanding the rest. The component's name is PowerPC Processor Element (PPE) and you can think of it as the MIPS R5900 of the Emotion Engine.
Composition of the PPE
Remember how I divided Cell into different areas before? Well, the same can be done with the PPE. IBM uses the term 'element' to describe the independent machine , but once inside it uses the term 'unit' to separate the core circuitry from the interfaces that communicate with the rest of Cell.
Simplified diagram of the PowerPC Processor Element (PPE).
Having said that, the PowerPC Processor Element is surprisingly composed of two parts:
- PowerPC Processing Unit (PPU): This is the logical part of the PPE (the 'core'). Don't forget this is not Nintendo's PPU! (even though they are sharing the same letters of the Latin alphabet... in the same order...).
- PowerPC Processor Storage Subsystem (PPSS): The big interface that connects the PPU to the outside world. Furthermore, it provides a whopping 512 KB of L2 cache.
As you can see, the design of the PPE (and the rest of Cell) is pretty modular, which follows the teachings of RISC design, you'll soon see that the modularity is applied even inside the PPU.
The PowerPC Processing Unit
We are going to take a look at the insides of the PPU just now. To recap, we've dived into Cell, then into the PPE, and finally into the PPU. We'll analyse the PPU just like any other CPU core.
A familiar architecture
To start with, the PPU is not built from the ground up but re-purposes existing PowerPC technology. However, unlike previous iterations where IBM grabbed an existing processor and half-updated it to meet new requirements, the PPE doesn't replicate any previous CPU design. Instead, IBM constructed a new CPU that follows version 2.02 of the PowerPC specification (which happens to be the last PowerPC spec before being rebranded to 'Power ISA'). To sum up, you won't find the PPU's design on any existing chip from that time, yet, it's programmed using the same machine code as other PowerPC chips.
That being said, why did IBM choose PowerPC technology to develop a high-performance chip? Simple, PowerPC is a mature platform that enjoyed ~10 years of Macintosh user-base testing and revisioning, it ticks all the boxes in Sony's list and, if the need arises, it can be adapted to different environments. Last but not least, the use of a well-known architecture is good news for existing compilers and codebases which, for a new console, is a big starting advantage.
It's worth mentioning that IBM was one of the authors of the first PowerPC chips, along with Motorola and Apple (recall the AIM alliance). Be that as it may, towards the early 00s, the so-called alliance members were already working separately, where Motorola/Freescale developed a different PowerPC series from IBM.
Distinctive features
The PPU shares some history with the PowerPC 970 (called G5 by Apple). Both are descendants of POWER4, a PowerPC predecessor mainly used in workstations and supercomputers - not to be confused with the barely-related GameCube's 750-line CPU, which had considerable input from Motorola but was then slightly modified by IBM. Anyway, the influence of POWER4 will become more evident when I show you the modularised execution units soon.
Back on topic, the PPU is a complete 64-bit processor. This means:
- The size of a word is 64-bits.
- There are 64-bit general-purpose registers (32 to be exact).
- The data-bus is at least 64-bit wide: in the next sections of the article, you'll see it's much wider than that, but for now, keep in mind that transferring 64-bit words won't penalise performance.
- The address bus is 64-bit wide: in theory, the CPU can access up to 16 exabytes of memory. Now, in practice, this is very costly if the machine doesn't house all that memory. So, modern CPUs delegate addressing to the Memory Management Unit (MMU) to provide more uses to the address bus.
Finally, the PPU implements the PowerPC ISA version 2.02, including optional opcodes for floating-point square root . It's also been extended with a group of SIMD instructions called Vector/SIMD Multimedia Extension (VMX). On the other side, some elements are missing from the original specification, such as little-endian mode (in fact, Cell only operates in big-endian) and just a handful of opcodes.
PPU's building blocks
By applying a 'microscopic' view to the PPU, we can observe this unit is composed of different blocks or sub-units which perform independent operations (load values from memory, carry out arithmetic, etc). The capabilities of the PPU are defined by what each block can do and how:
Instructions
Simplified diagram of the Instruction Unit (IU).
The first block is called Instruction Unit (IU) and as its name suggests, it pulls instructions from L2 cache and signals other units to perform the requested operation. Like its i686 contemporaries, part of the instruction set is interpreted with the use of microcode (the IU embeds a small ROM for this purpose). Lastly, the IU also houses 32 KB of L1 cache for instructions.
Instruction issuing is carried out with a 12-stage pipeline, though in practice the total number of stages will greatly vary depending on the type of instruction. For instance, the branch prediction block may bypass great parts. If we combine the IU with the neighbour units, the final number of stages is often close to 24 (yes, it's a big number, but remember Cell runs at 3.2 GHz).
Now for the interesting parts, the IU is dual-issued: in some cases, the IU will dispatch up to two instructions at the same time, consequently improving throughput greatly. In practice, however, there are many conditions for this to work, so programmers/compilers are responsible for optimising their routines so their sequence of instructions can take advantage of this function. By the way, dual-issuing has been implemented by previous CPUs as well, and the term varies between vendors, so here I used IBM's definition.
Furthermore, to top it off, the IU is also multi-threaded, where the unit can execute two different sequences of instructions (called 'threads') at the same time. Behind the scenes, the IU is just alternating between the two threads at each cycle, giving the appearance of multi-threading. This technique is historically known as Simultaneous Multi-Threading (SMT) or hyper-threading, as Intel later coined. Nevertheless, IBM's multi-threading mitigates unwanted effects like pipeline stalls, since the CPU will no longer be blocked if one instruction jams up the flow. To accomplish multi-threading, IBM engineers duplicated the internal resources of the IU, which includes general-purpose registers (previously I said there are 32 registers available, that's per thread. In reality, there are 64 in total!), however, resources that don't belong to the PowerPC specification (such as L1 and L2 cache; and the interfaces) are still shared. Thus, the latter group is single-threaded.
All in all, combining dual-threading with dual-issuing, the PPU can execute up to four instructions per cycle. Even though this is a 'best-case scenario', it still provides optimisation opportunities that users will ultimately notice in the game's frame rate!
Memory management
Simplified diagram of the Load-Store Unit (LSU) and its neighbours.
The following blocks grant the PPU the ability to execute load-store instructions and carry out memory management.
To begin with, the Load and Store Unit (LSU) executes 'load' and 'store' opcodes backed by 32 KB of L1 data cache. As a consequence, this unit has direct access to memory and the register file.
Furthermore, the LSU is coupled with a Memory Management Unit (MMU), which is a common occurrence in contemporary hardware. To make a long story short, the MMU handles memory addressing using a virtual address map combined with memory protection. To improve the latter, this MMU in particular features a segment unit, which groups memory addresses using ranges called 'segments'. Now, to prevent performance degradation in the process, a Translation Lookaside Buffer (TLB) (caches converted addresses) and a Segment Lookaside Buffer (SLB) (caches segments) are included.
Arithmetic
Simplified diagram of the units that perform arithmetic.
There are only two more units of the PPU left to explain: the ones computing the math any game will need.
The first one is a traditional Fixed-Point Integer Unit (FXU). It carries out integer arithmetic, such as division, multiplication, bit rotation (similar to bit shifting but discarded bits are returned to the other end) and count-leading zero (useful for normalising vertex coordinates, for instance). Its pipeline is 11 stages long.
If you look at the diagram, you'll see that the FXU, LSU and MMU are grouped into a single unit called Execution Unit (XU), this is because they share the same register file.
The second unit is way more interesting, the Vector/Scalar Unit (VSU) performs operations with floating-point numbers and vectors. It's made up of a 64-bit FPU (follows the IEEE 754 standard) and a Vector/SIMD Multimedia Extension unit (VXU), which executes a set of SIMD instructions called VMX. The latter operates 128-bit vectors made from sixteen 8-bit values to four 32-bit ones . You may have heard about this extension before, as 'VMX' is IBM's name to Motorola's 'AltiVec' or Apple's 'Velocity Engine' (long live trademarks). Conversely, Cell's competitive SIMD capabilities are found in another processor, so don't relax just yet!
Wrapping the PPE up
You've just seen how the PPE works and what it's made of, but what does it mean for a developer?
After all, the PowerPC Processor Element is only a general-purpose processor, but here's the thing: it's not meant to work alone. Remember that wide main bus (the EIB)? IBM designed the PPE so engineers may combine it with other processors to accelerate particular applications (i.e. HPC, 3D graphics, security, scientific simulations, networking, video processing, etc) and since this writing is about the PlayStation 3, you'll see the rest of Cell is treated with computer graphics and physics in mind, so, the rest of the article reflects that purpose.
Outside Cell: Main Memory
Let's now step out of Cell for a moment, as it doesn't matter how good the PPE is if we don't have a proper working space (memory) to put it to work.
Thus, Sony fitted 256 MB of XDR DRAM on the motherboard... But, again, what does this mean? To answer that, we need to take a look at how the memory blocks work and how they connect to Cell.
Cell next to the four 64 MB XDR DRAM chips.
First of all, the type of memory fitted is called Extreme Data Rate (XDR). You may recognise XDR DRAM as the successor of the jinxed RDRAM found in the Nintendo 64 and the PlayStation 2. But don't jump to conclusions just yet!
Rambus, like any other company, improves upon their inventions. Their third revision (XDR) now operates at octa-rate (four times the rate of its adversary, DDR DRAM) . Latency doesn't pose an issue anymore, if we take a look at one of its manufacturers' data-sheets, XDR's latency is reported between 28 ns and 36 ns , almost 10 times faster than the first-generation RDRAM chips.
The first revision of the PlayStation 3's motherboard contains four 64 MB chips, handled in pairs. XDR is connected to Cell using two 32-bit buses, one on each pair. So, whenever the PPU writes a word (64-bit data), it's split between two XDR chips. The latter are clocked at 400 MHz .
Cell's memory architecture diagram.
Cell connects to the XDR chips using the Memory Interface Controller (MIC), another component within Cell (like the PPE). Additionally, the MIC buffers memory transfers to improve bandwidth, but it has a big limitation: large byte alignment. In essence, the MIC's smallest data size for transfers is 128 Bytes, which works well for sequential reads or writes. But if the data is smaller than 128 B or it requires alternating between writing and reading, performance penalties appear.
That being said, is the MIC a bottleneck or an accelerator? Well, you have to put it into perspective, bandwidth optimisation is critical in data-hungry systems. In the past, we've seen solutions like the write-gather pipe or the write back buffer, so the MIC is simply a new proposal to a recurring problem. For what it's worth, Sony claims the transfer rate is 25.6 GB/s. Still, there are too many factors that will condition the final rate in practice (you've seen how convoluted it is to move data from one place to another within Cell).
This is as far as it goes for main RAM, but there's more memory elsewhere: the hard drive. The PS3 also enables games to use 2 GB from its internal hard drive as a working area (similarly to what the original Xbox provided) .
Inside Cell: The assistants
We've seen before how Sony always supplies a general-purpose processor (the PPE in this case) accompanied by accelerators to reach acceptable gaming performance (the VPUs and IPU in the case of the PS2; and the GTE and MDEC with the PS1). This is common practice with video game console hardware, as general-purpose units can perform a wide range of tasks, but are not specialised in anything. Game consoles require only a subset of skills (physics, graphics and audio, for instance) so co-processors bring them up to their task.
[The PPE] is a watered-down version to reduce power consumption. So it doesn't have the horsepower that you see in say a Pentium 4 (...) If you take the code that runs today on your Intel or AMD, whatever your power, and you recompile it on Cell, it'll run today - maybe you have to change the library or two, but it'll run today here, no problem. But it'll be about 60% slower, 50% slower and so people say "Oh my god! This cell processor's terrible!" but that's because you're only using that one piece .
- Dr. Michael Perrone, manager of the IBM TJ Watson Research Center's Cell Solutions Department
The accelerators included within PS3's Cell are the Synergistic Processor Elements (SPE). Cell includes eight of them, although one is disabled while the console boots up. This is because chip fabrication requires an exceptional amount of precision (Cell initially used the 90nm fabrication process) and the machinery is not perfect. So, instead of chucking out circuitry that came out < 10% defective, Cell includes one spare SPE. Thus, if one of them comes out defective, the whole chip is not discarded. Now, that spare SPE will always be deactivated, regardless of whether it's working or not (Sony can't have two different PS3s in the market).
Composition of the SPE
Moving on, the Synergistic Processor Element (SPE) is a tiny independent computer inside Cell and commanded by the PPE. Remember what I explained before about the adoption of elements from homogeneous computing? Well, these coprocessors are somewhat general-purpose and not restricted to a single application, so they will be able to assist in a wide range of tasks, that is, as long as developers can program them properly.
Simplified diagram of the Synergistic Processor Element (SPE), there are eight of these within Cell (one disabled).
Just like we did with the PPE, we'll have a look at the SPE. It's a shorter one so if at the end, you'd like to learn more about the SPEs, check out the 'Sources' section at the end of the article. That being said, let's start...
The SPE is a processor that follows similar structuring to the PPE, being made of two parts:
The Memory Flow Controller
The Memory Flow Controller (MFC) is the block that interconnects the core with the rest of Cell, this is equivalent to the PowerPC Processor Storage Subsystem (PPSS) in the PPE. The MFC's main job is to move data between SPU's local memory and Cell's main memory and keep the SPU in sync with its neighbours.
To perform its duties, the MFC embeds a DMA controller to handle communication between the EIB and the SPU's local memory. Furthermore, the MFC houses another component called Synergistic Bus Interface (SBI) that sits between the EIB bus and the DMA controller. It's a very complex piece of circuitry to summarise, but it basically interprets commands and data received from outside and signals the internal units of the SPE. As the front door to Cell, the SBI operates in two modes: bus master (where the SPE is adapted to request data from outside) or bus slave (where the SPE is set to receive orders from outside).
As a curious fact, considering the limit of EIB packets (up to 128-bit long), the MFC's Direct Memory Access (DMA) block can only move up to 16 KB of data per cycle, otherwise, the EIB throws a 'Bus Error' exception during execution .
The Synergistic Processor Unit
The Synergistic Processor Unit (SPU) is the part of the SPE where the core processor resides, equivalent to the 'PPU' when we talked about the PPE.
Unlike the PPU, the SPU is isolated from the rest of the Cell. Thus, there's no shared memory between the PPU and other SPUs. Instead, the SPU contains local memory used as working space. However, the contents of local memory can be moved back and forth using the MFC.
In terms of functionality, the SPU is a lot more limited than the PPU. For instance, SPU doesn't include any memory management functions (address translation and memory protection) or even state-of-the-art functions (i.e. dynamic branch prediction). Nonetheless, it performs exceptionally well at vector processing.
To program this unit, developers use the PPU to invoke routines provided by the PlayStation 3's Operating System, these upload the executable specifically written for the SPU to the SPU of choice and signal it to start execution. Afterwards, the PPU keeps a reference of the SPU's thread for synchronisation purposes .
Architecture of the SPU
Like any CPU, the Synergistic Processor Unit (SPU) is programmed using an Instruction Set Architecture (ISA). Both SPU and PPU follow the RISC methodology, however, unlike the PPU (which implements a PowerPC ISA), the SPU's ISA is proprietary and mainly composed of a SIMD-type instruction set. As a result, the SPU features 128 128-bit general-purpose registers which house vectors made of 32/16-bit fixed-point or floating-point values. On the other side, to preserve memory, SPU instructions are much smaller, just 32 bits long. The first part contains the opcode and the rest can reference up to three operands to be computed in parallel.
This is very relatable to the previous Vector Floating Point Unit debuted in the PS2, but a lot has changed since then. For instance, the SPU doesn't require developers to learn a new proprietary assembly language - IBM and Sony provided toolkits to program the SPUs using either C++, C or assembly.
In terms of design, this processor doesn't execute all instructions using the same unit, execution is instead divided into two blocks or 'execution pipelines', one is called Odd Pipeline and the other is named Even Pipeline. These two pipelines execute different types of instructions, enabling the SPU to issue two instructions per cycle whenever it's possible to do so. On the other hand, the SPU will never dual-issue instructions that depend on each other, thus, mitigating data hazards that may emerge.
Let's now take a look at the two pipelines :
Odd Pipeline
Simplified diagram of the odd pipeline.
The Odd pipeline executes most of the instructions except the arithmetic ones.
First of all, you'll find the SPU Load/Store unit (SLS) does three essential things:
- Houses 256 KB of local memory to store instructions and data. The type of memory fitted is single-ported (considering this is a critical area, it's a bit disappointing they didn't use dual-ported chips...). Furthermore, the address bus is 32-bit long.
- Executes load and store instructions.
- Forwards instructions to another block for issuing.
Notice that there are only 256 KB available to store the program. Considering SPU programs can be compiled using C/C++, it's not easy to predict how large the binary will be. For this reason, it is recommended that developers assume there is only half the memory available (128 KB) , which leaves enough window for the compiled code to take up as much space as it needs, although this comes at the cost of storage and efficiency.
Finally, there's also a SPU Channel and DMA Transport (SSC) unit, which the Memory Flow controller uses to fill and/or fetch local memory, and a puny Fixed-Point Unit that only does shuffling and vector rotation.
Even Pipeline
Simplified diagram of the even pipeline.
The Even pipeline is notable for its arithmetic capabilities.
In here we find a real Fixed-point Unit (FXU) which performs basic arithmetic, logical operations (AND, OR, etc), and word shifts.
Last but not least, we've got a Floating-Point Unit (FPU) which performs single-precision (32-bit float), double-precision (64-bit double) and integer (32-bit int) operations. It follows IEEE standard with some deviations (floats behave similarly to the PS2).
Inside Cell: Programming styles
As we reach the end of Cell, you may ask how are developers supposed to program this monster? Well, similarly to the previous programming models devised for the Emotion Engine, IBM proposed the following methodologies :
PPE-centric approaches
Representation of the multistage pattern, where the PPE assigns a task that gets passed around each SPE, and eventually returned with the data processed.
Representation of the parallel pattern, where the PPE assigns a subtask to each SPE, and in turn each SPE returns the processed data, which the PPE merges.
Representation of the services pattern, where the PPE allocates a different task to each SPE, and each work individually to fulfil it.
PPE-centric approaches are a set of programming patterns that place the main responsibilities on the PPE and leave the SPE for offloading work. There are three possible patterns:
- Multistage pipeline model: the PPE is tasked with sending work to a single SPE, which in turn performs the required computations and passes the results to the next SPE. This continues until the last SPE in the chain sends the processed data back to the PPE.
- For obvious reasons, IBM doesn't suggest this design for primary tasks as it requires a considerable amount of bandwidth and it tends to be difficult to maintain.
- Parallel stages model: the PPE divides its main task into independent sub-tasks and sends each one to a different SPE. Each SPE then returns the processed data to the PPE after they finish, then, the PPE combines it to produce the final result.
- Services model: each SPE gets assigned a single job (i.e. MPEG decoding, audio streaming, perspective projection, vertex lighting, etc) and the PPE is in charge of sending raw data to the designated SPE. While waiting, the PPE carries out other functions.
- While this implies each SPE will have a single job, their job designation is not meant to last forever. The PPE must reallocate different jobs on the fly as the needs of the program change.
SPE-centric approaches
Representation of the SPE-centric pattern, where each SPE is in charge of its functionality and only interacts with the PPE to obtain a resource.
Instead of using the SPEs to serve the PPE, it's the other way around. Using the internal DMA unit, SPEs fetch and execute tasks stored in main memory, while the PPE is limited to resource management.
This model is a lot more radical than the rest, in the sense that previous patterns are closer to the traditional and PC-like 'general-purpose processor with co-processors' paradigm. Thus, codebases implementing SPE-centric algorithms may be harder to port to other platforms.
Conclusion
As you can imagine, while the multi-core design of Cell accelerates emerging techniques such as procedural generation, none of these designs are particularly simple to implement, especially considering game studios prefer codebases that can be shared across different platforms.
To give you an example, the developers of the Unreal Engine 3 (Epic Games) demonstrated the limitations of the SPUs while trying to implement their collision detection system . Their design relies on Binary Space Partitioning (BSP), an algorithm strongly dependent on comparisons (branching). Because the SPUs don't provide dynamic branch prediction like the PPU, their implementation disappointed PlayStation 3 users when compared side-by-side against other platforms (i.e. Xbox 360 or i686 PCs, both of which provide consistent prediction techniques across all their cores). Hence, Epic Games had to resort to further optimisations only compatible with Cell.
I suppose it's just a matter of time, patience and a lot of learning for software engineers to crank up the full potential of Cell. However, history demonstrated that's not feasible for every studio, which makes me wonder if that's the reason current console hardware (as of 2021) has homogenised so much.