6 ms·

ARM's Cortex A57 and Cortex A53: The First 64-bit ARMv8 CPU Cores

85 points by sciwiz 14y ago

haberman 14y ago
Looks very cool; the idea of having "big" and "little" processors on the same SoC is interesting. I wondering if this is a big win vs. just having a "big" processor that is frequently put into idle mode when not needed. As a side note, does anyone else find the ARM naming conventions totally impossible to follow? I look at the list of ARM models (http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_core...) and have no idea where to begin. The family/architecture/core scheme means you can have a single chip that is an ARM11 family, ARMv6 architecture, ARM1136JF-S core. How do people make sense of this? As someone who's writing a library that I want to be supported across all (or most) ARM cores, I don't have any idea how many different chips I'd need to test against to get a representative sample. There are so many optional features (NEON, Thumb, Thumb-2, VFP, etc) that seems to be supported in various combinations across the different models. It's like a maze and I never have any idea how a new model I read about fits in.
- lucian1900 14y ago
  The two CPUs appear to differ in dispatch and branch prediction. Interestingly, that's where much of the power/silicon budget goes nowadays.
  - hoprocker 14y ago
    As I understand it, incorrect branch prediction becomes significantly more expensive (power-/time-wise) as pipeline length increases, so getting the prediction right and being able to correct quickly is quite important.
- Symmetry 14y ago
  Well, in regards to the first question generally a processor's performance is proportional to the sqaure root of it's area at a given frequency and voltage, and it's active power use and leakage are both proportional to it's area. So yes, a smaller core will be able to accomplish the same task for less energy even though it takes longer. Now it used to be that processors power budget was dominated by active power and the solution was to scale clockspeeds and voltage levels. As we move to smaller process nodes it's more about leakage power, which only goes away when you power down the core meaning that now race to idle is a better choice. But that's tangential to the bigger/smaller core issue.
