I wouldn't get my hopes up about going to E3. The show isn't open to the general public.

bulky? Looking at the photos at the PS3 thread, we can roughly judge the dimensions of the console:
width is roughly twice of the DVD/CD/BD slot. To fit a 12cm diameter disc, the slot is usually wider, let's say about 13cm. So PS3 width ~ 2 x 13cm = 26cm.

height/thickess is roughly three and a half times of the IEC power connector. The power connector is roughly 2cm high. So PS3 thickness is approximately 3.5 x 2cm = 7cm. Give or take 1cm if I'm cock-eyed.

depth is about 1.5 the diameter of a DVD, so about 18cm.

somebody should shoot the designer of that awful controller though... at least I hope third parties like logitech will adopt a more DS-like shape.

Straight from the horse's mouth:IBM Cell project page


Furthermore, each SPE has 256K of "Local Storage", which is effectively a Von Neumann style L1 cache.

Actually, after reading the arstechnica article on the X360 CPU, I was reminded of something. The targetted application of the SPUs is mainly processing of streaming data, which is inherently cache-unfriendly. Cache in the memory hierarchy alleviates the memory-to-cpu bottleneck by leveraging temporal and spatial locality. 3D scene data and video decoding have neither locality. However, code that acts on this data has high locality. Hence, the SPE local store looks like it is more useful as I-cache + deep buffer for streaming data.

This sort of lines up with the "DSP-like" tag the SPEs have been given. Real DSPs also don't feature much in the way of data caches, since they're operated in more of a "fire and forget" way. Which makes sense, because unless you're playing a broken record, or pointing a camera at a painting, there's no way that the data into the DSP is going to repeat itself.

This post has been edited by silkworm: May 26 2005, 05:09 PM

First, let's share what google brought me this morning: microprocessor report article

In that report, it is written that SPEs do not have cache, and we can infer that the LS is indeed not an L1 cache. But why do you have this fixation on L1 anyway?

The LS is SRAM, it sits right next to the SPE's logic and execution units. With that kind of placement it probably runs at the same clock frequency (or perhaps matched with the pipeline latency for read/writes to save power?) That's probably all that the LS have in common with cache.

I've also mentioned earlier that cache is only effective when there is locality to be exploited. When there is no locality, cache misses are so expensive that it's better not to have them there in the first place. Cache adds an element of unpredictability to programming; Cache misses are inevitable and the programmer has no direct control over when they happen. This sort of unpredictability is a no-no in realtime applications. Graphics rendering in games can be classified as realtime, because they have a 1/60 second deadline for all their processing.

The LS of each SPE can be mapped into system memory. Which means that LS is visible to the programmer. A cache is invisible to the programmer, it has no implicit memory address range.

After all this discussion on the SPE, we seem to have left out the PPE which is a traditional 64-bit processor, and has its own L1 data and instruction cache.

For context:

Fed my own medicine, gah! In hindsight that was a rather naive conclusion based on the observation that the LS consists of SRAM (as are all low-level caches), is geographically close to the SPU and (maybe) runs at core frequency. If I wanted to cover my backside, I could retort that by using the word "effectively", I wasn't too convinced of it being L1 cache even back then, but that would make me look small, so I won't.

So, can we safely agree that the Local Store memory of 256K on each SPE is neither L1 nor L2 cache, and doesn't need to be?

WRT to cache implementation and cost:

The fastest caches are implemented in SRAM, which iirc, take 6 transistors to implement a single cell. They are certainly not as dense as DRAM. A common convention for calculating gate counts is to take the number of transistors to implement a NAND gate, in CMOS processes, that is 4 transistors. That gives us a 3:2 transistor ratio, ie for every 2 SRAM cells we could have had 3 logic cells. Let's see you guys bake your noodles on that tid-bit.

I'd like to add that n-way set associativity isn't the only way to make a cache. Direct mapping does not require the sort of logic complexity that we see in the L2 in the die photos. Sure, nobody wants to use direct mapped caches anymore today, but computer architecture trends tend to make a full circle every couple of decades. We're seeing stack machines and VMs making a re-appearance lately even though they were supposed to have died off in the 70s and 80s. That said, we should not write off any technique even though it looks sub-obtimal based on today's performance metrics/requirements.

First off, some more nice nice PDF files. And another one.. These are the papers that were being analysed seperately by Real World Technologies and ArsTechnica. Both authors were probably also privy to other material, having attended the ISSCC talks in person. The arstechnica article, in particular, covers what we had been debating about previously, namely the role of the LS in replacing L1.

I was going to write a rebuttal to your points, but I've had a long day at work and I badly need a shower. The documents should keep you occupied for the rest of the time though. I'll get round to rebutting tomorrow, if still necessary.

Sorry, those are pretty bad examples. Looks to me like you're mixing up microcontrollers, which are actually systems-on-a-chip.

OMAP
Uses ARM7/9/11 cores. ARMs are traditionally cacheless.

MCORE and MC68HCxx
Again, the RAM is not internal to the actual processing core itself. The 68HCxx are 8-bit (`05, `08) or 16-bit (`11, `12) parts.

