Multicore OS

Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in Multicore OS

Multi-Core. Hardware assumptions

CPU Core features
• Two or more cores in the same fever segment.
• The hardware provides a method for the software to identify a core.
• It also supports atomic read and atomic write operations for a specific word length determined by the hardware.
• The hardware supports some atomic Test-And-Set functionality or similar functionalities that can be used to built a critical section shared between cores. Additional atomic operations may exist.
• All cores may share the same instruction set, or at least have access to a common basic instruction set. Specific core add-ons may be present, but they are not considered.
• The cores have the same data representation. For instance, the identical size of integer, identical byte and bit order, and so on.
• If kernel-specific caches exist, AUTOSAR requires RAM cache coherency in HW or SW. In software, this means that the SW can program the cache driver to invalidate cache lines or exclude certain memory areas from the cache.
• If an exception occurs (such as an illegal memory reference or division by zero), the exception occurs in the kernel that caused the exception.
• It is possible to trigger an interrupt/trap on any core for notification purposes.

Multi-Core. OS limitations

• In AUTOSAR R4.0, it is not supported to activate additional cores under the control of AUTOSAR after the OS was started.
• The scheduling algorithm does not dynamically assign TASKS to cores.
• AUTOSAR OS RESOURCE algorithm is not supported between cores. RESOURCES can be used locally, between tasks on the same core, but not between TASKS/ISRs on different cores.

Multi-Core. Background & Rationale

• The existing AUTOSAR-OS is based on the OSEK/VDX OS. AUTOSAR Multi-Core OS is derived from the existing AUTOSAR operating system.
• All kernels must use the same codebase to reduce memory space. Sometimes it can be useful to use more ROM/Flash, e.g. use local ROM and "duplicate" parts of the code to get faster access to ROM/Flash.
• The generated part of the operating system is derived from a single set containing the information necessary for all kernels. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Each ID must refer to a single entity, regardless of which principal belongs to that entity. This also applies to items that cannot be shared in sections.

Multi-Core. Scheduling
The scheduling strategy as defined in AUTOSAR OS is applied for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core.

Multi-Core. Scheduling
The scheduling strategy as defined in AUTOSAR OS is applied for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core.

Multi-Core. OS-Applications

• A locatable entity (LE) is an entity that has to be located entirely on one core. Assignment of LEs to cores is determined during configuration.
• OS-Applications are the LEs in the OS.
• the usage of OS-Applications is obligatory in AUTOSAR for Multi-Core systems. This is independent from the SC class.
• On single-core systems, OS applications are only available for SC3 and SC because the mechanism is used to protect memory.
• All TASKS assigned to the same operating system application must be executed on the same core.
• All ISRs defined for the same operating system application are executed in the same kernel.
• OS should disable ISR balancing on boot (if supported by HW).

Multi-Core. Start-up

• The AUTOSAR multi-core OS specification requires system master-slave boot behavior.
• Each subkernel used by AUTOSAR must be activated before StartOS() is issued to the kernel. The slave cores might activate additional cores before calling StartOS().
• It is allowed to use only a subset of the cores available on a μC for the AUTOSAR system.

Multi-Core. Spinlocks
• Spinlock mechanism is introduced to support mutual exclusion for TASKS/ISRs on different cores.
• This mechanism shall not be used between TASKs/ISRs on the same core because it makes no sense. In such cases, the AUTOSAR OS returns an error.

• A spin key is a busy wait mechanism that requests a (key) variable until it becomes available. Typically, this requires an atomic “test and set” functionality, the details of which are implementation specific.
• To avoid a deadlock, the OS provides the possibility to configure a unique order in which multiple spinlocks can be occupied by a TASK/ISR2 on one core.

Occupation of the spinlocks in the predefined order

Multi-Core. IOC

General purpose
• IOC provides communication services available to customers who want to communicate between OS application domains on a single ECU.
• The RTE relies on IOC services to communicate across those boundaries. All communications must be transferred via RTE from both the sender (or client) and the receiver (or server).
• To make the RTE independent as a separate device, all internal application-OS-application communication processes and various input variables are integrated into the IOC. The internal performance of the IOC depends on the hardware architecture, especially the memory architecture.
• The IOC must ensure data consistency in inter-unit and inter-unit (multi-core systems) communications.

Multi-Core. IOC communication

• 1:1, N:1, and N: M (not only linear) are supported by IOC.
• Transfer of more than one data item in a single operation is only supported for 1:1 communication.
The advantage compared to sequential IOC calls is that mechanisms to open memory protection boundaries and to notify the receiver have to be executed just once. Additionally, consistency is guaranteed because all data items are sent in a single atomic process.
• IOC provides both queues less (last-in-best, data semantics) and queued (first-in, first-out, event semantics). Communication work. If you have an internal IOC queue, it has a long configuration.

• Each atomic communication operation gets specified individually by its own description block in a Configuration Description with regard to sender, receiver, data type(s), notification, and queuing.

Multi-Core. IOC interface

• The interface between RTE and IOC is similar to the interface between Software Components and the RTE, i.e.
Instead of providing a general API, we create a specific interface for each communication function.
• Software components can access IOC only through RTE. Only RTE decides which communication services it uses to support the communication needs of the software components.
• Direct access to IOC services via BSW modules is not supported but is allowed for CDDs and other modules if unavoidable.

Conclusion
AUTOSAR's multi-core architecture emphasizes effective and dependable performance within the automotive industry, incorporating multiple cores with standardized instruction sets and data representations. Nonetheless, there are constraints to consider, including the incapability to activate extra cores post-OS startup and the fixed nature of the scheduling algorithm. The design logic involves utilizing a shared codebase across kernels to enhance memory utilization. Operating system applications, with identifiable entities designated during configuration, ensure that tasks and ISRs are executed on the same core for uniformity. The system's startup procedure follows a master-slave model, activating subkernels before issuing StartOS().

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.