Heterogeneous multi-core inter-core communication method and system, electronic equipment and medium

Abstract

The invention provides a heterogeneous multi-core inter-core communication method and system, electronic equipment and a medium, and belongs to the technical field of intelligent driving, and the method comprises the steps: obtaining a to-be-sent message of a first core, and setting a priority for the to-be-sent message; packaging the to-be-sent message and the corresponding priority to obtain a packaged message; storing the packaged message in a shared memory; and triggering inter-core interruption to enable the second core to read the message in the shared memory by adopting a non-preemptive priority scheduling strategy. According to the invention, the priority of the message is set, and the priority scheduling strategy is combined with the inter-core communication protocol, so that the time delay requirement is ensured, and the inter-core real-time communication is realized. By adding the non-preemptive priority scheduling strategy, the messages are scheduled according to categories, the low-delay requirement of the real-time messages is met, the QoS requirement of the real-time messages can be ensured, and the scene with the high real-time requirement such as intelligent driving is met.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and in particular to a heterogeneous multi-core inter-core communication method, system, electronic device and medium. Background Technology

[0002] In the field of intelligent driving, as the complexity of system functions increases (such as environmental perception, path planning, and real-time control), the requirements for the real-time performance, computing power, and energy efficiency of computing architecture are becoming increasingly stringent. Heterogeneous multi-core SoCs have become the mainstream solution for computing architectures. However, inter-core communication suffers from problems such as the inability to guarantee the real-time performance of inter-core messages and the inability to meet the communication latency requirements of real-time messages, which directly affects the functional safety of intelligent driving systems. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a method, system, electronic device and medium for inter-core communication in heterogeneous multi-core systems.

[0004] In a first aspect, embodiments of the present invention provide a method for inter-core communication in heterogeneous multi-core systems, comprising:

[0005] Obtain the messages to be sent from the first core and set the priority for the messages to be sent;

[0006] The message to be sent and its corresponding priority are encapsulated to obtain the encapsulated message;

[0007] The encapsulated message is stored in shared memory;

[0008] An inter-core interrupt is triggered so that the second core can read messages from the shared memory using a non-preemptive priority scheduling strategy.

[0009] In some embodiments, the first core and the second core are hardware isolated and transmit information through an inter-core communication channel.

[0010] In some embodiments, obtaining the messages to be sent from the first core and setting a priority for the messages to be sent includes:

[0011] Retrieve the messages to be sent from the first core;

[0012] Determine the message data volume of the message to be sent;

[0013] Priority is set based on the amount of message data.

[0014] In some embodiments, setting the priority based on the message data volume includes:

[0015] The maximum number of data bytes in a message frame is determined according to the message format of the inter-core communication protocol.

[0016] Determine the ratio of the message data volume to the maximum number of bytes in the data;

[0017] When the ratio is less than or equal to 1, the message to be sent is set to the first priority;

[0018] When the ratio is greater than 1, the message to be sent is set to the second priority; wherein the first priority is higher than the second priority.

[0019] In some embodiments, encapsulating the message to be sent and its corresponding priority to obtain the encapsulated message includes:

[0020] The messages to be sent are divided into corresponding priority queues according to the set priorities.

[0021] The RPMsg driver based on the main core encapsulates the message to be sent and priority information to obtain the encapsulated message.

[0022] In some embodiments, the priority queue includes: a first priority queue and a second priority queue; the first priority queue includes messages to be sent with a first priority, and the second priority queue includes messages to be sent with a second priority, wherein the first priority is higher than the second priority;

[0023] Messages of the same priority enter the queue in a first-in, first-out manner, and the first priority queue and the second priority queue share the same server.

[0024] In some embodiments, the method further includes:

[0025] Determine if the first priority queue is ready;

[0026] If the first priority queue is ready, then transmit the first message of the first priority queue;

[0027] If the first priority queue is not ready, then determine whether the second priority queue is ready;

[0028] If the second priority queue is ready, then transmit the first message of the second priority queue;

[0029] If the second priority queue is not ready, wait for the first priority queue or the second priority queue to become ready.

