What is the maximal speed a StrongARM (or an XScale) can talk to external memory?
For instance an Intel P4 has a 'front side bus' that operates at 100MHz quad pumped - it can talk to its RDRAM memory at effectively 400MHz over 64bits giving 3.2Gb/s bandwidth to the memory which is also capable of providing 3.2Gb/s.
What are the related terms and numbers for a StrongARM/XScale system?

We know that the Imago uses a 128bit 'bus'(?) at ~100MHz, and I've read that this provides more than enough bandwidth, the rest used for the graphics chip.
But will it actually be faster than whatever setup Omega uses? (which also has the graphics chip sharing main memory iirc)

Is there any point in using recent high-performance memory systems like RDRAM or DDR-SDRAM with an ARM-powered system?

Those are my questions, but if anything has anything intersting to say on the topic (or closely related ones), please speak up.

Is there any point in using recent high-performance memory systems like RDRAM or DDR-SDRAM with an ARM-powered system?

If you're willing to pay the price RDRAM would be great but even Intel has considered dropping it because of the price. People have moaned about high prices for RISC OS hardware and I doubt that those same people would take it quitely.

I think there are several things more important than thinking of higher performance memory, like getting a computer with processors and motherboards that can actually use that memory.

In the Imago the total available memory bandwidth (assuming 100MHz*128Bits) is 1.6GBytes/Sec, the xScale would (therefore) only use just under 50% of total bandwidth.

The Omega uses (according to the MD website) PC133 RAM, therefore 133MHz x 64 (just over 1.01GByte/sec). As before video subsystem shares memory with the processor so xScale would use 75% of the available bandwidth. Video and all other resources would get just 25% of the bandwidth.

From that (crude) analysis the available bandwidth for video (or coprocessors) on the Omega is around 25% while on the Imago it is about 50% (bear in mind the difference in the absolute values are even larger). So the short answer to Sendu's question is that in both cases the available memory bandwidth is GREATER than xScales, so the processor will execute equally quickly on either.

However there is a catch, the Omega will be using the bulk of its available bandwidth for xScale, leaving only 25% for video. This means if you use a high bandwidth mode (say 1280x1024x24 bits) that bandwidth would limit refresh to about 67Hz (requiring a video bandwidth of 252MBytes/sec). The same sum on the Imago would be 203Hz (best of luck finding a monitor with that refresh rate mate !). Both processors would perform as fast, the video on the Imago would be at a higher refresh rate (limited only by the monitor). At higher resolutions, however, the Imago moves ahead (because at higher rates the Omega will have to "stall" the processor to allow the video priority). Whether this matters to you or not depends on if you are likely to operate at stratospheric resolutions like 1600x1200 or not !

Its like the old days of the BBC Model B, when you ran a high bandwidth mode (like Mode 0) things ran slower but when you switched to lower bandwidth modes processor performance improved. The difference now is this effect will only become pronounced at very high resolutions and will appear sooner on the Omega than the Imago.

[Edited by 144 at 21:19, 17/12/2000]

[Edited by 144 at 21:20, 17/12/2000]

Bear in mind for (say) if you allocated 300MBytes per second for video you'd get 80Hz refresh (better) at the expense of a reduction of available bandwidth (for processing) from
763 to 714MBytes/sec (a speed reduction of 6.4%) which begs the question who'd notice?

Incidentally the highest resolution/colour depth mentioned on the Microdigital site is Up to 2048 x 1536 x 24 bit colour@72Hz (that translates as 648MBytes/sec). This means your xScale will be hit (somewhat harder) at that resolution (the bandwidth for processing and other I/O drops to 366MBytes/sec (a drop of 52%)). But as even at half speed it will still run rings round a RPC I would not worry too much.

Lower resolutions will offer higher refresh rates and/or higher processor performance than that (again the above is a "worse case scenario" with the processor starved and the video subsystem given priority).

Oddly enough the Omega initially will be using the SA-110 (StrongARM) rather than xScale, as this has a lower bandwidth than xScale it's performance will be less effected than xScale, but as its slower than xScale to start with xScale will still be faster, its just that SA-110 users will perceive less of an effective loss in performance (the SA-110's bandwidth is 251MBytes/sec somewhat less than the lowest available bandwidth on Omega for processing so it will not be effected at all !).

Please don't go away thinking that that means SA-110 is better than the xScale on Omega, yes its less sensitive to the bandwidth demands of video but its also slower (and even a hamstrung xScale will STILL be faster than the SA-110). Remember that the xScale cache is larger and this will somewhat counter the effect (when running processor intensive code).

[Edited by 144 at 20:20, 19/12/2000]

And don't think XScale will be 'too fast'. I for one got used to StrongARMs speed pretty fast and I'd find the idea of slowing it down, even to above ARM7 speeds, unacceptable.

It means, for myself at any rate, I've got a very good reason for going with Imago - which is what I wanted to know. I wanted to know if the tech in Imago actually gave the user advantages in real-world use. Now just gotta save up...

Sendu, what resolution do you need, in which application and why ? Just to make sure there aren't alternative solutions to your problem.

Full colour is a must, 1280x1024 is a minimum - I'm using Photodesk, creating collages, dealing with multiple images at once, so the more screen area (the higher the res) the better. But I don't want to be sitting around for half a year as a slowed-down processor copes with the demands of Photodesk.

Of course right now I'm making do with 1024x768 at 32k, but this is limiting my work (and pleasure!). I also find my SA desperately slow compared to my pc laptop for many global operations. There's no way I can get enough speed.

Full colour is a must, 1280x1024 is a minimum - I'm using Photodesk, creating collages, dealing with multiple images at once, so the more screen area (the higher the res) the better. But I don't want to be sitting around for half a year as a slowed-down processor copes with the demands of Photodesk.

