Heterogeneous multi-core inter-core communication scheduling method

Abstract

The application discloses a heterogeneous multi-core inter-core communication scheduling method, wherein a main core system application encapsulates different priority messages generated by the main core system application through an RPMsg device driver module, and the messages are scheduled by a message scheduling module and written into shared memory; an RPMsg communication component module reads and analyzes the messages generated by the main core system in the shared memory, and then sends the messages to a slave core system application; the slave core system application encapsulates the messages generated by the slave core system application through the RPMsg communication component module, and writes the messages into the shared memory; and the RPMsg device driver module reads and analyzes the messages generated by the slave core system in the shared memory, and then sends the messages to the main core system application. The application can meet the requirements of strong real-time, high computing power and rich running environment in an industrial field, and the inter-core communication efficiency is high, so that the time delay of real-time messages can be reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of inter-core communication of embedded heterogeneous multi-core processors, and particularly relates to an inter-core communication scheduling method of heterogeneous multi-core. BACKGROUND

[0002] With the continuous improvement of various complex business requirements in industrial sites, it is difficult for traditional embedded devices using single-core processors to meet the requirements in performance. In order to improve performance, embedded devices are facing the transition from single-core processors to multi-core processors. The continuous development of semiconductor technology makes it possible to integrate multiple processors on a chip, and the device can process multiple services at the same time, greatly improving the performance. The common heterogeneous multi-core architecture usually integrates a microprocessor (Micro Processor Unit, MPU) and a microcontroller (Mirco Controller Unit, MCU) in the chip. The MPU has high performance, generally runs a general operating system, provides a rich running environment, and processes image display services such as human-computer interaction. The MCU focuses on control, generally runs a real-time operating system or a bare machine program, and processes real-time control and signal processing services. In view of the requirements of embedded devices in industrial sites such as strong real-time, high computing power, and rich running environment, the heterogeneous multi-core device, i.e., integrating MPU and MCU on a chip, can meet the requirements.

[0003] The heterogeneous multi-core architecture device supports running different systems at the same time, and each slave system assists the master system to complete the work, so there is a demand for communication between systems. However, each core is independent of each other, making the inter-core communication of the operating system complex. Two systems can complete communication by establishing a Socket, but real-time systems generally do not support Socket, and need to add an additional protocol stack component, which is relatively complex in implementation steps. In order to realize the unified management of the inter-core communication of the heterogeneous multi-core device, Mentor Graphics and Xilinx proposed an open asymmetric multi-processing (Open Asymmetric Multi-Processing, OpenAMP) framework, which uses a remote processor messaging (Remote Processor Messaging, RPMsg) component to complete the inter-core communication. Meanwhile, NXP company proposed an RPMsg-Lite component, which can be applied to small MCUs. The RPMsg component completes communication based on shared memory. The operating system encapsulates the message in the RPMsg protocol specification, writes it into the shared memory, and triggers a hardware inter-core interrupt to notify the other party to read.

[0004] The RPMsg component provides a unified interface for master-slave core systems in heterogeneous multi-core architectures, enabling the management of inter-core communication. Inter-core communication requires hardware interrupt resources, and these resources are unique; therefore, contention arises when multiple services communicate between cores. The RPMsg component can use a first-in, first-out (FIFO) approach to schedule messages. While this approach ensures fairness, it cannot guarantee the real-time performance of critical messages. Priority scheduling ensures that high-priority messages receive the fastest response; however, when using FIFO for messages of the same priority, inconsistent message lengths will compromise the real-time performance of messages of the same priority. Summary of the Invention

[0005] This invention provides a heterogeneous multi-core inter-core communication scheduling method, which achieves message scheduling by adding a scheduling module, thereby ensuring the real-time performance of critical messages.

[0006] The technical solution adopted in this invention is a heterogeneous multi-core inter-core communication scheduling method, comprising the following steps:

[0007] Step 1. The main core system application sends the main core system messages it generates to the message scheduling module;

[0008] Step 2. The message scheduling module schedules the main core system messages and sends them to the RPMsg device driver module;

[0009] Step 3. The RPMsg device driver module encapsulates the main core system messages according to the RPMsg protocol specification to generate main core system RPMsg messages;

[0010] Step 4. The RPMsg device driver module writes the generated main core system RPMsg message into shared memory;

[0011] Step 5. The RPMsg device driver module initiates an inter-core interrupt to notify the RPMsg communication component module to read the main core system RPMsg messages in shared memory;

