Not a small story at all. There's a lot apparently that didn't go as planned.
Not a small story at all. There's a lot apparently that didn't go as planned.
D
Deleted member 13524
Guest
You mean Samsung's first-ever 28nm chip using the first-ever mass-produced big.LITTLE implementation didn't go exactly as planned?
I'd be very surprised if it did, to be honest.
Ailuros said:
I don't understand what these cancelled projects are. A cancelled SoC would be one that is never made available for sale.
Even then, a 2+2 Exynos 5 would hardly supersede 5410, it's a totally different performance point (may have a weaker GPU too, we don't know). The costs would likely be different. And while it may look like Exynos 5250 has been obsoleted this isn't entirely the case either - it's showing up in cheaper third party devices (http://liliputing.com/2013/04/chinese-tablets-with-samsung-exynos-5250-arm-cortex-a15-chips.html) and I know it's being put on the table for some other low volume deals where Exynos 5410 is not.
Besides, even if it was limited to Nexus 10 and Chromebook that wouldn't have made it a totally wasted opportunity; it could have worked as a path finding chip to get some of the new IP working right on a known process.
If Samsung wants to do anything with the big drop in fab capacity Apple's move will represent then they're probably going to want to fill it with more than one type of Exynos. A lot of their phones are lower end than the flagship Galaxy S, these mostly use non-Samsung SoCs (in addition to Qualcomm, ST-E SoCs were popular, that's not even an option now) so we could see some of these transition to lower scale Exynos 5s in addition to 32nm and possibly 28nm Exynos 4s or similar.
Nothing about the current migration policy or any hardware flaw limiting the OS to it would make code run on A7s any more than they have to. Quite the opposite, code that could have ran on an A7 may instead run on an A15. The only performance issue is the amount of time needed to migrate the clusters; if the CCI is broken it's going to be even higher than it should be since the L2 cache would have to be flushed to RAM.
ToTTenTranz said:
That's not the extent of the limitation or really the desired goal. It's to be able to simultaneously run any mix of the 4 A15s and A7s.
I'd expect migration bias to be towards the A7-cluster. The all-or-nothing cluster execution means you end up with a bunch of lightweight processes running on A15s, compromising battery life doing so.
Cheers
Not really, but I obviously don't want to go into any further details either. At the end of the day it's an internal Samsung problem. I expect Samsung to further increase sales and market share and it really doesn't make any significant difference to the average user how they're going to reach their own goals in the end.
Does the average consumer today care which of the two SoCs his Galaxy S4 will contain?
D
Deleted member 13524
Guest
There's hardly any difference in usability so I doubt there's anyone at all who actually cares except for fans or people who talk a lot on the phone.
BTW, turns out the GS4 Mini will come with the same 1.7GHz Snapdragon 400 as they put in Galaxy Mega 6.3:
http://vr-zone.com/articles/samsung...to-come-packing-snapdragon-400-cpu/32081.html
It's weird how many SoCs Samsung is purchasing from Qualcomm. Unless they're still taking massive orders from apple, they're probably not using their fabs at full capacity.
So those rumours of another exynos5 variant for this phone were incorrect, unless Samsung is continuing to use dual soc solutions for different markets
Nebuchadnezzar
Legend
Might be one of those cancelled projects.
Very relevant to the recent discussion here.
http://www.sammobile.com/2013/05/30...disappointments-and-their-current-soc-future/
Totally rips apart the relationship between Samsung semi and Samsung mobile, as well as stating numerous issues within Samsungsemi.
"...Something went on during last winter that panicked the mobile division to change SoC provider for many variants of the S4.."
"...We have information from several sources that Exynos’s CCI is inherently crippled in silicon..."
"...Internally at SLSI, as many as three projects were cancelled late last year..."
"...The surprise use of the SGX 544MP3 in the Exynos 5410 is due to panic caused by Mali’s own T6xx GPUs: again an issue of extremely excessive power consumption..."
"The above is written by a guest writer, a current respected and knowledgeable developer in the community"
Anyone want to fess up to being the author ?
http://www.sammobile.com/2013/05/30...disappointments-and-their-current-soc-future/
Totally rips apart the relationship between Samsung semi and Samsung mobile, as well as stating numerous issues within Samsungsemi.
"...Something went on during last winter that panicked the mobile division to change SoC provider for many variants of the S4.."
"...We have information from several sources that Exynos’s CCI is inherently crippled in silicon..."
"...Internally at SLSI, as many as three projects were cancelled late last year..."
"...The surprise use of the SGX 544MP3 in the Exynos 5410 is due to panic caused by Mali’s own T6xx GPUs: again an issue of extremely excessive power consumption..."
"The above is written by a guest writer, a current respected and knowledgeable developer in the community"
Anyone want to fess up to being the author ?
Last edited by a moderator:
I don't think the author is amongst us, but for the points listed there's only one thing to say: you can run, but you can't hide.
Nebuchadnezzar
Legend
I don't think their author actually exists, but some of those snippets are almost exactly the same as I've been saying on xda over the past week, it's basically a rewrite. It wouldn't surprise me given their track record.
I still don't really understand why problems with the Exynos Octa SoC would lead Samsung Mobile to use it only some of the time. Are there different branches for different regions with different political influences? Or did they have some kind of minimum purchase obligation to uphold?
Could you link? If you post there as Nebuchadnezzar I can't find it because it's in a standard user title and I can't find a member list
Could you link? If you post there as Nebuchadnezzar I can't find it because it's in a standard user title and I can't find a member list
Last edited by a moderator:
Nebuchadnezzar
Legend
Could you link? If you post there as Nebuchadnezzar I can't find it because it's in a standard user title and I can't find a member list
http://forum.xda-developers.com/showthread.php?t=2258519&page=24 and pages before/after. However there's also things I never discussed, so I think somebody just read what I wrote there. Hell you linked my posts to Linus on that mailing-list so things are wide-spread.
Thanks. I've read through all your posts there. The part about previous gen hardware not being able to power gate CPUs while maintaining coherency was enlightening. I know you mentioned it was an issue before but I didn't know what the problem was. Does this mean L1 didn't get properly flushed? If this is a problem with Exynos 5250 I should bring it up with a someone I know who is evaluating it.
In one post (http://forum.xda-developers.com/showpost.php?p=41872704&postcount=216) you say it should be possible to run some mix of A7 + A15 if the migration involves a manual cache flush. But I don't see how this can be the case because active threads running simultaneously on separate clusters will still expect to be coherent with each other. The assumption of coherency is deeply rooted in multi-threaded and probably even some multi-process coding. Is it possible you were describing something different from what I think you were?
It looks like the addendum part of the article is lifted straight from your posts. It could have been done by a separate author from the main part. But the big points in the main part - that Samsung is canceling a bunch of chips, Samsung Mobile is unhappy with Exynos and doesn't want to use it at all for S5, Mali-T604 having unacceptable perf/W (although we could kind of ascertain that to some degree) are fairly separate. They're also identical to what I've been hearing shortly beforehand, so I'm guessing this information is coming from the same source.
I actually never saw the tablet video until now. Totally bizarre, I wonder what the explanation is.. I guess there are only a few possibilities:
1) Uses a revision of hardware that has working A7 to A15 coherency. Probably not since this video predates Galaxy S4 by months.
2) Isn't actually using Exynos Octa despite saying it does, instead using ARM hardware. I strongly doubt this because ARM's test SoC wouldn't be well suited for a tablet design and there's far more utility out of Samsung doing one with Octa. Plus there'd be no reason for ARM to lie about this; I doubt they'd chose to give Samsung credit for their hardware.
3) Uses special software that's safe with incoherency (manual cache management). Very unlikely given the wide set of tasks, this would be a software nightmare and not at all worth it for some little demo.
4) Isn't actually running as advertised, perhaps always runs on A15 (perhaps also at a fixed clock) and the display simply uses an algorithm to say if the core should be in A7 or A15 mode based on current load. Unfortunately this is the most likely scenario. Also not particularly honest of ARM and Samsung.
I don't expect to ever really learn the full truth on this one.
Nebuchadnezzar
Legend
I don't know the factual reason behind it but that is what I think it is. The 5250 doesn't have independent power gating so it should have the same issue. The 5410 has explicitly some new boot entry parameter for the C2 state, something not to be found on the 5250. The way the coupled driver in the 5250 works is that it waits for both CPUs to be in WFI.
I've been told that's how you could bypass the problem of not using the CCI. How is this different than say a multi-socket CPU system?
I don't know about that tablet video. I managed to enable the IKS to behave exactly as in the video, just that in reality it never switched CPU and only the CPUFreq driver reported it as such.
I actually searched for a bit since the mention of the 5440 in that article really intrigued me: I totally missed it, there have been reports back as December claiming that would have been the chip for the S4. I just dismissed it as just a numbering mismatch in the reporting, but it actually exists as there's been upstreamed patches and code for it: http://www.linux-arm.org/git?p=linu...8;hb=88e418489f5666f437e5546985ed83ec8280fa71
And it's been steadily getting some updates which indicate that it's anything else but dead...
Multi-socket CPUs have cache coherent interconnects. Currently, that includes QPI for Intel and Hyper Transport with cache coherency extensions for AMD.
Actually these days it's even more than that, since each CPU also has an integrated memory controller, meaning that normal memory accesses are forwarded to other nodes as well.
I don't know the details, but there are rumors in the background for years now that Samsung LSI and Samsung mobile could hardly ever agree to anything. It now just seems worse than ever.
***edit: by the way the part about Samsung whatever panicing with T6xx and licensing Series5XT sounds like utter rubbish. It's not too hard to look up on IMG's homesite when the license agreement between Samsung and IMG for 5XT was signed and if memory serves well it must have been around Mali400MP4 (before or after its initial launch) timeframe. What I had heard back then is that the latter was planned to get released at 400MHz initially but was reduced due to power problems to 267MHz; granted frequency rose in followup silicon but they obviously couldn't reach 400MHz with initially without draining the battery in a couple of minutes and the latter is something Nebu has verified here with his own experiments.
Nebuchadnezzar
Legend
Sorry, I'm not familiar with x86 systems. Wasn't aware of this. In any case I got told that you could theoretically manually flush the cache to RAM and do it like this.
It's like this for any multi-CPU systems, x86 or otherwise. Consider that ARM didn't offer multicore until ARM11 and Cortex-A9. If there was no need for cache coherency then you would have seen SoC makers place multiple Cortex-A8s on an SoC, for instance. There are cases of SoCs with multiple cores that weren't cache coherent by design, but not such that a general purpose OS like Linux can freely schedule threads on them.
Whoever you were talking to may have meant that the software can be designed to work around it by manually flushing cache after writing to shared memory. That may work for specialized software but it wouldn't work for the existing multithreaded software that's expected to run on Android. The OS can't do anything to remedy this (at least nothing realistic, short of trapping a lot of memory accesses)
Similar threads
- Deleted member 13524
- Mobile Devices and SoCs