Of course right now I'm making do with 1024x768 at 32k, but this is limiting my work (and pleasure!). I also find my SA desperately slow compared to my pc laptop for many global operations. There's no way I can get enough speed.

At 1024 x 768 x 24 bits there would be NO SLOW DOWN of EITHER SA or xScale. At the more useable 1280 x 1024 x 24 bits (with 80Hz refresh) the SA would not slow down and worse case the xScale might slow by around 6% (bear in mind overall its already x3 times faster than your existing SA so the reduction would not be noticed except when compared with itself).

The best analogy is that the SA is a Ferrari F50 and the memory bus on the RPC is the M25 at rush hour(s). Great car but no way to hit 200mph I think. Put the same car on a race track and it shows it true performance. The SA appears slow because its on the M25. The Omega and Imago are Monza.

I've seen a normal 233MHz StrongARM on the Imago prototype moving a full screen megapixel display in real time with breathtaking smoothness. You could NOT do that on an RPC with an SA-110 at 233MHz because the bandwidth on an RPC is 64MBytes/sec on an Imago its 1600MBytes/sec and an Omega its just over 1000MBytes/sec. So Sendu comparing your existing machine with a fundementally different architecture and imagining the same slow down happening to your machine is unfair. At its slowest an SA will ALWAYS be faster in one of these new architectures than on the RPC (just look at those bandwidth figures !).

The Omega (giving the very WORST case scenario) would ALWAYS provide enough bandwidth to ensure that the SA-110 would be running FLAT OUT. It would NOT slowdown as there would always be enough excess bandwidth in Omega to cope. In fact the lightning chip would not support a resolution or refresh rate high enough to slow the SA.

The only issue is how will xScale fare. It may be able to shift data so fast that when run in high resolution modes and when running code that does not favour its cache (lots of I/O for example) then the memory bus (on Omega) will become limiting.

But remember when running internal code xScale may be over 3 or more times faster than the old SA in addition its I/O performance will always be better than the SA. Its just that compared with itself at lower resolutions it will slow slightly where code is such that lots of I/O is performed. Code that runs entirely in cache will NOT be effected irrespective of the resolution. Very worse case is a 52% slow down when at the limits of the lightening chip and at that as its already 3 or more times faster than the SA on a fast bus, it will STILL be faster and by a margin even at the highest resolutions.

Worry not I think !

Will I be able to encode MP3's at any reasonable sort of speed on the Omega with or without X-Scale?
(Given that I can do a 4 minute song in about 30 seconds on that other machine of mine)

As the SA is run at 287MHz (rather than 233) on Omega the minimum improvement should be proportional to that (23% faster). It will probably do somewhat better than that as some memory read/writes occur during MPEG3 encoding. So the short answer is somewhere between +23% and +400% (the exact amount depending on the ratio of internal register operations and external memory accesses, that being determined by the software used).

Its like the old days of the BBC Model B, when you ran a high bandwidth mode (like Mode 0) things ran slower but when you switched to lower bandwidth modes processor performance improved.

No you are wrong here the Model B did not use any software overhead in it's graphics system. Graphics data was accessed at a constant rate and then serialised if a higher resolution was required. There was no processor bandwidth hit. You're not mixing it up with the Spectrum are you?

Mind you MODE 0 always seemed slower when running certain timed tasks (like screen scrolling) when compared with some other modes (particularly MODE 7). Perhaps that's down to other reasons.

This does not take away from the fact that at higher resolutions the Omega will be faced (in the case of xScale) with a bandwidth restriction on the processor at very high resolutions and bit depths that may reduce the performance of the processor (the exact amount will depend on the efficiency of the cache system on the xScale).

However there is a catch, the Omega will be using the bulk of its available bandwidth for xScale, leaving only 25% for video. This means if you use a high bandwidth mode (say 1280x1024x24 bits) that bandwidth would limit refresh to about 67Hz (requiring a video bandwidth of 252MBytes/sec).

Wait a minute, given that most people find 67Hz unusable, doesn't this mean Omega won't be able to do full colour 1280x1024 without slowing down? We're not talking ridiculously high resolutions here. This should be a _minimum_ resolution for a new machine.

I for one am greatly disapointed.

are there any plans with Millipede for the Imago board to support the XScale processor???

Short answer yes (please refer to their website). They had an xScale on show at Epson, although it was not yet integrated into the motherboard.

A supplemental point is apparently (according to the Cerilica website) they are commited to provide Imago boards as an upgrade option to existing RiscPC users. For those on a limited budget this may be a more cost effective option than the £2000 Nucleus. Although mind you the Nucleus is seriously funky

dont forget the point that the Xscale will also have its large cache to help it along, with its SIMD instructions too.
U also got the Lightning card to help with any 3D stuff too

As long as the application understands this. I don't think any RISC OS applications are 3D aware...yet.

regards,

Malcolm

400% would be nicer
It would also be realistically usable.
I shall look forward to doing some tests with it, when it arrives

Sadly its more likely to be closer 23% than 400% but it all depends on how well the encoder is written and the mix of FP and I/O instructions used. Still any improvement is still an improvement.

The xScale would give better performance (around x3 times that of the SA-110) and the ARM10 might even fair better (its Vector FP unit is faster than most PC's clocked at 2 or 3 times its speed). The improvement in the case of xScale and ARM10 is due to the fact they have much more efficient caches (the internal cache on the xScale manages a stunning 4.8GBytes/sec) and better FP support (or SIMD in the case of xScale). The encoder would need to be targeted to use the new instructions to acchieve the full improvements promised.