Samsung Exynos 5250 - production starting in Q2 2012

[Nebuchadnezzar]

Performance at a given Hydra clock, much like a given GPU clock, will depend on rendering load and memory access.

So I guess it's no problem to have hydra tied to the core clock on a DVFS policy?

I actually went ahead and mapped the possible clock sources: http://i.imgur.com/gHgE5k3.png

Basically the hydra and core clock planes have the same source (mout_g3d) but have a divisor of 1-8 available to them. So I guess one could make them run asynchronously with a custom kernel, I'm just wondering if it's worth it or not to go alter the driver for it, doesn't seem overly complicated to do.

 

[Ailuros]

That's why it's a blessing to have someone like Nebu on a board like this. Series5XT is how old as GPU IP by now and there is nowhere a shred of information about Hydra so far heh....

 

[Rys]

So I guess it's no problem to have hydra tied to the core clock on a DVFS policy?

I actually went ahead and mapped the possible clock sources: http://i.imgur.com/gHgE5k3.png

Basically the hydra and core clock planes have the same source (mout_g3d) but have a divisor of 1-8 available to them. So I guess one could make them run asynchronously with a custom kernel, I'm just wondering if it's worth it or not to go alter the driver for it, doesn't seem overly complicated to do.

It's no problem at all, and given Samsung have chosen to do so then I'd go with that in your kernel too.

 

[Rys]

That's why it's a blessing to have someone like Nebu on a board like this. Series5XT is how old as GPU IP by now and there is nowhere a shred of information about Hydra so far heh....

I already got the "give away too much and you're in trouble" email, so that's probably it now

 

[Nebuchadnezzar]

Hrmm. They pulled the i9500 sources. Probably realized the source is incomplete.

 

[Nebuchadnezzar]

By the way: one of the reasons they probably had to delay the chip is this:

#define EXYNOS5410_REV_0 (0x0)
#define EXYNOS5410_REV_1_0 (0x10)
#define EXYNOS5410_REV_2_0 (0x20)
#define EXYNOS5410_REV_2_3 (0x23)

If the revisions are respins, then that's pretty hefty for a chip to have before it even meets a device. For comparison, the S3 shipped on Rev 1.1. Don't know what major.minor represent in their coding, but if the 4412 2.0 is to mean anything, it can be a major change.

 

[Ailuros]

From one side there had been rumors about power issues with 5410 and other rumors suggesting of canned house own GPU projects. If those are chip revisions it might be related to the first rumor; but that's of course pure speculation based on speculation

 

[Turbotab]

It turns out that Samsung has a sense of humour..

https://twitter.com/Chipworks/status/327869468506193920/photo/1

 

[Nebuchadnezzar]

It turns out that Samsung has a sense of humour..

https://twitter.com/Chipworks/status/327869468506193920/photo/1

Mhh? That's on the Sensirion SHTC1 Humidity and Temperature Sensor. Nothing to do with Samsung.

The Wifi package is really something I never saw before: http://www.chipworks.com/blog/recentteardowns/files/2013/04/SKY85303-11_P1_139955_XraySideB.jpg

http://www.chipworks.com/blog/recentteardowns/2013/04/25/inside-the-samsung-galaxy-s4/

 

[Nebuchadnezzar]

1175 1800 Mhz 1 core limit
1545 1700 Mhz 2 core limit

1860 1600 Mhz A15
1619
1293
1043
841
704
571
455
387 800 Mhz A15
182 1200 Mhz A7
146
118
94
75
60
45
35 500 Mhz A7

These are the power values in mW that Samsung populated the power management framework with. I think they're mapped correctly if I didn't do any mistake. The values are per-core.

I can't explain the top two frequency values with anything else than maybe parts of the L2 cache is power gated?

 

[Exophase]