Same goes with PowerPC, the PPC4xx cores were licensed out by IBM to other SoC houses, including Freescale, for use in embedded systems.

There are several pretty obvious differences between these chips and the PPE that's being discussed. Most of the time these ICs are self-sufficient. Program code is stored on, and run directly from ROM/EEPROM. Unless they are performing exceptionally data hungry tasks, the internal SRAM is all the memory they will ever use. In such cases, cache is largely unnecessary.

Embedded processors have not breached the 1GHz operating frequency barrier just yet. The PPE core may be integrated into a microcontroller, someday (if ever the need arises for a >GHz mcu, [shudder])

-Edit- Rather than to leave it hanging just like that, a conclusion should be in order:
The PPE is a processor core. Microcontrollers like the examples given are built around cores.

This post has been edited by silkworm: Jun 3 2005, 02:59 PM

Augh!

The last of the 68K series was the 68332, after which Motorola/Freescale evolved the architecture into the ColdFire series. You just used "68HC". The 8 and 16 bit freescale MCU families are commonly called by "HCxx", eg, HC05, HC12, etc.

A RTOS only needs as much RAM as necessary for a process table and storing context information (Instruction pointer, stack pointer, flags, GP Registers) for each process. Applications code can still be loaded direct from non-volatile storage like Flash ROM. Application heap space may be in external RAM. I admit we are seeing more lower end phones being able to run user installed programs, namely java games, but for the bare essential workings of a phone, larger RAM is unnecessary.

True enough, early personal computers and embedded systems were indistinguishable from each other. But as soon as miniaturisation kicked in, their paths diverged. Microprocessors packed all their peripherals like ADCs, DACs, timers, counters, RAM and ROM into a single package, while general purpose processors today are just cores with one or two levels of cache and buttloads of address/data/IO pins.

The word "embedded" projects an image of permanence, ie the function of the system is unchanged throughout its working life. A general purpose computer on the other hand is transient, the user chooses what he wants to do with the computer by running different application programs. Embedded systems run solely on firmware. A PC BIOS is indeed a form of firmware, but it only bootstraps the system and the rest is up to the user (yes, even an OS is optional).

OK, I may have underestimated the RAM usage required in the case of a cellphone design, particularly the consumption during baseband processing and the protocol stack. Probably has to do with me playing with 8-bitters too long, I'm too used to offloading the heavy stuff onto ASICs.

Sony makes no pretense about their PlayStation platform being "computers", after all the division that makes PlayStations is called Sony Computer Entertainment Inc.


There isn't any hard definition of what makes an embedded system. If it has a processor in it, it could be an embedded system. Even a regular PC could be pressed into service as an embedded system, which happens quite often in industrial environments such as production lines.

My personal definition of an embedded system is a system that performs a function, and from the moment it turns on until it turns off, that function does not change fundamentally. A cellphone is an embedded system, because once you turn it on you expect it to function as a phone. Sure you may play games on a cellphone, use it as an organizer or alarm clock, even browse the internet and send e-mails. But when a call comes in, you can still answer it.

Quite a logical definition, but perhaps a bit narrow. For physically small or resource limited systems, this rings true. However, once certain criteria of performance (CPU/RAM) and user interface are met, an embedded system is entirely capable of self-hosting its development environment. For instance, one needs a decent method of character input, a screen that displays a reasonable amount of text, and storage for the source files and compilation tools. My example of the "embedded PC" above could be one such system.

PS2 development is done on what is basically a beefed up version of the retail PS2, running linux. I expect the production versions of the PS3 development kit to be more of the same.

Phew at last we're getting back on topic. I'll call them "computer-based entertainment systems". This is not a cop-out. The purpose of a console system is to entertain you. For the moment it means games, but it's recently expanded in scope to cover other forms of electronic entertainment, chiefly movies and music. Stuff like Xbox Live expands it some more by adding a social element. But the one thing you will not find running on a console is a spreadsheet or word-processor. So that strikes it out as a "computer" in the classic sense. You're not going to be calculating the effects of a nuclear explosion, or predict the weather (no matter how much Sony insists you could), so that doesn't make it a "super computer" either. You will be having a good time, (at least the game developers and console manufacturers hope so), or otherwise generally entertained . That's what matters.

Those of you who are still with me up to this point will note that this conforms with my definition of an embedded system too. So what. Bring on the games.

You are confused. The purpose of OoO is not to predict, but rather to exploit more instruction level parallelism out of a pipeline. There are basically two major drawbacks to a pipelined structure: data dependancy/hazards and pipeline flushes due to branches. Pipeline flushes affect the whole pipe from the point where the branch is taken and are generally more "expensive" in terms of lost performance. They are countered by branch prediction, which the PPE and SPEs of Cell do have.

Data hazards such as Read-after-Write(RAW), Write-after-Read (WAR), and Write-after-Write (WAW), stall a pipeline by inserting "bubbles" in the pipeline until the dependancies have been solved, at the cost of a few cycles. Out-of-Order Execution may help in special cases where there are enough operands available in the instruction stream to feed to an execution unit, so that the processor can go ahead and execute that instruction while another (earlier) instruction is still waiting for its data to be ready. Sort of like in a bank, if a customer is at the counter and he's busy filling out a form, the teller will ask the next customer to come to the counter, provided that this next customer doesn't need to fill any forms.

