Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Embedded and Microcontrollers blog ARMv7-A - Power to the People
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • Armv7
  • Armv7-A
  • Cortex-A12
  • Cortex-A9
  • Cortex-A15
  • Cortex-A5
  • Cortex-A
  • Cortex-A7
  • Cortex-A8
  • cortex
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

ARMv7-A - Power to the People

Chris Shore
Chris Shore
October 17, 2013
Recently, I wrote an article called “Navigating the Cortex Maze” (Navigating the Cortex Maze) That was intended as an easy way-in to the ARM processor range, covering Cortex-A (architecture ARMv7-A), Cortex-R (ARMv7-R) and Cortex-M (ARMv7-M). A subsequent document (ARMv6-M vs ARMv7-M - Unpacking the Microcontrollers) looked in more detail at the microcontroller architectures, ARMv6-M and ARMv7-M.

In this article, I want to look deeper into ARMv7-A, the Applications profile.

Because of the products in which it is used, ARMv7-A has perhaps the highest public profile of the ARMv7-A architectures. Since it is targeted at high-performance application processors which need to run a platform OS, like Linux, Android or Windows Phone, it gets a lot of headline exposure in consumer electronics. Your new smart electricity meter is likely to be powered by a Cortex-M microcontroller but it’s very unlikely that you’ll find that information in the user manual; your new mobile phone, on the other hand, is almost certain to be powered by a Cortex-A applications processor and, if you check out the specifications, you’ll likely find that highlighted as one of its features. You may find other information as well, such as whether it is dual-core or quad-core, what clock speed it runs at and so on.

Origins of ARMv7-A

As explained in the earlier document on microcontrollers, ARMv7-M was the first profile of the ARMv7 architecture to result in physical products, with the release of the Cortex-M3 in 2004. ARMv7-A was launched just a year later with the release of the Cortex-A8 processor in 2005.

While the ARMv7-M profile took a radically different direction to earlier architecture evolutions, with its cut-down instruction set, fixed memory map and hardware exception handling, the ARMv7-A profile continued the “upwards-and-to-the-right” evolution in capability and performance.

The high-performance devices which have since been released by ARM’s partners based on Cortex-A processors have enabled the huge growth in the smartphone and tablet industries of the last few years. Their ability to enable a huge increase in processing power while remaining extremely power-efficient is what has enabled us to carry in our pockets more processing power than a desktop system of only a few years ago.

ARMv7-A overview

The ARMv7-A architecture is targeted at applications which require a rich OS platform, such as Linux or Android. As such, the architecture includes support for full virtual memory, security and multimedia processing. Although best known for its extensive use in the smartphone/superphone and tablet markets, It is also extensively used in high-performance network switches, gaming platforms, digital TV and many other applications.

Base architecture

Building on all the features of ARMv6 and earlier, here are some highlights of what is provided in ARMv7-A.

  • Full ARM and Thumb instruction sets
    Support for both ARM and Thumb (including the Thumb-2 technology) allows developers to balance performance with code density.
  • Multiple operating modes
    ARMv7-A provides a basic set of 7 operating modes. All except one (User mode) are privileged. User mode, being unprivileged, is used for execution of user tasks when in an OS environment. The remaining modes are mostly associated with different types of exception. Banked registers in the exception modes make for efficient exception entry/exit sequences.
  • Virtual memory
    ARMv7-A includes full virtual memory support via the Virtual Memory System Architecture (VMSAv7). A Memory Management Unit (MMU) provides virtual-to-physical address translation, allowing the implementation of full demand-paged virtual memory environments as required by operating systems like Linux. The MMU makes use of page tables which are stored in external memory and is capable of automatically loading translation information on demand, minimizing the software overhead.
  • Advanced SIMD (NEON) technology
    The NEON general-purpose SIMD engine provides an additional register bank (32 x 64-bit registers) and a rich SIMD instruction set which provides flexible and powerful acceleration for many multimedia applications.
  • Full Debug and Trace support
    The ARMv7-A debug architecture provides for extremely flexible debug and trace support. Both invasive and non-invasive debug techniques are supported as well as support for sample-based profiling tools. Optionally, a set of hardware performance counters is available to support benchmarking and performance analysis.

Optional extensions

