A parallel running method of a system architecture based on inter-core communication of heterogeneous multi-core

Abstract

The application relates to a system architecture parallel operation method based on heterogeneous multi-core inter-core communication and belongs to the field of embedded operating systems. The application utilizes a heterogeneous processor system management framework based on a global object and HPCI, can support different operating system copies deployed on the heterogeneous processor cores to run in parallel, each heterogeneous processor core can independently execute a task, and the heterogeneous processor cores are cooperatively processed through the HPCI. The operating system copies can be conveniently expanded according to the number of the heterogeneous processor cores, hardware resources can be fully utilized, the operating system can fully utilize the core where the operating system is located, the overall execution efficiency is improved, and true parallel processing is realized.

Description

Technical Field

[0001] This invention belongs to the field of embedded operating systems, specifically relating to a parallel operation method for a system architecture based on heterogeneous multi-core inter-core communication. Background Technology

[0002] With the widespread application of heterogeneous multi-core processors in embedded systems, ensuring the efficient operation of various applications on heterogeneous processors has become a crucial problem that operating systems urgently need to solve. In heterogeneous processors, the operating system often operates in asymmetric multi-processing (AMP) mode, where each core has its own independent copy of the operating system, and tasks are statically distributed across different cores during the application design phase. To enable parallel operation of multiple cores in a heterogeneous processor, efficient inter-core communication mechanisms need to be established, such as shared memory areas and inter-processor interrupts, for synchronization, data exchange, and control of shared resource access. This allows the operating systems to work collaboratively to achieve the goal of collaborative processing.

[0003] Chinese patent CN113391821A, "An Asymmetric Multiprocessor Embedded Operating System," proposes deploying a main operating system on the main processor of an asymmetric multi-core hardware platform and an embedded real-time operating system on the slave processors. The method specifically includes the following aspects: First, the main operating system manages the loading, running, access to peripheral hardware resources, and unloading of the embedded real-time operating system. Second, the embedded real-time operating system executes real-time tasks assigned by the main operating system. Finally, information is exchanged between the main operating system and the embedded operating system through inter-core interrupts and shared memory. This method fully utilizes the characteristics of asymmetric multi-core processor architecture, resolving the contradiction between a real-time operating system and a fully functional software operating system coexisting on the same embedded asymmetric multi-core processor. By improving system real-time performance and security, it provides a more efficient solution for embedded applications.

[0004] Chinese patent CN114327930A, "System Architecture and Operating Method for Heterogeneous Multi-core Inter-core Communication," provides a system architecture for heterogeneous multi-core inter-core communication based on the Remoteproc framework. This system architecture consists of two parts: 1. A first processor system: including a first control device and a first operating system module. The first control device manages the system's operation, while the first operating system module executes related tasks; 2. A second processor system: including a second control device and a second operating system module, wherein the second operating system module is also configured with an asymmetric multiprocessor (AMP) communication software component. The second operating system module not only includes conventional operating system functions but also has an AMP communication software component that works in conjunction with the Remoteproc framework to control the operation of the first processor system. By configuring the AMP communication software component on the second processor system to extend the Linux Remoteproc framework, efficient heterogeneous multi-core inter-core communication is achieved, effectively enabling collaborative processing of heterogeneous multi-cores and improving the overall performance and efficiency of the system.

[0005] Chinese patent "CN113391821A An Asymmetric Multiprocessor Embedded Operating System" proposes deploying a main operating system on the main processor of an asymmetric multi-core hardware platform to resolve the contradiction between a real-time operating system and a fully functional software operating system coexisting on the same embedded asymmetric multi-core processor. However, this method, with the main processor managing all hardware resources, forms a master-slave working mode, which cannot effectively achieve heterogeneous parallel operation. Furthermore, this method uses inter-core interrupts and shared memory to exchange information between the main operating system and the embedded operating system. Inter-core interrupts and shared memory are methods that do not require operating system support, making it difficult to handle multi-threaded synchronization and communication issues.

