74 Views

How to Choose the Right Arm CPU Core for ASIC

Choosing an Arm CPU core starts with the workload, not with the processor name. The right core depends on what the chip must do, the software it must run, the power and area available, whether deterministic real-time behavior is required, and how much performance the system actually needs. Arm offers processor IP ranging from extremely small embedded Cortex-M cores to Cortex-R real-time processors, Cortex-A and Cortex-X application processors, and Neoverse CPUs for infrastructure, cloud and high-performance computing.

For an SoC designer, the objective is therefore not to select the “fastest” Arm processor. It is to choose the processor architecture and core that provide the required performance and software capability without adding unnecessary power, silicon area, integration complexity or licensing cost.

 

Start With the Arm Processor Family

Arm organizes its CPU architecture around three main profiles. The M-profile targets small, energy-efficient embedded systems, the R-profile targets systems with real-time requirements, and the A-profile targets high-performance application processing. Arm’s Neoverse processors also use the application-class architecture but are optimized for infrastructure workloads such as cloud, networking, HPC and AI systems.

Processor Family Typical Applications Main Selection Driver
Cortex-M MCUs, IoT, sensors, wearables, embedded control, endpoint AI Low power, low area, deterministic embedded operation
Cortex-R Automotive control, storage, industrial systems, safety-critical real-time applications Deterministic real-time performance and functional safety
Cortex-A / Cortex-X Linux systems, mobile devices, consumer electronics, automotive compute and rich embedded systems Application performance and rich operating-system support
Neoverse Cloud, networking, telecom infrastructure, data centers, HPC and AI infrastructure Scalable compute performance and performance per watt

This first decision can eliminate much of the portfolio. A battery-powered sensor does not normally need an application processor, while a Linux-based edge computer is unlikely to be well served by a small microcontroller core.

1. Define the Software Environment

Software is often the fastest way to narrow the CPU choice. If the product runs bare-metal code or a small RTOS, a Cortex-M processor may be sufficient. If it requires Linux, Android or another rich operating system, an application-class processor is generally more appropriate.

Real-time systems require another distinction. Some products need predictable interrupt latency and deterministic response rather than maximum average throughput. Cortex-R processors are designed specifically for this class of workload, while newer Cortex-R82-class processors also add capabilities such as 64-bit processing and MMU support for richer software environments.

Existing software can be equally important. Reusing a validated software stack, safety package, middleware or development environment may save more engineering time than selecting a theoretically faster core.

2. Estimate the Performance You Actually Need

CPU performance should be defined from the workload rather than from marketing numbers. Consider interrupt rates, control-loop deadlines, operating-system overhead, protocol processing, application code, DSP workloads and the amount of headroom required for future software.

Do not rely on clock frequency alone. Two Arm cores operating at the same frequency can deliver very different performance because of differences in pipeline design, cache architecture, memory subsystem and instruction capabilities.

For high-end embedded applications, Cortex-M85 is currently positioned by Arm as its highest-performing Cortex-M processor and includes Helium vector-processing technology. Cortex-M55 provides mainstream DSP and machine-learning capability, while Cortex-M52 targets smaller, cost- and power-sensitive designs that still require Helium support.

3. Consider DSP, Machine Learning and Vector Processing

Many embedded processors are no longer used only for control code. Audio processing, motor control, computer vision, sensor fusion and small machine-learning models can create significant DSP requirements.

If these workloads are important, check whether the candidate core supports the appropriate vector or DSP extensions. Cortex-M52, Cortex-M55 and Cortex-M85 can include Arm Helium technology for DSP and ML acceleration. Application-class and infrastructure processors may use technologies such as Neon or Scalable Vector Extensions, depending on the processor and architecture.

For larger AI workloads, the CPU may also work alongside an NPU or other accelerator. In that case, CPU selection should consider orchestration, memory movement and system-level performance rather than CPU inference performance alone.

4. Determine Whether Real-Time and Functional Safety Are Required

Automotive, industrial, robotics, medical and storage systems may have strict timing or safety requirements. If the CPU must respond within guaranteed timing bounds, deterministic behavior can be more important than peak performance.

Cortex-R is Arm’s real-time processor family. Current options include Cortex-R52, Cortex-R52+, Cortex-R82 and Cortex-R82AE. Arm positions Cortex-R82AE as its highest-performing real-time safety processor, combining high single-thread performance with real-time and functional-safety capabilities.

