In today's session, IBM introduced the overall architecture of the Cell processor. Unfortunately, they didn't include many more microarchitectural details in today's session than they did in yesterday's. Most of the session covered issues like power management, clocking, the design process, and so on. So today's article is going to be more along the lines of a follow-up to yesterday's piece. I'll fill in the new information that I've picked up, as well as clarifying leftover questions from yesterday.
The Cell's basic architectureThe basic architecture of the Cell is described by IBM as a "system on a chip" (SoC) design. This is a perfectly good characterization, but I'd take it even further and call Cell a "network on a chip." As I described yesterday, the Cell's eight SPUs are essentially full-blown vector "computers," insofar as they are fairly simple CPUs with their own local storage.
These small vector computers are connected to each other and to the 512KB L2 cache via a element interface bus (EIB) that consists of four sixteen-byte data rings with 64-bit tags. This bus can transfer 96 bytes/cycle, and can handle over 100 outstanding requests.
The individual SPEs can use this bus to communicate with each other, and this includes the transfer of data in between SPEs acting as peers on the network. The SPEs also communicate with the L2 cache, with main memory (via the MIC), and with the rest of the system (via the BIC). The onboard memory interface controller (MIC) supports the new Rambus XDR memory standard, and the BIC (which I think stands for "bus interface controller" but I'm not 100% sure) has a coherent interface for SMP and a non-coherent interface for I/O.
Unfortunately, today's session was severly lacking in information on the 64-bit PPC core that handles the Cell's general-purpose computing chores. We do know that this core has a VMX/Altivec unit, at least one FPU, and supports simultaneous multithreading (SMT). It's also in-order issue, like the SPUs. So it appears that this core also lacks an instruction window, presumably for the same reasons that the SPUs do (i.e. to save on die space and cut down on control logic.) I have in my notes that the core is two-issue, like the SPUs, but I can't find this corroborated anywhere else. So it's possible that the core only issues two instructions per cycle peak, i.e. one from each currently-running thread. I'd imagine that if this is the case, this core's pipeline is very short. This would fit with the SPUs, in which the pipeline was also kept short and simple.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4