## 3 Communication Strategies in Multicore Systems  
In real-time multicore microcontrollers, software components are typically allocated to each core, presenting an additional challenge for inter-task communication, primarily when tasks are assigned to different cores. Each processing core operates independently and may have different clock configurations, leading to unsynchronized task execution within the same period. Furthermore, varying initialization conditions, such as the number of data blocks that need to be loaded from Non-Volatile Memory (NVM) to Random Access Memory (RAM) at startup, can result in different core initialization times. In this context, data shared between cores are read from and written to a shared memory section at any point during task execution. According to [6], this behavior exemplifies explicit communication, as illustrated in Figure 1.  
According to [PERSON] et al. [28], with this paradigm, tasks directly access the shared register to read its value or write a new value to the register. This means that whenever the code requires a read or write operation on the variable, the shared register is accessed. This results in uncertainty since the exact timing of the register access depends on the task's specific execution path.  
This model presents different performance issues, leading to problems such as the following:  
* Sampling jitter;
* Sample loss;  
Figure 1: Explicit communication: Illustration of data read and write operations to a shared global memory (GLOBAL X) section during task execution on multicore systems, demonstrating inter-task communication handling when tasks are allocated to different cores.  
* Lack of determinism in event chains;
* Variable data exchange latency.  
The data shown in Figure 2 demonstrate the challenges of transferring data between cores, which can lead to a loss of signal resolution and potentially affect the performance of application algorithms. For this example, the modeling was conducted using a modeling and simulation environment such as Simulink's SoC Blockset. The timing reference for the example is managed by the simulation setup, starting at 0 at the beginning of the execution.  
In this scenario, a producer task was designed to run at a fixed rate of 10 ms on the primary core, triggered by an external event representing any scheduler event or an ISR in the operating system. To simulate unpredictable delays caused by external events like task preemption, ISRs, or execution jitter, the data output was generated at random times. The output was written to a shared buffer without any synchronization mechanisms, meaning that write operations could occur at any time during execution. A similar consumer task was designed to run on a secondary core at a fixed rate of 10 ms, also triggered by an external event. The consumer task read the input data from the shared buffer at the beginning of its execution.  
Both tasks were designed to run concurrently in parallel core models and exchanged data at different points in time, which affected predictability. Data flow consistency is compromised when write operations occur after read operations, leading to the loss of data samples. This degradation can significantly impact software performance, especially in critical applications where composability and predictability are essential, such as in safety-critical systems.