[0006] Chinese patent "CN114327930A System Architecture and Operating Method for Heterogeneous Multi-core Inter-core Communication" extends the Linux Remoteproc framework by configuring an asymmetric multiprocessor (AMP) communication software component on a second processor system to achieve efficient inter-core communication in heterogeneous multi-core systems, thereby enabling collaborative processing of heterogeneous multi-core systems. However, this method controls the operation of the first processor system through the second processor system, which is also a master-slave working mode and cannot effectively achieve heterogeneous parallel processing. Furthermore, this method uses the hardware mechanism Mailbox for inter-process synchronization and data exchange, requiring hardware support and processes to adhere to certain protocols to ensure the correctness and reliability of communication, which may lead to message loss. Moreover, it limits the system to two processor systems, proving inadequate for handling multiple heterogeneous processing cores and unable to provide effective communication management. Summary of the Invention

[0007] (a) Technical problems to be solved

[0008] The technical problem to be solved by the present invention is how to provide a system architecture parallel operation method based on heterogeneous multi-core inter-core communication, so as to solve the above-mentioned problems existing in the prior art.

[0009] (II) Technical Solution

[0010] To address the aforementioned technical problems, this invention proposes a parallel operation method for a system architecture based on heterogeneous multi-core inter-core communication. Each heterogeneous processor core in this system architecture has an independent copy of the operating system. The system architecture includes: a system service component module and an HPCI module.

[0011] The system service component module uses APIs to support multi-core mode and manage kernel resources.

[0012] The HPCI module is used to implement communication between multiple cores running in parallel.

[0013] The HPCI module contains three sub-modules: the HPCI interface layer, the shared memory implementation layer, and the hardware-related implementation layer.

[0014] The HPCI interface layer is a message passing interface module based on packet switching.

[0015] A shared memory implementation layer, used to provide an HPCI interface based on shared memory;

[0016] The hardware-related implementation layer is used to implement hardware-related operations, including memory addressing, format conversion, mutual exclusion access, and handling interrupts during the process.

[0017] (III) Beneficial Effects

[0018] This invention proposes a parallel operation method for a system architecture based on heterogeneous multi-core inter-core communication. Utilizing a heterogeneous processor system management framework based on global objects and HPCI, this invention supports the parallel execution of different operating system replicas on heterogeneous processor cores. Each heterogeneous processor core can execute tasks independently and perform collaborative processing through HPCI. The number of operating system replicas can be easily expanded according to the number of heterogeneous processor cores, fully utilizing hardware resources and allowing the operating system to fully utilize its assigned core, thereby improving overall execution efficiency and achieving true parallel processing.

[0019] This invention achieves efficient inter-core communication between heterogeneous processors through HPCI, ensuring the correctness and reliability of the communication. On one hand, through synchronization processing, the master node and other nodes can coordinate and synchronize to ensure that all nodes have a clear view of the shared space. Figure 1On the one hand, by ensuring consistency, thread synchronization is maintained; on the other hand, by locking the communication queue in shared memory, mutual exclusion is achieved, avoiding access conflicts that may occur when multiple copies access the resource simultaneously. The locking mechanism ensures that only one copy can operate on the shared resource at a time, thus guaranteeing correct parallel operation. Attached Figure Description

[0020] Figure 1 This is a structural diagram of the heterogeneous multi-core processor support system of the present invention;

[0021] Figure 2 This is a flowchart of the system's workflow;

[0022] Figure 3 Storage organization diagram for the shared area;

[0023] Figure 4 Flowchart for initializing shared memory. Detailed Implementation

[0024] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0025] To address the aforementioned problems in existing technologies, this invention provides a heterogeneous multi-core processor framework based on global objects and a heterogeneous processor communication interface (HPCI) layer to achieve parallel operation of heterogeneous multi-core processors. In this invention, the operating system does not impose any limit on the number of heterogeneous processor cores, using the number of heterogeneous processor cores as a system configuration parameter, which can be configured according to specific hardware, thereby supporting the expansion of heterogeneous multi-core processors. Through HPCI, a message passing mechanism between heterogeneous multi-core processors is logically defined, enabling efficient communication between heterogeneous cores, supporting collaborative work between heterogeneous cores, and achieving true parallel processing. Locking the communication queues in shared memory within HPCI ensures mutual exclusion access to the queues, avoiding access conflicts. By implementing parallel processing of heterogeneous processors through HPCI, the full utilization of heterogeneous hardware resources is achieved, improving execution speed and efficiency.