[0012] Step 6. The RPMsg communication component module reads the RPMsg messages from the main core system in shared memory; parses them, and sends them to the slave core system application.

[0013] Step 7. The kernel system application processes the parsed master kernel system RPMsg message to generate a slave kernel system message;

[0014] Step 8. The kernel system application sends the kernel system messages it generates to the RPMsg communication component module. The RPMsg communication component module encapsulates the kernel system messages according to the RPMsg protocol specification to generate kernel system RPMsg messages.

[0015] Step 9. The RPMsg communication component module writes the generated slave system RPMsg message into the shared memory; the RPMsg communication component module initiates an inter-core interrupt to inform the RPMsg device driver module to read the slave system RPMsg message in the shared memory;

[0016] Step 10. The RPMsg device driver module reads and parses the slave system RPMsg message in the shared memory and sends it to the master system application program; the slave system application program processes the parsed slave system RPMsg message.

[0017] The application has the characteristics that:

[0018] The master system message includes a high-priority message, a medium-priority message and a low-priority message.

[0019] The message scheduling module includes a high-priority queue, a plurality of medium-priority queues and a low-priority queue; the high-priority queue, the medium-priority queue and the low-priority queue are used to buffer the high-priority message, the medium-priority message and the low-priority message.

[0020] The high-priority message, the medium-priority message and the low-priority message are respectively stored and buffered in the high-priority queue, the medium-priority queue and the low-priority queue in a linked list structure.

[0021] The message scheduling module further includes a scheduler for scheduling the master system high-priority message, medium-priority message and low-priority message and sending them to the RPMsg device driver module.

[0022] The high-priority message and the low-priority message are scheduled in a first-in-first-out manner; the master system medium-priority message is scheduled in a deficit round robin manner.

[0023] The message scheduling module is scheduled in the following steps:

[0024] Step A1. The scheduler judges whether the high-priority queue is empty, if the queue is empty, go to step A2; if the queue is not empty, output the message at the head of the high-priority queue, write it into the shared memory, and re-enter step A1;

[0025] Step A2. The scheduler judges whether the medium-priority queue is empty, if the queue is empty, go to step A3; if the queue is not empty, use the deficit round robin manner to output the first message of the corresponding queue, write it into the shared memory, and re-enter step A1;

[0026] Step A3. The scheduler judges whether the low-priority queue is empty, if the queue is empty, go to step A1, if the queue is not empty, output the message at the head of the low-priority queue, write it into the shared memory, and re-enter step A1.

[0027] The scheduling process using the deficit polling method in step A2 is carried out according to the following steps:

[0028] Step B1. The scheduler obtains the index i of the queue corresponding to this poll;

[0029] Step B2. The scheduler determines whether the deficit D needs to be updated based on the update flag. i If an update flag is set, then the deficit D i The constant Q needs to be added. i ;

[0030] Step B3. The scheduler checks if the current medium-priority queue is empty. If the medium-priority queue is empty, the deficit D will be... i Clear the queue, update the queue index i, and set the deficit D. i Update the flag and re-enter step B2; if the medium priority queue is not empty, proceed to step B4.

[0031] Step B4. The scheduler determines whether the current queue deficit is greater than the length of the message at the head of the queue. If it is, the message is dequeued, and the queue deficit is updated, i.e., D. i Subtract the message length and end the polling; if the current queue deficit is less than the message length, proceed to step B5.

[0032] Step B5. The scheduler updates the queue index i and sets the deficit D. i Update the flags and end this polling.

[0033] deficit is the maximum number of bytes allowed to be output in this polling cycle.

[0034] The beneficial effects of this invention are as follows: Firstly, the heterogeneous multi-core inter-core communication scheduling method of this invention utilizes a heterogeneous multi-core platform. The processor cores are divided into a master core system and a slave core system. The master core runs the general-purpose Linux system, while the slave cores run the real-time FreeRTOS system, which can meet the requirements of strong real-time performance, high computing power, and rich operating environment in industrial environments. Secondly, inter-core communication between the master and slave cores uses RPMsg, providing a unified interface for management, using shared memory to store messages, and triggering hardware inter-core interrupts to notify the other party, resulting in high inter-core communication efficiency. Finally, by adding a message scheduling module, messages are divided into high, medium, and low priorities, and scheduling is strictly performed according to priority. Furthermore, medium-priority messages are scheduled using a deficit round-robin method, which can reduce the latency of real-time messages. Attached Figure Description

