It’s that time of the year again, and after last month’s unveiling of Arm’s newest infrastructure Neoverse V1 and Neoverse N2 CPU IPs, it’s now time to cover the client and mobile side of things. This year, things Arm is shaking things up quite a bit more than usual as we’re seeing three new generation microarchitectures for mobile and client: The flagship Cortex-X2 core, a new A78 successor in the form of the Cortex-A710, and for the first time in years, a brand-new little core with the new Cortex-A510. The three new CPUs form a new trio of Armv9 compatible designs that aim to mark a larger architectural/ISA shift that comes very seldomly in the industry.

Alongside the new CPU cores, we’re also seeing a new L3 and cluster design with the DSU-110, and Arm is also making a big upgrade in its interconnect IP with the new cache coherent CI-700 mesh network and NI-700 network-on-chip IPs.

The Cortex-X2, A710 and A510 follow up on last year's X1, A78 and A55. For the new Cortex-X2 and A710 in particular, these are direct microarchitectural successors to their predecessors. These parts, while iterating on generational improvements in IPC and efficiency, also incorporate brand-new architectural features in the form of Armv9 and new extensions such as SVE2.

The Cortex-A510, Arm's new little core, is a larger microarchitectural jump, as it represents a new clean-sheet CPU design from Arm’s Cambridge CPU design team. A510 brings large IPC improvements while still having a continued focus on power efficiency, and, perhaps most interestingly, retains its characteristic in-order microarchitectural.

An Armv9 CPU Family – AArch64 only for all practical purposes*

The new CPU family marks one of the largest architectural jumps we’ve had in years, as the company is now baselining all three new CPU IPs on Armv9.0. We've extensively covered the details of the new Arm architecture back in late March. Cornerstone features of the new ISA include the new enrollment of prior optional/missing Armv8.2+ features that weren’t guaranteed in mobile and client designs (mostly due to the older A55 cores), and the introduction of new SVE2 SIMD and vector extensions.

One big change we’ve been expecting for quite some time now is that we’ll be seeing a deprecation of the 32-bit AArch32 execution mode in upcoming Arm Cortex-A mobile cores. The clock has been ticking for 32-bit apps ever since Google’s announced in 2019 that the Google Play store will require for 64-bit app uploads, and the company will stop serving 32-bit applications to 64-bit compatible devices later this summer

While Arm is declaring that shift to happen in 2023, for all intents and purposes it’s already happening next year for most global users. Both the Cortex-X2 flagship core and the Cortex-A510 little cores are AArch64-only microarchitectures that are no longer able to execute AArch32 code.

With that said, sharp readers will note that two out of three CPUs isn't a complete shift, and the reason for that is because the Cortex-A710 actually still supports AArch32. Arm states that the reason for this is primarily to meet the needs of the Chinese mobile market, which lacks the homogeneous ecosystem capabilities of the global Play Store markets, and Chinese vendors and their domestic app market require a little more time to facilitate the shift towards 64-bit only. This means we’ll have an odd scenario next year of having SoCs on which only the middle cores are able to execute 32-bit applications, with those apps being relegated to the middle A710 cores and missing out on the little A510 cores’ power efficiency or the X2 cores’ performance.

On the big core side, the new Cortex-X2 and Cortex-A710 are successors to the Cortex-X1 and Cortex-A78. Both designs are mostly designed by Arm’s Austin design team, and represent the 4th generation of this microarchitecture family, which had started off with the Cortex-A76 several years ago. These cores should be the last of this microarchitecture family before Arm hands things off to a completely new design with next year’s new Sophia cores.

In terms of design philosophy, the X2 and A710 generally keep the same overarching goals the X1 and A78 had defined: The X-series continues to focus on advancing performance by increasing microarchitectural structures and by Arm being willing to make compromises on power within reasonable limits. Meanwhile the A710 continues to focus on advancing performance and efficiency through smarter design and with a large focus on maximizing the power, performance, and area (PPA) balance of the IP.

One point Arm makes in the above slide is having optimized critical paths and physical design for sustained voltage operations – this is more of a goal the company is striving for in the next generations of “middle” cores rather than something that’s specifically reflected in the Cortex-A710.

This year, we are also finally seeing a new little core. We had covered the Cortex-A55 back in 2017, and since then we haven’t had seen any updates to Arm’s little cores, to the point of it being seen as large weakness of last few generations of mobile SoCs.