Safety requirements should be identified early because they affect much more than CPU selection. They can influence lockstep implementation, memory protection, diagnostic coverage, safety documentation, software architecture and the overall SoC development process.

5. Balance Performance Against Power and Silicon Area

More CPU performance normally comes at a cost. A larger processor may consume more silicon area and power and require larger caches, a more capable interconnect and a higher-performance memory system.

For an always-on battery-powered product, reducing active and leakage power may be more valuable than maximizing benchmark performance. For a data-center processor, the calculation is different: performance per watt, memory bandwidth and scalability across many cores become key system metrics.

This is why selecting a CPU should be treated as an SoC-level decision. The CPU cannot be evaluated independently from the cache hierarchy, SRAM, DDR subsystem, interconnect, accelerators and process technology surrounding it.

6. Check 32-bit vs 64-bit Requirements

Word size can quickly narrow the available choices. Small embedded applications can often remain 32-bit, while applications requiring large address spaces, rich operating systems or modern infrastructure software increasingly require 64-bit support.

Do not select 64-bit simply because it appears more advanced. If the application does not benefit from the larger address space or software environment, a smaller embedded implementation may provide better power, area and cost efficiency.

7. Evaluate Security Requirements

Security capabilities should be considered at the beginning of CPU selection rather than added after the SoC architecture is complete. Depending on the core, relevant technologies can include TrustZone, privilege separation, memory protection, pointer-authentication features and support for secure execution environments.

The correct security architecture depends on the threat model. A connected sensor, automotive controller and cloud processor have very different security requirements even though all may use Arm CPU technology.

8. Consider the Complete SoC Ecosystem

The CPU is only one IP block. Before final selection, evaluate the surrounding ecosystem: interconnect IP, debug and trace, interrupt architecture, memory controllers, development tools, compilers, RTOS or OS support, software libraries, verification IP and available physical implementations.

It is also important to consider the target foundry and process node. A core that fits comfortably in one technology may have a very different power, frequency and area result in another. The final decision should therefore be based on implementation targets rather than processor specifications alone.

Arm CPU Core Selector: Find the Closest Match for Your SoC

With dozens of Arm processor options available, narrowing the portfolio can take time. The AnySilicon Arm CPU Core Selector is designed to provide a fast first-pass shortlist based on your project requirements.

Select your application, software environment and performance priority, then specify requirements such as functional safety, DSP or machine-learning acceleration, 64-bit processing and security. The tool compares these requirements against the Arm CPU portfolio and suggests the processors that most closely match your design profile.

The selector is intended for the early architecture stage. It does not replace detailed benchmarking, PPA analysis, Arm documentation or discussions with an IP supplier, but it can help design teams reduce a large CPU portfolio to a manageable shortlist before beginning a deeper technical evaluation.

[PROGRAMMER: INSERT ARM CPU CORE SELECTOR HERE]

Suggested button/heading inside tool: Find My Arm CPU Core
Suggested result label: Closest Matches for Your Requirements

Independent selection tool: This tool is provided by AnySilicon as an independent engineering aid and is not affiliated with or endorsed by Arm. Recommendations are intended for preliminary CPU IP shortlisting only. Final selection should be verified against the latest Arm documentation, licensing options and implementation requirements.

Do Not Choose an Arm Core on Performance Alone

The best Arm CPU core is the one that satisfies the complete product requirement with the lowest unnecessary complexity. Start with the software model and workload, determine whether real-time behavior or functional safety is required, estimate realistic compute performance, and then consider power, area, security, memory architecture and process technology.

A small Cortex-M processor may be the best solution for an embedded controller. A Cortex-R processor may be the right answer for deterministic real-time processing. Cortex-A or Cortex-X can support richer application workloads, while Neoverse targets scalable infrastructure compute. The important point is that these processors solve different problems; they should not be ranked on a single performance axis.

Once the processor family has been identified, compare the remaining candidates using workload-specific benchmarks and implementation data. That approach usually produces a more efficient SoC than simply starting with the most powerful available core and scaling backward.

Sources

Technical basis: Arm CPU Architecture and Processor IP product information, including current Cortex-M, Cortex-R, Cortex-A/Cortex-X and Neoverse portfolio information. Processor capabilities and availability evolve over time; confirm the latest Arm documentation before making a final IP selection.

Logo Image
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.