The Cortex-A32 is a unique product in the ARM architecture, holding an important position. The Cortex-A32 is based on the ARMv8-A architecture but is designed specifically for 32-bit processors. The figure below shows the compatibility of the Cortex-A32 with the ARMv8-A architecture and compares it with the Cortex-A35.
Figure 1: Cortex-A32 and ARMv8-A
Tips
Based on the above, the Cortex-A35 can achieve two execution states: 32-bit AArch32 and 64-bit AArch64, fully utilizing the 64-bit operational capabilities of the ARMv8-A architecture. In contrast, the Cortex-A32 only supports the 32-bit AArch32 execution state, a decision that not only further compresses product area but can also lead to significant power consumption optimization for use cases that do not require 64-bit operational capabilities.
Undoubtedly, some embedded applications can benefit from 64-bit, but many others are 32-bit, and for a long time, the market will remain so. The Cortex-A32 is tailored for these applications.
The AArch32 execution state is an upgraded version of the ARMv7-A architecture used in earlier Cortex-A processors. Although it does not have 64-bit capabilities, other features have been significantly enhanced, making the Cortex-A32 more efficient compared to the Cortex-A7 and Cortex-A5; it is an ideal choice for the evolution of designs based on earlier ARM processors or for entirely new designs focused on the embedded market.
Compared to ARMv7-A, AArch32 has the following enhancements:
Adding multiple new instructions, improved performance of cryptographic functions
New Load Acquire and Store Release instructions make memory access ordering more efficient, matching the new C++11 memory ordering semantics
Additional scalar and single-instruction multiple-data structure (SIMD) floating-point instructions
A richer set of system control instructions
Compared to earlier 32-bit ARMv7-A processors, these additional features of AArch32 provide better performance.
The Advanced Coherency Extensions (ACE) on the Cortex-A32 bus interface allow it to build fully coherent multiprocessor systems on demand for higher performance. However, if product area and power consumption are the main limiting factors, the Cortex-A32 also offers a version optimized for single-processor applications, removing coherency logic for greater efficiency.
With the Large Physical Address Extension (LPAE), the addressable memory space of the Cortex-A32 is expanded beyond the 32-bit (4GB) limit of the Cortex-A5 to 40-bit physical address space.
The core itself is equipped with additional advanced features to further enhance efficiency. These include more flexible power management, optimized power domains, and extended use of retention power gating.
Main Features of ARMv7-M
The ARM Cortex-M processors are based on the ARMv7-M architecture (Cortex-M0 and Cortex-M0+ adopt a similar ARMv6-M architecture). While there are many similarities with earlier ARM architectures, ARMv7-M has been specifically designed for deep embedding and low-cost real-time microcontroller applications. As a result, many features of earlier architectures have been removed, and new features have been added to create a programming model that better fits a “microcontroller” environment.
Compared to earlier processors (such as the popular ARM7TDMI), the changes are as follows:
1.The number of operating modes has been significantly reduced from 7 or more to 2: only retaining the processor mode and thread mode. One of the modes (processor mode) can be set as the default priority.
2.The register file has been simplified. Although the number of registers available to the programmer remains essentially 16, the grouping register mechanism used in earlier architectures has been significantly reduced, so both operating modes only store the stack pointer (r13). Whether to use register copies can be set freely.
3.The changes in exception modes are the most significant. Since typical microcontroller applications may generate a large number of external peripheral interrupts, all Cortex-M cores in the new architecture are equipped with a standard Nested Vectored Interrupt Controller (NVIC). Similarly, the exception handling modes have been standardized based on the vector table that records processor addresses. Context saving and restoration operations are implemented entirely in hardware, further simplifying the software tasks of writing interrupt handlers. As a result, the chances of disruptive delays during implementation are minimized and highly predictable.
4.Similar to earlier ARM processors, ARMv7-M defines an optional memory protection architecture. Additionally, since bare-metal systems or systems running under real-time operating systems (RTOS) typically do not require virtual memory, ARMv7-M does not provide support for it.
5.To assist in the implementation and porting of real-time operating systems (RTOS), some standard on-chip peripherals have also been defined in the architecture, such as the SysTick timer.
6.To further reduce the area of the processor core, ARMv7-M processors only use the Thumb instruction set (including the Thumb-2 instruction set extension).
Main Features of ARMv8-A AArch32
The Cortex-A processors are based on the ARMv7-A or ARMv8-A architecture. ARMv8-A processors support the AArch32 execution state, which is a compatible upgrade of the 32-bit ARMv7-A architecture. The designs of these architectures add exclusive features, such as virtual memory environments, to support platform operating systems including Linux, Android, and Windows.
Compared to Cortex-M processor cores, the unique features of Cortex-A include:
1.Having 7 or more operating modes: User, Manager, IRQ, FIQ, Undefined, Abort, and System. Each mode can handle a specific event; for example, the IRQ mode is used to handle IRQ interrupts. AArch32 also supports two additional modes: Hyp and Monitor, which are used for virtualization and ARM TrustZone, respectively.
2.Although the number of registers available is also 16, AArch32 has many “banked” registers corresponding to the above operating modes. Once entering a specific operating mode, these registers will replace the corresponding user mode. This simplifies many aspects of exception handling but also means that machine management capabilities need to be enhanced, requiring more effort in initialization.
3.Exception modes have significant differences, inheriting from the original ARM architecture devices. Specifically, the vector table consists of a set of executable instructions rather than addresses, and the tasks of saving and restoring context are almost entirely handled by the programmer.
4.Another important difference is the Memory Management Unit (MMU), which compiles the virtual addresses submitted by the core with the physical addresses required by the storage system. Cortex-A can also support the complete demand paging virtual memory environment used by platform operating systems like Linux.
Differences Between ARMv7-M and AArch32
When migrating from a Cortex-M based system to a Cortex-A32 based system, many new features are also necessary to understand. Although there are many similarities between the two architectures (such as the commonality of register groups and instruction sets), it is essential to be clear that many features of the ARMv8-A architecture in the AArch32 execution state are based on earlier architectures. This section will detail the features of AArch32 that are not present in ARMv7-M or are implemented very differently.
Operating Modes
As shown in Figure 2, ARMv7-M defines only two operating modes: thread mode and processor mode. The processor mode can be set to normal mode, meaning that software can disable this feature when not needed. The processor mode is primarily used for handling exceptions, while the linear mode is used for user processes. The transition between modes is essentially automatic, occurring under the conditions shown in the figure. When an exception occurs, the processor mode is automatically enabled, and after the exception handling is completed, the processor mode automatically exits. The SVCall instruction is the primary method for software to enter processor mode (setting the triggered IRQ as pending allows the processor to perform exception operations).
Figure 2: ARMv7-M Operating Modes
In contrast to Figure 3, Figure 2 shows the operating modes supported under the AArch32 execution state. There are seven basic operating modes, five of which are used to handle specific exceptions. For example, if a Fast Interrupt (FIQ) exception occurs, it will enter FIQ mode; if an undefined instruction occurs, it will enter Undef mode, and so on.
Figure 3: AArch32 Operating Modes
Mode transitions are typically executed automatically, but if the mode field in the Current Program Status Register (CPSR) is written, mode transitions can be fully controlled by software, with further details provided later. Similar to the SVCall instruction, the SVC instruction can support software handling of SVC exceptions and enter SVC mode.
AArch32 also supports two other modes that are not shown in the figures (shown only to save space). They are the Hyp mode (for hypervisors) and Monitor mode (for TrustZone).
Register Groups
Figures 4 and 5 illustrate the register groups of ARMv7-M and AArch32, respectively. From the figures, it is evident that there are many similarities between the two register sets because both inherit common features from ARMv6 and earlier architectures.
Most instructions can access 13 general-purpose registers (r0 to r12). Under both architectures, r13 is preset as the stack pointer (SP), r14 as the link register (LR), and r15 as the program counter (PC). In the ARMv7-M architecture, access to special-purpose registers is strictly limited; in AArch32, these registers can be accessed in the same way as other general-purpose registers; however, needless to say, unauthorized modification of the PC value may have adverse consequences!
Figure 4 Figure 5
ARMv7-M has a small group of other special-purpose registers, including PRIMASK, FAULTMASK, xPSR, CONTROL, and BASEPRI, used for controlling and configuring the processor and handling exceptions.
Instruction Set
As shown in Figure 5, AArch32 also has some registers related to specific operating modes. When entering the corresponding mode, these registers will switch with the corresponding user mode. Only a very few special instructions can access them, and they cannot be accessed directly. These values are saved as modes change to assist in exception handling. It is particularly noteworthy that each exception mode has a corresponding separate stack pointer, allowing each exception situation to be resolved on a separate stack. This makes exception handlers more reliable and defensive. After an exception occurs, the link register of the relevant mode will be set to the exception return address.
Each exception mode corresponds to an additional register, the Saved Program Status Register (SPSR). The SPSR is used to timely record the value of the current Program Status Register and LR when an exception occurs, thereby automatically saving relevant data. Additionally, the Mon and Hyp modes are not shown in the AArch32 diagram. Like other modes, they also support R13 and R14 banked registers.
Under the Cortex-A architecture, there is a separate register group associated with the ARM NEON SIMD instruction set, containing 32 128-bit wide registers. Each register can be addressed as a single word, double word, or quadruple word, and the NEON instruction set also supports vector operations based on bytes or quadruple words.
Exception Model
The exception models of the two architectures have significant differences, but both support internal and external exceptions caused by system events or peripheral interrupts.
ARMv7-M supports a model closer to exceptions found in traditional microcontrollers, where all external interrupts are vectored separately through a vector table containing processor addresses.
AArch32’s exception model is closer to that of earlier ARM architectures, which had only 8 types of exceptions, each with different vectors. The vector table consists of executable instructions, typically branch instructions for specific exception handlers. It only supports two sources of external interrupts, namely FIQ and IRQ. Usually, a high-priority interrupt is connected to FIQ, while others are connected to IRQ. This means that the system either has a software scheduler or, like modern systems, has a Vectored Interrupt Controller (VIC) that can utilize a single vector address for programming.
Most Cortex-A systems are equipped with an ARM-based Generic Interrupt Controller (GIC). The GIC is the interface for many physical interrupts and ARM core interrupt inputs (FIQ and IRQ), handling priorities, masking, single interrupt enabling or disabling, and priorities. For more information, please refer to the “GIC Architecture Reference Manual”.
Virtual Memory Support
Support for a fully virtual memory environment is a major feature of ARMv8-A, enabling devices to support platform operating systems like Linux and Android. Similarly, virtual memory capability is often a key consideration for customers when selecting cores.
The virtual memory environment allows the operating system to manage memory in a more flexible way, for example, allowing separate handling of dynamically expanding stack areas, paging individual code and data areas in and out of external storage, and providing each user process with the same view of memory mapping.
Figure 6: Virtual Memory
To this end, as shown in Figure 6, virtual memory performs “translation” on every address provided by the processor. Software runs in the “virtual address space” and in a module called the Memory Management Unit (MMU), converting it into “physical address space”, creating new virtual memory mappings for each user task in the system as well as the operating system itself, and giving the operating system complete control over access permissions, etc. Each task can execute in its own virtual memory space as if it were the only task in the system. Only the operating system knows the actual physical locations of the code and data areas of that task in the external physical memory.
During task switching, one of the operating system’s jobs is to reconfigure the MMU so that the code and data can be used by the input task while allowing the output task’s memory to be temporarily accessible. This further enhances the separation between tasks, building a secure and reliable system.
We will not delve into all the details here. In short, the MMU of ARM processors uses data from “page tables” (in external memory) to drive and control the translation. The system has undergone a series of optimizations (such as Translation Lookaside Buffers (TLBs), caching to reduce power consumption while reading page tables), minimizing the power consumption of the translation process.
1.The Embedded Store is officially open! All books are 15% off, free shipping on orders over 39!
2.Is C still the programming language for embedded systems tomorrow?
3.For other professionals wanting to switch to embedded systems, these suggestions are worth a look!
4.Book Recommendations | Programmers looking to get promoted, please prepare this reading list!
5.Why don’t CTOs at Chinese IT companies write code?
6.Hackers analyze seven methods of human flesh search on Song Zhe from a technical perspective, and we are all amazed after reading!
Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are copyright issues with the work, please contact us, and we will confirm the copyright based on the copyright certificate you provide and pay for the manuscript or delete the content.