A physical Dummy, Power Usage and MIPI

[ExquisiteCorpse]

Man I was just reading about the Allwinner A80 board and that sounds amazing!!

it can switch from the duel A15 processors to the A7 processors to conserve power if CPU power is not being used so we'll get amazing battery times

But most of all....it supports Open GL 3.0!!!

Moving to Open GL makes so much more sense on the next device. So much stuff will be able to be ran.

 

[EvilDragon]

Man I was just reading about the Allwinner A80 board and that sounds amazing!! 

it can switch from the duel A15 processors to the A7 processors to conserve power if CPU power is not being used so we'll get amazing battery times

That's not A80 specific, that's the ARM big.LITTLE technology

About the minimum speed the normal OMAP5 seems to be able to run is about 1GHz Pandora speed.

Apps using less than that would probably gain from that.

But one thing that would interest me:

At least on the OMAP5, the cores use less power when idling (similar to the Pandora), so you need less power when doing small tasks anyways.

Has anyone informations about the difference in power consumption between the A7 and A15 here?

What would we REALLY safe from using big.LITTLE in this case?

But most of all....it supports Open GL 3.0!!!

Moving to Open GL makes so much more sense on the next device. So much stuff will be able to be ran.

I'm not sure Allwinner will release an OpenGL 3.0 Linux driver - it might be it'll only be available for Android.

We don't know this yet and I don't want to say they won't do it (or we can't use the Android driver), but it's something you need to be aware of as well.

 

[_wb_]

There probably is something to gain from real big.LITTLE in terms of power consumption, but I think the difference would be most noticeable if you have lots of background processes going on that are constantly doing some low-cpu-load stuff, e.g. on an Android phone. If you cannot let the cpu enter deep sleep, it's better if you only have to keep an A7 awake than if you have to keep the A15 awake (wasting most of its time on switching between power states).

But it's probably better to ask Exophase about this.

Anyway, I thought the A80 was not really an option because Allwinner's answers sucked?

I'm still wondering what Qualcomm will reply. They take their time... (probably normal when dealing with small fries)

 

[PokeParadox]

But most of all....it supports Open GL 3.0!!!


Moving to Open GL makes so much more sense on the next device. So much stuff will be able to be ran.

I'm not sure Allwinner will release an OpenGL 3.0 Linux driver - it might be it'll only be available for Android.


We don't know this yet and I don't want to say they won't do it (or we can't use the Android driver), but it's something you need to be aware of as well.

Indeed it must be noted that the SoC may support certain things, but you are still dependent on driver support to compliment the hardware support.

For instance, the PowerVR that the Pandora uses supports full OpenGL 2.0, the ARM driver only expose the OpenGL ES 2.0 API.

 

[bzar]

For instance, the PowerVR that the Pandora uses supports full OpenGL 2.0, the ARM driver only expose the OpenGL ES 2.0 API.

This is something that needs to be said more often when people suggest chips with "full opengl support!"

 

[ExquisiteCorpse]

Oh I see... :blink:

 

[SNESFAN]

Has anyone informations about the difference in power consumption between the A7 and A15 here?

What would we REALLY safe from using big.LITTLE in this case? 

I can't find any real world data on a fair comparison, possibly because the transition from a7 to a15 is seamless on big.little, you would have to manually turn off the 15 cores on a chipset, run a benchmark, then turn off the a7 cores and run only the a15 cores and run the same benchmark. The whole time capping the freq at different levels to get a accurate comparison. It sounds like an immensely hard thing to accurately gauge.

page 3 gives rough statistics, but it reads more as marketing than real readings.

http://www.arm.com/files/downloads/big.LITTLE_Final.pdf

I think what you are wanting to find out is not the a7 vs a15, but the power savings of a7(big.little) vs m4(omap). Which might be easier to get, or just do a straight power reading running same benchmarks at different frequencies on different chipsets.

EDIT: maybe inquire with arm holdings for their measurement data on their testbed or inquire if they have any information regarding a7 vs m4

 