[0026] To achieve the above objectives, this invention provides a parallel operation method based on a heterogeneous multi-core inter-core communication system architecture, which makes full use of heterogeneous hardware resources to work together and achieve true parallel operation.

[0027] In this invention, each heterogeneous processor core has an independent copy of the operating system, and a heterogeneous processor system management framework based on global objects and HPCI are provided for synchronization and communication between operating systems. The number of heterogeneous processor cores is a system configuration parameter that can be set according to the specific hardware configuration.

[0028] The overall architecture diagram of the system operating system supporting this heterogeneous multi-core inter-core communication and parallel operation architecture is as follows: Figure 1 As shown, the modules that directly support this architecture are:

[0029] (1) System service component module, which uses API to support multi-core mode and complete kernel resource management;

[0030] (2) HPCI module, used to implement communication between multiple cores running in parallel.

[0031] The HPCI module is not directly provided to application developers as an application API. Instead, it is used in the implementation of system resource APIs related to multi-core communication. It adds a multi-core communication branch to the implementation and handles operations such as system resource allocation. This part of the API implementation is called a system service component. This allows users to focus on application development without needing to understand the specific mechanisms of multi-core communication. The HPCI module contains three sub-modules:

[0032] (1) HPCI interface layer, mainly based on packet switching message passing interface module;

[0033] (2) Shared memory implementation layer, providing HPCI interface based on shared memory;

[0034] (3) Hardware-related implementation layer, which mainly involves the implementation of hardware-related operations such as memory addressing, format conversion, mutual exclusion access, and interrupts during processing.

[0035] 1. System Service Component Module

[0036] The system service component provides application-oriented system resource management, including task management, inter-task synchronization and communication, memory management, interrupts, time, and I / O management. In heterogeneous processors, objects are divided into local objects and global objects. Accessing local objects is exactly the same as in a single-processor scenario, directly calling functions provided by the local kernel to complete operations; however, the settings for global objects are for communication between heterogeneous processors, and accessing global objects requires calling the interface of the heterogeneous processor support layer to complete interaction with remote tasks. The implementation of the system service component requires support from the operating system's basic kernel.

[0037] 2. HPCI Interface Layer

[0038] The HPCI module provides a set of general interfaces for application-layer API implementations, logically defining a message passing mechanism between heterogeneous processor cores. This mechanism includes: a set of message packet processing routine interfaces and message packet receiving / sending logic. The message packet processing routine interfaces are called by the system when preparing and issuing remote requests. The entry point of the routines must be registered in the heterogeneous processor communication interface table, as shown in Table 1.

[0039] Table 1 HPCI Routine

[0040] HPCI_table->initialization Initialize HPCI HPCI_table->get_packet Get Packet Buffer HPCI_table->return_packet Return (release) the packet buffer HPCI_table->send_packet Send packets to another node HPCI_table->receive_packet Get the arriving package

[0041] The message packet processing routine interface is called by the system when preparing and issuing remote requests. HPCI maintains a buffer pool to implement the message packet receiving / sending logic. Each unit in the buffer pool is called a packet, and the packet buffer contains messages passed between nodes.

[0042] 3. System Workflow

[0043] The system's workflow is as follows Figure 2 As shown:

[0044] S11. The Application Programming Interface (API) requests access to global objects on heterogeneous processor cores through system service components.

[0045] S12. The operating system determines the processor core (hereinafter referred to as the remote core) where the global object resides;

[0046] S13. The processor core requesting the global object (hereinafter referred to as the local core) uses the routine get_packet provided by the HPCI interface layer to request a packet, uses send_packet to send a notification to the remote core, and stores the packet in the specified location of shared memory. The task of the local core requesting resources is blocked and waits until timeout or the resource is obtained.