The top value seems to fit with the chart Samsung gave: http://www.anandtech.com/show/6768/samsung-details-exynos-5-octa-architecture-power-at-isscc-13 Following the values down as being per-cluster instead of per-core at least gives a smooth curve, if a very steeply dropping one. Having such a large expense for L2 seems odd when considering how low the leakage has to be here (unless higher clock speeds have much worse leakage due to the reverse body biasing), I expect a good chunk of the L2 cache power consumption to be static since most of the SRAM cells won't be accessed most of the time.

It's hard to tell since they use DMIPS (ugh..) instead of MHz, but if we go by ARM's 3.5DMIPS/MHz that gives a top value there of about 1.9-2GHz, for a power value of around 5.5W or 1.375W/core. Note that Samsung also used 3.5DMIPS/MHz and 2GHz figures for Exynos 5250 here: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/news_11.html

1.86W @ 1.6GHz seems much higher than what would be suggested by the graph. It's also rather striking that the phone would be putting out over 8W, even 9W under the full CPU load you'd experience in benchmarks. Mind you, there do appear to be reports that it gets very hot (http://www.nextpowerup.com/news/1236/samsung-galaxy-s4-overheats-new-benchmarks-surface.html) but so did Galaxy S2 while putting out much less heat.

The other datapoint is in Anand's power measurements of Exynos 5250 (http://www.anandtech.com/show/6536/arm-vs-x86-the-real-showdown/13) he remarks that the throttling makes it drop down to 800MHz; both cores are still fully active but the CPU power consumption is not even 415mW. So unless the frequency was really lower or the throttling also involved an uneven clock cadence (going in and out of clock gating for some big chunks of time) then it suggests around 208mW per core at 800MHz. That makes 387mW @ 800MHz for Exynos 5410 seem awfully high (considering improvements in process and possible enhancements to the design). 96.75mW/core would seem quite low, but maybe not if the power measurements contain L2 cache and the graph values don't.

 

[Helmore]

That Cortex-A7 is pretty frugal with its 182 mW at 1.2 GHz.

 

[Nebuchadnezzar]

The top value seems to fit with the chart Samsung gave: http://www.anandtech.com/show/6768/samsung-details-exynos-5-octa-architecture-power-at-isscc-13 Following the values down as being per-cluster instead of per-core at least gives a smooth curve, if a very steeply dropping one. Having such a large expense for L2 seems odd when considering how low the leakage has to be here (unless higher clock speeds have much worse leakage due to the reverse body biasing), I expect a good chunk of the L2 cache power consumption to be static since most of the SRAM cells won't be accessed most of the time.

It's hard to tell since they use DMIPS (ugh..) instead of MHz, but if we go by ARM's 3.5DMIPS/MHz that gives a top value there of about 1.9-2GHz, for a power value of around 5.5W or 1.375W/core. Note that Samsung also used 3.5DMIPS/MHz and 2GHz figures for Exynos 5250 here: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/news_11.html

1.86W @ 1.6GHz seems much higher than what would be suggested by the graph. It's also rather striking that the phone would be putting out over 8W, even 9W under the full CPU load you'd experience in benchmarks. Mind you, there do appear to be reports that it gets very hot (http://www.nextpowerup.com/news/1236/samsung-galaxy-s4-overheats-new-benchmarks-surface.html) but so did Galaxy S2 while putting out much less heat.

The other datapoint is in Anand's power measurements of Exynos 5250 (http://www.anandtech.com/show/6536/arm-vs-x86-the-real-showdown/13) he remarks that the throttling makes it drop down to 800MHz; both cores are still fully active but the CPU power consumption is not even 415mW. So unless the frequency was really lower or the throttling also involved an uneven clock cadence (going in and out of clock gating for some big chunks of time) then it suggests around 208mW per core at 800MHz. That makes 387mW @ 800MHz for Exynos 5410 seem awfully high (considering improvements in process and possible enhancements to the design). 96.75mW/core would seem quite low, but maybe not if the power measurements contain L2 cache and the graph values don't.

The power values I posted are immediate load power numbers, or power peaks, not averages; so they don't consider clock-gating or anything. The framework usues these values multiplied by process execution time to calculate the application power usages you can see in the battery statistics in Android.

Other than some hilarious quotes from that article:

[Update: We tested the Linpack with the free instead of Linpack Pro which shows different values. Updated the graphs for Linpack accordingly.]

How about using a native implementation with proper CPU warmup you loons? Linpack is a Dalvik running benchmark that finishes nowdays in < 0.3s which doesn't even properly trigger maximum frequency half of the time on this phone.

I find it odd that users report the camera overheating: I have no such issue.

The only case of the phone getting unreasonably warm was when I ran CF-Bench as it is a long-running processor only benchmark, and the phone did get very hot near the SoC location, about S2 heat indeed. Otherwise during every-day use the phone is very cool. I still have to do some proper analysis during gaming.

 

[Exophase]

They use peak power measurements to calculate application power over time long periods of time? :/

I suppose the power numbers Samsung gave in that graph should correspond to running Dhrystone on all cores, which isn't a great stress test. I also say "should" but I know very well that they could have used all kinds of indirect reasoning to get there.

I take it you will be doing more power consumption tests like you did with S2. Were those measured with battery current/voltage sensors provided by the PMIC?

 

[Nebuchadnezzar]

They use peak power measurements to calculate application power over time long periods of time? :/

Huh? No. I mean, what's wrong with that? It is a realistic estimate; The kernel and framework tracks CPU load on a per-process basis at a microsecond granularity. They just use that load time times the provided power values from the manufacturers to generate a power estimate for total power used and calculate the percentages based off that. All Android phones's battery statistics are calculated like this.

I take it you will be doing more power consumption tests like you did with S2. Were those measured with battery current/voltage sensors provided by the PMIC?

The PMIC sadly doesn't have a columb counter fuelgauge and it can only measure incoming current, not outgoing. I used a digital multimeter for voltage and a professional analog/digital combo one for the current and I measured it at the battery with the screen off. Not optimal but close enough. I have amateur equipment here, a proper oscilloscope would do wonders but I don't have access to one.

 

[Exophase]

Huh? No. I mean, what's wrong with that? It is a realistic estimate; The kernel and framework tracks CPU load on a per-process basis at a microsecond granularity. They just use that load time times the provided power values from the manufacturers to generate a power estimate for total power used and calculate the percentages based off that. All Android phones's battery statistics are calculated like this.

When you said peak instead of average I thought you meant the spikes during a bursty load. If you just mean the average value with a full CPU load then at least some of the numbers still look worse than what I expect.

The PMIC sadly doesn't have a columb counter fuelgauge and it can only measure incoming current, not outgoing. I used a digital multimeter for voltage and a high-quality analog one for the current and I measured it at the battery with the screen off. Not optimal but close enough.

Ah okay, yeah that should be pretty good. Would be curious to see what the screen uses here too

Of course when comparing those values with whatever marketing figures have been presented they would be inflated not just by peripherals, RAM, other stuff but inefficiency in the regulators. I'm guessing it'd be quite a lot more involved to try to measure the current on the CPU rails.

 

[Nebuchadnezzar]

I see the overheating issue that was rumored about. After checking the actual CPU sensor, temperatures can routinely go into the first throttling limit of 90c if you do any kind of extended load longer than 20 seconds, and the chip throttles to 1400 in its first step.

 

[Helmore]

I see the overheating issue that was rumored about. After checking the actual CPU sensor, temperatures can routinely go into the first throttling limit of 90c if you do any kind of extended load longer than 20 seconds, and the chip throttles to 1400 in its first step.

I'm feeling stupid here, but which SoC are you talking about here? The 5410, right? That seems awfully high for a smartphone SoC. Makes me worried about burning my fingers on my phone.

 

[Nebuchadnezzar]

The 5410, yes.

 

[Exophase]

Driving the temperature up to throttling limits is also going to make the power consumption even worse. That could make the power consumption of all the CPUs at 1.6GHz more than four times the power consumption of one core at 1.6GHz, and therefore a bad proxy.

Nebuchadnezzar; Do you have a list of voltages corresponding with the power values you gave earlier?