[EvilDragon]

No. M4 on OMAP5 can't be used like the A7.

As _wb_ mentioned, the A7 are only useful if you need LOW processing power.

If you don't use any processing power at all (CPUs are idling), power consumption goes down anyways.

The Pandora has been optimized to run as little tasks in the background as possible (unless the user starts some), so if the Pyra will be similar, it won't need much power when just lying around idling.

Android has tons of stuff running even when you're not using the phone, so the A7 helps saving power by running these small tasks, but without all these tasks and daemons, I wonder if we really get some noticeable difference in battery life?

The A7 won't be used when browsing the web, reading mail, playing games on emulators, etc.

It might be used for MP3 playing - but then again, OMAP powersaving function don't seem to be that bad either, as when simply playing MP3, the Pandora lasts 20+ hours as well.

 

[SNESFAN]

@ ED

cpu time is cpu time though, be it less intensive or more intensive programs, if the core is not processing much on a more power efficient core it's better than using the big core to perform that process. I don't see how assigning certain tasks a specific affinity is that much different from it being handled based off task intensity in hardware, except for web browsing due to how it doesn't differ between lower process stuff like page manipulation and processing new page requests.

the use case for the true big.little is not only that of low intensive services, but stuff like web browsing as mentioned before (scrolling etc, window manipulation, not processing new pages) and audio/video streaming, text documents, ebook reading, file browsing, downloading apps/files and stuff of that nature as well could and probably would use the lower power core. I don't know why you don't think it wouldn't be used for email reading, the m4 core is still powerful 1.2dmips/hz(m4) vs 1.9dmips/hz(a7) to do some things other than low powered services. I'm completely aware omap doesn't behave exactly like big.little, but if you chose it, and optimized it correctly you would surely see benefits other than just shoving everything through the powerful cores.

It doesn't have to be balls to the wall all the time, and android devices with it's background services isn't the only platform that would benefit from big.little. I also understand while idle big.little makes little difference on arm regardless of the os. Please don't downplay the benefit a mock big.little could have as well. I really think a direct comparison between the omap m4+15 and a true big.little a7/a15 should be considered for sake of power saving. That's why I suggested looking at m4 vs a7, even if it's not a true comparison, it would at least give you a better idea.

I love you ED, but you have in the past twisted situations into it meeting your argument rather than comparing things at face value.

 

[bzar]

The A15 and M4 don't speak the same language (in part same, but the M4 supports a lot less stuff). You can't just put a process running on one to the other. They'd probably be used more like the DSP.

 

[Exophase]

There probably is something to gain from real big.LITTLE in terms of power consumption, but I think the difference would be most noticeable if you have lots of background processes going on that are constantly doing some low-cpu-load stuff, e.g. on an Android phone. If you cannot let the cpu enter deep sleep, it's better if you only have to keep an A7 awake than if you have to keep the A15 awake (wasting most of its time on switching between power states).

But it's probably better to ask Exophase about this.

We don't actually know the clock speeds, but if we're talking about a Cortex-A7 clocked at at least 1.2GHz, it'll be able to do most tasks better than a Pandora can do at 1GHz and it'll probably use substantially less power doing it. And for a lot of stuff people do on Pandora now much less clock will suffice. I don't know what the perf/W curve for the Cortex-A15 looks like, maybe it can often offer similar performance at 550MHz or so and use less power doing it. But I don't think you'll be able to push power consumption that much below that, you'll soon hit minimum voltage and static consumption will start to dominate, plus there'll be a minimum clock speed somewhere.

I'd really like to see some basic measured perf/W curves for the SoC in isolation, and also something for the DDR3L. For the latter this might help give an idea: https://www.micron.com/~/media/Documents/Products/Power%20Calculator/DDR3L_Power_Calc.XLSM Peak burst read for the 533MHz 4Gbit 16-bit DDR3L is about 284mW, you can basically multiply that by 4 that'll be accessed in parallel: one for each part of a 64-bit transfer. Ideally the controller will know how to operate in single channel mode when necessary, to save power. Still, that's over 1W that you can at least see in power virus style benchmarks that try to saturate the memory bus.