[0047] S14. The remote core learns of the multi-core communication request through an interrupt. The interrupt handler releases the semaphore to make the multi-core processing service task ready to run. In this task, the routine receive_packet provided by the HPCI interface layer is called to receive the information packet sent from the shared memory.

[0048] S15. After the remote core parses the information packet, it calls a system service to make a resource request. If the request is successful, it releases the requested global object resources. If it fails, it returns an error code and uses the send_packet routine provided by the HPCI interface layer to send the information packet to the local core through shared memory.

[0049] S16. The HPCI layer on the local core learns about multi-core communication through interrupts and receives and parses information packets to obtain information on whether the resource request was successful or failed. It then calls system services to prepare the suspended task and completes the subsequent resource acquisition operation on the local core or returns the corresponding error code. This completes an interaction with a task on the remote core.

[0050] 4. Shared memory implementation layer

[0051] Shared memory is the physical foundation for packet switching. The shared memory implementation layer is the functional basis for the communication semantics of the HPCI interface layer; it stores node state control information, communication control information, and communication entities (CEs). The logical organization of the shared area is as follows: Figure 3 As shown, it includes: a node state control block, a communication queue control block (CQCB), and a CE control block. The node state control block stores the shared state information of the node, the communication queue control block (CQCB) stores the communication state information, and the CE control block stores message packets from the HPCI interface layer. When message packets formed at the HPCI interface layer enter shared memory, they are encapsulated into CE control blocks, which are managed by the CE controller in the form of a linked list. The formed linked list consists of multiple communication queues based on the sending and receiving needs of each core. Each core, as a node, stores and manages its own shared state in the node state control block.

[0052] Based on the above shared storage organization method, the semantics of the packet processing routines defined by the HPCI layer are implemented using shared queues. The corresponding implementation routines and HPCI interfaces are shown in Table 2.

[0053] Table 2 Comparison of Shared Queue Routines and HPCI Interface

[0054]

[0055]

[0056] As shown in Table 2, packet sending and receiving are essentially read and write operations on the relevant communication queues and communication queue control blocks in the shared memory area. Acquiring a CE and sending and receiving data packets are all operations performed in the allocated queues after completion in the shared memory area, and almost never involve other heterogeneous processor cores.

[0057] The initialization of the shared memory area is asymmetric. One node (selected as the master node, CPU0 in this system) is responsible for initializing the main data structures of the shared memory. Shared memory initialization occurs after bridge configuration, HPCI kernel structure initialization, and the creation and startup of the Remote Communication Service (RCS) thread. Shared memory initialization is accomplished by calling the initialization function `sharemem_initialization` registered in HPCI. The shared memory initialization process is as follows: Figure 4 As shown.

[0058] During shared memory initialization, the master node (cpu0) and other nodes synchronize to ensure that all nodes have a consistent view of the shared space before proceeding with subsequent processing. During shared memory initialization, the master node is responsible for initializing the main data structures of the shared memory, while other nodes initialize their own local information control blocks. After the local information control blocks of each node are initialized, synchronization is performed. Each node sends system messages to other nodes, containing global information such as the maximum number of communicable nodes and the maximum number of global objects. After receiving system messages from other nodes via interrupts between heterogeneous processor cores, each node's RCS is activated, and the system message handling function registered in the previous steps is called for processing. If the received global information is found to be inconsistent with the information possessed by the node, an error is reported, and the node exits or resets. This is the first communication between heterogeneous multi-core processor cores before starting user tasks, and this communication verifies whether the system's heterogeneous processor core communication mechanism is functioning correctly.

[0059] 5. Hardware-related implementation layer

[0060] In HPCI, hardware-related operations primarily involve shared memory. Heterogeneous processors communicate with each other through shared memory, and inter-core interrupts provide a means of synchronization. The implementation of the heterogeneous processor interrupt mechanism involves many aspects, including shared memory address mapping and interrupt configuration, queue lock implementation, and the implementation of inter-core interrupt triggering and handling functions.