[0035] Figure 1 This is an overall architecture diagram of the heterogeneous multi-core inter-core communication system of the present invention;

[0036] Figure 2is a structural schematic diagram of a message scheduling module queue in the isomerous multi-core inter-core communication system of the application;

[0037] Figure 3 is a flow schematic diagram of message scheduling in the isomerous multi-core inter-core communication scheduling method of the application;

[0038] Figure 4 is a flow schematic diagram of priority use deficit round-robin scheduling in the isomerous multi-core inter-core communication scheduling method of the application;

[0039] Figure 5 is a performance graph of the first embodiment using the first-in-first-out scheduling method;

[0040] Figure 6 is a performance graph of the first embodiment using the isomerous multi-core inter-core communication scheduling method of the application. DETAILED DESCRIPTION

[0041] The application will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0042] The isomerous multi-core inter-core communication system of the application, as shown in Figure 1 , comprises a host core system, a slave core system and a shared memory; and the communication system is implemented to run on a heterogeneous multi-core platform.

[0043] The host core system is a general system Linux, which has strong performance and provides a rich running environment; the general system Linux runs a host core system application, which is used for image display and data processing tasks.

[0044] The RPMsg device driver module is used for reading and writing inter-core messages by the host core system application.

[0045] The message scheduling module is used for scheduling messages sent by the host core system application.

[0046] The message scheduling module comprises:

[0047] The high-priority queue, the medium-priority queue and the low-priority queue are respectively used for corresponding high-priority messages, medium-priority messages and low-priority messages.

[0048] The scheduler is used for scheduling messages stored in the high-priority queue, the medium-priority queue and the low-priority queue.

[0049] The slave core system is a real-time system FreeRTOS, which runs:

[0050] The slave core system application, which is used for executing real-time control and signal processing tasks.

[0051] The RPMsg communication component module is used for reading and writing inter-core messages by the slave core system application.

[0052] The master core system and the slave core system notify each other of reading messages through an inter-core interrupt mechanism, which is efficient.

[0053] The shared memory is used for storing inter-core messages generated by communication between the master core system and the slave core system.

[0054] The heterogeneous multi-core inter-core communication scheduling method comprises the following steps:

[0055] Step 1. The master core system application sends the master core system message generated by the master core system to the message scheduling module;

[0056] Step 2. The message scheduling module schedules the master core system message and sends it to the RPMsg device driver module;

[0057] Step 3. The RPMsg device driver module encapsulates the master core system message according to the RPMsg protocol specification to generate a master core system RPMsg message;

[0058] Step 4. The RPMsg device driver module writes the generated master core system RPMsg message into the shared memory;

[0059] Step 5. The RPMsg device driver module initiates an inter-core interrupt to notify the RPMsg communication component module to read the master core system RPMsg message in the shared memory;

[0060] Step 6. The RPMsg communication component module reads the master core system RPMsg message in the shared memory; after analysis, it is sent to the slave core system application;

[0061] Step 7. The slave core system application processes the analyzed master core system RPMsg message to generate a slave core system message;

[0062] Step 8. The slave core system application sends the generated slave core system message to the RPMsg communication component module, which encapsulates the slave core system message according to the RPMsg protocol specification to generate a slave core system RPMsg message;

[0063] Step 9. The RPMsg communication component module writes the generated slave core system RPMsg message into the shared memory; the RPMsg communication component module initiates an inter-core interrupt to notify the RPMsg device driver module to read the slave core system RPMsg message in the shared memory;

[0064] Step 10. The RPMsg device driver module reads and analyzes the slave core system RPMsg message in the shared memory and sends it to the master core system application, which processes the analyzed slave core system RPMsg message.

[0065] The main master core system messages include high-priority messages, medium-priority messages and low-priority messages.

[0066] As shown in Figure 2 , the message scheduling module includes a high-priority queue, a plurality of medium-priority queues and a low-priority queue, which correspond to three queue head nodes respectively;

[0067] The high-priority queue and the low-priority queue have only one queue node;

[0068] The medium-priority queue includes a plurality of queue nodes, and each message corresponds to a message node;

[0069] In the message scheduling, first, the queue head node of the corresponding priority is found, then the corresponding queue node is found according to the queue head node, and finally the message node is found according to the queue node, so as to complete one message scheduling.