As _wb_ mentioned, the A7 are only useful if you need LOW processing power.

If you don't use any processing power at all (CPUs are idling), power consumption goes down anyways.

A7s (of decent clock) are able to run the vast majority of tasks a 1GHz Pandora can run with at least as good performance. Would you characterize Pandora as only supporting low processing power? That seems contrary to the justification that Pandora is usually good enough for things people want to do on it.

These processors aren't just good for light background tasks that pop up now and then, they're great for steady state lower power stuff like less demanding games and emulators.

 

[Exophase]

I don't know why you don't think it wouldn't be used for email reading, the m4 core is still powerful 1.2dmips/hz(m4) vs 1.9dmips/hz(a7) to do some things other than low powered services.

Dhrystone is an awful benchmark, you should ignore DMIPS numbers for anything outside of tight embedded applications that can run in a small footprint. Even then Dhrystone is very flawed.

perf/MHz numbers are meaningless anyway, without also knowing clock speed of the device. I don't know how fast the M4s in OMAP5 run, maybe it's something you can figure out by staring at clock trees in the user manual for long enough, I'm not really up for that just now. But here's what I do know:

- For standalone M4 parts, the highest clock speed is only around 204MHz. OMAP5 has some advantage due to being on a better process than your typical microcontroller but that only goes so far.

- Cortex-M4 has a very short pipeline, it's not meant to scale very high. Compare with Intel's Quark processor - it's basically a 486, which still has a deeper pipeline than M4, it's on Intel's advanced 22nm process, and it only clocks at 400MHz.

- OMAP5 has address translation (TLB) and a shared (between both M4), unified cache on the other side of the M4's memory bus. In order to satisfy the tight timing requirements of the M4 these things have to complete as fast as a plain old SRAM lookup usually completes. This will heavily limit how high they can clock it.

- And if somehow it was clocked high they'd quickly hit performance degradation by having limited L1 cache and no L2 cache. You can see that GPH's Wiz suffered from this, it had the same processor type as the GP2X and over 2.5x the clock speed but on average nowhere close to double the performance. That's also a big reason why iPhone 3GS is so much faster than iPhone 3G (they added L2 cache)

I'd be surprised if the M4s ran over 500MHz, and even that'd really be pushing it. They'd be good for embedded-like tasks that are closely coupled with peripherals but not more general purpose code.

 

[SNESFAN]

I'll admit I have no experience with M4's and  I only seen armv7 architecture on the m4 and the a7 and saw the dmips benchmark for both as well and used it as rough estimate as to what it was capable of doing. If m4's aren't capable of the same code that sounds strange seeing as it's roughly the same architecture??

I'm also pretty surprised if it will only clock to 500mhz, where the "companion core" on the tegras which I figured was doing something similar to the omap is able to hit 1.2ghz and you can tell when you're using only that core because it literally sips the battery (emulators and web browsing)

You would be the person to know for sure, but the point I was making about not underestimating the big.little's power and power saving use cases remains the same. How gimp'ed it's implementation is on the omap is another story.

 

[Letalis Sonus]

If m4's aren't capable of the same code that sounds strange seeing as it's roughly the same architecture??

They only support Thumb/Thumb2, no 'common' ARM instructions.

 

[Exophase]

I'll admit I have no experience with M4's and  I only seen armv7 architecture on the m4 and the a7 and saw the dmips benchmark for both as well and used it as rough estimate as to what it was capable of doing. If m4's aren't capable of the same code that sounds strange seeing as it's roughly the same architecture??

Why do you think it's roughly the same architecture? One is ARMv7a, the other is ARMv7e-m. A big difference in M4 is that it only runs Thumb-2 code, no 32-bit ARM code. Floating point is only optional on M4, I can't remember if OMAP5 has them or not, but NEON is not an option.

