Throughout the world, if there's one universal constant in the smartphone and mobile device market, it's Arm. Whether it's mobile chip makers basing their SoCs on Arm's fully synthesized CPU cores, or just relying on the Arm ISA and designing their own chips, at the end of the day, Arm underlies virtually all of it. That kind of market saturation and relevance is a testament to all of the hard work that Arm has done in the last few decades getting to this point, but it's also a grave responsibility – for most mobile SoCs, their performance only moves forward as quickly as Arm's own CPU core designs and associated IP do.

Consequently, we've seen Arm settle into a yearly cadence for their client IP, and this year is no exception. Timed to align with this year's Computex trade show in Taiwan, Arm is showing off a new set of Cortex-A and Cortex-X series CPU cores – as well as a new generation of GPU designs – which we'll see carrying the torch for Arm starting later this year and into 2024. These include the flagship Cortex-X4 core, as well as Arm's mid-core Cortex-A720. and the new little-core Cortex-A520.

Arm's latest CPU cores build upon the foundation of Armv9 and their previous Total Compute Solution (TCS21/22) ecosystem. For their 2023 IP, Arm is rolling out a wave of minor microarchitectural improvements through its Cortex line of cores with subtle changes designed to push efficiency and performance throughout, all the while moving entirely to the AArch64 64-bit instruction set. The latest CPU designs from Arm are also designed to align with the ongoing industry-wide drive towards improved security, and while these features aren't strictly end-user facing, it does underscore how Arm's generational improvements are to more than just performance and power efficiency.

In addition to refining its CPU cores, Arm has undertaken a comprehensive upgrade of its DynamIQ Shared Unit core complex block, with the DSU-120. Although the modifications introduced are subtle, they hold substantial significance in terms of improving the efficiency of the fabric holding Arm CPU cores together, along with extending Arm's reach even further in terms of performance scalability with support for up to 14 CPU cores in a single block – a move designed to make Cortex-A/X even better suited for laptops.

With three new CPU cores and a new core complex, there's a lot to cover. So let's dive right in.

Arm TCS23 at a High Level: Pushing Efficiency & Going Pure 64-bit

Expanding on the enhancements introduced in the Armv9.1 architecture last year, Arm is progressing through its scheduled development cycle with the latest Armv9.2 architecture. The primary objective of this cycle is to eliminate support for 32-bit applications and transition to a comprehensive 64-bit platform. Underpinning this transition is Arm's strategic framework, "Total Compute Solutions" (TCS), which revolves around three core principles: compute performance, security, and developer access. This approach forms the foundation for Arm's methodology and guides its efforts in delivering optimal performance, robust security measures, and streamlined developer capabilities.

Arm's focus on phasing out the 32-bit instruction set has been one it has been working towards for several years. For their latest TCS23, they have finally created a fully 64-bit cluster to capitalize on the benefit of a complete 64-bit mobile ecosystem, excising AArch32 (32-bit instruction) support entirely.. So whether it's a big, mid, or little core, for Arm's latest generation of IP there is only AArch64.

Developing a dynamic system-on-a-chip (SoC) that caters to a broad spectrum of mobile devices, ranging from cutting-edge flagship smartphones to entry-level models, necessitates a meticulous and consistent approach to maintaining competitiveness in a rapidly expanding market. In the realm of flagship devices, for instance, Qualcomm's Snapdragon 8 Gen2 SoC stands out, leveraging a cluster of Arm's Cortex-X3, Cortex A715/710, and Cortex-A510 cores. The upcoming iteration of Qualcomm's Snapdragon 8 Gen3 and other SoC manufacturers are poised to harness the power of Arm's TSC23 core cluster and intellectual property to further enhance performance in the subsequent generation of flagship mobile devices.

Arm's latest DynamIQ Shared Unit, DSU-120, offers support for up to 14 CPU cores in a cluster, which opens the door to a significant number of different CPU core combinations. We'll see what SoC vendors have opted for later this year, but one probably configuration is a 1+5+2 (X4+720+520), which is likely a configuration for a high-end smartphone. Compared to a last-generation 1+3+4 cluster (X3+715+510), Arm is claiming an uplift of 27% in compute performance within GeekBench 6 MT and a more considerable uplift of between 33% and 64% in the Speedometer 2.1 benchmark depending on software optimizations implemented.