[0070] The high-priority messages, the medium-priority messages and the low-priority messages are stored in the high-priority queue, the medium-priority queue and the low-priority queue in a linked list structure.

[0071] The message scheduling module further includes a scheduler, which is used to schedule the high-priority RPMsg messages of the master core system, the medium-priority RPMsg messages of the master core system and the low-priority RPMsg messages of the master core system, and write them into the shared memory.

[0072] The high-priority messages and the low-priority messages are scheduled in a first-in-first-out manner; and the medium-priority messages of the master core system are scheduled in a deficit round robin manner.

[0073] As shown in Figure 3 , the message scheduling module is scheduled according to the following steps:

[0074] Step A1. The scheduler judges whether the high-priority queue is empty, if the queue is empty, go to step A2; if the queue is not empty, output the message at the head of the high-priority queue, write it into the shared memory, and re-enter step A1;

[0075] Step A2. The scheduler judges whether the medium-priority queue is empty, if the queue is empty, go to step A3; if the queue is not empty, use the deficit round robin manner to output the first message of the corresponding queue, write it into the shared memory, and re-enter step A1;

[0076] Step A3. The scheduler judges whether the low-priority queue is empty, if the queue is empty, go to step A1, if the queue is not empty, output the message at the head of the low-priority queue, write it into the shared memory, and re-enter step A1.

[0077] AsFigure 4 The scheduling flow in the deficit round-robin mode in step A2 is performed according to the following steps:

[0078] The scheduling flow in the deficit round-robin mode in step A2 is performed according to the following steps:

[0079] Step B1. The scheduler obtains the subscript i of the queue corresponding to the current polling.

[0080] Step B2. The scheduler determines whether the deficit D needs to be updated according to the update flag i . If the update flag is set, the deficit D i needs to be added by the set constant Q i ; D i is the maximum number of bytes allowed to be output in this polling;

[0081] Step B3. The scheduler determines whether the medium priority queue is empty. If the medium priority queue is empty, the deficit D i is cleared, the queue subscript i is updated, and the deficit D i update flag is set, and the step B2 is re-entered; if the medium priority queue is not empty, the step B4 is entered.

[0082] Step B4. The scheduler determines whether the deficit of the current queue is greater than the length of the head message. If it is greater than the length of the message, the message is dequeued, the queue deficit is updated, that is, D i is subtracted by the length of the message, and the current polling is ended; if the deficit of the current queue is less than the length of the message, the step B5 is entered.

[0083] Step B5. The scheduler updates the queue subscript i, sets the deficit D i update flag, and ends the current polling.

[0084] Embodiment 1

[0085] The NXP I.MX 8M Plus heterogeneous multi-core chip is selected, which integrates an MPU (4 Cortex-A53 cores) and an MCU (1 Cortex-M7 core). The MPU runs a Linux system as a master core, the MCU runs a FreeRTOS system as a slave core, and the two systems use the RPMsg mechanism for inter-core communication. The message scheduling module on the Linux side divides the message scheduling into two processes: message enqueueing and dequeuing. First, the priority of the specified message is applied, the message is cached to the queue through the RPMsg device driver, and the scheduler service is waited for to complete the enqueueing process. A kernel thread is implemented on the Linux side to determine whether each queue is empty to complete the message dequeuing process.

[0086] The heterogeneous multi-core inter-core communication scheduling method of Embodiment 1 of this invention is compared with the original first-in-first-out (FIFO) scheduling method. Taking the sending of messages from the Linux side to the FreeRTOS side as an example, assuming that there are 5 applications that need to communicate, the scheduling method of this invention corresponds to 1 high-priority, 3 medium-priority, and 1 low-priority application, while the FIFO method...

[0087] The scheduling method has no priority, and the message size, period, and quantum number are shown in the table below:

[0088] Table 1 Experimental Parameters (Maximum Length of RPMsg Message L) max =496 bytes)

[0089] The performance of two scheduling methods is compared by measuring message communication latency. The latency of sending 100 messages by the application is recorded. Figure 5 , Figure 6 The comparison shows that this invention is superior to the first-in-first-out (FIFO) approach.

[0090] Compared with other scheduling methods, the heterogeneous multi-core inter-core communication scheduling method of the present invention can reduce the latency of inter-core communication between various applications, and at the same time ensure that the latency of high-priority message communication is less than that of low-priority message communication, which further proves the excellent performance of the heterogeneous multi-core inter-core communication scheduling method of the present invention.

