ARM Cortex A12

Certainly a surprise announcement since I didn't hear of it coming from anywhere:

http://www.anandtech.com/show/7009/...9-and-a15-in-power-perf-sampling-in-late-2014

Also a 2-core Midgard2 GPU: T622:
http://www.anandtech.com/show/7010/arm-malit622-v500-video-block-complement-cortex-a12

Why do I feel these are about 18 months too late to the game?

 

The list of lead partners says it all.. Marvell and Mediatek, two SoC vendors who have been anything but cutting edge :/ Being optimized for 28nm is also telling; TSMC's 28HPM in particular will be pretty old by the time this comes out.

18 months behind is a little harsh, it could be quite a nice core if it were out in the next few months. I'd say 12 months too late. Which still sounds awful.

Still, would be nice to hear more uarch details about this. You can find a lot of hints that Cortex-A9 is the successor to ARM11, Cortex-A15 is the successor to Cortex-A8, and Cortex-A7 is the successor to Cortex-A5. Meanwhile from what little information we've been shown Cortex-A57 looks like a tweak of Cortex-A15 and Cortex-A53 one of Cortex-A7. That leaves the Cortex-A9 team as the most likely candidate behind Cortex-A12, which makes sense based on - again - what little has been revealed.

Not reall on topic: is anyone else tired of Anand proclaiming Atom (where Silvermont isn't specified, so I presume he means Saltwell) easily beats Cortex-A9? Pretty much any native code test I've seen shows Cortex-A9 with stronger perf/MHz, even that paper where they were using a quite old GCC version before some major ARM improvements. And these days Cortex-A9s are coming in at clocks nearly equivalent to Saltwell.

 

Yeah that's extremely frustrating. Most tech sites are dismissing Geekbench results which show that A9 is above Atom.

OTOH Intel is playing it well by heavily optimizing the Android software stack. This partly explains AnTuTu results. I found out that the FP score is relying a lot on... libm. Optimize libm and your AnTuTu FP score will go up, isn't that nice?

 

Hmm since this chip is late wouldn't it have made more sense if it would have been armv8, i.e. Cortex-A55 instead?

 

This is expected to show up in the latter half of next year, right? If that's the case, wouldn't it have made more sense to focus on ARMv8?

 

http://forum.beyond3d.com/showthread.php?t=63681

 

Dumb question: why do we need two threads for the same topic?

 

It is a dumb question considering I closed the other thread an hour before you made this post.

Now back to the A12!

[ninja edit] In an effort to make all parties happy, I merged the two threads

 

Well thank you kind Mr. Mod and errr uhmmm I should refresh the damn pages at work before I post

 

I wanted to say the same thing. Very odd move from ARM. A12 seems to compete with A55 and will come at same time. But A55 looks to be the most advanced arch from the 2 with 64bit support.
Maybe some things are happening under the hood and A12 is a stop gap product before A55 comes in...
Anyway, it's the first time in recent ARM history that they don't look consistent in their roadmap. They may feel Intel pressure for sure !

 

There is no such thing as a Cortex-A55 AFAIK. Only an A53 and an A57.

 

For when this is scheduled to actually appear in devices, won't A53 and A57 be out? Unless A57 is a lot more power efficient than A15, wouldn't it have made more sense to make an A55 instead of this?

I guess the fact that A12 is designed for 28nm depicts what kind of devices it will end up in. Still, for the cutting edge, ARM better hope that big.LITTLE works a lot better by then. If they have to announce an A55 which will also arrive late, they're going to look a little silly.

 

Making an A55 instead of an A12 could have added quite a bit to A12's release schedule which is already pretty late. Given the targets it's better that ARM sacrifice 64-bit over pushing it out several more months.

Bear in mind, A12 isn't a CPU designed from scratch, it's a successor to A9. You budget uarch modifications on top of this, and going 64-bit would be one of them. From what little we know A57 and A53 look like relatively minor tweaks over A15 and A7 ignoring the 64-bit support; I'd venture a guess that A12 changes more outside of that. Yet A57 looks like it's going to hit devices at least two, maybe even 2.5 years after A15. Which makes the move to ARMv8 look non-trivial.

I think people have a bad feeling about this because they see A53 coming out which is a weaker CPU yet with 64-bit. But ARM needs a 64-bit little core to make big.LITTLE work with A57s, and ARM is betting on big.LITTLE as the preferred strategy for high-end phones using their processors. So while A53 is a lower end core it's part of a high-end strategy. High-end phones in 2015 will need to be 64-bit, mid-range phones in mid-2014 can just barely get by without it.

 

Did ARM stated which level of SIMD/Neon support those cores are to offer?
Do we look at a native 128 bit implementation (both ALUs and datapath)?

 

For A12 as far as I know, this is not public.

 

armv8 is needed for >4 GiB virtual memory. (but not needed for >4 GiB of physical memory, A12 and A15 have PAE).

I don't see anybody running > 4 GiB processes running on their phones in the next couple of years.

Web browsers, which are one of the biggest memory hog programs, have started using multiple processes, so the average process size of web browser processes has actually decreased lately.

So no need to run phone on 64-bit mode. And when running it only on 32-bit mode, cpu which lacks the upper bits inthe datapaths is cheaper and slightly more power efficient.

A12 is clearly designed for phones, to be cheaper and more energy efficient than A15, and A57 which is beefier core will go to servers. But propably they'll release some 64-bit version of A12 (maybe "A55") later.

 

Bingo.

And from ARM's perspective at least, this is definitely a low-end/mid-range solution. Currently, low-end Android phones have 512MB and mid-range ones have 1GB. If we (optimistically?) assume 24 months Moore's Law with slightly increasing wafer costs you'll need to wait until 2018 until you can afford 2GB in the low-end and 4GB in the mid-range. By that point, the A12 will be outdated and you still won't need ARMv8 in those segments.

Yes, although in the case of the in-order Cortex-A53, the extra registers probably help noticeably, so you'll likely end up with similar power efficiency than an equivalent ARMv7 design but at higher maximum power/performance. The relative benefit of extra registers should be significantly smaller on an OoOE core so it doesn't make sense there.

Also FWIW, it's quite obvious to me that they decided to sacrifice a tiny bit more power efficiency in A53 in order to hit higher performance targets (e.g. I was told that the A7's limited dual-issue was engineered based on extensive profiling showing it was slightly more efficient than full dual-issue, yet A53 has full dual-issue...)