Focusing more on the approach to 64-bit migration, last year Arm announced their first AArch64-only CPU core, the Cortex-A715. Consequently, last year saw the release of the first 64-bit only products, such as MediaTek's Dimensity 9200 SoC, as well as Google's Pixel 7 – which was 64-bit only as a platform choice rather than an architectural restriction.

That said, actual AArch64 adoption/use within the larger software ecosystem has been slower than expected, primarily due to the Chinese market being slow to make the switch from 32-bit to 64-bit. Google has actually been key with its application storage (Google Play) by requiring its developers to submit 64-bit apps as far back as 2019, while also allowing the use of 32-bit applications on devices without native 64-bit support. Other markets haven't been as quick in doing so, but Arm claims that it is 'nudging' companies such as OPPO, Vivi, and Xiaomi to adopt AArch64 faster, which is believed to have the desired effect.

With the initial Armv9 architecture, Arm made improvements to security through the use of its Memory Tagging Extension (MTE) (Armv8.5), which is a hardware-based implementation that uses Pointer Authentication (PA) extensions to help protect from memory vulnerabilities. Memory-based vulnerabilities have been a consistent threat to hardware-based security for many years, and it is something Arm is continually developing within its IP to help mitigate these types of attacks. For reference, Google's Chromium Project claimed that around 70% of high-severity bugs are from memory.

One of the related security features of the latest Armv9.2 architecture is the introduction of a new QARMA3 Pointer Authentication Code (PAC) algorithm. Arm claims the newer algorithm reduces the CPU overhead of PAC to less than 1%, even on their little cores, giving developers and handset vendors even less of a reason to not enable the security feature. Most of these improvements revolve around hardware integrity and security, with a combination of MTE and native benefits through the 64-bit instruction and architecture, all designed to make devices even more secure going into 2023 and beyond. This fits with Arm's ethos to encourage a full switch to 64-bit over a hybrid 64 and 32-bit marketplace.

Finally, looking at performance, Arm claims that their latest generation CPU and core complex architecture has made solid gains in power efficiency. At iso-performance, Cortex-X4 offers upwards of a 40% reduction in power consumption versus Cortex-X3, while Cortex-A720 and A520 save 20-22% over their respective predecessors. On the DSU-120 hub itself, Arm claims an 18% improvement in power efficiency.

Of course, most of these power savings are going to instead be invested in additional performance. But it goes to show what SoC and handset vendors can aim for in this generation if they focus singularly on power efficiency and battery life.

Arm Cortex X4: Fastest Arm Core Ever Built
Comments Locked

52 Comments

