Future ARM based processors for RISC OS? - RISC OS News, Software and Information

Future ARM based processors for RISC OS?

Published: 25th Jul 2003, 21:13:26GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

From ARM7 to ARM11 and XScale, our stocking wishlist

Editorial OS owners Castle recently stated that their 32 bit, HAL abstracted RISC OS 5 can be used in devices powered by ARM9, ARM10, ARM11 and XScale processors. This fact was pretty much obvious when Castle first revealed details of its 32 bit OS however it's worth looking at what's on offer in terms of ARM based processors.

StrongARM processor

Remember that these days ARM designs processor 'cores' which are the inner fundamental components inside processor chips. Usually, third party companies and manufacturers then license the rights to take these core designs and put them in custom designed chips to form a full processor. This means a company could take an ARM9 core and package it up in a chip that features LCD and wireless support circuitry to make a processor designed ideally for small portable devices.

So, it's therefore unusual to pick up a chip now with just an ARM processor core in it, like the processors in the ARM610, ARM710 and StrongARM daughter cards for RiscPCs. However, it does mean that ARM based processor chips contain built in useful functionality.

Processor cores suitable for RISC OS:

ARM 7 family [details]
We're all pretty much familiar with cores from this family, as seen in the ARM710 processor chip and the Cirrus PS7500FE. Cirrus offer other processors powered by the ARM 7 family including three chips aimed at portable products that use the ARM720T core. The ARM720T is a good modern core designed for embedded and low power products, like MP3 players and digital cameras. The core clock speed can run up to 100MHz.

ARM 9 family [details]
ARM920T based processor

We're now entering the territory of intelligent consumer based eletronics where Symbian OS, Palm OS, Linux and Windows CE roam. The ARM920T core can be used in products such as next generation mobile phones, PDAs and set top boxes and ARM suggest clock frequencies of up to 200MHz. Earlier this week, Samsung boasted an ARM920T based processor, clocked at 533MHz. Their S3C2440 chip, which features the ARM 920T core, is touted as "the world's fastest mobile CPU" and includes built in support for LCD displays, interface for a touch screen and support for USB.

ARM 10 family [details]
The ARM 10 family is aimed at digital consumer projects and also industrial control systems. While the ARM1020E core is a 32 bit processor with 16 bit Thumb support, a 64 bit internal bus and digital signal processing (DSP) extensions. It also has a clock frequency of 325MHz. We're not aware of any high profile use of this core although last year, Samsung spoke of using an ARM 10 core in a 400-600MHz processor for PDAs. Samsung also said last year they had an ARM core capable of running at 1.2GHz. The 1GHz barrier breaking ARM1020E compatible core, nicknamed Halla, was said to be ready for sampling by Q3 of 2003.

ARM 11 family [details]
The ARM 11 family is really pushing into specialised areas. This family of cores focuses on applications where memory is a premium and there is a need for high performance, real time processing with low power consumption. This means wireless, sub-notebook computers and networking devices. ARM offer clock frequencies up to 400MHz for this family. We're not aware of any ARM 11 cores being widely available, however around this time last year, the EE Times reported that ARM wanted to control the release of their ARM11 based cores.

Intel XScale [details]
Iyonix XScale processor

The XScale core is currently overseen and packaged into integrated chips by Intel as a result of Intel buying DEC and thus the StrongARM design that ARM and DEC created. The XScale was once upon a time dubbed the 'StrongARM 2' and current cores are ARM architecture and code compliant. The XScale core can be found in numerous flavours of processor chips that are highly integrated with additional features to suit the markets Intel are aiming at. Firstly, there's the PXA26x family of chips designed for wireless products and mobile phones - by now you've probably started seeing a trend in the suggested applications of these ARM based chips. The PXA26x family offers clock frequencies of 200-400MHz and supports storage cards (such as CompactFlash), USB and the Bluetooth wireless standard. The PXA255 processor also runs between 200 and 400Mhz and also supports PCMCIA, other storage card media, USB and Bluetooth wireless.

