I do agree that cache miss is expensive. But it must be said that the SPE would still be benefiting from some form of cache implemented sensibly.

We all agreed that there's no need for a D-cache. But adding an I-cache could enhance the throughput of the SPE based upon these assumption:

1) I've never implemented or seen a graphic processing algorithm before, but I would assume that it would need to process acquired buffered real-time data (either acquired through the CPU or DMA). Since the SPE is not designed to have a resident RTOS, instead of having multiple tasks waiting on mutexes/semaphores synchronized to the acquisition of these data, it would most probably be synchronized to an IRQ. The acquired real-time data should be synchronous, thus the IRQs should be fired periodically and at deterministic intervals. With a 256K of internal storage, there should be minimal cache miss (cache fill) if the cache is large enough (16k?) and has a suitable block and set distribution, and the executable image has a small enough footprint.

2) Unlike DSP required for network protocol processing, which branches frequently (to service hardware interrupt, software interrupt or task switch), the access pattern of a graphic processing application should be more predictable. Thus could be sensibly distributed and optimized to minimized cache miss. The CPM module of the PowerPC would be used for protocol handling.

I've made I-cache evaluation on certain DSP. And I must say, even with large executable image and unpredictable access pattern, we could still register some throughput improvement compared to accessing plain old RAM (although it must be said that as the size increases and pattern becomes unpredictable, the access time grows drastically). Now, compare running code at RAM speed most of the time and running code at core speed sometime and RAM speed at others, it's not hard to see which is better.

My 2 cents.

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 but could only skim through the ars-technica article. I could only see that this could be a non-issue if the 256K LS is synchronized to core frequency but has none of the typical cache function, as stated in the article, such as tag and cache coherency/snooping logic (i.e. having the speed of a L1 cache but not the redundancies associated with it). Can we assume that much?

EDIT: Nevermind. Got my answer. No assumption required. The 256K is indeed synchronized at core frequency. Now, that's one %@^&#^ SRAM.

EDIT2: There's a fundamental flaw in my argument. Nobody caches internal RAM. Now let me wallow in my pool of ignorance. (* splash..splash)

This post has been edited by ray_: Jun 2 2005, 04:06 PM

Ars Technica has another in-depth article on the Xbox 360, this time focusing on the CPU. Thanks to Evil Avatar for the link.

Great read and good post.

Now for the customary bait to lure massive tech. flames:

Comments on my part:
1) If I'm not mistaken, branch prediction would never work for IRQ. Thus with PPE's deep 21 stages pipeline, there should be much pipeline stall (pipeline flush) if the PPE were to run interrupt prone tasks (eg. protocol related, TDMA...etc.). The XBox would need to handle a couple of network related processing such as WIFI and Ethernet, presumably using dedicated hardwares on the CPM module.
2) Another one of those single-threaded task would be this:
while(1)
{
printf("Hello 4TW\n");
}
But I do not think noobs would be programming for large gaming companies.

Anyone know if the MPx or the 60x bus is used as inter-processor bus? And if there's an internal RAM on each PPE like the DPRAM in previous PowerPC?

The PPE has 32k/32k L1 cache and 512kB L2 cache. Is that what you mean by internal RAM?

And yes i believe it will have hardware to handle networking and such things.

Hey, ikanayam. Yep, there are caches. But I was looking for internal RAM such as that on the SPE.

Nah, it does not have internal RAM like the SPE. Cache would serve a CPU better. The SPE is different because all it is supposed to do is crunch data, it's not made to work with many things a general purpose CPU has to deal with. The internal RAM on the SPE sounds to me like a dumbed down cache from what i've read.

Despite popular believes, most processor has a small internal RAM. Usually either a single-ported (single access) or dual-ported (dual access) one. This is in addition to the L1 and L2 cache. These caches were meant to cache slow external SRAM or DRAM and were never designed to cache internal RAM. The logic for this is simple, internal RAM are fast running RAM usually synchronized at core speed.

EDIT: There's a high probability that the PPE would have an internal RAM. But like always, it always bad to assume and good to find out.

This post has been edited by ray_: Jun 3 2005, 01:29 PM

Hm... any examples of processors that use such internal RAM?

Just google:
Microprocessor "internal RAM"

The result can be overwhelming.

But it must be said that most off-the-shelf processor does not have an internal RAM and relies heavily on cache. But processor that powers PC/Mac represents just a small percentage of the total processor used in the world, most of them in embedded systems.

Top of the list are some of the architecture that uses internal RAM:
1) OMAP
2) MCore
3) 68k
4) variants of PowerPCs

This post has been edited by ray_: Jun 3 2005, 02:00 PM

Surprise find in embedded.com:

EET: Will game-title development also be a challenge for such a high-performance processor?