The new Cortex-A510 is a clean-sheet design from Arm’s Cambridge design team, leveraging a lot of the technologies that had been employed in the company’s larger cores, but implemented into a new in-order little microarchitecture. Yes – we’re still talking about an in-order core, and Arm still sees this to be the best choice in terms of extracting the best efficiency and “Days of use” of mobile devices.

Even though it’s a in-order core, Arm made a comparison that the new design is extremely similar to a flagship core of 2017 – namely the Cortex-A73, achieving very similar IPC and frequency capabilities whilst consuming a lot less power.

The new design also comes with a very interesting shared complex approach and shares the L2 and FP/SIMD pipelines with a second core, a design approach Arm calls “merged core” and undoubtedly will remind readers of AMD’s CMT approach in Bulldozer cores 10 years ago, even though there are quite important differences in the approaches.

The Cortex-X2: More Performance, Deeper OoO
Comments Locked


View All Comments

  • WorBlux - Thursday, May 27, 2021 - link

    These micro-ops are greatly exaggerated. For instance Gracemont CPU's don't have any. And 4 of the 5 decoders on intel are simple, meaning they only drop one micro-op per instruction.

    Having to deal with a variable length instruction is still a bitch on the front end.
  • mode_13h - Saturday, May 29, 2021 - link

    > Gracemont CPU's don't have any.

    I think you meant to say they don't have micro-op *caches*.
  • Tomatotech - Tuesday, May 25, 2021 - link

    They’re correct. x86 cores have been RISC internally since the Pentium era. They’re black boxes that take CISC instructions, then internally these instructions are converted to RISC for the microprocessors.

    See the Development section of this wiki article for the Pentium. Later chips expanded and further developed the internal RISC parts after the success of the Pentium. Sorry to shatter your illusions.
  • Wilco1 - Tuesday, May 25, 2021 - link

    RISC/CISC is only ever about the ISA, never about implementation. Even the very first 8086 uses simpler micro-ops internally in its microcode, but that doesn't make it any more RISC than modern implementations.

    Another common misconception that changing the decoder is all that is required to change ISAs. This is also incorrect since the internals are very different between ISAs.
  • Thala - Tuesday, May 25, 2021 - link

    Precisely. x86 will never escape from the problem:
    - having variable length instructions
    - having less architectural registers
    - having TSO memory model

    And no internal RISC-like microarchitecture will help with above issues.
  • GeoffreyA - Wednesday, May 26, 2021 - link

    "having variable length instructions"

    The main bottleneck of x86 and the part where ARM has the upper hand. Still, it's not impossible that some genius at AMD or Intel could crack the variable-length handicap once and for all. The micro-op cache did much. Something else is still missing.
  • mode_13h - Wednesday, May 26, 2021 - link

    > Still, it's not impossible that some genius at AMD or
    > Intel could crack the variable-length handicap once and for all.

    The only solution I see to that is basically letting the uop cache spill to RAM, so the decoder works more like a JIT translation engine.

    And that only solves *one* of x86's key detriments.
  • GeoffreyA - Thursday, May 27, 2021 - link

    That's a possibility but more work on the OS side. In that case, it might be better to switch to a new, fixed-length ISA altogether.

    If there were some way to index instruction start/end before reaching the decoder. Perhaps the compiler could help but that might break compatibility.
  • mode_13h - Saturday, May 29, 2021 - link

    > That's a possibility but more work on the OS side.

    Yes. The era of "free" CPU performance improvements is coming to an end.

    > In that case, it might be better to switch to a new, fixed-length ISA altogether.

    Well, it's one thing Intel or AMD could do to eke a little more life out of x86-64. I think it's actually not a lot to ask from operating systems.

    > If there were some way to index instruction start/end before reaching the decoder.

    Perhaps the L1 instruction cache could do some preliminary analysis, during fills. They could add a couple extra bits per byte, to hold information subsequently useful to the decoder.

    Or, maybe the decoder could just write back some info to help itself, if it needs to re-decode those same instructions after the corresponding micro-ops have been evicted from the micro-op cache.
  • GeoffreyA - Monday, May 31, 2021 - link

    "Perhaps the L1 instruction cache could do some preliminary analysis"

    Interestingly, some CPUs did mark the instruction boundaries in the cache. Possibly the same principle. If I remember right, the Pentium MMX and some of the Atoms; and on AMD's side, K7 all the way to Bulldozer.

Log in

Don't have an account? Sign up now