SoC: Back and forth!


Will the pyra run 3 or 2 hours on full power?
It's a bit of a missleading question.  When you say, "full power", it could mean many things.

On, operating, desktop running, playing music or light gaming or other 'light' task, the expectation is 10+ hours.  The Pandora does this.  The Pyra is expected to be more efficient than the Pandora on a task-task basis. 

Pushing the system hard under 'normal' conditions should still yield 4-5 or more hours of use.  Think emulators running full tilt with wifi on downloading stuff simultaneously.

On, operating, movie playing, doing some folding, SETI or bitcoin mining (senselessly topping out the SoC) web browser running, USB turned on running a resistive coil tea cup warmer,  screen on full brightness, wifi pegged, maybe 2-3 hours.

The 'full power' example is silly.
 
I get 2-3 hors of my Pandora with HDD connected and running.

So Pyra should at least lat for 3 hours at full load.
 
Under full load the Pyra will most likely run a lot shorter than the Pandora under full load, as the Cortex-A15 cores are particularily power-hungry.
True but missleading. Clock for clock the A15 is processing more data.
Their efficiency is lower than that of the Cortex A9 cores under load.
False. The A15 is MORE efficient in processing/Watt than the A9. The A15 is capable of consuming more power at maximum, but at that point it's doing around 5 times the work of the A9.
The modern Intel X86 SoC are actually more power efficient than A15 based SoC.
True. Apparently irrelevant as there is a senseless anti-X86 bias, but true.
As we know which battery will be used for the Pyra, we know its capacity, which is about 15 Wh. Under full load the SoC will probably use about 4 W, so if you are lucky you get about 3 hours under full load.
True but missleading. What the Pyra accomplishes in 3 hours under full load would have taken a Pandora 15 hours or more. The Pandora would have died at 4-5 hours under a similar 'full load'.
This of course depends on the power consumption of the other components as well (display brightness, wifi, etc.).
True statement, but missleading. Both devices have similar power needs for all of those components.
 
I get 2-3 hors of my Pandora with HDD connected and running.

So Pyra should at least lat for 3 hours at full load.
True and False. With a similar parasitic device (HDD) running on the USB port and both devices having the CPU doing the 'same work' the Pyra should last somewhat longer - though it would be a fractional increase. The Pyra would be expending fewer watts to do the 'work' involved with processing the data - but that is a small part of the overall drain in that example.
 
Last edited by a moderator:
The 'full power' example is silly.
The full-power example is not necessarily silly. Emulators will probably run at a fixed frame rate and as such will not use 100 % of the CPU time, but native games tend to try to run as fast as possible, which usually means loading the CPU as much as possible (unless something else is limiting like the GPU).

I get 2-3 hors of my Pandora with HDD connected and running. So Pyra should at least lat for 3 hours at full load.
That seems to be a rather arbitrary assumption. 3 hours might be possible, but it might as well be less than that, see my previous post.
 
I don't think "full power" should be used lightly either. The shield (tegra 4 cortex-15) when playing emulators lasts about 10 hours, but has a much larger battery than 4200mah. The shield has a 7350mah battery And that's not "full tilt" as there are games that take advantage of the full power of the GPU makes the shield last more like 4-5 hours. (dead trigger 2) It's not using all 4 cores and the gpu all at 100% full blast like bit coin mining either. I bet 3-4 hours would be a possible "high end" of what you could expect given 100% usage with everything running full blast on the shield.

My point is, a-15's are very battery hungry even if not being balls to the wall. The shield would be a good example, wifi only 5 inch display with an a-15. roughly 2/3rd the battery I would expect to get roughly 2/3rd the battery life of the shield in a rough estimate. 6-7 hours of emulation doesn't sound bad though. But if you take the 2/3 to the high end, you'd be looking at 2-3 hours which is kinda painful. I just wouldn't go into it expecting the same 10 hours the current pandora gets under the same conditions. (heavier emulation would drag that number down also)

That larger screen + magnitude of more pixels will probably pull away the same amount of battery saving as will be gained going to a smaller manufacturing process on the chip. That is if it doesn't eclipse it completely. (eats more power than is saved)

EDIT:

if it were me, use the same battery, but use 2 of them side by side to make up the bottom of the unit to maintain that 10 hour of "real usage" I guess that can be determined once you guys start prototyping though and find the actual power drawl
 
Last edited by a moderator:
False. The A15 is MORE efficient in processing/Watt than the A9. The A15 is capable of consuming more power at maximum, but at that point it's doing around 5 times the work of the A9.
Actually, no. The A15 is about 40% faster per clock than the A9 and consumes about twice as much power for that, which makes it less efficient. That does not say anything about its idle consumption, though.

