Samsung Announces Exynos 5430: First 20nm Samsung SoC
by Joshua Ho & Andrei Frumusanu on August 13, 2014 8:44 PM EST- Posted in
- SoCs
- Samsung
- Smartphones
- Mobile
- Tablets
While we mentioned this in our Galaxy Alpha launch article, Samsung is finally announcing the launch of their new Exynos 5430 SoC.
The main critical upgrade that the new chips revolve around is the manufacturing process, as Samsung delivers its first 20nm SoC product and is also at the same time the first manufacturer to do so.
On the CPU side for both the 5430, things don’t change much at all from the 5420 or 5422, with only a slight frequency change to 1.8GHz for the A15 cores and 1.3GHz for the A7 cores. We expect this frequency jump to actually be used in consumer devices, unlike the 5422’s announced frequencies which were not reached in the end, being limited to 1.9GHz/1.3GHz in the G900H version of the Galaxy S5. As with the 5422, the 5430 comes fully HMP enabled.
A bigger change is that the CPU IP has been updated from the r2p4 found in previous 542X incarnations to a r3p3 core revision. This change, as discussed by Nvidia earlier in the year, should provide better clock gating and power characteristics for the CPU side of the SoC.
On the GPU side, the 5430 offers little difference from the 5422 or 5420 beyond a small frequency boost to 600MHz for the Mali T628MP6.
While this is still a planar transistor process, a few critical changes have been made that make 20nm HKMG a significant leap forward from 28nm HKMG. First, instead of a gate-first approach for the high-K metal gate formation, the gate is now the last part of the transistor to be formed. This improves performance because the characteristics of the gate are no longer affected by significant high/low temperatures during manufacturing. In addition, lower-k dielectric in the interconnect layers reduce capacitance between the metal and therefore increase maximum clock speed/performance and reduce power consumption. Finally, improved silicon straining techniques should also improve drive current in the transistors, which can drive higher performance and lower power consumption. The end-effect is that we should expect an average drop in voltage of about 125mV, and quoting Samsung, a 25% reduced power.
In terms of auxiliary IP blocks and accelerators, the Exynos 5430 offer a new HEVC (H.265) hardware decoder block, bringing its decoding capabilities on par with Qualcomm’s Snapdragon 805.
Also added is a new Cortex A5 co-processor dedicated to audio decoding called “Seiren”. Previously Samsung used a custom FPGA block called Samsung Reprogrammable Processor (SRP) for audio tasks, which seems to have been now retired. The new subsystem allows for processing of all audio-related tasks, which ranges from decoding of simple MP3 streams to DTS or Dolby DS1 audio codecs, sample rate conversion and band equalization. It also provides the chip with voice capabilities such as voice recognition and voice triggered device wakeup without external DSPs. Samsung actually published a whitepaper on this feature back in January, but we didn’t yet know which SoC it was addressing until now.
The ISP is similar to the one offered in the 5422, which included a clocking redesign and a new dedicated voltage plane.
The memory subsystem remains the same, maintaining the 2x32-bit LPDDR3 interface, able to sustain frequencies up to 2133MHz or 17GB/s. We don’t expect any changes in the L2 cache sizes, and as such, they remain the same 2MB for the A15 cluster and 512KB for the A7 cluster.
The Galaxy Alpha will be the first device to ship with this new SoC, in early September of this year.
Facebook
Twitter
RSS
77 Comments
View All Comments
twotwotwo - Wednesday, August 13, 2014 - link
Not all AT's fault--I think if NV mailed them a Denver gadget to play with, we'd hear about it. :)Ryan Smith - Thursday, August 14, 2014 - link
We're hard at work on Denver. It hasn't been ignored, it just takes time to go through it all.GC2:CS - Thursday, August 14, 2014 - link
Well if it will be the same story as the GPU, I am not interested at all.kron123456789 - Thursday, August 14, 2014 - link
what story?GC2:CS - Thursday, August 14, 2014 - link
Big words, about "PC class performance" and "incredible efficiency", all of those incredible technologies they implemented and how it blows away the competition, then the products will came after all those months and we will see some nice performance numbers, but the chip is power hungry as a kitchen sink.Compared to the A7 they claimed 3 times the performance and 50% higher efficiency back in January, and today we got 2,4 times the performance at 7W which is for what I know 2 to 3 times as much as the A7 and that is a year old SoC, built on a potentially less efficient process, that matches the nvidia's best GPU offering in terms of efficiency.... I am just asking myself where is the revolution in which to be interested in ? I am more interested in a detailed comparison on this site between last years iPad mini with Retina display and nVidia tablet Shield that would prove me wrong, but nothing did so far.
lilmoe - Thursday, August 14, 2014 - link
The overheating and short battery life of the iPhone 5S totally contradict your "facts"...GC2:CS - Thursday, August 14, 2014 - link
And still, the iPhone with its tiny 5,92 Wh battery can withstand ~114 minutes, at full GPU load which is not so much less than an K1 tablet with over 3x the battery size running just close to its full load for ~135 minutes. The iPhone is warm when under load, so either the chip doesn't run on 85 degrees like Tegra, or I should get rid of that thick skin on my hands.This actually supports my "facts" as you just can't put Tegra into a very thin 4" phone and run it out of a downright feature phone sized battery like the A7.
lilmoe - Thursday, August 14, 2014 - link
1) Tegra's GPU is HUGE, and the performance difference is night and day (Tegra K1 being 2x-3x faster). Nvidia is also relaxing the thermal headroom to showcase its power.2) Tegra is driving more pixels on the Shield tablet
3) Tegra is still 28nm, which obviously isn't efficient enough for the initially intended power envelope of the GPU. Nvidia have been pretty vocal about how displeased they are with TSMC's 20nm process.
4) This chip isn't intended for smartphones in the first place.
Back to topic, I'm reading lots of articles about the new Exynos and Samsung's 20nm process here and there. This seems to be the most power efficient performance ARM chip to date. It will most likely be more efficient than Apple's A8 if Apple decides to stick with their dual core Cyclone setup and a faster GPU. big.LITTLE is fully and *truly* functional this time around, and the Linux kernel is getting better and better at supporting it. I seriously won't be surprised if the Galaxy Alpha's smaller battery lasts just as long as the GS5's. Samsung has loaded that chip with efficient co-processing, signaling, encoding/decoding features. The screen also appears to be built on a newer, better process too.
name99 - Thursday, August 14, 2014 - link
"It will most likely be more efficient than Apple's A8 if Apple decides to stick with their dual core Cyclone setup and a faster GPU. big.LITTLE is fully and *truly* functional this time around, "What makes you say this? I understand your claim to be that this SoC will be more efficient than A8 because of big.LITTLE.
That's THEORETICALLY possible, in the sense that big.LITTLE can steer work that it knows can be performed slowly to the (slower, more power efficient) core. But there's a whole lot of gap between that theory and reality.
The first problem is the question of how much work fits this category of "known to be able to run slowly". Android and iOS obviously both have various categories of background work of this sort, but we won't know, until the phone is released, how well the combination of latest Android plus Samsung's additions actually perform. You're asserting "big.LITTLE is fully and *truly* functional this time around" based on hope, not evidence; AND you're assuming that this type of background work makes up a substantial portion of the energy load. I'm not sure this second is true. It obviously is if you use your phone primarily as a phone, ie you look at it a few times a day to scan notifications, and do nothing else. Well, when I use my iPhone5 that way, it already gets about 4 days of battery life. Improving that is nice, but it's not going to excite anyone, and it's not going to show up in reviews.
The problem is that the code that runs based on user interaction is a lot harder to segregate into "can run slow" vs "must run as fast as possible". and that's what's needed to reduce energy consumption for common usage patterns. THIS is dependent as much on the quality of the APIs, the quality of their implementation, and the quality of the developers exploiting those APIs as it is on the hardware. Samsung has no control over this.
The second problem is that you assume Apple doesn't have the equivalent of a low-power core. But they do, in the 5S (the M7 chip), and presumably will going forward. This is described as a sensor fusion chip, but I expect that Apple actually considers it the "slow, low power" chip, and within their OS they move as much as possible background work off to it. So we're further reducing the real-world gap between big.LITTLE and iOS. At the high end, as I said in part 1, the work can't easily be segregated into fast vs slow. At the low end, the work that can be segregated as slow has its equivalent of a companion core to run on.
The third problem, for the mid-range, is that we have no idea how much dynamic range control Apple has for Cyclone. For example, it certainly appears to be a clustered design, based on two 3-wide clusters (basically take the execution guts of Swift and duplicate them). If this is so, an obvious way to run the CPU slower and cooler (if you know that this is acceptable) is to shut down one of the clusters. Their are many other such tricks that are available to CPUs, for example you can shut down say 3/4 of the branch prediction storage, or some of the ways in the I or D cache. It's all a balancing act as to what gives you the best bang for the buck.
Point is
(a) power-proportional computing (as opposed to "hurry up and sleep") is a legitimate strategy BUT it relies on knowing that code can run slowly. This knowledge is hard to come by, outside some specialized areas.
(b) there are multiple ways to implement power-proportional computing. ONE is big.LITTLE; but another is a companion core (which Apple definitely has) and a third is to shut down micro-architectural features on the CPU (which Apple could do, and for all we know, already does do).
extide - Thursday, August 14, 2014 - link
Uh dude, the M7 is a Cortex M -- definitely not a companion core man. It is absolutely not doing any OS background tasks, it is just a sensor fusion hub. That's about all it has the capability to do anyways, those little processors are quite slow... I mean like typically in the 40-80 Mhz range, and that is not a typo, plus they run the Thumb instruction set which is different to the regular ARM instruction set, so you would need to convert the instructions (using the Cyclone cores) first. It would not save any power and would be pointless.