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

181 Comments

View All Comments

  • mode_13h - Tuesday, June 1, 2021 - link

    > some CPUs did mark the instruction boundaries in the cache.

    Not surprising, other than how far back you say it went.
  • mode_13h - Wednesday, May 26, 2021 - link

    All good points. People who think "ISA doesn't matter" don't really understand everything an ISA encompasses.
  • GeoffreyA - Wednesday, May 26, 2021 - link

    The difference that divides them is that CISC can include a memory operation as part of an arithmetic one, whereas in RISC the two are separate (at least, in a load-store architecture).
  • mode_13h - Wednesday, May 26, 2021 - link

    > The difference that divides them is that CISC can include a memory operation

    I'm not an expert on the subject, but there are other elements in RISC orthodoxy, concerning things like:

    * number of operands (also number of src & dst operands)
    * encoding of immediates
    * side-effects

    I view the whole subject of CISC vs. RISC as something like MMA (Mixed Martial Arts). It turns out that there's no single best classical martial arts style. The most effective fighters use a blend of techniques adopted from various, disparate fighting styles.
  • GeoffreyA - Thursday, May 27, 2021 - link

    "The most effective fighters use a blend of techniques"

    Absolutely. It's almost a universal principle that the winning design puts together the best elements from competing designs and throws away the junk.
  • Thala - Tuesday, May 25, 2021 - link

    It does not matter that they are RISC-like inside, the issue with x86 is that they still carry the typical CISC baggage - and no internal RISC-like structure will help them here.
  • km1810vm4 - Wednesday, May 26, 2021 - link

    I would say x86 baggage. There were much nicer CISC architectures around at the time, like the Motorola 68000.
  • TheinsanegamerN - Wednesday, May 26, 2021 - link

    Intel's p5 processors implemented RISC style micro ops into their x86 decoding, that's part of why they were so dramatically faster then 486. It's not like this is hard to find out....
  • mode_13h - Thursday, May 27, 2021 - link

    > Intel's p5 processors implemented RISC style micro ops into their x86 decoding

    In fact, early CPUs used a lot of microcode, and one of the ways they got faster was by replacing microcoded operations with hardwired logic. This was enabled by ever-increasing transistor budgets.

    > that's part of why they were so dramatically faster then 486.

    This feels like a bit of revisionist history. Here are some of the reasons why Pentium was faster than 80486:

    https://en.wikipedia.org/wiki/P5_(microarchitectur...
  • Kamen Rider Blade - Tuesday, May 25, 2021 - link

    Android needs to get their developers to stop using Java and use C/C++/Rust for their apps to eek out the max performance possible.

    Apple's App code base is generally C/C++, that's why they have the performance that they have.

    And it's a long time nagging issue that I wish the Android community would solve.

    It would give Android a HUGE performance boost to move their Apps over to C/C++/Rust.

    Programming Languages have already been benchmarked against each other to see which one's faster and sorry to say it, but the C/C++/Rust family win the day in terms of Code Speed while using the same hardware platform.

    https://benchmarksgame-team.pages.debian.net/bench...

Log in

Don't have an account? Sign up now