[0030] Secondly, embodiments of the present invention provide an inter-core communication system for heterogeneous multi-core systems, comprising:

[0031] The priority setting module is used to obtain the messages to be sent from the first core and set the priority of the messages to be sent.

[0032] The encapsulation module is used to encapsulate the message to be sent and its corresponding priority to obtain the encapsulated message;

[0033] A storage module is used to store the encapsulated message in shared memory;

[0034] The communication module is used to trigger an inter-core interrupt so that the second core can read messages from the shared memory using a non-preemptive priority scheduling strategy.

[0035] Thirdly, embodiments of the present invention provide an electronic device, including:

[0036] One or more processors;

[0037] Memory, used to store one or more programs;

[0038] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described above.

[0039] Fourthly, embodiments of the present invention provide a computer-readable medium on which a computer program is stored, the computer program being executed by a processor to implement the steps of any of the methods described above.

[0040] The inter-core communication method for heterogeneous multi-core processors provided by this invention includes: acquiring a message to be sent from a first core and setting a priority for the message; encapsulating the message and its corresponding priority to obtain an encapsulated message; storing the encapsulated message in shared memory; and triggering an inter-core interrupt to enable a second core to read the message from the shared memory using a non-preemptive priority scheduling strategy. In this invention, by setting message priorities and combining the priority scheduling strategy with the inter-core communication protocol, latency requirements are guaranteed, enabling real-time inter-core communication. By adding a non-preemptive priority scheduling strategy, messages are scheduled according to category, meeting the low-latency requirements of real-time messages and ensuring the QoS requirements of real-time messages, thus satisfying scenarios with high real-time requirements such as intelligent driving. Attached Figure Description

[0041] Figure 1 A flowchart illustrating an inter-core communication method for heterogeneous multi-core systems provided in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the heterogeneous multi-core hardware platform involved in the embodiments of the present invention;

[0043] Figure 3 This is a schematic diagram of the inter-core communication process of the dual system involved in an embodiment of the present invention;

[0044] Figure 4This is a schematic diagram of the non-preemptive priority scheduling strategy scheduling process involved in an embodiment of the present invention;

[0045] Figure 5 This is a schematic diagram illustrating the storage of inter-core messages in different priority queues in an embodiment of the present invention;

[0046] Figure 6 This is a schematic diagram illustrating the storage of inter-core messages in the same queue in an embodiment of the present invention;

[0047] Figure 7 A structural block diagram of a heterogeneous multi-core inter-core communication system provided in an embodiment of the present invention;

[0048] Figure 8 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0049] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0050] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0051] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0052] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0053] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0054] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0055] The key terms involved in this invention are defined as follows:

[0056] SoC: System on Chip;

[0057] IPC: Inter-Process Communication;

[0058] QoS: Quality of Service;

[0059] MCU: Microcontroller Unit.

[0060] In related technologies, heterogeneous multi-core SoCs (such as TI TDA4 and NXP S32G) have become the mainstream solution, typically employing a combination of a high-performance Linux kernel (running complex algorithms and upper-layer applications) and a real-time-intensive FreeRTOS kernel (handling hard real-time tasks, such as sensor timing control). To achieve efficient collaboration between the two systems, the RPMsg (Remote Processor Messaging) protocol is widely used for inter-core communication (IPC). It plays the role of a "nerve fiber" in heterogeneous multi-core intelligent driving systems, balancing the computing power of Linux and the real-time performance of FreeRTOS through a standardized communication interface. Its efficiency and reliability directly affect the functional safety of the intelligent driving system (e.g., ISO 26262 ASIL-D certification).