- Nursie 14y ago
  Does your library have to be a single compiled binary across all these variants? If so, good luck... Otherwise, hopefully, a compiler takes care of most of the mess for you and gets you the best it can on the platform you're targeting. You might need to check that things would run on a variety of configurations - for instance hardfloat and softfloat do indeed have very different performance profiles when it comes to floats. Thumb shouldn't bother you too much as an application programmer (unless I'm very much mistaken) because it's just another instruction set for a compiler to target. Errr.... You can get into all sorts of complications when actually looking at the platform ABIs. Debian, for instance, seem to have something of a lowest-common-denominator approach that targets features present everywhere. Which is then why someone had to rebuild it to get decent FP performance out of the Raspberry Pi which had hard-float... Part of the complexity is that ARM is a licensed architecture. Some companies license the design of the whole core, some incorporate their own stuff and some just license the instruction set and do their own stuff otherwise. What do you mean 'supported across all (or most) ARM cores'? Because that's huge and varies massively. There are the sub-100MHz embedded devices I happen to be working on at the moment (which may be running any of a load of different OSs), there are ARM cores embedded in all sorts of controllers where I wouldn't think you'd want to run, then there's the multi-core multi-GHz stuff from the likes of Samsung, Qualcomm and Marvell...
  - mbrubeck 14y ago
    I know that some of haberman's libraries (like upb) include JIT compilers. In those cases you can't just rely on the compiler to take care of instruction set differences. (I'm on the mobile Firefox team, and we run into similar issues targeting our JavaScript engine to different ARM flavors.)
    - Nursie 14y ago
      Then that very well could turn out to be a complete nightmare! Yes, if you're in the business of writing compilers - traditional, JIT or otherwise - then you're going to hit all sorts of issues with this stuff, and rapidly head off beyond the realms in which I have anything useful to say :)
  - 14y ago
- modeless 14y ago
  Tegra 3 already has this big/little architecture, but using the same core design for all cores, the difference being that the "little" core is clocked lower and fabbed with a special low-power process. I imagine using two different core designs would be even more effective.
- deleted 14y ago
  [deleted]
- brigade 14y ago
  One good thing about 64-bit ARM is that there are no optional extensions (yet...) Floating-point and SIMD support are both required. As for your library, ignore CPU models to start with. Instead, look at the ARM architecture reference manual for a given revision; it will say which instructions are supported and which extensions are optional. Also the quick reference [1] which has a good summary of when various core instructions were added. Then test for the instructions you actually care about. You can safely ignore Thumb; it's an alternate encoding with tradeoffs that made sense nearly two decades ago but not anymore. You can also mostly ignore Thumb-2; there are processors that only support Thumb-2 but they also lack MMUs. Thumb-2 added some additional ARM instructions that can be useful, however. So essentially, (with each revision including the prior) ARMv4 : baseline ARMv5E : Load/store double, more multiply instructions, prefetch, bx <reg> ARMv6 : DSP extensions, rev, load/store exclusive ARMv6T2 : Thumb-2, movw/movt, bitfield manipulation, rbit, orn ARMv7-A : Memory barriers Thumb was optional in v4 and v5, and mandatory in v6. VFP was optional as of ARMv6, NEON optional as of ARMv7. NEON mandates VFP. Revisions of VFP and NEON aren't terribly important, except that VFPv3 (but not VFPv3-d16) gets 32 registers. As for chip to care about, ARMv6 + VFP (ARM1176jzf-s), ARMv7-A + VFPv3-d16 (Tegra 2), and ARMv7-A + NEON are by far the most common for general purpose stuff. If you want to get old-school, test a SheevaPlug for ARMv5E and an old PDA for ARMv4, though I'd not worry too much about ARMv4 (llvm for instance requires a baseline of ARMv5E last I checked.) [1] http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QR...
  - haberman 14y ago
    This is a fantastically informative comment, thank you!
ChuckMcM 14y ago
Pretty creative stuff. I am looking forward to AMD building an eco-system around these things. My guess is that if AMD could deliver 64 bit ARM server chips and full programming documentation to support a robust Linux server OS architecture they could take a huge chunk of server share away from Intel based machines. My reasoning is that people started migrating to AMD when they had a 64 bit x86 architecture and Intel didn't. That showed me that folks were willing to go with AMD if they provided something that Intel wouldn't (or couldn't). Given that ARM isn't bogged down by Intel's staggering licensing challenges (chipsets, busses, instruction sets, etc) this suggests a very interesting couple of years ahead.
- wmf 14y ago
  It's not clear how AMD's ARM chips will be any better than the other ones (e.g. Calxeda), though.
  - WiseWeasel 14y ago
    AMD could package them with their ATI/Radeon graphics processors.
    - mtgx 14y ago
      Unless they intend to make a mobile GPU like Nvidia did with Tegra, how will their Brazos GPU's compete in performance/Watt with something like the ARM Mali GPU, which would probably be a default choice for Calxeda.
      - WiseWeasel 14y ago
        It wouldn't. It would be a 16-CPU-core beast with a Radeon GPU aimed at competing with x86-64 performance/Watt.
      - wmf 14y ago
        Interestingly, ATI had mobile GPUs but sold them to Qualcomm. Nvidia's trickle-down approach of putting really old desktop GPUs in a mobile SoC doesn't seem to be doing very well.
deleted 14y ago
[deleted]
hemancuso 14y ago
Any Intel employees in the crowd? What's the level of worry surrounding ARM these days? Given Intel's high levels of competitive paranoia, news like this must have people fairly worried. Not to mention the explosive growth in adoption of the ISA over the past few years.
- czhiddy 14y ago
  I spoke to my friend @ Intel a while back, and he said that the company viewed Samsung as their main rival (not AMD, not ARM). His argument was that Intel's main competitive advantage (and where the majority of spending/R&D happens) was their fabs, and Samsung was the only other company that could come close to competing on that front.
- EwanToo 14y ago
  I think Intel's major worry with ARM is that simply speaking, ARM don't need their licencees to be particularly profitable at making chips for them to carry on designing chips, they just need them to buy new licences. For Intel, having a competitor designing CPUs who can't be undercut directly is a real issue - Intel are not going to be letting Samsung produce Xeon chips under licence in the next 5 years, though I do wonder about Atom ones..
- fieldforceapp 14y ago
  Well, INTC could adopt the same IP-based business model as ARM and then give up 98% of it's revenue: http://www.wolframalpha.com/input/?i=revenue+of+intel+vs+arm http://www.wolframalpha.com/input/?i=revenue+of+intel+vs+arm So the folks at INTC are doing what you'd expect, competing on discrete components and application-tuned architectures. A key example of that is the recent Merrifield-based chipset for smartphones which is obviously a key initiative: http://www.intomobile.com/2012/05/14/intel-merrifield-system-chip-may-end-up-2013-superphones/ http://www.intomobile.com/2012/05/14/intel-merrifield-system...
- theatrus2 14y ago
  Intel is first and foremost a fab company - they're ahead of pretty much everyone in semiconductor processes by at least one generation. If Intel needed to create an ARM-ISA compatible CPU tomorrow, they probably could, and it would be top notch (though maybe not at a margin Intel wants to play at). The biggest threats come from companies which have shown that they're willing to pour the big bucks into R&D and new fab construction (Samsung).
mtgx 14y ago
It sounds like A53 will start at 1.3 Ghz, and A57 will end at 3 Ghz. A 3 Ghz ARM CPU. Interesting: "For those who are still looking for gigahertz performance numbers Hurley sais]d that new A-50 family will deliver performance ranging from 1.3 gigahertz to 3 Gigahertz depending on how the ARM licensees tweak their designs." http://gigaom.com/2012/10/30/meet-arms-two-newest-cores-for-faster-phones-and-greener-servers/ http://gigaom.com/2012/10/30/meet-arms-two-newest-cores-for-...
Jonanin 14y ago
I wish they would release the architecture reference manual to the public... all we have is the instruction set right now. Not enough to do bare metal/os work.
- robot 14y ago
  you can get it if you register at arm.com and agree to their legal terms.
deleted 14y ago
[deleted]
mrbill 14y ago
I look forward to when I can replace my current quad-core 3Ghz x86 server (running Debian) with a many-cores ARM box with 16G+ RAM and use much less power - nothing I do on that machine needs x86. It's all webserving and email and IRC and such. Got my Chromebook in yesterday, and it's exactly what I've been wanting in a portable system for years. The screen isn't perfect but it's "good enough"; my only worries are about durability and build quality. I'm afraid my 2012 Macbook Air won't get near as much use now...
codex 14y ago
I don't believe these will be the first 64-bit ARMv8 CPU cores. Doesn't that honor go to Applied Micro's X-Gene SOCs? They'll ship a lot sooner than 2014.

85 points by sciwiz 14y ago

Looks very cool; the idea of having "big" and "little" processors on the same SoC is interesting. I wondering if this is a big win vs. just having a "big" processor that is frequently put into idle mode when not needed. As a side note, does anyone else find the ARM naming conventions totally impossible to follow? I look at the list of ARM models (http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_core...) and have no idea where to begin. The family/architecture/core scheme means you can have a single chip that is an ARM11 family, ARMv6 architecture, ARM1136JF-S core. How do people make sense of this? As someone who's writing a library that I want to be supported across all (or most) ARM cores, I don't have any idea how many different chips I'd need to test against to get a representative sample. There are so many optional features (NEON, Thumb, Thumb-2, VFP, etc) that seems to be supported in various combinations across the different models. It's like a maze and I never have any idea how a new model I read about fits in.

lucian1900 14y ago
The two CPUs appear to differ in dispatch and branch prediction. Interestingly, that's where much of the power/silicon budget goes nowadays.
- hoprocker 14y ago
  As I understand it, incorrect branch prediction becomes significantly more expensive (power-/time-wise) as pipeline length increases, so getting the prediction right and being able to correct quickly is quite important.
Symmetry 14y ago
Well, in regards to the first question generally a processor's performance is proportional to the sqaure root of it's area at a given frequency and voltage, and it's active power use and leakage are both proportional to it's area. So yes, a smaller core will be able to accomplish the same task for less energy even though it takes longer. Now it used to be that processors power budget was dominated by active power and the solution was to scale clockspeeds and voltage levels. As we move to smaller process nodes it's more about leakage power, which only goes away when you power down the core meaning that now race to idle is a better choice. But that's tangential to the bigger/smaller core issue.
Nursie 14y ago
Does your library have to be a single compiled binary across all these variants? If so, good luck... Otherwise, hopefully, a compiler takes care of most of the mess for you and gets you the best it can on the platform you're targeting. You might need to check that things would run on a variety of configurations - for instance hardfloat and softfloat do indeed have very different performance profiles when it comes to floats. Thumb shouldn't bother you too much as an application programmer (unless I'm very much mistaken) because it's just another instruction set for a compiler to target. Errr.... You can get into all sorts of complications when actually looking at the platform ABIs. Debian, for instance, seem to have something of a lowest-common-denominator approach that targets features present everywhere. Which is then why someone had to rebuild it to get decent FP performance out of the Raspberry Pi which had hard-float... Part of the complexity is that ARM is a licensed architecture. Some companies license the design of the whole core, some incorporate their own stuff and some just license the instruction set and do their own stuff otherwise. What do you mean 'supported across all (or most) ARM cores'? Because that's huge and varies massively. There are the sub-100MHz embedded devices I happen to be working on at the moment (which may be running any of a load of different OSs), there are ARM cores embedded in all sorts of controllers where I wouldn't think you'd want to run, then there's the multi-core multi-GHz stuff from the likes of Samsung, Qualcomm and Marvell...
- mbrubeck 14y ago
  I know that some of haberman's libraries (like upb) include JIT compilers. In those cases you can't just rely on the compiler to take care of instruction set differences. (I'm on the mobile Firefox team, and we run into similar issues targeting our JavaScript engine to different ARM flavors.)
  - Nursie 14y ago
    Then that very well could turn out to be a complete nightmare! Yes, if you're in the business of writing compilers - traditional, JIT or otherwise - then you're going to hit all sorts of issues with this stuff, and rapidly head off beyond the realms in which I have anything useful to say :)
- 14y ago
modeless 14y ago
Tegra 3 already has this big/little architecture, but using the same core design for all cores, the difference being that the "little" core is clocked lower and fabbed with a special low-power process. I imagine using two different core designs would be even more effective.
deleted 14y ago
[deleted]
brigade 14y ago
One good thing about 64-bit ARM is that there are no optional extensions (yet...) Floating-point and SIMD support are both required. As for your library, ignore CPU models to start with. Instead, look at the ARM architecture reference manual for a given revision; it will say which instructions are supported and which extensions are optional. Also the quick reference [1] which has a good summary of when various core instructions were added. Then test for the instructions you actually care about. You can safely ignore Thumb; it's an alternate encoding with tradeoffs that made sense nearly two decades ago but not anymore. You can also mostly ignore Thumb-2; there are processors that only support Thumb-2 but they also lack MMUs. Thumb-2 added some additional ARM instructions that can be useful, however. So essentially, (with each revision including the prior) ARMv4 : baseline ARMv5E : Load/store double, more multiply instructions, prefetch, bx <reg> ARMv6 : DSP extensions, rev, load/store exclusive ARMv6T2 : Thumb-2, movw/movt, bitfield manipulation, rbit, orn ARMv7-A : Memory barriers Thumb was optional in v4 and v5, and mandatory in v6. VFP was optional as of ARMv6, NEON optional as of ARMv7. NEON mandates VFP. Revisions of VFP and NEON aren't terribly important, except that VFPv3 (but not VFPv3-d16) gets 32 registers. As for chip to care about, ARMv6 + VFP (ARM1176jzf-s), ARMv7-A + VFPv3-d16 (Tegra 2), and ARMv7-A + NEON are by far the most common for general purpose stuff. If you want to get old-school, test a SheevaPlug for ARMv5E and an old PDA for ARMv4, though I'd not worry too much about ARMv4 (llvm for instance requires a baseline of ARMv5E last I checked.) [1] http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QR...
- haberman 14y ago
  This is a fantastically informative comment, thank you!

ChuckMcM 14y ago

Pretty creative stuff. I am looking forward to AMD building an eco-system around these things. My guess is that if AMD could deliver 64 bit ARM server chips and full programming documentation to support a robust Linux server OS architecture they could take a huge chunk of server share away from Intel based machines. My reasoning is that people started migrating to AMD when they had a 64 bit x86 architecture and Intel didn't. That showed me that folks were willing to go with AMD if they provided something that Intel wouldn't (or couldn't). Given that ARM isn't bogged down by Intel's staggering licensing challenges (chipsets, busses, instruction sets, etc) this suggests a very interesting couple of years ahead.

wmf 14y ago
It's not clear how AMD's ARM chips will be any better than the other ones (e.g. Calxeda), though.
- WiseWeasel 14y ago
  AMD could package them with their ATI/Radeon graphics processors.
  - mtgx 14y ago
    Unless they intend to make a mobile GPU like Nvidia did with Tegra, how will their Brazos GPU's compete in performance/Watt with something like the ARM Mali GPU, which would probably be a default choice for Calxeda.
    - WiseWeasel 14y ago
      It wouldn't. It would be a 16-CPU-core beast with a Radeon GPU aimed at competing with x86-64 performance/Watt.
    - wmf 14y ago
      Interestingly, ATI had mobile GPUs but sold them to Qualcomm. Nvidia's trickle-down approach of putting really old desktop GPUs in a mobile SoC doesn't seem to be doing very well.

deleted 14y ago

[deleted]

hemancuso 14y ago

Any Intel employees in the crowd? What's the level of worry surrounding ARM these days? Given Intel's high levels of competitive paranoia, news like this must have people fairly worried. Not to mention the explosive growth in adoption of the ISA over the past few years.

czhiddy 14y ago
I spoke to my friend @ Intel a while back, and he said that the company viewed Samsung as their main rival (not AMD, not ARM). His argument was that Intel's main competitive advantage (and where the majority of spending/R&D happens) was their fabs, and Samsung was the only other company that could come close to competing on that front.
EwanToo 14y ago
I think Intel's major worry with ARM is that simply speaking, ARM don't need their licencees to be particularly profitable at making chips for them to carry on designing chips, they just need them to buy new licences. For Intel, having a competitor designing CPUs who can't be undercut directly is a real issue - Intel are not going to be letting Samsung produce Xeon chips under licence in the next 5 years, though I do wonder about Atom ones..
fieldforceapp 14y ago
Well, INTC could adopt the same IP-based business model as ARM and then give up 98% of it's revenue: http://www.wolframalpha.com/input/?i=revenue+of+intel+vs+arm http://www.wolframalpha.com/input/?i=revenue+of+intel+vs+arm So the folks at INTC are doing what you'd expect, competing on discrete components and application-tuned architectures. A key example of that is the recent Merrifield-based chipset for smartphones which is obviously a key initiative: http://www.intomobile.com/2012/05/14/intel-merrifield-system-chip-may-end-up-2013-superphones/ http://www.intomobile.com/2012/05/14/intel-merrifield-system...
theatrus2 14y ago
Intel is first and foremost a fab company - they're ahead of pretty much everyone in semiconductor processes by at least one generation. If Intel needed to create an ARM-ISA compatible CPU tomorrow, they probably could, and it would be top notch (though maybe not at a margin Intel wants to play at). The biggest threats come from companies which have shown that they're willing to pour the big bucks into R&D and new fab construction (Samsung).

mtgx 14y ago

It sounds like A53 will start at 1.3 Ghz, and A57 will end at 3 Ghz. A 3 Ghz ARM CPU. Interesting: "For those who are still looking for gigahertz performance numbers Hurley sais]d that new A-50 family will deliver performance ranging from 1.3 gigahertz to 3 Gigahertz depending on how the ARM licensees tweak their designs." http://gigaom.com/2012/10/30/meet-arms-two-newest-cores-for-faster-phones-and-greener-servers/ http://gigaom.com/2012/10/30/meet-arms-two-newest-cores-for-...

Jonanin 14y ago

I wish they would release the architecture reference manual to the public... all we have is the instruction set right now. Not enough to do bare metal/os work.

robot 14y ago
you can get it if you register at arm.com and agree to their legal terms.

deleted 14y ago

[deleted]

mrbill 14y ago

I look forward to when I can replace my current quad-core 3Ghz x86 server (running Debian) with a many-cores ARM box with 16G+ RAM and use much less power - nothing I do on that machine needs x86. It's all webserving and email and IRC and such. Got my Chromebook in yesterday, and it's exactly what I've been wanting in a portable system for years. The screen isn't perfect but it's "good enough"; my only worries are about durability and build quality. I'm afraid my 2012 Macbook Air won't get near as much use now...

codex 14y ago

I don't believe these will be the first 64-bit ARMv8 CPU cores. Doesn't that honor go to Applied Micro's X-Gene SOCs? They'll ship a lot sooner than 2014.