Demystifying multi-core architecture for avionics
StoryJanuary 30, 2014
Patrick Huyck
Green Hills Software, Inc.
Avionics system architects making design decisions today are often frustrated by an expensive problem - having to perform a substantial redesign because an existing system lacked the flexibility required to support an update. Such inflexible barriers in the design process may be overcome by using new, highly-integrated multi-core processors that can provide long-term system flexibility. Multi-core processors are now being utilized to not only address the dwindling availability of new single-core processors, but also to take advantage of increased throughput while maintaining equivalent power consumption.
Discussions of the various multi-core operating system (OS) architectures often come to a common faulty conclusion: that they all provide similar capabilities, reducing the importance of architecture in design selection. A more detailed examination highlights the significant differences among some of the key multi-core OS architectures. Careful consideration of these differences can help prevent today’s multi-core OS architecture choices from becoming a multi-million dollar roadblock to future system updates.
Background
In a single-core system, multiple applications may share a computing resource by robustly partitioning the memory, resources, and processor time between the hosted applications. A common approach to time partitioning is to divide a fixed time interval into a sequence of fixed sub-intervals referred to as “partition time windows.” Each application is allocated one or more partition time windows, with the length and number of windows being factors of the application’s worst-case execution time (WCET) and required repetition rate. The OS ensures that each application is provided access to the processor during its allocated time.
A concern in any system is how to account for application growth, especially for systems that tend to expand in scope (e.g., flight management or onboard maintenance). Approaches for single-core systems include using unallocated time, shifting and/or shortening the time allocations of other applications, and moving applications to more capable computing platform. A port to a multi-core platform should continue to support these methods as well as permit techniques that were not feasible under single-core architecture.
Multi-core – concurrent scheduling
At the most basic level, the cores of a multi-core processor can be allocated to concurrently execute independent applications or to concurrently execute multiple threads within an application. Any contention that can occur through the resources shared by two or more cores (like main memory or system interconnects) must be taken into account. Unfortunately, today’s COTS multi-core processors currently lack hardware controls that permit administrating access to all the shared resources.
SMP multi-core architecture
Symmetric multi-processing (SMP) is a multi-core-based architecture in which a single OS controls all resources, including the allocation of cores to applications. “Symmetric” refers to all cores being considered as equal, permitting an OS to utilize any core to execute application threads. Even though an application may have been designed to be multi-threaded, this does not mean that it will execute the same when multiple cores are available. For robust partitioning, the OS should include support to configure which cores are allocated to an application and which core a thread will have an affinity to execute on.
With SMP support, a conservative approach may be taken when porting a set of applications from a single-core to a multi-core processor, including preserving the existing partition schedule. By ensuring that all threads have an affinity for the same core, the threads will execute as if on a single-core processor. As illustrated in Figure 1, application growth can now be achieved by parallelizing specific applications as needed to gain throughput, choosing which core each thread will run on. New applications can be specifically designed to utilize multiple cores concurrently, potentially with shorter time allocations. In addition, the continuous built-in-test (BIT) application would be extended to confirm the correctness of all cores and the shared resources.
Figure 1: Application growth considerations with SMP
(Click graphic to zoom by 1.9x)
|
|
AMP multi-core architecture
When porting an application, even a multi-threaded one, there may be practical limits to how many cores can be effectively used in parallel. Asymmetric multi-processing (AMP) is a multi-core-based architecture in which each core operates essentially as a separate computing resource, permitting concurrent schedules. Such an architecture is referred to as “asymmetric” as it permits (but does not require) implementations to use different types of processor cores and/or operating systems. Since multiple dissimilar operating systems cannot all run at the highest processor privilege level, there is likely a monitor function (sometimes referred to as a “hypervisor”) that provides this support across all cores. A strength of an AMP architecture is that different applications can run concurrently on the available cores. With some level of virtualization support (e.g., as part of the monitor function), this includes applications of dissimilar operating environments (think Linux or proprietary OS).
When porting applications from a single-core processor to an AMP architecture, a similar approach as described with the SMP architecture can be taken. However, the number of concurrently executing cores that can be realistically analyzed (for example, WCET) will be bounded until contention issues are resolved. As Figure 2 illustrates, server applications such as file systems are potentially good candidates for parallelism even under contention because of application codependency. Assuming contention for shared resources can be accounted for, each core in an AMP architecture could be configured to run independent application schedules or an entirely dissimilar environment such as a guest OS. A difficulty associated with running independent schedules is that analysis of resource utilization across the schedules will still be required. If the independent schedules cannot be coordinated in time, analyzing and accounting for resource availability and coordinated hardware BIT may be impossible. If one of the cores is running a virtualized OS (Linux, for example), a lack of assurance activities on the OS combined with an inability to coordinate hardware BIT can result in significant limitations in what can be run in parallel.
When an application update requires more bandwidth than its current core can support, the application can be ported to one of the other cores. Such porting will be complicated by several factors inherent to an AMP architecture. For example, the bandwidth must all come from one core, porting may break assumptions about the order applications execute, and transport delay may be impacted as a result of differences in the on/off core communication mechanisms. These complications contradict the popular thought that an AMP architecture is easier to certify as a result of its less complicated scheduling.
Figure 2: Application growth considerations with AMP
(Click graphic to zoom by 1.9x)
|
|
tuMP multi-core architecture from Green Hills Software
Other architectures include heterogeneous multi-processing (HMP – individual cores are statically divided into independent AMP or SMP subsystems, each with their own OS) and unified multi-processing (UMP – individual cores are statically divided into subsystems on an application basis but with a single “unified” OS). A common limit to AMP, SMP, and other similar architectures is that core usage is fixed during execution and does not change once allocated. This limitation is resolved by a multi-core architecture developed by Green Hills Software, currently undergoing DO-178B Level A certification efforts as part of the INTEGRITY-178 product line. This architecture, referred to as “time-variant unified multi-processing” (tuMP), significantly improves the flexibility in how the processor cores can be utilized. (tuMP is a registered trademark of Green Hills Software.) The feasibility of the tuMP architecture is demonstrated by its implementation as an update to the INTEGRITY-178 single-core product, preserving 12 years of safety and security assurance pedigree and product service history.
Sidebar 1
(Click graphic to zoom)
|
|
The benefit of the tuMP architecture is that it retains all AMP and SMP scheduling capabilities while resolving their significant limitations. The tuMP architecture provides flexibility through a new schedulable entity referred to as an “affinity group,” which is an association of applications, cores, and scheduling characteristics. Only the applications assigned to the affinity group can use the cores assigned to that same affinity group during their scheduled time window. By creating multiple subsystem schedules, independent affinity groups (i.e., non-overlapping use of applications and cores) can be scheduled simultaneously and without restriction that the time windows must be aligned across all cores. In addition, applications can run on different sets of cores by creating unique affinity groups for each combination. With tuMP there is complete flexibility to utilize the available cores for concurrent application and concurrent thread execution and change these relationships when required (that is, time-variant).
The tuMP architecture is referred to as “unified” in that a common OS controls the scheduling of all cores and the overall communications between applications. This characteristic resolves the AMP application porting concern when moving between cores; the same mechanisms can be utilized to communicate between applications on the same or different cores.
Sidebar 2
(Click graphic to zoom by 1.9x)
|
|
The port of a partition schedule from a single-core processor can be accomplished by creating an identical subsystem schedule with an affinity group for each application bound to the same core. If some applications need additional throughput, additional cores can be allocated to their affinity groups or they can be allocated unused time from any core.
In the AMP system (seen in Figure 2), a degree of parallelism was achieved by running a file system application in parallel with the codependent applications. If the application requires more throughput than the file system, the file system underutilizes its core. As shown in Figure 3, tuMP resolves the underutilization by creating an affinity group that combines the file system with the applications dependent upon it – such as flight management – and assigning multiple cores to it. In this scenario, the file system can have an affinity for a specific core that the application also utilizes when not in use for file system operations.
Integration of a guest OS on a core is a design challenge in an AMP system when other applications (BIT, for example) require simultaneous control over all cores or when an existing application is not tolerant to other applications running in parallel. In tuMP, the guest-OS affinity group can be assigned to multiple partition time windows that break up the usage of the core to support these other requirements. Now the BIT application’s affinity group can be assigned all the cores so that it can perform the necessary hardware tests.
In the AMP system, an application whose core had insufficient throughput to support an update could be supported if another core had sufficient unallocated time to support the updated application. With tuMP, the application (e.g., Onboard Maintenance) can be spread across time windows associated with multiple cores, not just one core.
Figure 3: Application growth considerations with tuMP
(Click graphic to zoom by 1.9x)
|
|
Integrating multi-core processors
Avionics-certification efforts require thorough understanding of the complexities and consequences of the use of those technologies. System designers should keep in mind the importance of carefully choosing their architecture as they integrate multi-core processors into their avionics platform designs. System designers should consider selecting a multi-core architecture based on its system flexibilities to optimize core usage and manage certification risks. For their part, users should understand that their supplier’s choices of today will impact the economic feasibility of future software expansions.
Sidebar 3
(Click graphic to zoom by 1.9x)
|
|
Patrick Huyck, Systems Certification Manager at Green Hills Software, has more than 27 years’ experience in the development of real-time embedded products for commercial avionics, military, and security products. Patrick supports the certification of DO-178B Level A and Common Criteria EAL 6+ real-time operating systems and middleware products. He is an active member of the ARINC 653 standard committee, the FACE consortium, and is an FAA software Designated Engineering Representative (DER). His career also includes 15 years with Rockwell Collins. Patrick has a B.S. in electrical engineering and an M.S. in computer engineering.
Green Hills Software [email protected] www.ghs.com