[0061] The address mapping and interrupt configuration of shared memory are completed during system initialization, mainly by defining the base address and length of shared memory, configuring the interrupt information table, and installing interrupt trigger functions.

[0062] When using communication queues in shared memory for communication, to avoid errors caused by access conflicts, it is essential to ensure mutual exclusion access to the same queue by each node. Mutual exclusion can be achieved by locking the queues. The basic method is as follows: A lock is set for each queue in the queue control block. When an application needs to access a queue, it must first acquire the lock. If the lock is held by another task, it waits until the lock is released. Only after acquiring and locking the queue can the application perform operations on it. After the operation is completed, the lock is released.

[0063] Interrupt handling requires the design and implementation of interrupt trigger functions (sharemem_cause_int) and interrupt handler functions (sharemem_isr) for inter-core interrupts from heterogeneous processors. Specifically:

[0064] Interrupt trigger function:

[0065] A segment of I / O space is defined, and each node is assigned an address and a specific value of a specified length (i.e., the content defined in the interrupt information table) within this space. When communication occurs between nodes, the node sending the request packet only needs to write the specific value corresponding to the target node into the corresponding memory unit within this space to generate an external interrupt on the target node. Therefore, the interrupt trigger function is configured to: query the interrupt information table, obtain the interrupt address and interrupt value of the target node, and write the interrupt value into the interrupt address to trigger an inter-core interrupt in the heterogeneous processor.

[0066] Interrupt handler:

[0067] When an external interrupt occurs from a remote node, the main task of the interrupt handler is to wake up the Remote Communication Server (RCS) task. When the RCS task is initially created, a system semaphore (HPCI_sem) is defined to indicate the scheduling timing of the RCS. Initially, the semaphore is 0, and the RCS is blocked on this semaphore. When a remote message packet arrives, the interrupt handler releases the semaphore, allowing the RCS to capture it and gain control (while simultaneously decrementing the semaphore by 1). Then, the RCS receives the message packet and calls the corresponding processing function according to the message type. This process repeats until the semaphore becomes 0 again, at which point the RCS returns to sleep. The main functions of the interrupt handler are: releasing the semaphore to wake up the RCS and clearing the interrupt bit.

[0068] This invention proposes a parallel operation method for a system architecture based on heterogeneous multi-core inter-core communication. A separate operating system copy is deployed on each heterogeneous processor core, and the number of heterogeneous processor cores is unlimited. The heterogeneous processor cores communicate with each other through the heterogeneous processor system framework and HPCI, thereby supporting true parallel operation of heterogeneous processors. It can maximize parallel work on heterogeneous platforms and thus improve the resource utilization efficiency of heterogeneous platforms.

[0069] The HPCI module designed in this invention defines a message passing mechanism between heterogeneous processor cores through message packet processing routine interfaces and message packet receiving / sending logic. The HPCI maintains a buffer pool and implements message packet receiving / sending logic, effectively realizing communication between heterogeneous processor cores and successfully supporting the parallel operation of heterogeneous processors.

[0070] Initializing shared data is a challenge in shared memory design, involving the consistency of views of the shared memory area across heterogeneous processors. This invention employs an asymmetric initialization method: the master node is responsible for initializing the main data structures of the shared memory, while other nodes maintain their own information control blocks. Synchronization between the master node and other nodes ensures that all nodes have a consistent view of the shared space. Figure 1 To the point of being responsive.

[0071] In the CQCB within shared memory, a lock is set for each queue. When accessing a queue, the lock is used to protect it. By locking the queue, mutual exclusion access is achieved, avoiding access conflicts and ensuring the correct parallel operation of multiple operating system copies.

[0072] The beneficial effects of this invention are:

[0073] This invention utilizes a global object-based heterogeneous processor system management framework and HPCI to support the parallel execution of different operating system replicas on heterogeneous processor cores. Each heterogeneous processor core can execute tasks independently and perform collaborative processing through HPCI. Operating system replicas can be easily expanded based on the number of heterogeneous processor cores, fully utilizing hardware resources and allowing the operating system to fully leverage its assigned core, thereby improving overall execution efficiency and achieving true parallel processing.

