Qualcomm Krait & MSM8960 @ AnandTech

I understand that, but the decision looks like 100% marketing led. With a shrink to 20nm and some evolutionary refinements, Krait 32-bit would have at least rivaled A57's performance and beat A53 in terms of perf/w. What is the point of 64-bit, if it doesn't give you a marked increase in perf/w, there is clearly no short-term need for 4GB + RAM for 99.9% of mobile apps.

 

You're comparing Samsung's gate-first 28nm LP HKMG to TSMC's gate-last 28 HPm HKMG process.

Qualcomm's voltages are stupidly lower than what Samsung can achieve at those frequencies, regardless of architecture. Qualcomm's fastest frequency uses 150mV less than Samsung's.
The processes have 0.1V difference in Vdd. Basically TSMC's HPm is practically a whole node ahead of Samsung in terms of power.

You can shave off 21 to 16% off the power with a 100mV reduction.

I think a better comparison will be Tegra5 or LG's Odin, HPm vs HPm on the same foundry.

 

My guessometer would indicate a Cortex-A7 at 1300Mhz to be slightly faster than a Krait 400 at 800Mhz. In any case the difference wouldn't be worth bothering with big.LITTLE.
Interestingly the difference between the bins is quite large. The best bin of the S800 2.3Ghz (8974 v2 AC) easily blows away the worst bin of the 8974Pro (aka S801, 2.5Ghz AC) in terms of power draw, at any frequency (though obviously the S801 AC can still go up 3 speed steps higher). I guess you can't order a particular bin . Wondering what bins the reference platforms and review devices are using...

FWIW the link from Nebuchadnezzar points to a 8974Pro Chip aka S801 (AB), not S800.
(OMG did qualcomm make a mess with the numbering...)

 

I doubt these numbers include static power consumption, because the intercept of this curve is nearly at zero. That plays a role in the comparison between TSMC's 28nm HPM vs HPL or LP processes (although the latter is penalized for not having HKMG), and Samsung's 28nm HKPG, as well as one between big.LITTLE and asynchronous clocking.

MediaTek 6589 offers a bit of an additional datapoint:

https://github.com/varunchitre15/MT...atek/platform/mt6589/kernel/core/mt_cpufreq.c

I don't know which of TSMC's 28nm processes it's made on, but I have a feeling it's the original LP one. There are numbers for static leakage per-core there, but they might not be that representative either if they were taken at 125C..

 

Nice.

If their formula is correct I get 48mW static leakage at 60°C and 200mW dynamic per core. That's .. quite bad. Not even sure what voltage it is cause their driver looks retarded. Seems to be 1250mV.

 

I can't possibly read much out of that stuff as a layman but if the peak frequency is above 1.2GHz as I'm reading it here, then it's a MT6589T and afaik TSMC 28LP if also the wiki entries here are correct: http://en.wikipedia.org/wiki/MediaTek (at least the GPU frequencies for 6589/6589M/6589T are).

 

So a S800 core seems to use roughly half the amount of energy (767 mW @ 2,3GHz) compared to what Nvidia claims for the A15 core within the K1 (1,6W @ 2,3GHz). Both are on the same process, or?
It seems that the A15 cores really need a lot of energy.

 

Depends on what Nvidia counts in that number. Clearly Qualcomm ignores static and L2 in these figures. I wish the ARM's IPA driver in the Exynos' was complete so we would have a complete power modelling formula.

 

I don't see the point in comparing max power consumption at max clock speed when the perf/MHz is totally different between the two. You're looking at two different variables (max perf and max clock) on an equation that's not linear. Unfortunately review sites do this all the time and in particular they've painted Cortex-A15 in a worse light than they should have over it. A lot of comments like "it uses 100% more power but it's only 20% faster!" and those aren't very informative.

Instead you should be looking at power consumption for a fixed performance level (or levels, maximum performance of the slower part is a good place to start) or performance for a fixed power consumption level. For all of the nonsense in nVidia's marketing they're at least right to approach it that way. Granted, the comparison changes for every test, so you can't get an exact number, but that's always the case for perf/MHz numbers.

nVidia claims around 1W at 2GHz for A15 cores in K1. That's probably still generally faster than Krait 400 cores at 2.3GHz.

 

New roadmap:

http://image.itmedia.co.jp/l/im/ee/articles/1406/11/l_mm140610_qualcomm2.jpg

Looks like the 808 isn't even positioned in H1 2015.

 

How is the 805 not present in the flagship smartphones and tablets that were introduced during the last few weeks?
I thought it just wasn't ready for production yet, but that roadmap tells me it has been for a while now. Could it be that much more expensive than the fastest 801?

 

There's always going to be a noticeable gap between when an SoC is released and when you can see it for sale in a product. Especially for phones.

 

Plus the S805 does not feature an integrated modem, though I seem to remember something about Qualcomm offering packaging options with their modem that could bring comparable benefits.

 

Logically, it should be larger than the than a S801, due to 2 x64 bit wide memory channels. I noticed on the latest Qcomm roadmap, that S805 is linked to the 20nm 9x35 modem, perhaps OEMS have been instructed to wait until that part is ready before shipping 805 devices, for whatever reason.

 

Look at where the 801 appears on that roadmap versus when it actually released in devices. S805 devices are still some ways off.

 

First device with S805 officially launched:

http://www.theverge.com/2014/6/18/5820270/samsung-galaxy-s5-lte-a-korea-launch

It's a Galaxy S5 revision, so the SoC is being used in smartphones.

 

I always thought S5 were LTE-A as it came after Samsung already made some S800 LTE-A S4.

Oh well.

 

So first consumer product with a shipping 20nm chip, MDM9x35.

 

Interesting question is if it's really TSMC silicon or not: http://www.digitimes.com/newsshow/company.asp?datePublish=2014/05/13&pages=PD&seq=203

 

Hmmm either 20SoC is below expectations even for ULP SoCs or Apple is devouring too many capacities and QCOM is looking for alternatives or even a combination of both?