52 replies to this topic

[kanzlr]

according to the ARM official cortex site, the slowest A8 available runs at 650MHz, and ED once said it will default to 800MHz, well

[atomicthumbs]

openpandora.ca has some info at the bottom of the page that was not there before. I know it's been mentioned elsewhere, but atleast it is new news. 550MHz CPU, 128DDR 333MHz and 256MB NAND.

I'm sure FAQs, and blogs will come along soon. It'll be really good in no time, once we all et to see what can be done with the dev boards. That'll be entertaining enough for me until April.

As I said, it's hiding.

[Stealth Bagel]

according to the ARM official cortex site, the slowest A8 available runs at 650MHz, and ED once said it will default to 800MHz, well

Didn't he also say the GPU would be 1600 MHz, which is complete off the wall nonsense.... even the most advanced PC-based video cards don't have RAM clocked that high. And we're talking about a graphics block roughly on par with a GeForce 3 not an 8800GTX.

Every impression I got from M. Weston (who really seems to be the brains behind this entire project, rather than marketing/financially involved) was that the OMAP3 chipsets have NO set clock and only a range within they CAN operate, the selected frequency is dependent on the whims of the device manufacturer and what application they are aiming for; e.g. a cell phone using the chipset would be clocked lower and a gaming device would be clocked higher. It should be simple to adjust the internal PLLs by manipulating registers in software though. That's a standard feature on modern SOC chipsets... even fly by night chipsets like gp2x's mmsp2 could do that.

I strongly suspect each omap3 will have a different top speed, and it will also vary based on core voltage selected. Hopefully that is a software adjustment as well made available to users... with a warning, I'm sure, that if they exceed the operational spec of the omap3 their warranty wouldn't cover it. Though with conservative adjustment for short periods of time that sort of tweaking is usually pretty harmless in my experience.

[Aquilus]

Official information about the ARM Cortex-A8 can be read here.

[Squidge]

To give you a rough estimation of the new chip, I've compiled an emulator for the gp2x, noted down some performance figures from various roms, and then run the exact same executable on the new platform (No recompiling or whatever, so no platform-specific optimisations).

The new platform was typically 3x faster. I'll let you guess how fast it will be when it is compiled for the Cortex (ARMv7) rather than 920 (ARMv4t), and then you have other hardware acceleration (and lets not forget this is all running on an unoptimised Linux kernel, drivers/etc, with early hardware).

Oh, and the clock speed is a little on the conservative side at the moment, too

Like they say, the only way is up

[atomicthumbs]

on the new platform

!!!

[MWeston]

Didn't he also say the GPU would be 1600 MHz, which is complete off the wall nonsense.... even the most advanced PC-based video cards don't have RAM clocked that high. And we're talking about a graphics block roughly on par with a GeForce 3 not an 8800GTX.

Every impression I got from M. Weston (who really seems to be the brains behind this entire project, rather than marketing/financially involved) was that the OMAP3 chipsets have NO set clock and only a range within they CAN operate, the selected frequency is dependent on the whims of the device manufacturer and what application they are aiming for; e.g. a cell phone using the chipset would be clocked lower and a gaming device would be clocked higher. It should be simple to adjust the internal PLLs by manipulating registers in software though. That's a standard feature on modern SOC chipsets... even fly by night chipsets like gp2x's mmsp2 could do that.

I strongly suspect each omap3 will have a different top speed, and it will also vary based on core voltage selected. Hopefully that is a software adjustment as well made available to users... with a warning, I'm sure, that if they exceed the operational spec of the omap3 their warranty wouldn't cover it. Though with conservative adjustment for short periods of time that sort of tweaking is usually pretty harmless in my experience.

Yeah, not sure where ED got those numbers from, but I did try to clear that up in a different thread a while back. The graphics core in all SOC's is a fractional value of the main processor clock. It would be impossible to keep the pipe full if the clock was anywhere near the processor clock and would completely dominate the memory bus. The result would be degraded performance at an ever higher power consumption! The graphics core does have a set clock speed that will be made available when Pandora is released.