Of course, ARM knows that, which is why they are pushing their big.LITTLE configuration so much. The OMAP5 does not have cores suitable for big.LITTLE unfortunately.
 
Last edited by a moderator:
^No but we do have the ability to throttle down our CPU/System speed fairly easy..
 
Last edited by a moderator:
OMAP does not need big.LITTLE.

TI has it's own technology to save power.

That's why the Pandora is so power efficient.
 
The z3770 has open source drivers.  It is supported  in the Linux kernel.  It meets 100% of the other requirements for an SoC for this system, but it is X86 not ARM. 
It is even available though Mouser in single unit quantities at around 40 EUR. They even have 100 in stock. But no data sheets :( I.e. we can't even check if and how we can connect anything.

What makes me nervous is that it is said to be a "FCBGA1380" in a 17x17mm package (OMAP5 is 17x17 mm PBGA754). This means it may need a more expensive pcb technology to be connected. And if I interpret some rough diagram correctly, it has only one eMMC and one SD card interface. This makes interfacing two SD slots plus internal eMMC more difficult (could go through USB and an extra chip) and WiFi as well. So the total system complexity must be taken into account.

But it is quite useless to buy chips without getting public documentation. For the OMAP5 there are 6000 pages of technical reference manual available.

At the moment it looks to be the first time that we have a small chance to get an up-to-date SoC with x86 architecture (it was impossible for the last 10 years). But if this is the right train to board is a different question.
 
We had that long ago.

This debate is over already.
Why would it be before the Pyra is so far in development it's impossible to change?Where is this debate? (So I could go check whether there were any good arguments against going x86)
 
We had that long ago.


This debate is over already.
Why would it be before the Pyra is so far in development it's impossible to change?
Where is this debate? (So I could go check whether there were any good arguments against going x86)
Was it this one?

http://boards.openpandora.org/topic/14346-what-would-the-world-and-his-dog-think-if-p2-used-an-x86-soc-but-not-mini-sd/

At least you have 10 pages to read through.

We had that long ago.


This debate is over already.
Why would it be before the Pyra is so far in development it's impossible to change?
Where is this debate? (So I could go check whether there were any good arguments against going x86)
Availability of data sheets to the public, for example.
Do you know how good Qualcom is in that way?

Is there better support from their side?
 
Last edited by a moderator:
OMAP does not need big.LITTLE. TI has it's own technology to save power. That's why the Pandora is so power efficient.
Which is what exactly? TI is implementing ARM's Cortex-A15 core on their SoC (unlike some other manufacturers who design their own ARMv7 CPU cores), so basically the only thing having a major influence on the CPU core's power consumption is the manufacturing process. They might implement power saving features (and they most likely are) for other components of the SoC, but that does not influence the power consumption of the CPU cores. If they would have changed the actual CPU cores (for which they need a special ARM license), those would no longer be A15's anymore.
 
OMAP does not need big.LITTLE. TI has it's own technology to save power. That's why the Pandora is so power efficient.
Which is what exactly? TI is implementing ARM's Cortex-A15 core on their SoC (unlike some other manufacturers who design their own ARMv7 CPU cores), so basically the only thing having a major influence on the CPU core's power consumption is the manufacturing process. They might implement power saving features (and they most likely are) for other components of the SoC, but that does not influence the power consumption of the CPU cores. If they would have changed the actual CPU cores (for which they need a special ARM license), those would no longer be A15's anymore.
They have some power saving features but you're right that the maximum performance is still the same as on other A15 cores.
 
But it is quite useless to buy chips without getting public documentation.
It seems kind of strange to me, that there does not seem to be any documentation for those chips, but on the other hand Intel tries to encourage small developers to use their chips by releasing development boards (even as open source hardware), like the http://www.minnowboard.org/'>Minnow board ( http://www.minnowboard.org/ ). I know this is not the SoC that would be interesting for the Pyra, but why would they make a difference there? They even emphasize that you can roll your own designs without the need to sign any NDA.
 
Last edited by a moderator:
The 'full power' example is silly.
The full-power example is not necessarily silly. Emulators will probably run at a fixed frame rate and as such will not use 100 % of the CPU time, but native games tend to try to run as fast as possible, which usually means loading the CPU as much as possible (unless something else is limiting like the GPU).
Native games that don't cap their framerate at 60 fps (or less) are utterly stupid, since that is the refresh rate of the screen.
 
Back
Top