ARM Cortex-R Architecture: Simon Craske, Senior Principal Engineer October, 2013
ARM Cortex-R Architecture: Simon Craske, Senior Principal Engineer October, 2013
ARM Cortex-R Architecture: Simon Craske, Senior Principal Engineer October, 2013
October, 2013
Foreword
The ARM architecture continuously evolves to support deployment of energy-efficient computation devices in a growing spectrum of applications that can take advantage of progress in semiconductor technology. Recent advances included the Large Physical Address Extensions (LPAE) for the ARMv7-A applications architecture and the new 32-/64-bit ARMv8-A applications architecture. This whitepaper discloses, for the first time, preliminary details of ARMs next step in architecture development for the ARM Cortex-R real-time processor series. These developments will lead to a new generation of Cortex-R processors that will meet the needs of integrated control and safety systems in applications such as automotive Advanced Driver Assistance Systems (ADAS), Hybrid Electric Vehicle (HEV) power train control and factory automation. This paper provides an opportunity for SoC and MCU designers to factor these architectural developments into their product planning, and for OEMs and ecosystem partners to be informed about what is driving the Cortex-R processor roadmap forward.
Page 1 of 7
Introduction
ARM is known primarily for its range of Cortex-A processors used in significant numbers of consumer devices such as smartphones and tablets. Each of these processors is based on evolutions of ARMs application profile (A profile) architecture, with each generation adding new features for increased performance and capabilities, while ensuring compatibility with a broad software ecosystem. Some features -- for example, the addition of 64-bit processing in ARMv8-A -- benefit significantly from being presented to the ARM ecosystem ahead of products containing this feature becoming available; this provides an opportunity for discussion and development of associated software, including operating systems, and system IP collateral, as well as providing guidance on ARMs intended direction. In addition to the A profile, the ARM architecture also contains profiles targeting the specific needs of embedded, real-time processors and microcontrollers, respectively called the Real-time (R profile) and Microcontroller profiles (M profile). Found in systems ranging from anti-lock-braking to white goods to cell phone radios, the Cortex-R and Cortex-M series processors, based on these profiles, form the relatively unknown masses of CPUs that make the everyday world work in a safe and reliable way. While not announcing any new specific processors, this white paper aims to provide an introduction to the next evolution in the ARM R architecture profile used by ARMs Cortex-R series processors, and in doing so, kick-start changes in the ecosystem to accommodate the benefits this new architecture brings to integrated control and safety systems.
Page 2 of 7
Cortex-R4 Introduced 2005: - ARMv7-R architecture - High-performance, real-time, deeply embedded processor - Deterministic event response - Soft and hard error handling - Configurable feature set
Cortex-R7 Introduced 2012: - ARMv7-R architecture - Large performance increase - Advanced micro-architecture - Higher clock frequency - Symmetric multiprocessing - Accelerator coherency port - Quality of service features - Enhanced error management - Integrated interrupt controller Table 2 ARM Cortex-R portfolio evolution
Cortex-R5 Introduced 2010: - ARMv7-R architecture - Low-latency peripheral port - Accelerator coherency port - Dual core in split or lock step - Bus error management - Smaller floating-point unit - Enhanced memory protection
As shown in Table 2, since the introduction of the Cortex-R4 processor in 2005, the features and capabilities of ARMs embedded processors have been driven to provide a portfolio capable of supporting high-performance computing solutions for embedded systems, where high availability, fault tolerance, maintainability and real-time responses are required, such as: Automotive: Storage: Mobile handsets: Embedded: Enterprise: Home: Cameras: Airbag, braking, stability, dashboard, engine management Hard disk drive controllers, Solid state drive controllers 3G, 4G, LTE, WiMax smartphones and baseband modems Medical, industrial, high-end microcontroller units (MCU) Networking and printers; Inkjet and multi-function printer Digital TV, BluRay players and portable media players Digital still camera (DSC) and digital video camera (DVC)
In addition to the requirements of todays systems, ARM sees four new challenges for real-time application developers. These can be summarized as: Desire for consolidation: The aim of providing more capable systems results in a desire to merge previously multiple discrete systems onto a single processor, bringing new challenges regarding isolation of these previously independent systems. Increased safety and integrity: The evolution of safety standards and a requirement for more robust systems are resulting in demands for improved isolation between tasks along with guaranteed quality of service for interrupts. Demand for feature-rich software: The ability to reuse communication stacks, such as Ethernet or WIFI, along with other libraries and applications from the application world, in a real-time system compatible way. New higher-performance applications: New application markets, such as radar processing in automotive and improved graphics in human machine interfaces (HMI), result in new computational requirements.
Page 3 of 7
ARMv8-R Architecture
The ARMv8-R architecture represents the latest evolution of the ARM real-time architecture profile. While adopting some features from the ARMv8-A architecture announced in 2011, ARMv8-R remains a 32-bit architecture using the AArch32 exception model (compatible with that used in ARMv7-R) and executing the A32 (ARM) and T32 (Thumb) instruction sets. In addition to the real-time features already present in ARMv7-R, the ARMv8-R architecture adds a number of key architectural capabilities aimed at addressing the requirements of future integrated control and safety applications.
SP_svc LR_svc
SP_abt LR_abt
SP_und LR_und
SP_hyp
Figure 1 - AArch32 register file The addition of virtualization, when combined with appropriate hypervisor software (also known as a virtual machine monitor), provides the ability to isolate memory and processing time between numerous different guest operating systems and their tasks/applications. As show in Figure 2, a single hypervisor at exception level 2 (EL2) is capable of hosting multiple guest operating systems, with each guest operating system (OS) still retaining two distinct exception levels, typically one for the kernel (EL1) and one for its applications/tasks (EL0). Flexibility in the architecture also permits time critical tasks, such as interrupts and device drivers, to be run directly by the Hypervisor as its own tasks at EL0.
Page 4 of 7
EL0 Multiple consolidated operating systems and tasks EL1 Dedicated real-time hypervisor exception level
TASK 1
TASK 2
TASK 1
TASK 2
Guest OS 1
Guest OS 2
EL2
Hypervisor
Figure 2 - Three exception level model In order to maintain determinism, the stage-2 memory translation scheme of the ARMv8-R architecture differs from that of a conventional system, such as ARMv8-A. In particular, a conventional scheme would support translation at stage-2, i.e. every memory address produced by EL1 would traditionally be translated to a new address by a second stage of translation; whereas the stage-2 scheme in the ARMv8R architecture only supports protection. As a result, the intermediate physical address (IPA) generated by a given guest OS is always the same as the final Physical Address (PA). Like the PMSA Memory Protection Unit (MPU) of ARMv7-R architecture, the MPU is register-based and tightly coupled to the processor, providing fast, deterministic responses. This avoids cases, for example, causing failures in hard real-time systems when an interrupt is not serviced in the required time due to the overhead of pagetable walks required to refill the TLB on a miss. The stage-2 MPU ensures the integrity of the hypervisor software and isolates each of the guest operating systems to its own physical address space, controlling whether or not a particular OS can assess any given peripheral or memory location.
MPU
TASK TASK TASK TASK
ADDRESS SPACE
Guest OS 1
Guest OS 2
x x
Hypervisor
Page 5 of 7
software: the MPU permits a region to start and end at any address equal to an integer multiple of 64 bytes. As Figure 4 illustrates, this permits a single region to describe a given memory region that requires the concatenation of numerous regions in PMSAv7.
0x3BC00 PMSAv7 PMSAv8
0x3C000
0x80400
16kB 256kB SINGLE 274kB REGION
0x40000 0x80000
1kB
1kB
Figure 4 - PMSAv7 vs PMSAv8 MPU example The potential to describe the required memory map with fewer regions allows for faster programming of the MPU, and thus context switching. This is further enhanced by PMSAv8 providing direct access to each of the MPU region registers which, when compared with the indirect mechanism used by PMSAv7, reduces the number of system register writes required to program the same number of regions. The ARMv8-R architecture implements separate PMSAv8 compatible EL1 controlled stage-1 and EL2 controlled stage-2 MPUs. This allows EL1 operating systems to reconfigure their memory protection without intervention by the hypervisor software. However, the stage-2 MPU always makes the final decision about whether or not a memory transaction is permitted, ensuring a robust system.
Page 6 of 7
Conclusion
The ARMv8-R architecture brings new technology to the world of integrated control and safety applications. Providing virtualization and new memory protection features, theARMv8-R architecture offers the ability to consolidate and safely isolate multiple systems. At the same time, the ARMv8-R architecture offers the addition of VMSA capabilities to real-time systems, allowing the combination of communication and other software stacks with embedded software for fully featured systems. This white paper provides an early preview of the architecture and its capabilities ahead of any product announcement with the intention of facilitating discussion and development of the associated eco-system collaterals.
References
For further details on ARMs architecture profiles and Cortex-R processor portfolio, please visit the ARM website at www.arm.com or the new online ARM Connected Community.
Page 7 of 7