The ARM core clock speed doesn't seem to have a pre-defined speed. TI seems to expect their customers to clock the chip at a speed that suits their needs for battery life but then we aren't using a tiny little battery like you would have in a cell phone (which is where these chips usually go) so we should have more freedom to speed it up as we see fit. Development kits are set at 440MHz and 550MHz and of course they have that news report at 1GHz. It will probably be a very dynamic setup for Pandora: low clock for things like the main menu, MP3 playback, and some video playback and then boost the clock for apps that need it (like emulators and web browsers).

[Chip]

The ARM core clock speed doesn't seem to have a pre-defined speed. TI seems to expect their customers to clock the chip at a speed that suits their needs for battery life but then we aren't using a tiny little battery like you would have in a cell phone (which is where these chips usually go) so we should have more freedom to speed it up as we see fit. Development kits are set at 440MHz and 550MHz and of course they have that news report at 1GHz. It will probably be a very dynamic setup for Pandora: low clock for things like the main menu, MP3 playback, and some video playback and then boost the clock for apps that need it (like emulators and web browsers).

So TI doesn't give you an upper limit. Interesting. Have you done any torture testing to determine a safe upper limit, or will it be more like the GP2X where it is a matter of luck what your particular unit can handle? I'm concerned about applications being released with a very high clock speed because it works fine on the developers unit, only to have it cause other units to destabilize.

I know extensive testing of every single unit you sell is probably not an option, but a "generally acceptable" max freq. guideline would help to at least discourage potentially harmful overclocking. I'm not suggesting higher frequencies be somehow locked out, instead an official policy of "All units should operate correctly up to XXXMHz". Anything beyond that would be at-your-own-risk.

[whiskthecat]

I'm concerned about applications being released with a very high clock speed because it works fine on the developers unit, only to have it cause other units to destabilize.

Well if unoptimized code is running 3x faster on what Squidge calls a "conservative" clock speed, I think the clock will probably be adjusted down for optimal battery life since performance is so good. This would apply to almost all systems being emulated older than the ps1.

[A_SN]

I'm concerned about applications being released with a very high clock speed because it works fine on the developers unit, only to have it cause other units to destabilize.

Well if unoptimized code is running 3x faster on what Squidge calls a "conservative" clock speed, I think the clock will probably be adjusted down for optimal battery life since performance is so good. This would apply to almost all systems being emulated older than the ps1.

Well it's not just unoptimised, it's jut not using the full instruction set, like running a 486 binary on a modern CPU with MMX, SSE1/2/3 etc..

As for the battery life, as Exophase (iirc) keeps saying, if this thing has proper V-Sync wait, then we won't need to downclock to save battery life, as hardly any power will be drained while the main running program would wait for the V-Sync. That means full speed all the time and optimised battery efficiency. Now it all depends on how V-Sync is actually implemented.

[Squidge]

For some applications, it may be easier to down clock the unit, rather than rewrite the programs so they use the hardware properly. It all depends on how they are written.

But for new applications, there should be no need to down clock.

(I won't say "under clock" as there's not really an official "It should run at xMhz")

[A_SN]

But for new applications, there should be no need to down clock.

Yay! So that means proper V-Sync, doesn't it?

By the way, what did you mean by conservative clock? Exophase thinks it means 600 MHz instead of 550 MHz, I rather thought about 800..

[icurafu]

ARM may think the minimum is 650MHz, but TI has stated 450MHz as the minimum likely to be used for phones.

We don't have any indication on how they will overclock.

The units that use close to zero power when in standby are not supposed to clock super high. The 1GHz and above units are all processed using the GP process which goes even above 1.1GHz on standard.

http://www.arm.com/p..._Cortex-A8.html - It's all at the bottom. At 650Mhz we can expect 0.38W.

Edited by icurafu, 10 January 2008 - 12:05 AM.