[0074] This invention achieves efficient inter-core communication between heterogeneous processors through HPCI, ensuring the correctness and reliability of the communication. On one hand, through synchronization processing, the master node and other nodes can coordinate and synchronize to ensure that all nodes have a clear view of the shared space. Figure 1 On the one hand, by ensuring consistency, thread synchronization is maintained; on the other hand, by locking the communication queue in shared memory, mutual exclusion is achieved, avoiding access conflicts that may occur when multiple copies access the resource simultaneously. The locking mechanism ensures that only one copy can operate on the shared resource at a time, thus guaranteeing correct parallel operation.

[0075] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for parallel operation of a system architecture based on heterogeneous multi-core inter-core communication, characterized in that, Each heterogeneous processor core in this system architecture has an independent copy of the operating system. The system architecture includes: a system service component module and an HPCI module. The system service component module uses APIs to support multi-core mode and manage kernel resources. The HPCI module is used to implement communication between multiple cores running in parallel. The HPCI module contains three sub-modules: the HPCI interface layer, the shared memory implementation layer, and the hardware-related implementation layer. The HPCI interface layer is a message passing interface module based on packet switching. A shared memory implementation layer, used to provide an HPCI interface based on shared memory; The hardware-related implementation layer is used to implement hardware-related operations, including memory addressing, format conversion, mutual exclusion access, and interrupt handling. in, The HPCI module provides a set of general interfaces for application layer API implementations, logically defining a message passing mechanism between heterogeneous processor cores. This mechanism includes: a set of message packet processing routine interfaces and message packet receiving / sending logic. The message packet processing routine interfaces are called by the system when preparing and issuing remote requests. The entry point of the routines must be registered in the heterogeneous processor communication interface table. HPCI maintains a buffer pool to implement the message packet receiving / sending logic. Each unit in the buffer pool is called a packet, and the packet buffer contains messages passed between nodes. The shared memory implementation layer is the functional foundation for the communication semantics implementation of the HPCI interface layer. It stores node state control information, communication control information, and communication entities (CEs). The shared memory area includes: a node state control block, a communication queue control block, and a CE control block. The node state control block stores the shared state information of the node, the communication queue control block (CQCB) stores the communication state information, and the CE control block stores message packets of the HPCI interface layer. When a message packet formed in the HPCI interface layer enters the shared memory, it is encapsulated into a CE control block. The CE controller manages it in the form of a linked list. The linked list forms multiple communication queues according to the sending and receiving needs of each core. Each core stores and manages its own shared state in the node state control block as a node. In HPCI, hardware-related operations involve shared memory. Heterogeneous processors communicate with each other through shared memory. Inter-core interrupts provide a means of synchronization between heterogeneous processors, including shared memory address mapping and interrupt configuration, queue lock implementation, and implementation of inter-core interrupt triggering and handling functions.

2. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 1, characterized in that, The system service component provides application-oriented system resource management, including task management, synchronization and communication between tasks, memory management, interrupts, time and I / O management. In heterogeneous processors, objects are divided into local objects and global objects. Accessing local objects is exactly the same as in the single-processor case, directly calling the functions provided by the local kernel to complete the operation. The settings of global objects are for communication between heterogeneous processors. Accessing global objects requires calling the interface of the heterogeneous processor support layer to complete the interaction with remote tasks. The implementation of the system service component requires the support of the operating system's basic kernel.

3. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 2, characterized in that, The method includes: S11. The Application Programming Interface (API) requests access to global objects on heterogeneous processor cores through system service components. S12. The operating system determines the processor core in which the global object resides, hereinafter referred to as the remote core; S13. The local kernel requesting a global object uses the get_packet routine provided by the HPCI interface layer to request a packet, uses send_packet to send a notification to the remote kernel, and stores the packet in a specified location in shared memory. The task of the local kernel requesting the resource is blocked and waits until timeout or the resource is obtained. S14. The remote core learns of the multi-core communication request through an interrupt. The interrupt handler releases the semaphore to make the multi-core processing service task ready to run. In this task, the routine receive_packet provided by the HPCI interface layer is called to receive the information packet sent from the shared memory. S15. After the remote core parses the information packet, it calls a system service to make a resource request. If the request is successful, it releases the requested global object resources. If it fails, it returns an error code and uses the send_packet routine provided by the HPCI interface layer to send the information packet to the local core through shared memory. S16. The HPCI layer on the local core learns about multi-core communication through interrupts and receives and parses information packets to obtain information on whether the resource request was successful or failed. It then calls system services to prepare the suspended task and completes the subsequent resource acquisition operation on the local core or returns the corresponding error code; thus completing an interaction with the task on the remote core.

4. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 3, characterized in that, The initialization of the shared memory area is asymmetric. One master node is responsible for initializing the main data structures of the shared memory. The initialization of the shared memory is performed after the bridge chip configuration, HPCI kernel structure initialization, and the creation and startup of the remote communication service thread RCS. The initialization of the shared memory is accomplished by calling the initialization function sharedmem_initialization registered in HPCI.

5. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 4, characterized in that, During shared memory initialization, the master node and other nodes synchronize to ensure that all nodes have a consistent view of the shared space before proceeding with subsequent processing. During shared memory initialization, the master node is responsible for initializing the main data structures of the shared memory, while other nodes initialize their own local information control blocks. After the local information control blocks of each node are initialized, synchronization is performed, and each node sends system messages to other nodes. These system messages contain the maximum number of communicable nodes and the maximum global object information for that node. After each node is notified of receiving system messages from other nodes via interrupts between heterogeneous processor cores, its RCS is activated, and the system message handling function registered in the previous steps is called for processing. If the received global information is found to be inconsistent with the information possessed by the node, an error is reported, and the node exits or resets. This is the first communication between heterogeneous multi-core processor cores before starting user tasks, and this communication is used to verify whether the system's heterogeneous processor core communication mechanism is functioning correctly.

6. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 1, characterized in that, The address mapping and interrupt configuration of shared memory are completed during system initialization, including: defining the base address and length of shared memory, configuring the interrupt information table, and installing interrupt trigger functions. When using communication queues in shared memory for communication, it is necessary to ensure mutual exclusion access to the same queue by each node. Mutual exclusion access can be achieved by locking the queue. The basic method is as follows: set a lock word for each queue in the queue control block. When an application needs to access a queue, it must first acquire the lock of that queue. If the lock is occupied by other tasks, it waits until the lock is released. Only after acquiring and locking the lock can the queue be operated on. After the operation is completed, the lock is released.

7. The parallel operation method of the system architecture based on heterogeneous multi-core inter-core communication as described in claim 1, characterized in that, The interrupt trigger function design includes: Define a space in the I / O space, and assign an address and a specific value of a specified length to each node in this space. When communication is sent between nodes, the node sending the request packet only needs to write the specific value corresponding to the target node into the corresponding memory unit in this space to generate an external interrupt on the target node. Therefore, the interrupt trigger function is set to: query the interrupt information table, obtain the interrupt address and interrupt value of the target node, and write the interrupt value into the interrupt address to trigger an inter-core interrupt of the heterogeneous processor. Interrupt handler: When an external interrupt occurs from a remote node, the main task of the interrupt handler is to wake up the Remote Communication Server (RCS) task. When the RCS task is initially created, a system semaphore is defined to indicate the scheduling timing of the RCS. Initially, the semaphore is 0, and the RCS is blocked on this semaphore. When a remote message packet arrives, the interrupt handler releases the semaphore, allowing the RCS to capture the semaphore and thus gain control. At the same time, the semaphore is decremented by 1. Then, the RCS receives the message packet and calls the corresponding processing function according to the message type. This process is repeated until the semaphore becomes 0 again, at which point the RCS returns to the sleep state. The interrupt handler's functions are: release the semaphore to wake up the RCS, and clear the interrupt bit.

Images