I think A57 should be perfectly fine for phones *if* you manufacture it on a 14nm FinFET process. It's good to remember that FinFET improves performance at low voltages, which means that if you're willing to increase costs (die size) to reduce power (average, not peak) then it should clearly help.

Maybe more importantly, they should have all the issues worked out with big.LITTLE MP by then hopefully, so you should be able to make some much more interesting hybrid designs. For example, 1xA57+4xA53 would be a very interesting sweetspot for low-end smartphones. I'm honestly not sure why you'd want a hypothetical 4xA55 instead of that (it'd have lower single-threaded performance, lower power efficiency for multi-threaded workloads, and probably similar or higher cost). I'm still not convinced by big.LITTLE's cache hierarchy though, and I still don't understand why the CCN-504 apparently has a *minimum* L3 size of 8MB, but heh...

Also as Exophase pointed out, I agree that A53 is ARM's little core in a high-end strategy, and makes very little sense on its own. In a sense it's unfortunate that ARM doesn't seem to be pushing for ARMv8 to be omnipresent as soon as possible, but then again it makes very good short/mid-term business sense not to do so.

 

Oops late, thanks for the answer

 

Well, NEON is integrated into the OOOe scheduling machinery now, so I'd expect it to be mandatory.

AFAICT, the A12 is what the A15 should have been; significantly higher performance than A9 without a corresponding rise in power consumption.

Cheers