Next, we move onto the familiar XScale I/O processor family. The IOP321, as used in the Castle Iyonix, runs at 600MHz and provides PCI interface and DDR SDRAM support. The 733Mhz IOP310 is a two chip chipset but is slower than the IOP321 in terms of PCI bus speed and DDR SDRAM access speed. The IOP200 is unlike the other ARM based processors we've seen here as it's a straight ARM compatible processor with no special integrated abilities. It can have a clock frequency as high as 733MHz. You can read a run down of what the XScale IOP321 brings to RISC OS here.

Will we see ARM processors breaking the golden 1GHz barrier? We have to consider that ARM processors are going into mobile gadgets where power usage is critical or into devices that don't need to go beyond 1GHz. However, this may one day all change.

"Desktops today are (consuming power of) 75 to 100 watts and when you go to handheld devices you are typically operating at less than 1 watt," said Pat Gelsinger, Intel's chief technology officer speaking at the Intel Developer Forum in Japan last October. "Obviously, you are optimizing the design for different criteria. So today, if I was going to look at a StrongArm core or XScale core, could I create a 2GHz or 3GHz XScale today? Absolutely. Could I do so and deliver the best trade-off of power and performance inside a 1-watt envelope? No. You tend to design the chips differently to live inside different devices."

Summary
The bottom line is RISC OS can be employed on any available processor that features an ARM7 to ARM11 or XScale core and a suitable memory management unit (MMU). A processor's MMU provides flexible manipulation and control over the memory and memory mapped hardware in a device.

With these new processor cores unlocked, the leaping of RISC OS from the Iyonix to existing ARM based PDAs and similiar gadgets will rely on the availability of drivers for the proprietry PDA hardware. The HAL in RISC OS 5 enables the OS developers to adapt RISC OS to vital systems like hardware timers, clocks, interrupts and interfaces provided by new chipsets. With this and 32 bit compatibility out of the way, it's now largely down to the substantial work required to produce the necessary device drivers for newer hardware.

Links
RISC OS 5
ARM
ARM processor cores
Intel
Intel XScale processors
With thanks to David Ruck, Martin Wuerthner, Steffen Huber and Ian Jeffray for their individual assistance.

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

