XScale PDA Processor Shrinking

bookemdano writes "Intel announces first stacked processor for their XScale line. No core speed increases but the smaller sizes helps with power, overall unit size, and adding additional pieces like WiFi and color screens to smart phones and MP3 players. But speed increases are in the future."

Comments

As an embedded engineer

[ObviousGuy]

I work with the XScale processor platform every day and it is simply disappointingly slow. A cheaper and faster choice for a processor would be something like the x86 Geode from National Semi which runs rings around the XScale for a fraction of the cost. Too bad National Semi is selling off their Geode platform division now.

Re:As an embedded engineer

[cpeterso]

I agree. I have done some development for Pocket PCs. Our testing shows that the new 400 MHz XScale Compaq iPaq are about 2x slower than the old 206 MHz Strongarm Compaq iPaqs! So the XScale processors are effectively 4x slower per MHz compared to the old Strongarm processors. Needless to say, customers blame me when my code runs 2x slower on their new "twice as fast" Pocket PC.

Re:As an embedded engineer

[ObviousGuy]

We've got these Lubbock reference boards sitting around the lab now. When we first fired them up we thought they were broken. One excuse I've heard is that the MS compilers are not good, but still you'd expect that the same ARMV4I (SA1100 and XScale) code would execute faster on the newer XScale chip than on the older SA.

I don't know if this is a dead end product for Intel, but they better start putting out some compilers that take advantage of the XScale improvements or there won't be many customers left. A lot of our customers are going with the platform because we've already got a kit for it that can get them up and running immediately, but there's a lot of complaints about speed regardless.

Re:As an embedded engineer

[cpeterso]

Intel told us the same story:

Intel: The Microsoft Strongarm compiler is old and does not have XScale optimizations. You need a newer compiler with XScale optimizations.

Me: Where can I download it? Can you send me a CD?

Intel: Sorry, we don't have any compilers with XScale optimizations. Better luck next time!

Eventually, Intel gave us a beta XScale compiler, but even with all optmiziations turned on, it produced code LARGER and SLOWER than Microsoft's Strongarm compiler. And the XScale compiler seemed to be written by some company called Northwood, not Intel.

Ironically, XScale is not a dead-end product. The Strongarm is the dead-end product. Intel says that XScale is the future! I think their new Centrino mobile chipset uses XScale. Maybe the XScale architecture is more scalable and will eventually "ramp up" faster than Strongarm could..?

Re:As an embedded engineer

[StormForge]

With most of the silicon bugs fixed, people are still getting pretty poor performance. I think it's still the compilers though. I ran a bunch of benchmarks for image processing applications and saw about 1/2 the performance one might expect from the architecture. The same routines from Intel's hand-optimized IPP library for XScale were blazingly fast... This suggests that the chip is fine but we need a decent compiler that knows how to take good advantage of the XScale's pipelined architecture and instruction set.

So the big question becomes, why is Intel waiting for someone else to write the compiler? Ultimately, what's the point of making good silicon if you don't support it with decent tools?

Re:As an embedded engineer

[bgat]

Done any testing with gcc?

Stacked chips?

[PD]

Maybe this is the time for the silicon/silicone typo?

Another Xscale alternative

[toybuilder]

I've been working with the AMD Alchemy family chips. In our particular situation, it ran faster, used less power, and was priced much lower than the XScale chips that we considered.

It is a wonderful little piece of silicon with lots of integrated peripherals, low power, and great performance. It is built around a MIPS architecture processor core.

Linux-MIPS runs great on this chip.

Check them out.

Re:Another Xscale alternative

[ObviousGuy]

Alchemy's definitely got a good piece of hardware, but the demand we've seen for the platform has been pretty minimal.

The breakdown we've seen for platforms is something like 60% XScale, 35% x86, 4% Alchemy, 1% other (SHx, etc). The market for Alchemy just isn't big enough to make it worth our while to develop a solution for Alchemy. However, this does mean that an enterprising small company could fill that niche very nicely.

And this is great because...

[brejc8]

I cant see how stacking chips to make them smaller is going to impact the consumers (very much). They aren't lower power, faster or in any way what customers wanted. They are simply cheaper to produce and give better profit margines. Considering the ARM's are tiny I can't see how they can charge 20-40$ for them after the stacking.

Re:And this is great because...

[Anonymous Coward]

Um, I believe it says that they *are* lower power.

Re:And this is great because...

[brejc8]

Actually they dont. The submitter got it wrong.

XScale errata

[Anonymous Coward]

The first steppings of the XScale had many known problems. For example, the onboard cache was effectively disabled. Later steppings (like the PXA255) are much, much faster at the same clockspeed.

obviously better compilers would help, but there were plenty of hardware bugs to go around.

Re:XScale errata

[ObviousGuy]

We'll probably have to bite the bullet and readapt the kit at some point. There's going to be quite a few slow XScale-based devices out there for a while though.