I'm also pretty surprised if it will only clock to 500mhz, where the "companion core" on the tegras which I figured was doing something similar to the omap is able to hit 1.2ghz and you can tell when you're using only that core because it literally sips the battery (emulators and web browsing)

The companion cores on Tegra are nothing like Cortex-M4s, they're not even anything like Cortex-A7s in big.LITTLE, they are the exact same microarchitecture as the big cores but with a different physical implementation that's more optimized for low leakage than performance.

The claim that you can run them at 1.2GHz runs highly counter to nVidia's claims which are that they only clock up to something like 500MHz on Tegra 3 and I think 800MHz on Tegra 4. When your battery capacity is as huge as it is on Shield it's probably not hard to drain it slowly even if you keep one of the main cores running (and the GPU mostly off), even those will have much better efficiency at substantially lower clock speeds. Something ED attests to with OMAP5.

You would be the person to know for sure, but the point I was making about not underestimating the big.little's power and power saving use cases remains the same. How gimp'ed it's implementation is on the omap is another story.

OMAP5 doesn't contain a gimped implementation of big.LITTLE. It doesn't contain anything remotely resembling big.LITTLE. Having heterogeneous cores on the chips is nothing new, every single OMAP SoC has had this in the form of the DSPs. OMAP4 had Cortex-M3s. And did you know the OMAP3 on Pandora even has an ARM9 on it?

 

[_wb_]

Still, if I just have to pass -mthumb or something like that to gcc and my code can be executed on the M4, that's quite a bit easier than coding for the DSP...

 

[Exophase]

Still, if I just have to pass -mthumb or something like that to gcc and my code can be executed on the M4, that's quite a bit easier than coding for the DSP...

You'd pass something like this:

-mcpu=cortex-m4 -march=armv7e-m -mthumb

But if the same level of OS infrastructure is present for DSP vs Cortex-M4 the only difference in using the former would be using a different compiler. Could have further implications if your code is reliant on GCC-only extensions..

There are still big challenges here. It's not like the M4 code can make a syscall into the kernel like normal ARM code could.

 

[_wb_]

Still, if I just have to pass -mthumb or something like that to gcc and my code can be executed on the M4, that's quite a bit easier than coding for the DSP...

You'd pass something like this:


-mcpu=cortex-m4 -march=armv7e-m -mthumb


But if the same level of OS infrastructure is present for DSP vs Cortex-M4 the only difference in using the former would be using a different compiler. Could have further implications if your code is reliant on GCC-only extensions..


There are still big challenges here. It's not like the M4 code can make a syscall into the kernel like normal ARM code could.

Sure. But at least a decent Free compiler is available. That's a better start than with the DSP, where all we have is a closed source compiler binary for x86, which doesn't allow me to compile code for the DSP on my Pandora.

 

[Exophase]

Sure. But at least a decent Free compiler is available. That's a better start than with the DSP, where all we have is a closed source compiler binary for x86, which doesn't allow me to compile code for the DSP on my Pandora.

And yet you'll probably never code anything for either

 

[Batou456]

Has anyone informations about the difference in power consumption between the A7 and A15 here?
What would we REALLY save from using big.LITTLE in this case?

 

The ARMH provided perf/W curves (article with an example of them http://www.theregister.co.uk/2011/10/20/details_on_big_little_processing/) show that an A7 at it's highest operating point performs better then an A15 at it's lowest point and consumes significantly less power.

 

ARMH claims around 70% power savings for the CPU and around 30% for the SoC by using this.  Mind that the A7's are basically at the level the Pandora is.  Ergo the A7s would be the primaries for low through mid loads with the A15s kicking in for high demand loads, and thus most operating time would be on the A7s curve rather then the A15's in a proper big.LITTLE implimentation.

 

That said from my perspective while it's a very nice, nice to have feature it is a nice to have feature in this context.