Kutaragi: It should be the reverse. I want it to be the reverse. The greater the limitations of the hardware, the more labor is needed for software development. With earlier hardware, direct access [from a game program to machine-language-level] hardware or some tricky programming was required to pull off the full performance.

The PS2, for example, made full use of the semiconductor technology available at the time, but only a software effort on the part of the game developers enabled high performance titles like Gran Turismo [a realistic car racing game that has sold more than 43 million copies worldwide]. The more closely they accessed the hardware, the higher the performance they achieved.

Cell is not like that. Application programs can no longer directly access the hardware; instead they will have to be written in high-level, object-oriented language. That was done for security reasons: If processors of high performance and wide bandwidth like the Cell were linked together without sufficient security, a worldwide system crash could occur with one attack.

The big feature of the processor is that multiple operating systems run on it. From the beginning, I wanted multiple operating systems to run on the processor simultaneously.

The Cell processor has a kernel called Level 0 at the bottom. This level is not disclosed and is kept secure. Level 1 handles operations close to the kernel, such as scheduling, the real-time kernel and device drivers. Level 2, which we call the guest OS layer, is for general-purpose operating systems such as Linux and PC OSes and operating systems for the Playstation. All operating systems and applications run on Level 2 or higher. Programmers can concentrate on their targeted area of concern without worrying about other operating systems.

Read the rest here:
http://www.embedded.com/showArticle.jhtml?...cleID=163702001

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

Bait works.

These are 32bit processors. The term SoC and processor are interchangeable.

Hence my point.

Last I've check, the 68k is a 32bit microcontroller.

I don't think cell-phones or PDAs are running from ROM/EEPROM or just internal RAM. Modern RTOS neccessitates some form of external RAM.

Now you could argue that PPE processor core is different to microcontroller in embedded systems. But you must realize that early iterations of the computer are infact embedded systems. They are intricately linked as demonstrated by the use of internal RAM on the SPE.

EDIT: I see where you're going with this one. You're saying, the inclusion of an internal RAM into the processing core is different from the inclusion of internal RAM to the processor (SoC). Strictly speaking, you're right. And these aren't the best examples. Infact I was assuming that the PPE is an SoC.

Now, I could have covered my hinny by saying that I was giving examples of "processor's with internal RAM" and did not mentioned anything about processing core. But that would make me look bad. So I won't (* now where did I read that before).



This post has been edited by ray_: Jun 3 2005, 04:28 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).

Awesome rebuttal. But have to explain 1 point and disagree with another.

Yes, I've edited it for correctness.

Even with everything statically binded, modern function-packed tech. gadgets (qualified as embedded system), would still be requiring some sort of external RAM. You do not need to have a cell-phone that runs Java games to be needing an external RAM, the cell-phone's core functionality itself is sufficient enough to be requiring one.

In a typical cell-phone, you would have RTOS or some form of scheduler, disportionate amount of interrupt sources with corresponding amount of service routines, codes to handle signalling, codes to handle ergonomic, low-level hardware drivers, numerous different level of abstract interfaces (POSIX...etc), DSP algorithm, and huge amount of temporary storage required for real-time data. These translate to a large amount of volatile memory real estates required.

I think you would find most of the paraphernalia running on 32bit core, requiring an external RAM. Now that's lots.

Here's the bomb.

Consoles are traditionally embedded systems. With the introduction of the PS3 and the cell technology, Sony wants them to be called "computers":

Now there are numerous definition for embedded system. Just goggling it returns this:
http://www.google.co.uk/search?hl=en&lr=&c...Embedded+system

Some of the descriptions are ridiculous ("four-digit dates or leap days??"). But some do represent the concept of an embedded system and even fit the bill for our next generation consoles.

But to me, I've always identified a system as an embedded system if there's a need for a cross-compiler to build an application that runs on that system (tool association??). It's a weird definition, but I'll stick to that. Computer lets you write and run application locally in its native language, but embedded system requires a cross-compiler to translates it into target readable instructions and be transfered and loaded into the target's memory space using specialized tools.

With that said, it would qualify consoles as embedded systems. Unless of course, Sony lets its tool chains run natively on the PS3.

The line has blurred so much that it's almost indistinguishable. Who knows, H@H@ might need to move "Console Couch" back to "Computer" and back again several times. Now, would you call these next generation consoles, computers or embedded systems?

This post has been edited by ray_: Jun 3 2005, 07:01 PM

i will call them as computer

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.

*peeks head in*
Did someone call me?

An embedded system != Personal Computer
A phone is an example of an embedded system. It is basically a system with a very specific purpose with very little options in terms of modifications (Not customization mind you)

This is what I figure is an embedded system based on a short analysis I did on Symbian for an assignment.

And the Computer section is for Personal Computers only... If it included embedded systems as well, half of everything in the Special Interest section would end up in there as well.