The Arm Cortex-R52 processor delivers high performance 32-bit processing offering efficient code density combined with the highest level of integrated capability for functional safety of any Arm processor.
The Cortex-R52 processor meets the rising performance needs of advanced real-time embedded systems. As the first Armv8-R processor, Cortex-R52 introduces support for a hypervisor, simplifying software integration with robust separation to protect safety-critical code.
Arm Cortex-R52 processor
|Instruction set||Arm and Thumb-2. Supports DSP instructions and a configurable Floating-Point Unit either with single-precision or double precision and Neon.|
|Microarchitecture||8-stage pipeline with instruction pre-fetch, branch prediction, superscalar in order execution, parallel execution paths for load-store, MAC, shift-ALU, divide and floating-point.
|Up to quad-core||Multi-processor configurations of up to 4 integer CPUs within a single cluster or 8 logical cores (in DCLS configuration).|
|Dual Core Lock Step (DCLS)||Redundant Cortex-R52 cores in lockstep for fault detection in dependable systems with optional Split/lock configuration to decouple checking core enabling independent execution.|
|Safety Package||Licensable, extended safety package to simplify product safety implementation.|
|Self test technology||High fault coverage through ‘Built In Self Test’ capabilities (BIST).|
|Software test libraries||Software libraries providing flexible non-destructive run-time fault coverage.|
|Cache controllers||Optional Harvard memory architecture with write through Instruction and Data caches. Cache sizes are independently configurable for 4K to 32K.|
|Tightly-coupled memories||Optional Tightly-Coupled Memory for highly deterministic or low-latency applications that may not respond well to caching (e.g. instruction code for interrupt service routines and data that requires intense processing). Cortex-R52 supports up to 3 TCMs, each configurable up to 1MB.
|Generic Interrupt Controller||Fully integrated Generic Interrupt Controller (GIC) supporting complex priority-based interrupt handling managing standard interrupt (IRQ), fast interrupt (FIQ) inputs.The processor includes low-latency interrupt technology that allows long multi-cycle instructions to be interrupted and restarted. Deferral of lengthy memory accesses occurs in certain circumstances. Configurable to support from 32 to 960 interrupts including Software Generated Interrupts which can be routed between multiple cores.
|Memory Protection Unit (MPU)||Level 1 MPU always implemented with optional Level 2 MPU.
Up to 24 region Level 1 MPU configures attributes for regions from 64 bytes upwards with resolution of 64 bytes.
Optional additional Level 2 MPU operating at EL2 also configures attributes for up to 24 regions with as little as 64 Byte resolution. All transactions executed at EL0/EL1 perform a look-up in both MPUs with the combined least permissive attributes taken. All transactions executed at EL2 perform a look-up in Level 2 MPU only.
|Floating-Point Unit (FPU)||Support for two FPU options: either a single precision-only with 32x 32-bit single precision registers, or double precision in Advanced SIMD implementations with 32x 64-bit / 16x 128-bit double precision registers. The FPU performance is optimized for both single and double precision calculations. Operations include add, subtract, divide, multiply, multiply and accumulate, square root, conversions between fixed and floating-point, and floating-point constant instructions.|
|Advanced SIMD (NEON)||Optionally implemented when double precision floating point is included is the Advanced SIMD supporting integer or single precision results.|
|ECC||Single-bit error correction and double-bit error detection for cache and TCM memories. All bus interfaces using Error Correcting Code (ECC). Single-bit soft errors are automatically corrected by the processor. In addition, full and flexible support for managing hard errors.
|Port protection||Optional port protection enabling ECC on the Level 2 interfaces including Data and Address.
||128-bit AMBA AXI-4 bus manager port for Level-2 memory and peripheral access, with ECC protection.
|TCM access port
||128-bit AMBA AXI-4 bus subordinate port for low latency access to the TCMs for high-speed streaming of data in and out of the processor, with optional protection.
|Low Latency Peripheral Port (LLPP)
||A dedicated 32-bit AMBA AXI port supporting 4Mbytes addressable range to integrate latency-sensitive peripherals more tightly with the processor, with optional protection.
|Flash Interface Port||Per core dedicated 128-bit AMBA AXI port to integrate latency-sensitive Flash memory tightly to a specific core within the processor cluster, ECC protection configurable for either 128-bit or 64-bit chunk size.
|Bus Interconnect Protection||Optional additional protection to guard against errors in the interconnect switch fabric, and end to end transaction protection.|
|Debug||Debug Access Port is provided. Its functionality can be extended using CoreSight Debug and Trace.
|Trace||Cortex-R52 includes a CoreSight Embedded Trace Module that can be configured per core or shared between the cores in the cluster.|
Compare the specifications of Cortex-R processors:
Download comparison table
Start designing now
Arm Flexible Access gives you quick and easy access to this IP, relevant tools and models, and valuable support. You can evaluate and design solutions before committing to production, and only pay when you are ready to manufacture.
Processor area, frequency and power consumption are highly dependent on process, libraries and optimizations. The table below estimates a typical single processor implementation of the Cortex-R52 processor on mainstream low-power process technology (16nm) with high-density, standard-performance cell libraries and 32KB instruction cache and 32KB data cache.
|Cortex-R52 single processor||16nm FFC|
|Maximum clock frequency||Above 1.6 GHz|
|Performance||2.09 / 2.72 / 5.99 DMIPS/MHz*
|Total area (including core + RAM + routing)||From 0.35 mm2|
* The first result abides by all of the 'ground rules' laid out in the Dhrystone documentation, the second permits inlining of functions (not just the permitted C string libraries) while the third additionally permits simultaneous multifile compilation. All are with the original (K and R) v2.1 of Dhrystone.