[0061] An exemplary technology based on standard RPMsg inter-kernel communication: On the Linux side, a standard RPMsg driver (virtio_rpmsg_bus) runs, providing a character device interface ( / dev / rpmsgX) for user-space access. On the FreeRTOS side, a lightweight RPMsg implementation (such as OpenAMP or a library provided by a vendor's SDK) is integrated, registering message endpoints and handling interrupts. Hardware dependencies are based on shared memory (Mailbox / Shared RAM) and inter-processor interrupts (IPI). The RPMsg protocol uses a First-In-First-Out (FIFO) strategy for message scheduling, which cannot guarantee the QoS requirements of real-time messages. In scenarios with high real-time requirements, such as autonomous driving, there are issues with insufficient real-time performance, and it lacks priority scheduling.

[0062] The heterogeneous multi-core inter-core communication method designed in this invention solves the problem that the message scheduling strategy for inter-core communication in intelligent driving systems based on heterogeneous multi-core architecture cannot guarantee the real-time performance of inter-core messages, and meets the communication latency requirements of real-time messages.

[0063] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a method for inter-core communication in heterogeneous multi-core systems. Figure 1 This is a flowchart illustrating a heterogeneous multi-core inter-core communication method provided in an embodiment of the present invention.

[0064] As one embodiment of the present invention, such as Figure 1 As shown, the inter-core communication method for heterogeneous multi-core systems includes:

[0065] Step S1: Obtain the messages to be sent from the first core and set the priority of the messages to be sent;

[0066] Step S2: Encapsulate the message to be sent and its corresponding priority to obtain the encapsulated message;

[0067] Step S3: Store the encapsulated message in shared memory;

[0068] Step S4: Trigger an inter-core interrupt so that the second core can read messages from the shared memory using a non-preemptive priority scheduling strategy.

[0069] It's important to note that heterogeneous multi-core technology supports integrating different types of processor cores within a single chip. This allows for meeting diverse business needs, enabling parallel processing, and ultimately improving the performance of embedded devices. For high-performance, real-time requirements with concurrent business operations, a Linux + FreeRTOS dual-system platform can be built using a SOC + MCU heterogeneous multi-core device. Figure 2 As shown.

[0070] Specifically, the System-on-a-Chip (SoC), as the main core, has a high clock speed and powerful processing and computing capabilities. It needs to run a large operating system to handle complex and computationally intensive tasks, such as image display, human-computer interaction, and data processing. The Microcontroller (MCU), as the slave core, focuses on handling control tasks, such as signal processing and device control. It generally does not have the ability to handle complex tasks and primarily uses two development modes: bare-metal and with an operating system. The development mode with an operating system uses the system's task management mechanism to break down tasks into multiple threads, achieving modular programming. Threads have different priorities, ensuring the real-time performance of high-priority tasks. The dual-system platform enables concurrent processing of tasks. Since communication is required during task execution, inter-core communication can be achieved through the RPMsg protocol.

[0071] like Figure 2 As shown, for heterogeneous multi-core platforms, the SOC processor runs a Linux system, which is compatible with the RPMsg driver, while the MCU processor runs a FreeRTOS system, requiring the porting of the RPMsg-Lite component. The inter-core communication process between the two systems is as follows: Figure 3 As shown, the solid lines represent the message sending process of the Linux system, and the dashed lines represent the message reading process of the Linux system. Taking the message sending from the Linux system to the FreeRTOS system as an example, a complete communication mainly includes the following steps: First, the Linux system application encapsulates the message through the RPMsg driver and stores it in the write-shared memory; then, the Linux system triggers an inter-kernel interrupt to notify the FreeRTOS system to read the message; finally, the FreeRTOS system application reads the message from the write-shared memory and completes the parsing through the RPMsg-Lite component.

[0072] In some embodiments, the first core and the second core are hardware isolated and transmit information through an inter-core communication channel.

[0073] For example, this embodiment uses Figure 3 The following example illustrates a heterogeneous multi-core system with SOC and MCU. The first core can be a SOC, and the second core can be an MCU; this embodiment does not impose any limitations on this. Figure 3 As shown, the first-core SOC and the second-core MCU are hardware isolated and transmit information through the inter-core communication channel of the heterogeneous multi-core system.

[0074] Specifically, different QoS requirements exist for inter-core communication. For example, control signals and status synchronization signals have strict latency requirements, while ordinary information data and management data without latency requirements can be sent when the system is idle. The RPMsg protocol schedules inter-core messages according to a first-in-first-out strategy, which cannot guarantee the latency requirements of real-time messages. In this embodiment, a priority scheduling strategy is combined with the RPMsg protocol. By setting real-time messages to high priority, their latency requirements are guaranteed, thus enabling real-time inter-core communication.

[0075] In some embodiments, obtaining messages to be sent from a first core and setting a priority for the messages to be sent includes: obtaining messages to be sent from the first core; determining the message data volume of the messages to be sent; and setting a priority based on the message data volume.

[0076] In some embodiments, setting a priority based on the message data volume includes: determining the maximum number of data bytes in a frame of a message according to the message format of the inter-core communication protocol; determining the ratio of the message data volume to the maximum number of data bytes; setting the message to be sent to a first priority when the ratio is less than or equal to 1; and setting the message to be sent to a second priority when the ratio is greater than 1; wherein the first priority is higher than the second priority.

[0077] Specifically, inter-core communication in heterogeneous multi-core devices can utilize the RPMsg protocol. By adding a non-preemptive priority scheduling strategy, the real-time performance of critical messages can be guaranteed. The RPMsg protocol specifies the message format, with a maximum data size of 496 bytes per message frame. When devices communicate between cores, real-time messages, such as control signals and synchronization signals, typically have small data volumes and can be sent after a single encapsulation. However, ordinary information data and management data have larger data volumes and need to be encapsulated into multiple RPMsg message frames before transmission. Therefore, priorities can be set based on message data size; messages with less than 496 bytes are considered high-priority messages, and vice versa.

[0078] In this embodiment, the maximum data size in a message frame is determined to be 496 bytes according to the message format of the inter-core communication protocol RPMsg. In this embodiment, priority is set according to the size of the message data. That is, a message with a data size less than or equal to the maximum data size of 496 bytes is a high-priority message (first priority), and a message with a data size greater than the maximum data size of 496 bytes is a low-priority message (second priority).

[0079] For example, suppose the inter-core communication system has two priorities, high and low, and the data size of the i-th message is S. i Then the priority P of the i-th message is... i for:

[0080]

[0081] In one example, considering a Linux system sending a message to a FreeRTOS system: the Linux application determines the message priority based on its data size. If the data size is less than or equal to 496 bytes, it is marked as high priority; otherwise, it is marked as low priority. After determining the priority, the application encapsulates the message using the RPMsg driver, incorporating priority information into the message during this encapsulation process. The encapsulated message is then stored in shared memory. The Linux system triggers an inter-kernel interrupt, notifying the FreeRTOS system of the arrival of a new message. Upon receiving the inter-kernel interrupt signal, the FreeRTOS system reads the message from the shared memory using the RPMsg-Lite component and processes it accordingly based on the priority information within the message.

[0082] In some embodiments, the message to be sent and its corresponding priority are encapsulated to obtain an encapsulated message, including: dividing the message to be sent into a corresponding priority queue according to the set priority; and encapsulating the message to be sent and the priority information based on the RPMsg driver of the first core to obtain an encapsulated message.

[0083] In some embodiments, the priority queue includes: a first priority queue and a second priority queue; the first priority queue includes messages to be sent with a first priority, and the second priority queue includes messages to be sent with a second priority, wherein the first priority is higher than the second priority; messages of the same priority enter the queue in a first-in-first-out manner, and the first priority queue and the second priority queue share the same server.

[0084] Understandably, the inter-core communication system supports high and low priorities, corresponding to the high and low priority queues in the queuing system. Messages enter the corresponding queue according to their priority, and messages of the same priority enter the queue in a first-in-first-out manner. The two queues share the same server.

[0085] In some embodiments, the method further includes: determining whether a first priority queue is ready; if the first priority queue is ready, transmitting the first message of the first priority queue; if the first priority queue is not ready, determining whether a second priority queue is ready; if the second priority queue is ready, transmitting the first message of the second priority queue; if the second priority queue is not ready, waiting for either the first priority queue or the second priority queue to become ready.

[0086] Specifically, priority scheduling is a common message queue scheduling strategy. The system allocates service opportunities to the highest-priority message in the ready queue. It can be divided into preemptive priority scheduling and non-preemptive priority scheduling. Preemptive priority scheduling means that when a higher-priority message arrives at the system, the system actively stops serving the current message and switches to serving the higher-priority message. Non-preemptive priority scheduling means that when a higher-priority message arrives at the system, the system does not stop serving the current message; it must wait for the next scheduling iteration to receive service. In this embodiment, a non-preemptive priority scheduling strategy is adopted, and its scheduling process is as follows: Figure 4 As shown.

[0087] For example, such as Figure 4 As shown, the inter-core communication system initializes and determines whether the high-priority queue is ready. If the high-priority queue is ready, the first message of the high-priority queue is transmitted. If the high-priority queue is not ready, the system determines whether the low-priority queue is ready. If the low-priority queue is ready, the first message of the low-priority queue is transmitted. If the low-priority queue is not ready, the system waits for the queue to become ready.

[0088] In this embodiment, by adding a message scheduling strategy, messages are scheduled according to category to meet the low latency requirements of real-time messages, realize real-time communication between cores, guarantee the QoS requirements of real-time messages, and meet the high real-time requirements of scenarios such as intelligent driving.

[0089] In one example, considering a Linux system sending a message to a FreeRTOS system: the Linux application determines the message's priority based on its size. Depending on the priority, the message is assigned to either a high-priority or low-priority queue. This involves creating two queues (high-priority or low-priority) and managing message enqueueing. After being assigned to the appropriate queue, the message is encapsulated, potentially including priority information. The encapsulated message is then stored in shared memory. The Linux system triggers an inter-core interrupt, notifying the FreeRTOS system of the arrival of a new message. Upon receiving the inter-core interrupt signal, the FreeRTOS system reads the message from the shared memory using the RPMsg-Lite component and processes it according to a non-preemptive priority scheduling strategy.

[0090] It should be noted that, compared to the first-in, first-out (FIFO) scheduling strategy, this embodiment employs a non-preemptive priority scheduling strategy, which can reduce the average latency of the communication system. The following is a detailed analysis to illustrate this:

[0091] like Figure 5 As shown, assume that the arrival process of inter-core messages follows a Poisson distribution, and there are m types of high-priority messages with arrival rates of respectively. , , ..., There are n types of low-priority messages, with arrival rates of respectively , , ..., The system's service process follows a general distribution, with a service rate of μ for one RPMsg message frame and an average service time of μ. The second moment of the service time is .

[0092] Since the Poisson distribution is additive, the total arrival rate of high-priority messages is:

[0093]

[0094] The total arrival rate of low-priority messages is:

[0095]

[0096] The total arrival rate λ of inter-core messages is:

[0097]

[0098] The i-th low-priority message needs to be encapsulated into k. i Frame RPMsg message, i.e.:

[0099]

[0100] Among them, S i It is the data size of the i-th low-priority message.

[0101] Low-priority messages in the system need to be encapsulated into The frame RPMsg message contains:

[0102]

[0103] Based on the properties of mathematical expectation and variance, the average service time for high-priority messages is: The second moment of the service time is The average service time for low-priority messages is The second moment of the service time is .

[0104] Average waiting time for high priority messages for:

[0105]

[0106] Average dwell time of high-priority messages for:

[0107]

[0108] Average waiting time for low priority messages for:

[0109]

[0110] Average dwell time of low priority messages for:

[0111]

[0112] The average delay of the system for:

[0113]

[0114] like Figure 6 As shown, inter-core communication in heterogeneous multi-core devices uses the RPMsg protocol. The communication system will use a first-in-first-out (FIFO) scheduling strategy to provide indiscriminate service for inter-core messages. Queuing theory is used to analyze the average latency of the communication system using the FIFO scheduling strategy, and its performance is compared with that of a system using a non-preemptive priority scheduling strategy. The communication system is modeled as an M / G / 1 queuing system with a FIFO service rule, as shown... Figure 6 As shown, inter-core messages are stored in the same queue, and the communication system has only one server.

[0115] Under the same assumptions, the total inter-core message arrival rate λ of the system is as shown in the formula, then the average service time... for:

[0116]

[0117] Second moment of average service time for:

[0118]

[0119] The communication system operates on a first-in, first-out (FIFO) scheduling strategy, meaning all inter-core messages can be assumed to have the highest priority. The system's average latency is... and average length of stay They are respectively:

[0120]

[0121] Subtracting the above equation, we get:

[0122]

[0123] Summarized as follows:

[0124]

[0125] The arrival strength ρ of messages in the system can be represented by the ratio of arrival rate to service rate, i.e. For a queuing system to operate stably, the total arrival strength of messages must be less than 1, that is:

[0126]

[0127] Therefore, we can know ,and Therefore, ΔT > 0, meaning that theoretically, compared to the first-in-first-out scheduling strategy, the non-preemptive priority scheduling strategy adopted in this embodiment can reduce the average latency of the communication system.

[0128] In this embodiment, by adding a message scheduling strategy, messages are scheduled according to category to meet the low latency requirements of real-time messages, realize real-time communication between cores, guarantee the QoS requirements of real-time messages, meet the high real-time requirements of scenarios such as intelligent driving, and solve the problem that the existing message scheduling strategy for inter-core communication in intelligent driving systems based on heterogeneous multi-core architecture cannot guarantee the real-time performance of inter-core messages, thereby meeting the communication latency requirements of real-time messages.

[0129] This embodiment provides a heterogeneous multi-core inter-core communication method, including: acquiring a message to be sent from a first core and setting a priority for the message; encapsulating the message and its corresponding priority to obtain an encapsulated message; storing the encapsulated message in shared memory; and triggering an inter-core interrupt to enable a second core to read the message from the shared memory using a non-preemptive priority scheduling strategy. In this embodiment, by setting message priorities and combining the priority scheduling strategy with the inter-core communication protocol, latency requirements are guaranteed, enabling real-time inter-core communication. By adding a non-preemptive priority scheduling strategy, messages are scheduled according to category, meeting the low-latency requirements of real-time messages and ensuring the QoS requirements of real-time messages, thus satisfying scenarios with high real-time requirements such as intelligent driving.

[0130] Reference Figure 7 , Figure 7 This is a structural block diagram of an embodiment of the heterogeneous multi-core inter-core communication system of the present invention. Figure 7 As shown, the heterogeneous multi-core inter-core communication system includes:

[0131] The priority setting module 10 is used to obtain the messages to be sent from the first core and set the priority of the messages to be sent.

[0132] Encapsulation module 20 is used to encapsulate the message to be sent and its corresponding priority to obtain the encapsulated message;

[0133] Storage module 30 is used to store the encapsulated message in shared memory;

[0134] The communication module 40 is used to trigger an inter-core interrupt so that the second core can read messages in the shared memory using a non-preemptive priority scheduling strategy.

[0135] Specifically, this embodiment combines a priority scheduling strategy with the RPMsg protocol. By setting real-time messages to high priority, latency requirements are guaranteed, enabling real-time inter-core communication. The inter-core communication system supports high and low priorities, corresponding to high and low priority queues in the queuing system. Messages enter the corresponding queue according to their priority, and messages of the same priority enter the queue in a first-in-first-out manner. The two queues share the same server.

[0136] Specifically, priority scheduling is a common message queue scheduling strategy. The system allocates service opportunities to the highest-priority message in the ready queue. It can be divided into preemptive priority scheduling and non-preemptive priority scheduling. Preemptive priority scheduling means that when a higher-priority message arrives, the system actively stops serving the current message and switches to serving the higher-priority message. Non-preemptive priority scheduling means that when a higher-priority message arrives, the system does not stop serving the current message; it must wait for the next scheduling iteration. This embodiment uses a non-preemptive priority scheduling strategy. The message being processed will not be preempted by a higher-priority message, but newly arriving high-priority messages will be placed at the front of the queue.

[0137] The heterogeneous multi-core inter-core communication system provided in this embodiment combines priority scheduling strategies with inter-core communication protocols to ensure latency requirements and achieve real-time inter-core communication. By adding a message scheduling strategy, messages are scheduled according to category, meeting the low latency requirements of real-time messages and achieving real-time inter-core communication. This ensures the QoS requirements of real-time messages, satisfying scenarios with high real-time requirements such as intelligent driving. It solves the problem that existing message scheduling strategies for inter-core communication in intelligent driving systems based on heterogeneous multi-core architectures cannot guarantee the real-time performance of inter-core messages, thus meeting the communication latency requirements of real-time messages.

[0138] In addition, for technical details not described in detail in this embodiment of the heterogeneous multi-core inter-core communication system, please refer to the heterogeneous multi-core inter-core communication method provided in any embodiment of the present invention, which will not be repeated here.

[0139] Based on the same inventive concept, embodiments of the present invention also provide a heterogeneous multi-core chip (e.g., an automotive-grade chip), the heterogeneous multi-core chip including a heterogeneous multi-core platform, the heterogeneous multi-core platform employing the inter-core communication system of the heterogeneous multi-core described above.

[0140] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 8This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 8 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the heterogeneous multi-core inter-core communication methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0141] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0142] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0143] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0144] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the heterogeneous multi-core inter-core communication methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0145] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described heterogeneous multi-core inter-core communication method.