Even without OoO, a pipeline is still equipped with data forwarding buffers to minimize length of pipeline stalls. A forwarding buffer "forwards" the result of the execution units to the earlier stages of the pipeline so that those results may be used by following instructions that depend on it, instead of having to wait for it to be written to memory and fetched again. Furthermore, instruction re-ordering and scheduling is also within the capabilities of modern optimizing compilers. Put these two together and pipeline stalls are a non-issue with careful programming.

OoO is "expensive" to implement in terms of complexity and silicon area. In order (pun not intended) to find a suitable instruction to execute out-of-order, the decoded instruction buffer should be quite large. Look at the P4's Netburst micro architecture, their "L1" trace-cache is filled entirely with decoded micro-ops, which the OoO engine can search through to find a suitable candidate for scheduling. The further ahead the OoO engine grabs the instruction from, the larger the re-ordering buffer needs to be; instructions still need to be retired in order. The kind of silicon area that takes up could be put to different use, and in the case of the PPE in the Cell CPU, it looks like it's been taken up by Simultaneous Multi-Threading (SMT).

SMT is another strategy to make efficient use of the execution units in a CPU, at the cost of doubling the necessary units for thread context (Instruction Pointer, Stack, Flags, GPRs), when one thread is using the Adder, another can be using the Load-Store Unit, or the FP unit.

In summary, OoO is not a magic bullet that promises huge performance gains just by being featured in a CPU's architecture. It's not a new idea either, ironically it was used first by IBM in the 1960s, as shown in this research paper. The designers of Cell have made traded off this feature with other architectural features like SMT, dual-issue pipelines, etc to attain a balance that is acceptable to them, and hopefully suitable for the intended application, namely console gaming.

We can have a peek at the Linux "model" of programming the SPEs in these kernel patches released a couple of months ago. SPEs exist as "files" in the filesystem and that's how program code and data are transferred onto it. The SPEs are idle until a DMA "kick" command is sent to it, after which it looks like it's controlled by the standard POSIX threading API. At least, that's what I've managed to glean from the raw patch data. I'd need to actually patch the full kernel source to see the context of some parts, like the interrupt controller and the memory management unit.

One might also gain insight on the programming model of Cell from the archived presentation/webcast linked from Power.org, from the Barcelona Power conference held last week. I haven't had a chance to view it yet and the webcast isn't downloadable for offline viewing.

Right-o, its all a matter of statistics. Right now fabs are using 300mm diameter wafers, which gives 70,695mm˛. The Cell processor, weighs in at 235mm˛. Divide and you get about 300 dies, take away another 20% or so because you're fitting rectangles into a circle, and that leaves you with about 240 dies per wafer. The SPEs cover around 2/3 or 66% of a single Cell die, so that gives a higher chance that defects would form on a SPE. On new processes, the initial yield is usually below 50%. By making one SPE redundant, they may increase the yield up to 60-70%, which is important if they want to hit the volumes that they expect for PS3.

An SPE may be deactivated by firmware, by putting it in a power saving state, or by modifying the metal layers thereby cutting off the power to it on the IC level. If the first option is used, we might see something like what PC overclockers have been doing for a while now; tweaking firmware to unlock deactivated hardware. But that might be pointless because all PS3 software would be targetted for only 7 SPEs and the reactivated one wouldn't be used anyway.

Take it easy, the host thread is stalled, not the entire PPE. The SPU/SPE is going to be encapsulated into a Pthread, as you will see in the "bpathread.c" module.

Edit - oops, in my haste, I grabbed the google groups link off my browser history list, and apparently that thread didn't have the whole set of patches. No worries, the complete set of 8 patch files are available on the linux kernel mailing list archive, run a search for "ppc64 bpa" should get you the right hits.

This post has been edited by silkworm: Jun 16 2005, 05:12 PM

The PPE got a bump up in size in the "DD2" revision of the Cell, but there hasn't been any concrete explanation as to what was changed, just more speculation. Anyway, more goodies for the technically minded: papers at IBM research

The TRE demo paper is a good one.

I think you might have gone off-track somewhere. The round-robin scheduling is applied to the four regions being processed within each SPE, not SPE-to-SPE. There is a significant delay in DMA fetches, but that is being hidden by the double-buffering of input and output per SPE. As they explain further down, at any one time an SPE is calculating the ray intersection and downloading data for the next cut into LS. I believe they are doing it in this way to leverage the fact that the SPE is capable of issuing a SIMD arithmetic op and a load/store/DMA channel op per clock.

New consoles that are released in Japan usually get here in the first week of release, if not on Day Zero. However, be prepared for a serious markup. Going by the PSP pricing trend, I'd expect the prices of next generation consoles to reach parity with the overseas "suggested retail price" within 3-6 months of release.

PS, Low Yat Plaza isn't really a haven for console gaming, you'd be better off looking for console related things across the street in Sg. Wang or Imbi Plaza.

No, the "+" D-pad harkens all the way back to the Nintendo Game & Watch