Hello! Welcome to the first lesson in our new module, "Multi-Core Programming Concepts."
In our previous module, we concluded our deep dive into single-core ARM architectures by dissecting the AArch64 Procedure Call Standard. You now have a firm grasp on how functions communicate at the machine level, a crucial skill for low-level development and debugging.
Now, we shift our focus from a single core to the complex and powerful world of multi-core systems. The job description you are preparing for explicitly mentions "Multi-Processor concepts," and modern automotive SoCs, from ADAS controllers to gateways, almost universally employ multiple processor cores. Understanding how these cores are organized and managed is fundamental.
Today's learning outcome is to contrast Symmetric Multiprocessing (SMP) and Asymmetric Multiprocessing (AMP) architectures. We will explore these two foundational models for designing multi-core systems, laying the groundwork for the synchronization and communication techniques we'll cover later in this module.
An Introduction to Multiprocessing Models
At its core, multiprocessing is about using more than one CPU or core to perform work. The key difference between the main approaches lies in how these cores are managed and how they interact. The two dominant models are Asymmetric Multiprocessing (AMP) and Symmetric Multiprocessing (SMP).
To get a quick and clear overview of these two concepts, please watch this short introductory video.
Introduction to RTOS Part 12 - Multicore Systems | Digi-Key Electronics
The video 'Introduction to RTOS Part 12 - Multicore Systems' from DigiKey provides a concise and effective summary of the fundamental differences between AMP and SMP.
Watch the segment from 00:22 to 01:44. Focus on how it describes the OS management and task distribution in both AMP and SMP.
Comparing AMP and SMP
As you saw in the video, the distinction boils down to how tightly coupled the cores are and who is in charge. Let's formalize this with a more detailed comparison. The NXP brochure "Running AMP, SMP or BMP Mode for Multicore Embedded Systems" and the Promwad article "Combining RTOS and Linux" provide excellent definitions that we can synthesize.
Here is a summary of the key differences:
| Feature | Symmetric Multiprocessing (SMP) | Asymmetric Multiprocessing (AMP) |
|---|---|---|
| Operating System | A single OS instance runs across all cores. | Each core runs its own, independent OS instance (or is bare-metal). |
| Core Architecture | Cores must be identical (homogeneous). | Cores can be different (heterogeneous), e.g., Cortex-A + Cortex-M. |
| Task Scheduling | The OS scheduler dynamically dispatches tasks to any available core. | Tasks are statically assigned to a specific core. |
| Primary Goal | Performance scaling and load balancing. | Functional separation, determinism, and safety/security isolation. |
| Memory Model | Tightly coupled, with shared memory managed by the OS. | Loosely coupled. Memory is typically private, with explicit shared regions for communication. |
| Inter-Core Communication | Managed by the OS using standard primitives (mutexes, semaphores). | Requires explicit mechanisms like mailboxes, shared memory IPC, or Inter-Processor Interrupts (IPIs). |
| Legacy Code | Can be difficult to port due to concurrency issues. | Easier to port, as a single-threaded application can run on one core without modification. |
This visual diagram provides an excellent illustration of these architectural differences.
Deep Dive: Symmetric Multiprocessing (SMP)
In an SMP system, the goal is to maximize computational throughput. The OS sees a pool of identical processing units and its scheduler aims to keep them all busy by distributing ready tasks among them.
This architecture is exemplified by ARM's MPcore technology.
Advantages of SMP:
- Automatic Load Balancing: The OS scheduler automatically moves tasks to less-busy cores, maximizing CPU utilization without developer intervention.
- Simplified Programming Model: From a developer's perspective, inter-task communication and synchronization use the same OS primitives (like mutexes and queues) as in a single-core system. The OS handles the underlying complexity.
- High Performance: Ideal for computationally intensive applications where tasks can be parallelized.
Challenges of SMP:
- Concurrency Complexity: With tasks running truly simultaneously, the potential for subtle race conditions and deadlocks increases significantly. Assumptions from single-core programming are no longer valid. For example, a low-priority task can run at the exact same time as a high-priority task, each on a different core.
- OS Support: Requires an SMP-aware OS, such as SMP Linux or the SMP version of FreeRTOS.
- Determinism: The dynamic nature of the scheduler can make it harder to guarantee real-time deadlines compared to AMP.
For a deeper look into SMP within the RTOS world—highly relevant for the roles you're targeting—the following resource explains the concept in the context of FreeRTOS.
FreeRTOS SMP on the RP2040 Tutorial - Symmetric Multiprocessing with FreeRTOS!
The article 'FreeRTOS SMP on the RP2040 Tutorial' provides a clear explanation of how SMP works in an RTOS environment and the key differences from a single-core system.
Please review the information presented in the video from 02:45 to 05:42. Focus on the explanation of how a single FreeRTOS instance schedules tasks across multiple cores and the crucial point that a low-priority task can run concurrently with a high-priority task.
Deep Dive: Asymmetric Multiprocessing (AMP)
In an AMP system, the philosophy is "separation of concerns." Each core is treated as a specialist, often running a completely different software stack tailored to its task. Your experience with complex automotive systems likely involves AMP, even if it wasn't named as such.
A common pattern in automotive ECUs is to pair a high-performance core (e.g., ARM Cortex-A) running a rich OS like Linux or QNX for infotainment and connectivity, with a real-time core (e.g., ARM Cortex-R or Cortex-M) running an AUTOSAR stack for vehicle control, safety functions, and I/O. This is a classic AMP architecture.
To understand the benefits and common applications of this model, please read the following sections.
Combining RTOS and Linux in Heterogeneous Multi-Core ...
The article 'Combining RTOS and Linux in Heterogeneous Multi-Core Systems' from Promwad explores the practical advantages and use cases of AMP, particularly in embedded systems.
Read the sections 'What Is AMP and How Does It Differ from SMP?', 'Benefits of RTOS + Linux AMP Systems', and 'Common Use Cases for AMP Architectures'. Pay special attention to the automotive ECU example, as it directly relates to your field.
Advantages of AMP:
- Fault Isolation: A crash or bug on one core (e.g., in the Linux infotainment system) does not affect the operation of the other core (e.g., the RTOS handling real-time control). This is critical for functional safety (ISO 26262).
- Real-Time Determinism: Safety-critical, hard real-time tasks can run on a dedicated core with a simple RTOS, free from the scheduling latencies and interrupts of a complex OS.
- Optimized Power and Resources: You can use the right core for the right job—a small, low-power core for simple monitoring tasks and a powerful core for heavy processing, which can be shut down when not needed.
- Simplified Validation: Legacy or pre-certified code can be isolated on one core, simplifying system integration and validation efforts.
Challenges of AMP:
- Complex Inter-Core Communication (IPC): Since the cores run separate OS instances, they cannot use standard OS primitives to communicate. Developers must explicitly implement IPC mechanisms using shared memory, mailboxes, or hardware semaphores. This is a significant design effort.
- Tooling and Debugging: Debugging interactions between two different systems running simultaneously can be complex and may require sophisticated tools (like the Lauterbach JTAG debuggers you're familiar with) capable of synchronizing and observing multiple cores.
Test your understanding!
An automotive system needs to run a safety-critical (ASIL-D) real-time control loop for braking, which must have guaranteed low latency. On the same SoC, it also needs to run a less-critical ADAS algorithm that involves heavy data processing but has looser timing constraints. Which multiprocessing architecture (SMP or AMP) would you choose and why?
Show answer
The ideal choice is Asymmetric Multiprocessing (AMP).
- Reasoning: You can dedicate one core (likely a real-time core like a Cortex-R) to the ASIL-D braking function, running a certified RTOS like SafeRTOS or an AUTOSAR OS. This ensures fault isolation; a failure in the ADAS algorithm cannot crash the critical braking function. It also guarantees real-time determinism for the brake loop, as it has exclusive access to its core's resources.
- The ADAS algorithm can run on a separate, more powerful core (like a Cortex-A), possibly with a different OS (like Linux or QNX) that provides better support for complex algorithms and data processing.
- Using SMP would mean both the critical and non-critical tasks are managed by the same OS scheduler, making it much harder to guarantee the determinism and isolation required for an ASIL-D function.
Interview Corner
This is a fundamental topic for multi-core roles. Be prepared to clearly articulate the trade-offs.
Q1: What are the key differences between Symmetric and Asymmetric Multiprocessing?
A: The primary difference lies in the OS and core management. SMP uses a single OS instance across multiple identical cores to achieve performance scaling and load balancing. AMP uses a separate OS instance on each core (which can be different types) to achieve functional separation and isolation. This impacts everything from memory management and task scheduling to how you implement inter-core communication.
Q2: You're designing a system that combines a certified, safety-critical AUTOSAR stack with a graphics-intensive digital instrument cluster. Why would an AMP architecture be a better choice than SMP?
A: AMP is superior for this use case due to isolation. The AUTOSAR stack can run on a dedicated real-time core, ensuring its behavior is deterministic and isolated from the digital cluster. A failure or performance issue in the graphics-heavy cluster (running on a separate, high-performance core) will not impact the safety-critical functions. This separation is essential for meeting functional safety standards like ISO 26262. With SMP, both workloads would be managed by one OS, introducing the risk of interference.
Q3: You are porting a legacy single-core application to an SMP system. What fundamental assumption about task execution is no longer valid, and what new challenge does this introduce?
A: The invalid assumption is that a lower-priority task will never run while a higher-priority task is ready to run. In an SMP system, if two cores are available, the scheduler can run the highest-priority task on one core and the second-highest priority task (even if it's much lower) on the other core simultaneously. The new challenge is a higher risk of subtle concurrency bugs (race conditions, etc.) because multiple tasks are now executing in a truly parallel fashion, not just time-sliced. This requires a more rigorous approach to protecting shared resources.
Conclusion
Today you've established a strong foundational understanding of the two primary multi-core architectures. This is the starting point for all advanced multi-core programming topics.
Key Takeaways:
- SMP (Symmetric Multiprocessing): Think performance and load balancing. It uses a single OS across identical cores. It simplifies programming but requires careful management of concurrency.
- AMP (Asymmetric Multiprocessing): Think isolation and determinism. It uses separate OS instances on potentially different cores. It's ideal for mixed-criticality systems but requires explicit IPC design.
- The choice between SMP and AMP is a fundamental architectural decision driven by the system's requirements for performance, safety, security, and real-time behavior.
Next Lesson Preview:
Now that we've seen the high-level architectures, our next step is to look at the low-level mechanisms needed to make them work. In both SMP and AMP systems, you need ways to protect shared data from being corrupted by simultaneous access. Our next lesson will address this head-on as we learn to implement a spinlock using ARM exclusive access instructions (LDREX/STREX) for multi-core synchronization.