[0146] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0147] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0148] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0149] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0150] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0151] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0152] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0153] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0154] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0155] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method of inter-core communication for a heterogeneous multi-core, the method comprising: The method comprises: acquiring a to-be-sent message of a first core and setting a priority for the to-be-sent message; encapsulating the to-be-sent message and the corresponding priority to obtain an encapsulated message; storing the encapsulated message in a shared memory; triggering an inter-core interrupt to enable a second core to read the message in the shared memory by using a non-preemptive priority scheduling strategy.

2. The method of claim 1, wherein, The first core and the second core are hardware-isolated, and information is transmitted through an inter-core communication channel.

3. The method of claim 1, wherein, The acquiring of the to-be-sent message of the first core and the setting of the priority for the to-be-sent message comprise: acquiring the to-be-sent message of the first core; determining a message data volume of the to-be-sent message; setting the priority according to the message data volume.

4. The method of claim 3, wherein, The setting of the priority according to the message data volume comprises: determining a maximum data byte in a frame message according to a message format of an inter-core communication protocol; determining a ratio of the message data volume to the maximum data byte; when the ratio is less than or equal to 1, setting the to-be-sent message as a first priority; when the ratio is greater than 1, setting the to-be-sent message as a second priority; wherein the first priority is higher than the second priority.

