SMP vs. AMP: Multi-Core Architectures Explained

1. Defining the Architectures: SMP vs. AMP

At the highest level, multi-core systems are organized into two main software and hardware philosophies: Symmetric Multi-Processing (SMP) and Asymmetric Multi-Processing (AMP).

Let's break down these definitions. The following reading provides an excellent, concise comparison.

As the reading highlights:

• Symmetric Multi-Processing (SMP):

  • Hardware: Consists of two or more identical (homogeneous) processor cores.
  • Memory: All cores share the same main memory and peripherals through a common bus.
  • Operating System: A single instance of an OS runs across all cores. The OS is aware of all cores and can schedule any task on any available core.
  • Primary Goal: Performance and load balancing. It's the standard model for desktops, servers, and smartphones.

• Asymmetric Multi-Processing (AMP):

  • Hardware: Often consists of different (heterogeneous) cores, such as a high-performance application processor (e.g., ARM Cortex-A) paired with a real-time microcontroller (e.g., ARM Cortex-M).
  • Memory: Memory and peripherals may be shared, but are often partitioned or dedicated to specific cores.
  • Operating System: Each core or cluster of cores runs its own independent OS (e.g., Linux on the Cortex-A, an RTOS or bare-metal code on the Cortex-M). There is no single "master" OS.
  • Primary Goal: Specialization, isolation, and determinism. Ideal for mixed-criticality systems.

This distinction between software models is further clarified in the paper "Operating System Concepts for Embedded Multicores". It emphasizes that SMP and AMP are software concepts, which can be applied to different hardware configurations. You can skim Section II of LINK for this reinforcement if you wish.

2. Implications: A Head-to-Head Comparison

The choice between SMP and AMP has profound implications for how the system is designed and programmed. Let's analyze these across the key dimensions required by the learning outcome.

Let's dive deeper into these implications with practical examples.

Scheduling: Dynamic Flexibility vs. Static Predictability

In an SMP system, the OS scheduler maintains a global list of ready-to-run tasks and dispatches them to any available core. This is great for maximizing throughput. However, what if you need more control?

The following video uses the dual-core ESP32, which runs an SMP-capable port of FreeRTOS, to demonstrate this trade-off.

As the video shows, the key scheduling trade-off in SMP is:

• Dynamic Scheduling: Maximizes CPU utilization but can lead to non-deterministic behavior and performance loss from cache misses if tasks migrate frequently.
• Task Pinning (CPU Affinity): Sacrifices automatic load balancing but provides higher determinism and better cache performance, moving it conceptually closer to an AMP model.

In a pure AMP system, this isn't a choice—tasks are inherently "pinned" to the core/OS they were designed for. An automotive ECU might run its hard real-time motor control loop on a dedicated Cortex-R core, completely isolated from the Linux system running the dashboard display on a Cortex-A core.

Communication: Shared Memory vs. Message Passing

In SMP, cores communicate implicitly by reading and writing to shared memory. The main software challenge is synchronization to prevent race conditions, using primitives like mutexes and spinlocks.

In AMP, since cores run separate OS instances and may not even share memory in a fully coherent way, communication must be explicit. This is a major system design challenge. The industry-standard solution is OpenAMP.

The OpenAMP framework provides two key components:

• RPMsg (Remote Processor Messaging): A standardized protocol for sending messages between cores through shared memory buffers (vrings).
• RemoteProc: A framework that allows one processor (typically running Linux) to control the lifecycle (load firmware, start, stop) of a remote processor.

Cache Coherency: Hardware Problem vs. Software Problem

This is one of the most critical differentiators and a frequent interview topic.

• In SMP, all cores must be part of a coherency domain. Hardware protocols like MESI ensure that if one core writes to a memory location, all other cores see that update. This is complex in hardware but makes software simpler.
• In AMP, cores are often in different power domains and clock domains and are not part of a single hardware coherency domain. If you're not careful, one core can have a completely different view of "shared" memory than another.

This creates a classic data consistency problem. Imagine a Cortex-A core (with cache) writes data to a shared buffer for a Cortex-M core to process. The write may only exist in the Cortex-A's L1 cache. The Cortex-M, reading from main memory, will see stale data.

How do you solve this in AMP?
This is a software problem. The following video provides a perfect demonstration using an STM32H7 (Cortex-M7 + Cortex-M4).

As the video explains, the two primary solutions are:

1. Mark Shared Memory as Non-Cacheable: Use the MPU (on microcontrollers) or MMU (on application processors) to define the shared memory region's attributes as non-cacheable. This is simple and safe but forces all accesses to go to slower main memory, impacting performance.
2. Explicit Cache Maintenance: The software must manually manage the cache.
   • The writing core must perform a cache clean/flush after writing to the buffer to force the data out to main memory.
   • The reading core must perform a cache invalidate before reading from the buffer to discard any stale data in its own cache and force a fresh read from main memory.
     This is more performant but complex and error-prone.

3. Conclusion: Choosing the Right Architecture

Neither architecture is universally "better." The choice is a fundamental system design trade-off based on the application's needs.

• Choose SMP when your primary goal is maximizing raw performance for a single, complex application, and you can leverage standard parallel programming models (e.g., a multi-threaded web server or a high-end mobile gaming application).
• Choose AMP when your system has mixed-criticality requirements, such as combining hard real-time control with a rich user interface. The isolation provided by AMP is essential for safety, security, and determinism.

Today, most complex SoCs in your target companies are hybrid systems that use both. A cluster of four Cortex-A78 cores might run in SMP mode to handle an Android OS, while that entire cluster communicates in an AMP fashion with a separate Cortex-M core for sensor fusion, a security processor, and a DSP for modem processing.

Key Takeaways:

• SMP offers simplicity and automatic load balancing at the cost of determinism, relying on complex hardware cache coherency.
• AMP provides isolation, specialization, and determinism, but requires developers to explicitly manage inter-core communication and software cache coherency.
• The OpenAMP framework (with RPMsg and RemoteProc) is the industry standard for managing communication and lifecycle in AMP systems.
• Solving cache coherency in AMP systems is a critical software task, typically handled by making shared memory non-cacheable or performing manual cache flush/invalidate operations.
• Modern SoCs are often hybrid architectures, combining SMP clusters with other specialized cores in an overall AMP design.

Preview of the Next Lesson:
We've seen how AMP provides isolation by running different OS instances on different cores. But what if you need to run two completely isolated software environments on a single core? In our next lesson, we will explore ARM TrustZone architecture, a hardware security extension that partitions a single processor into a "Normal World" and a "Secure World," forming the foundation for system security and trusted execution environments.