As Software Defined Vehicles (SDVs) become increasingly dependent on multicore processors, architects must decide how best to use the available computing resources. Modern automotive SoCs often combine high-performance application processors, such as Arm Cortex-A53 clusters, with dedicated real-time and safety cores, such as the Cortex-R52. The architectural choice between symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) has a direct impact on system performance, timing determinism and certification effort.
How does Safety Before Silicon influence SMP vs AMP decisions?
In SDVs, key architectural decisions are increasingly made before software development begins. This "Safety Before Silicon" approach focuses on defining safety goals, software partitioning, and timing requirements early in the programme lifecycle.
One of the most important decisions is whether workloads should share processing resources through SMP or be partitioned using AMP. The answer can influence system determinism, freedom-from-interference analysis, and the effort required to build a safety case.
Throughput vs determinism: What are the trade-offs between SMP and AMP?
SMP is attractive because it simplifies software development. Applications do not need to be assigned to specific cores, and the operating system can dynamically balance workloads across all processors. This approach maximises utilization and can deliver excellent throughput with relatively little software redesign.
However, SMP systems share hardware resources, including caches, memory subsystems, peripherals and interconnects. Even when processor affinity is used, workloads can still interfere with one another through contention for these resources. As a result, worst-case execution times and response times can be more difficult to analyse and guarantee.
For applications such as networking, data processing, and user interfaces, this is often an acceptable trade-off because overall throughput is the primary objective.
AMP takes a different approach. By assigning critical software to dedicated cores, interference can be reduced and timing behaviour becomes more predictable. This allows tighter response-time guarantees and can simplify system analysis, making AMP particularly attractive for control functions and other hard real-time workloads. However, these benefits come at the cost of additional architectural effort, as communication between software partitions often requires explicit inter-core communication mechanisms.
-
The architectural choice between symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) has a direct impact on system performance, timing determinism and certification effort.
An automotive example
A Cortex-A53 cluster running SMP may be ideal for infotainment, connectivity, AI and domain applications where throughput is important.
By contrast, a Cortex-R52 safety island is typically used for functions that require deterministic behaviour and strong freedom-from-interference characteristics.
Although the A53 cluster may process a greater overall workload, the R52 environment can often provide more tightly bounded response times.
For safety-critical software, guaranteeing when work completes is usually more important than maximising processor utilization.
Certification considerations
Architecture also affects certification. For automotive systems developed to ISO 26262, demonstrating freedom from interference and showing that timing requirements are consistently met can form an important part of the safety case.
When software is statically partitioned onto dedicated cores, resource ownership and fault-containment boundaries are generally easier to define. While SMP can certainly be used in safety-certified systems, additional analysis is often required to demonstrate that critical functions remain unaffected by competing workloads.
Conclusion
Neither SMP nor AMP is universally better. SMP is often the best choice when throughput and resource utilization are the primary goals. AMP is frequently preferred when deterministic response times, freedom from interference, and certification objectives take priority.
As SDV architectures become increasingly complex, making these decisions early can reduce project risk and simplify certification activities. Selecting a Real Time Operating System that supports the target architecture is equally important. SAFERTOS® supports a range of automotive and safety-focused processor architectures, helping developers implement these architectural choices while maintaining predictable real-time behaviour.
Putting Safety Before Silicon into practice
Learn how safety islands support safety before silicon design principles, helping developers build deterministic, mixed-criticality systems while simplifying functional safety certification. Download the white paper.