5. The method of claim 1, wherein, The encapsulating of the to-be-sent message and the corresponding priority to obtain the encapsulated message comprises: dividing the to-be-sent message into corresponding priority queues according to the set priority; encapsulating the to-be-sent message and the priority information based on an RPMsg driver of the first core to obtain the encapsulated message.

6. The method of claim 5, wherein, The priority queues comprise a first priority queue and a second priority queue; the first priority queue comprises to-be-sent messages of a first priority, and the second priority queue comprises to-be-sent messages of a second priority; the first priority is higher than the second priority. Messages of the same priority enter the queue in a first-in-first-out manner, and the first priority queue and the second priority queue share the same service counter.

7. The method of claim 6, wherein, The method further comprises: judging whether the first priority queue is ready; if the first priority queue is ready, transmitting a first message of the first priority queue; if the first priority queue is not ready, judging whether the second priority queue is ready; if the second priority queue is ready, transmitting a first message of the second priority queue; if the second priority queue is not ready, waiting for the first priority queue or the second priority queue to be ready.

8. A heterogeneous multi-core inter-core communication system, characterized by, The method comprises: a priority setting module configured to acquire a to-be-sent message of a first core and set a priority for the to-be-sent message; an encapsulating module configured to encapsulate the to-be-sent message and the corresponding priority to obtain an encapsulated message; a storage module configured to store the encapsulated message in a shared memory; a communication module configured to trigger an inter-core interrupt to enable a second core to read the message in the shared memory by using a non-preemptive priority scheduling strategy.

9. An electronic device, comprising: The method comprises: one or more processors; a memory configured to store one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer readable medium having stored thereon a computer program, characterized in that The computer program, which is executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images