ksattic 26/7/03 12:08AM	Nice article! Are there any plans for an FPU co-processor for these ARM processors? -- Simon Wilson, Boulder, Colorado
nex 26/7/03 12:12AM	ARM based, wtf does ARM based mean?
Snig 26/7/03 12:21AM	Don't worry nex I'm sure it's armless.
ksattic 26/7/03 1:26AM	*In reply to nex:* ARM don't make processors, they design processor cores. When manufacturers licence the cores, they integrate them into their own processor design. Hence, an ARM chip you buy is based on ARM technology. -- Simon Wilson, Boulder, Colorado
diomus 26/7/03 3:03AM	*In reply to ksattic:* Gah, I left that FP issue out, accidentally. The ARM1020E core can have a VFP10 co-processor floating point unit that delivers up to 650 MFLOPS, according to ARM. Chris, drobe.co.uk
ksattic 26/7/03 3:11AM	*In reply to Chris:* NICE! Gimme one of those and a compatible ARM motherboard/chipset please! -- Simon Wilson, Boulder, Colorado
JGZimmerle 26/7/03 10:58AM	Hi Chris! 650 MFLOPS at 325MHz. A 1.2GHz version would be a lot faster. Only problem with it is, that it is not compatible with the old FPU in the 7500FE. But I guess one could make a SuperFPEm that takes advantage of it. -- Julian G. F. Zimmerle
mavhc 26/7/03 11:11AM	Or just pay one of the 53 companies that have the source code now Does compatibility matter? Is there enough old FP code to bother making a conversion module?
Dougal 26/7/03 11:41AM	So, wearing my contraversial hat, doesn't it worry anyone that your platform is stuck on using embedded processors? It worried me as an Apple user a little - I was concerned that I bought into a platform that couldn't keep up anymore. Motorola had no clear plans to speed up the G4 (which was essentially an embedded systems processor), it was only by going to IBM who championed PowerPC as a high-end platform that Apple managed to get back in line. I know processor power isn't the be all and end all, but if you're doing lots of compile work or scientific work (like I do), or want to play modern games, multimedia editing software, etc., then it helps at times -- Dougal
AMS 26/7/03 12:39PM	Good article Chris ! *In reply to Dougal:* Yes it is of concern that ARM is being targetted at "embedded" only devices. If I am correct Apple is still a major shareholder in ARM, if that is correct it follows that they would be less keen on seeing a "fast" ARM being used in computers that could compete against their boxes. The problem for ARM though is that with PowerPC and MIPS processors beginning to encroach into their territory ARM simply sitting on their hands (if you pardon the pun) won't do. It would be monumental folly to restrict the ARM to such a degree that some of the bigger players could simply "cut" some bits out of a high end processor and then drop down into ARM's niche and compete or even outperform the ARM. Perhaps ARM won't "officially" up their specs, but Samsung's HALLA (ARM10) may already represent a company off it's own bat upping the spec. Samsung have shown upping the ARM spec can be done (incidentally the HALLA puts out 1.5 Watts at 1.2GHz, so it's not that far outside Intel's 1 watt envelope, so perhaps Intel will be next - who knows). Again a good article.... -- Annraoi McShane,
thegman 26/7/03 1:15PM	I don't think that Apple will be too concerned about RISC OS competing with their boxes Being restricted to embedded processors is not so bad, MIPS is primarily an embedded chip and gets very fast indeed. SGI use them in some of the fastest workstations and servers in the world, and even the embedded ones are fast, 2x1Ghz cores on one chip. The only problem with an embedded processor, as stated above, is that speed is not the number one priority like it is with P4,G5 etc. But Intel,Samsung, and ARM themselves still want to see the ARM go faster, particularly if they want to go into markets like high end routers etc.
Dougal 26/7/03 1:49PM	*In reply to AMS:* I think you do ARM a disservice by saying they sit on their hands - they certainly do not. As one of the leading providers of embedded processor cores they are doing increadably well (and they're British - how confusing!) and having visited them I saw a very aggressive team determind to keep it like that. The point is that ARM are world leading experts in embedded processors, and as such they're unlikely to start thinking about going into other markets like the desktop arena. For that to happen there would need to be a large market demand, and RISC OS certainly isn't that. One of the reasons Motorola never really got its act together for faster PowerPC devices is that Apple as a Motorola customer is a small customer compared to the embedded device consumers. thegman is right - both SGI and Apple have made embedded processors do wonderful things, but again I'd argue that the ARMs target market is low power. I don't know the numbers, but I'm willing to bet that the G4 burns a lot more energy than an ARM device (and see the Intel quote in the article). Until someone produces an ARM design that's less concerned about power then it's still going to be a tardy thing in terms of raw performance. There's nothing particularly wrong with this (it's environmentally friendly for a start but the trade off is that some of the popular apps that people are starting to expect need more horse power., and without which I image Castle et al will have problems getting new people into the market rather than just selling machines to existing customers. -- Dougal
mavhc 26/7/03 1:58PM	Just need to put 64 ARMs in 1 computer, problem solved.
AMS 26/7/03 2:04PM	*In reply to Dougal:* I think you misunderstood what I meant, I mean that ARM are not really "pushing" the performance of their platform (for example ARM v6 is scheduled to hit 650->1GHz by Q4 2004 -the end of NEXT year). But Intel's IOP321 already is more or less there (at 600MHz) and Samsungs (ARM v5) Halla is ahead (1.2GHz), so why hold back ? By not "pushing" the envelope at all ARM are even falling behind what their licensee's are managing. I do not see any technical reason why ARM cannot have designs that cover the full gamut from hand held up to server processors. Unfortunately they don't, thing is Motorola/IBM or SGI (MIPS) are not as limited, they can hawk their wares to any company and assure them that their processor range covers everything from hand held battery powered devices up to high end servers. Why limit your market - that limits your possibilities doesn't it ? -- Annraoi McShane,
Dougal 26/7/03 2:15PM	"I do not see any* technical reason why ARM cannot have designs that cover the full gamut from hand held up to server processors."* But are you a processor designer? I've done some work on processor design (my PhD thesis was about extending an ARM processor to do whizzy stuff) and I don't think even I'd make such a sweeping statement The ARM ISA is a bit long in the tooth - it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures. Certain design decisions in the architecture that were fantastic at the time do not scale well these days (e.g., putting a barrel shifter on your critical path). Adding extra function units to an ARM processor requires the use of the coprocessor interface, which for load and store instructions requires the main integer unit to be tied up, so you can't superscale the ARM particularly well. My point is that there is no way that an ARM processor based on the current ISA will scale to compete in the server market. ARM, like a lot of chip companies, are customer focused. They listen to what the customers want, and then they take the features that will shift the most chips and build them in. Look at the Java support for instance. "Why limit your market - that limits your possibilities doesn't it ?" It's also social issues. Do they have enough expertise in the higher end markets? How much would it cost to try and design a higher level calss ship in terms of man power and what is the likelyhood it'll make real money up against the existing competitors? Can they tackle it without taking their eye off the embedded market too much? I disagree with you: I think ARM are probably doing the right thing by sticking with what they're good at. -- Dougal
epistaxsis_RISC OS 26/7/03 2:52PM	Groovy article. Erm - is it just me but isn't there an advantage for RISC OS with these embedded processors? Here is the example: Iyonix - once the 32 bit stuff & HAL done then a machine appears. A lot of what that machine is (DDR & no AGP) is perhaps because it was already on the chip? Omega - MD have to design RISC OS specific chips. Omega uses a "pure" processor. A [i]massive[/i} task. Result - machine is 3 years late. All credit to MD for actually getting the thing to work. RISC OS companies are tiny. I doubt that anybody has the resource to quickly bring a new RISC OS machine to market even now without using these embedded jobbies to short circuit some design issues. Last point.... Why is 1GHz so "magical" - does RISC OS really need it? Or we do need it because of the FP problem?
AMS 26/7/03 3:46PM	Eh Dougal, I am allowed a sweeping statement now and again Yep I am not a processor designer, so I'll accept that the ARM as it currently stands would not do as a Server CPU. In addition to what you say above it lacks bus snooping so making it work effectively in a multiprocessor or shared memory environment would be difficult. That having been said some of your assertions may still warrant a review, for example you say " it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures", true but many current server and desktop machines are usually x86 that have even fewer registers. What I was really focussing on would be thinks like why is the cache so small (making it bigger should not be a problem 16+16KB seems a bit restrictive). Not endorsing higher clock rates seems a bit of a downer as well (especially when some licensees have shown that they can) As to the market ARM are in ARM selected it before they had any customers. And as to your last comment that ARM are "doing the right thing by sticking with what they're good at. " that's precisely what Acorn did by sticking to the education market - and we all know what ultimately happened to Acorn don't we ? That having been said you've raised some interesting points, and although server may be aiming a bit high surely producing a compeditive desktop processor shouldn't be ? Bear in mind as well although ARM may not have the manpower to do an upscale design - bear in mind Samsung, Intel et al may so ARM should encourage them to get on with that. ARM would simply ensure compliance with the ISA and wide availability of architectural improvements if and when they come on stream (all IMHO) -- Annraoi McShane,
thegman 26/7/03 4:37PM	I think that ARM does need to go to GHz levels, or make performance better at current levels. Clock for clock, ARM chips seem to be about the slowest you can buy in a desktop computer, for most tasks. Also, if new RISC OS machines came out with a massive speed increase over existing models, people would be more liikely to upgrade. I'm not qualified to talk about ISAs and whether the ARM needs more registers or whatever, but it certainly does need to go faster to be serious on the desktop.
epistaxsis_RISC OS 26/7/03 5:52PM	*In reply to thegman:* running which OS? For a full desktop environment RISC OS is still remarkably efficient. unless this is to get around the software FP emulator issue?
thegman 26/7/03 6:34PM	*In reply to epis:* I should have clarified that statement: For stuff like C,Python,Java(Kaffe),web browsing, and graphics work, my RiscPC was very slow compared with my other machines. RISC OS is extraordinarily fast on slow hardware, granted. I have read that Linux tends to benchmark faster though. However my experience with Linux and other UNIXes, is that you can't buy a PC fast enough to make it as 'snappy' as RISC OS. I would like to see some benchmarks against other machines, I'm using a PA-RISC laptop right now, which feels sluggish, but would be interesting to see how it weighs up against RO boxes for comparable tasks. I think most of us here are not that bothered about clock speeds, but we are bothered about real-world speeds, which IME ARM does not do so well.
Dougal 26/7/03 7:46PM	*In reply to AMS:* Some how I doubt ARM will pursuade Intel to make a version of the XScale that could eat into the Pentium market, their cash cow. Note also that low end sever and high end desktops are using the same processors these days. You're not going to get that performance out of the ARM ISA as it is. And then if you design a new ISA you might as well go otherwhere. As for Samsung, they had the Alpha and failed to do much with it, so I wouldn't count on them taking the ARM anywhere upwards. BTW, one assumes the caches are small due to power concerns. The bigger they are the more power they consume. For an embedded device, which only does one thing very often, smaller caches are fine. -- Dougal
mavhc 27/7/03 12:12AM	The slowest part of the computer is usually the human/computer interface, the conclusion is obvious.
dansguardian 27/7/03 10:56AM	*In reply to Dougal:* whats this ISA you keep mentioning?
Dougal 27/7/03 11:08AM	*In reply to dansguardian:* Sorry, ISA = Instruction Set Architecture. Basically it covers the semantics and syntax of a processor from a programming point of view (what registers are available, what instuctions can be performed, etc.). An ISA can have many different implementations, but all should be able to (more or less) run the same software. *In reply to mavhc:* care to cite the scientific study that shows that? Persumably, for your sweeping statement, it shows that for all possible users for all possible applications, that the UI is the slowest thing. So when I set hardware simulations running that take days to complete, it was the UI I used that caused it to take that long? -- Dougal
goon 27/7/03 11:20AM	There's a new device from PsionTeklogix that uses the XSCALE unfortunately it also runs on windows CE.NET! shame..
mavhc 27/7/03 12:39PM	No, just usually. As in for 75% of the peopletime
AMS 27/7/03 1:47PM	*In reply to Dougal:* But you say "As for Samsung, they had the Alpha and failed to do much with it, so I wouldn't count on them taking the ARM anywhere upwards." Thing is Intel bought out DEC who sold their Alpha fab plant, Alpha was still second sourced by Samsung - but with Intel having "taken out" DEC where was Samsung to go. I'd also point out that some of the techniques Samsung have used with their ARM10 (Halla) were taken directly from their experience of developing their variant of Alpha (and Halla is the fastest ARM10, ARM were only aiming for 350-400MHz (ballpark), Samsung managed 1.2GHz). As for the ARM ISA it has some nice touches like conditional execution (and being able to avoid a branch is a useful way of keeping pipeline running efficiently I would have thought). Yes more registers would be nice, but (again) as I said the x86 manages with fewer - where the ARM really does fall down is the relatively low clock rates and small caches - improve those two and in conjunction with the efficiency of RISC OS and we would wind up with a platform that could take on everything but the very fastest (read expensive) processors. I'd also point out that later MS O/ses (such as 2003 Server with .NET, and Longhorn (whenever it finally appears)) will also sap performance improving our chances of catching up. Kind Regards -- Annraoi McShane,
epistaxsis_RISC OS 27/7/03 2:04PM	*In reply to goon:* yeah I heard about that one. crazy! perhaps psion can't afford EPOC (sorry - symbian) anymore? Anyone want to sell them galileo again? Joking!
Spriteman 27/7/03 3:26PM	If I can just pick up a few points raised by AMS: *In reply to AMS:* <Dougal says> " it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures", true but many current server and desktop machines are usually x86 that have even fewer registers. This is as much a question as a comment but I was under the impression that part of the risc philoshophy was to have fewer instructions and more registers. I'd guess that somehow the disadvantage of not having a dedicated instruction for everything is made up for by having loads of registers. Perhaps Dougal can enlighten us. *In reply to AMS:* What I was really focussing on would be thinks like why is the cache so small (making it bigger should not be a problem 16+16KB seems a bit restrictive). Not endorsing higher clock rates seems a bit of a downer as well (especially when some licensees have shown that they can) Of course, both a bigger cache and a higher clock rate have detrimental effects on the power consumption. With the market that ARM are focused on, it would seem that they prefer the balance they have. *In reply to AMS:* As to the market ARM are in ARM selected it before they had any customers. I'm not sure how true that is. Obviously, before ARM was ARM, they concentrated on making processors for desktop computers. I don't know what came first. The customers interested in their low power processor or ARM themselves going out to attract the low power market. *In reply to AMS:* And as to your last comment that ARM are "doing the right thing by sticking with what they're good at. " that's precisely what Acorn did by sticking to the education market - and we all know what ultimately happened to Acorn don't we ? That depends on which stage of Acorn's life you are referring. It's true that they may have been able to push the Archimedes into markets outside of education. They tried that with the beeb but one could argue that the machine was already a bit dated when they did that. Or perhaps the concepts were ahead of their time. Towards the end of Acorn/E14, education was hardly on the agenda. The company seemed to have lost focus. And that is one thing you can't say of ARM. They seem to know exactly what they are doing and they are having great success in doing so. Lastly, do we really /have/ to have an ARM processor? If it weren't for the fact that RISC OS is so closely tied to the ARM wouldn't we be just as happy with another processor type? I hear that IBM are doing some nice things with PPC risc chips. -- Spriteman.
Dougal 27/7/03 3:56PM	AMS & Spriteman: I'd speculate (and I'm just guessing here) that the reason ix86 can get away with fewer registers is that as a CISC architecture it needs less intermediate results. The RISC idea is to only have basic instructions, no composite instructions (like string copy in order to make the processor design simpler and then clock higher. From this it seems that you need more explicit data storage for intermediate results on a RISC processor as you build up the larger operations from the basic ones provided to you. Like I say, look at the big RISC chips and they have lots of registers. *In reply to AMS:* Yes, ARM have conditional instructions, and I won't disagree with you that it is very handy when writing ARM assembly (which I've done a fair amount of in my time), but then look at the designs for modern high speed processors - they all separate out the control flow instructions into a separate exection unit to try and increase instruction level parallelism (IPL). On the ARM you can't do this, as almost every instruction is potentially conditional. I think this feature is nice for software writers, but the moment you get to having the processor issue instructions out of order and in parallel groups then it's not so nice. *In reply to AMS:* regarding just ramping up the clock speed, like I've pointed out, it's not that easy - that barrel shifter in there really does slow things down. And, as myself and Spriteman have pointed out ARM don't see this as a big seller right now. If ARM had a majority of customers demanding such highly clocked ARM chips they'd be going for it I'm sure. As it is ARMs biggest customers are not people that try and stuff ARMs into desktop machines, not even PDAs I'd wager. It's people like, mobile phone companies (from bumping into ARM people I know ARM have a strong relationship with Nokia at least), who shift vast number of units that absolutely have to have low power. *In reply to Finally:* ARM originally was part of Acorn and designed their first ARM chip using just a handful of engineers who'd never made a chip before. It's still seen as a fantactic achievement in the industry that it worked so quickly. But the original ARM chip was aimed at a desktop device. ARM, since being spun off, have then over time drifted into the embedded market as they had such a low power chip in the ARM. Partly one imagines this drift will also have been in some small amount due to Apple's influence when it bought a large stake in ARM in order to get the Newton it's processor (note, I'm fairly sure this is no longer the case - I think Apple sold it's shares in ARM a while back). Anyway, I'd best do some actual work -- Dougal
Use the forum for more comments on this article