View All Comments

  • Doug_S - Tuesday, May 30, 2023 - link

    Yes TSO is a mode, which requires a setting IN THE ISA to be able to enable it. That setting does not exist on ARM CPUs, only on Apple Silicon implementations.

    abr2 found what I didn't have time to look for in the ARMv8 architecture reference manual proving your ridiculous claim that ARMv8 required AArch32 support was wrong. Now you're picking on nits trying to twist my words as if I was claiming TSO is an instruction. Give it up you are wrong, everyone knows it, go away quietly instead of making yourself look like even a bigger fool.
  • dotjaz - Tuesday, May 30, 2023 - link

    And your understanding of ARMv9 is abysmal at best. ARMv9-A made Aarch32 EL0 optional, it wasn't possible in ARMv8-A. There is no special license or "something like that".
  • Chelgrian - Tuesday, May 30, 2023 - link

    It has been possible an architecturally permissible since ARMv8.0 to create an AArch64 only implementation. If AArch32 is not supported at a particular exception level then setting the M[4] bit in the SPSR and executing an ERET instruction to that level will produce an illegal exception return exception. Combined with designing the system to only reset in to AArch64 at the highest implemented exception level gives you an AArch64 only design.

    This tangentially referred to in rule R-tytwb in section D1.3.4 of revision J.a of the ARM Architecture Reference Manual.

    A conformant ARMv8.x implementation can (but it not mandated to) implement AArch32 at any exception level.

    A conformant ARMv9.x implementation may only implement AArch32 at EL0. This is documented in section 3.1 of revision J.a of the ARM Architecture Reference Manual.

    There are even documented ARMv8.1 processors out there which are AArch64 only for example the Cavium ThunderX2

    https://en.wikichip.org/wiki/cavium/thunderx2

    "Only the 64-bit AArch64 execution state is support. No 32-bit AArch32 support."
  • abr2 - Tuesday, May 30, 2023 - link

    From:
    Arm® Architecture Reference Manual
    Armv8, for Armv8-A architecture profile
    [2021 version]

    D1.20.2 Support for Exception levels and Execution states
    Subject to the interprocessing rules defined in Interprocessing on page D1-2525, an implementation of the Arm architecture could support:
    • AArch64 state only.
    • AArch64 and AArch32 states.
    • AArch32 state only.
  • techconc - Thursday, June 8, 2023 - link

    @dotjaz - You don’t know what you’re talking about. The Apple A7 chip supported both A32 and A64 instruction set. By the A11 (in 2017), Apple dropped A32 instruction set and was 64bit only.
  • dotjaz - Tuesday, May 30, 2023 - link

    > I'm very fairly certain of this, but if you know something I don't? (I might not..)

    You are clearly wrong, no ARM licensees can alter ARM ISA in any way. That's the fundation of ARM's licensing terms. And that's the sole reason Apple's AMX extention is masked as undocumented "co-processor" not available to anyone. Even if you knew nothing about the fundamental licensing terms, you should be able to figure that out because if this.
  • name99 - Monday, May 29, 2023 - link

    Jesus. The levels of delusion that are required to write a comment like this.
    You really think that
    (a) ARM is going to make a big deal about Apple being, in some legalistic sense, "non-compliant" AND
    (b) that Apple gives a fsck?

    Exactly who do you think gets hurt if Apple are not allowed to call APPLE SILICON (note that branding...) Arm Compliant?
  • Wereweeb - Tuesday, May 30, 2023 - link

    Lmao apple fanboys still as hilarious and ignorant as always
  • Silver5urfer - Sunday, May 28, 2023 - link

    So much of this nonsensical 64Bit bs. Esp in the name of security, News Flash - Qualcomm EDL mode exists and thankfully it helps the folks to unlock their Bootloaders.

    The whole 64Bit thing killed the passion on Android. Google just enforces it brutally by n-1 where n being the latest API SDK, thus making all the old apps go obsolete. Windows and x86 excels massively just because of this, Apple did it because they always want to control everything which they do, and the stupid Google just copies them in hoping to make same but they killed all fun on android now, the UI is so boring garbage and the whole Filesystem nerfs - Scoped Storage, lack of proepr SD Card app support and a ton of other APIs blacklisted. Limited the scope of foreground and background apps utilizing the hardware of a phone.

    What's the use of the ARM processor devices, when your latest and greatest X4 ARM phone will be outdated in 1 year and goes to dumpster after 2-3 years max. Non Removable, non serviceable, no longevity of the OS / HW / Software. Locked like chastity belt for the User tinkering when the core OS, the Kernel runs Linux. A big L to consumers and all that Environment jabber is literally just a worthless cacophony. Literally you have latest V30 class Micro SDs and SD Association even had PCIe / NVMe SSD class but since not a single $1000-$2000 Android phone pushes forward for a real computer in pocket, its rather a spybox and a mere 2FA device with some Navigation, Social Media, Camera attached.

    All this ARM tech is only useful if your device Software API can open it up properly and used a proper pocket computer. But that ship has sailed. All that X4 processing power and multi core non homogeneous compute wasted on basic consumables.
  • rpg1966 - Monday, May 29, 2023 - link

    Could you explain how the UI is affected by the bitness of the OS?

Log in

Don't have an account? Sign up now