Although the features below re an optional part of the architecture (meaning that their inclusion is not an absolute requirement for a conformant processor), many of them (TrustZone, for example) are supported by all of the ARMv7-A cores available from ARM. For a complete list, see the table at the bottom of this article.

  • Multiprocessing
    ARMv7-A supports multicore extensions which allow designers to place up to four cores in a single, coherent cluster. Dedicated hardware, including a Snoop Control Unit and Interrupt Distributor, allow all the processors in a cluster to operate as a single coherent processing unit, with automatic, hardware-supported coherency in the L1 memory system.
  • 40-bit physical addressing
    The Large Physical Address Extension (LPAE) extends the virtual memory system to provide for physical addresses up to 40 bits in size. This allows up to 1TB of addressable physical memory, supporting the needs of future software applications.
  • Virtualization
    The Virtualization Extension introduces full hardware support for hypervisors and multiple guest operating systems.
  • Floating point
    The NEON SIMD engine supports single-precision floating point. The optional Floating Point Unit (FPU) adds full double-precision support as well. This is fully supported by development tools and libraries.
  • Performance Monitors
    The ARMv7 debug architecture includes optional support for a hardware Performance Monitoring Unit (PMU). This implements a number of counter registers which can be configured to collect non-intrusive run-time statistics covering things like branch predictor accuracy, cache utilization, instruction count etc. These can be integrated with high-level debug tool support to provide a range of sophisticated trace and coverage tools.
  • TrustZone security
    To support secure applications such as DRM and e-payment, TrustZone provides two virtual machines, running on a single processor which are separated into a “normal” world and a “secure” world. In this scheme, key elements of system configuration are banked between the two worlds. The separation also extends through the cache and MMU into the external memory system. Extra signals on the AXI bus allow chip designers to implement areas of secure memory and secure peripherals which can only be accessed by software running in the secure world. The transition between the two worlds is very tightly controlled via a single exception vector.

 

Big.LITTLE processing

ARM big.LITTLE processing is an energy-saving technology which combined multiple processors with different performance characteristics in a single multiprocessing system. In a typical system, one or more “BIG” cores, such as the Cortex-A15, are paired with one or more “little” cores, such as the Cortex-A7, to provide a system which can tackle both high intensity and low intensity tasks in the most energy-efficient manner. The operating system automatically selects the best core for each running task, seamlessly migrating tasks from one core to another as needs change. Unused cores can be completely shutdown, maximizing the energy saving. Because all the cores in the system support the same architecture and provide the same behaviour to software, this migration is completely transparent to the programmer and can be accomplished extremely quickly and efficiently.

ARMv7-A big.LITTLE systems typically use a combination of Cortex-A15 and Cortex-A7. Future ARMv8 systems will use Cortex-A57 and Cortex-A53 in the same way.

The ARMv7-A processor range

The following cores in the Cortex-A series support the ARMv7-A architecture. Together, they provide a scalable range of power-efficient performance points for their target applications.

 

Cortex-A5

Cortex-A5

MPCore

Cortex-A7

Cortex-A8

Cortex-A9

Cortex-A9 MPCore

Cortex-A12

Cortex-A15

Architecture

ARMv7-A

ARMv7-A

ARMv7-A

ARMv7-A

ARMv7-A

ARMv7-A

ARMv7-A

ARMv7-A

MP

 

Y

Y

   

Y

Y

Y

LPAE

   

Y

     

Y

Y

Virtualization

   

Y

     

Y

Y

TrustZone

Y

Y

Y

Y

Y

Y

Y

Y

NEON

O

O

Y

Y

O

O

Y

Y

FPU

O

O

Y

Y

O

O

Y

Y

PMU

Y

Y

Y

Y

Y

Y

Y

Y

For more detail on the Cortex-A series, please look at the product pages on ARM's website.

 
Anonymous
Parents
  • tony
    tony over 10 years ago

    Thanks Chris,
                          For the clarification

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Comment
  • tony
    tony over 10 years ago

    Thanks Chris,
                          For the clarification

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Children
No Data
Embedded and Microcontrollers blog
  • Formally verifying a floating-point division routine with Gappa – part 2

    Simon Tatham
    Simon Tatham
    A method of testing whether a numerical error analysis using Gappa really matches the code it is intended to describe.
    • September 4, 2025
  • Formally verifying a floating-point division routine with Gappa – part 1

    Simon Tatham
    Simon Tatham
    Learn the basics of using Gappa for numerical error analysis, using floating-point division in Arm machine code as a case study.
    • September 4, 2025
  • Adapting Kubernetes for high-performance IoT Edge deployments

    Alexandre Peixoto Ferreira
    Alexandre Peixoto Ferreira
    In this blog post, we address heterogeneity in IoT edge deployments using Kubernetes.
    • August 21, 2024