Claims

1. A method of scheduling inter-core communication for a heterogeneous multi-core, the method comprising: Comprising the following steps: Step 1. The master core system application sends the master core system message generated by it to the message scheduling module; Step 2. The message scheduling module schedules the master core system message and sends it to the RPMsg device driver module; Step 3. The RPMsg device driver module encapsulates the master core system message according to the RPMsg protocol specification to generate a master core system RPMsg message; Step 4. The RPMsg device driver module writes the master core system RPMsg message generated by it into the shared memory; Step 5. The RPMsg device driver module initiates an inter-core interrupt to notify the RPMsg communication component module to read the master core system RPMsg message in the shared memory; Step 6. The RPMsg communication component module reads the master core system RPMsg message in the shared memory; after parsing, it is sent to the slave core system application; Step 7. The slave core system application processes the parsed master core system RPMsg message to generate a slave core system message; Step 8. The slave core system application sends the slave core system message generated by it to the RPMsg communication component module, which encapsulates the slave core system message according to the RPMsg protocol specification to generate a slave core system RPMsg message; Step 9. The RPMsg communication component module writes the slave core system RPMsg message generated by it into the shared memory; the RPMsg communication component module initiates an inter-core interrupt to notify the RPMsg device driver module to read the slave core system RPMsg message in the shared memory; Step 10. The RPMsg device driver module reads the slave core system RPMsg message in the shared memory and sends it to the master core system application after parsing; the slave core system application processes the parsed slave core system RPMsg message; The message scheduling module further comprises a scheduler for scheduling the master core system high-priority message, medium-priority message and low-priority message and sending it to the RPMsg device driver module; The high-priority message and low-priority message are scheduled in a first-in-first-out manner; the master core system medium-priority message is scheduled in a deficit round robin manner; The message scheduling module schedules according to the following steps: Step A1. The scheduler determines whether the high-priority queue is empty, if the queue is empty, go to step A2; if the queue is not empty, output the message at the head of the high-priority queue, write it into the shared memory, and re-enter step A1; Step A2. The scheduler determines whether the medium-priority queue is empty, if the queue is empty, go to step A3; if the queue is not empty, use the deficit round robin method to output the first message of the corresponding queue, write it into the shared memory, and re-enter step A1; Step A3. The scheduler determines whether the low-priority queue is empty, if the queue is empty, go to step A1, if the queue is not empty, output the message at the head of the low-priority queue, write it into the shared memory, and re-enter step A1.

2. The heterogeneous many-core inter- core communication scheduling method of claim 1, wherein, The main core system messages include high-priority messages, medium-priority messages and low-priority messages.

3. The heterogeneous many-core inter-core communication scheduling method of claim 2, wherein, The message scheduling module comprises a high-priority queue, a plurality of medium-priority queues and a low-priority queue; the high-priority queue, the medium-priority queues and the low-priority queue are used for buffering the high-priority messages, the medium-priority messages and the low-priority messages.

4. The heterogeneous many-core inter-core communication scheduling method of claim 3, wherein, The high-priority messages, the medium-priority messages and the low-priority messages are respectively stored in the high-priority queue, the medium-priority queues and the low-priority queue in a linked list structure.

5. The heterogeneous many-core inter- core communication scheduling method of claim 1, wherein, The scheduling flow in the deficit polling mode in step A2 is performed according to the following steps: Step B1. The scheduler obtains the subscript i of the queue corresponding to the current polling; Step B2. The scheduler determines whether the deficit D needs to be updated according to the update flag i , and if the update flag is set, the deficit D i needs to be added by the set constant Q i ; Step B3. The scheduler determines whether the current medium priority queue is empty. If the medium priority queue is empty, the deficit D i is cleared, the queue index i is updated, and the deficit D i is set. The flag is updated and the process reenters step B2. If the medium-priority queue is not empty, step B4 is entered; If the medium-priority queue is not empty, step B4 is entered; Step B4. The scheduler judges whether the current queue deficit is greater than the head message length. If it is greater than the message length, the message is dequeued and the queue deficit is updated, i.e. D i Subtract the message length and end this polling. If the current queue deficit is less than the message length, go to Step B5. Step B5. Scheduler updates queue index i, sets deficit D i Update flags and end this poll.

6. The heterogeneous many-core inter- core communication scheduling method of claim 5, wherein, The D i is the maximum number of bytes allowed to be output for this poll.

Images