Inter-core communication method and multi-core chip control system

Abstract

The embodiment of the application discloses a method for inter-core communication and a multi-core chip control system. The method is applied to the multi-core chip control system, the multi-core chip control system comprises a data carrying device and at least two running heterogeneous processing cores; the data carrying device comprises at least one pair of one-way channels for bidirectional data transmission, and the method comprises the following steps: a sender stores data into an applied sending buffer; when the channel is idle, a channel source address is configured as the address of the sending buffer, the data length of the channel is configured, and the channel is triggered to transmit data; when a transmission completion interrupt initiated by the data carrying device is listened to, the sender releases the sending buffer; and a receiver stores a receiving buffer into a receiving queue to be read and applies a new receiving buffer when it is determined that the buffer can be applied. Through the method, the inter-core communication efficiency is improved, and the problem of CPU resource occupation caused by the inter-core communication is solved.

Description

Technical Field

[0001] This application relates to the field of power electronic control, and in particular to inter-core communication methods and multi-core chip control systems. Background Technology

[0002] With the development of semiconductor technology and industry, the variety of control chips available is becoming increasingly diverse. The industry has gradually shifted from early, mature applications of DSP (Digital Signal Processor Controller) controllers to MCUs (Microcontroller Units) with ARM (Advanced RISC Machines) cores. Now, ARM-based MCUs and more complex heterogeneous SoC (System-on-a-Chip) systems are becoming increasingly mature, exhibiting stronger performance and greater on-chip resources. The use of these emerging technologies and chips in the power electronics industry demonstrates high technological value.

[0003] When two heterogeneous processing cores interact within a heterogeneous SoC, the most common approach is shared memory. This shared memory approach allocates corresponding buffer spaces in the two heterogeneous systems. Each system accesses the other's buffer to send data and simultaneously reads its local buffer to receive data. Event notifications are sent via Inter-Processor Interrupt (IPI) interrupts, completing the data exchange. However, this shared memory approach has several drawbacks. Firstly, it relies heavily on CPU access, with the CPU performing memory-to-memory copying for data exchange, consuming significant CPU resources. Secondly, shared memory often implies a lack of complete memory isolation between the two systems (both access each other's buffer spaces). If one system experiences an abnormal dangling pointer access, it can cause the other system to malfunction, leading to amplified faults, impacting system stability, and ultimately reducing communication efficiency. Summary of the Invention

[0004] This application provides an inter-core communication method and a multi-core chip control system, which can improve the efficiency of inter-core communication and solve the problem of CPU resource consumption caused by inter-core communication.

[0005] In a first aspect, embodiments of this application provide an inter-core communication method applied to a multi-core chip control system. The multi-core chip control system includes a data transfer device and at least two processing cores running heterogeneous systems. In any pair of processing cores running heterogeneous systems, the processing core sending data is the sender, and the processing core receiving data is the receiver. The data transfer device includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores. Each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions. The method includes: In response to the inter-core data transmission instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be sent into the requested transmission buffer. When the sender's target dedicated channel in its transmission direction is idle, it configures the source address of the target dedicated channel as the address of the transmission buffer and configures the data length of the target dedicated channel, triggering the transmission of the target data through the target dedicated channel; the target address of the target dedicated channel is pre-configured by the receiver as the address of the receive buffer. When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer. When the receiver detects the interrupt and determines that there is an available buffer in its memory pool, it stores the receive buffer in its receive queue for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer.

[0006] Secondly, embodiments of this application also provide a multi-core chip control system, including a data transfer device, a memory, and at least two processing cores. The memory stores a driver program, and the processing cores execute the driver program to implement the above-described method.

[0007] This application provides an inter-core communication method and a multi-core chip control system. On one hand, in this solution, the sender independently completes the entire process of requesting a transmit buffer, filling data, configuring the unidirectional channel source address and transmission length, triggering transmission, and releasing the transmit buffer after transmission completion. On the other hand, the receiver independently completes the entire process of pre-configuring the receive buffer, enqueuing the receive queue after receiving a transmission completion interrupt, requesting a new receive buffer, and updating the channel target address. Furthermore, this application uses an interrupt initiated by a data transfer device as a message notification means for data transmission completion between the sender and receiver. Therefore, in this application embodiment, when the sender and receiver perform inter-core communication, both parties only need to process their own... The resource and channel configuration logic completely avoids the conflict risk caused by dual-core concurrent access to shared resources from the operational logic level, improving system stability and thus enhancing communication efficiency. On the other hand, through the inter-core communication scheme provided in this application, the CPU does not need to manually move data. Based on instructions, the data moving device moves data between processing cores through a dedicated channel, freeing the CPU from the heavy and simple data moving work, thereby solving the problem of CPU resource occupation by inter-core communication. Furthermore, the scheme provided in this application uses the interrupt initiated by the data moving device as a message notification means for the completion of data transmission between the sender and receiver, simplifying the timing design of both parties. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A schematic diagram of the driver architecture for the processing core provided in an embodiment of this application; Figure 2 A schematic diagram of the driver layering model of the processing core provided in the embodiments of this application; Figure 3 A flowchart illustrating the inter-core communication method provided in an embodiment of this application; Figure 4 A specific timing diagram of the interaction of channel 1 provided in the embodiments of this application; Figure 5 A schematic block diagram of a multi-core chip control system provided in an embodiment of this application; Figure 6 A schematic block diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. The user personal information involved in the embodiments of this application is obtained by an entity authorized (with the knowledge and consent) or fully authorized by all parties through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0012] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0013] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0014] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0015] With the development of semiconductor technology and industry, the variety of control chips available is becoming increasingly diverse. The industry has gradually shifted from early, mature applications of DSP (Digital Signal Processor) controllers to MCUs (Microcontroller Units) with ARM (Advanced RISC Machines) cores. Now, ARM-based MCUs and more complex heterogeneous SoC (System-on-a-Chip) systems are becoming increasingly mature, exhibiting stronger performance and greater on-chip resources. The use of these emerging technologies and chips in the power electronics industry has demonstrated significant technological value.

[0016] When two heterogeneous processing cores interact within a heterogeneous SoC, the most common approach is shared memory. This shared memory approach allocates corresponding buffer spaces in the two heterogeneous systems. Each system accesses the other's buffer to send data and simultaneously reads its local buffer to receive data. Event notifications are sent via Inter-Processor Interrupt (IPI) interrupts, completing the data exchange. The shared memory region is a physical memory area accessible to all heterogeneous processing cores. This shared memory region needs to be mapped into the address spaces of both heterogeneous processing cores. As an example, the shared memory region can be structured as a circular buffer or a double-buffered array, containing metadata such as head and tail pointers.

[0017] The problems with this scheme of sharing memory between two heterogeneous systems are as follows: Firstly, shared memory is primarily accessed by the CPU. The CPU performs memory-to-memory copying for data exchange, which consumes a certain amount of CPU resources.

[0018] Secondly, shared memory often indicates that there is no complete memory isolation between the two systems (both need to access the buffer space of the other side). Once an abnormal wild pointer access occurs in one system, it may cause the other system to also be abnormal, thereby amplifying the fault, affecting system stability, and reducing communication efficiency.

[0019] Thirdly, the timing design of shared memory schemes is more complex. It is necessary to strictly avoid situations where two CPUs access the same variable at the same time (such as switching the index of the buffer). Atomic operations or internal spin locks are needed to ensure the independence and integrity of shared resources.

[0020] To address the aforementioned issues, this application provides an inter-core communication method applied to a multi-core chip control system. The multi-core chip control system includes a data transfer device and at least two processing cores running heterogeneous systems. In any pair of processing cores running heterogeneous systems, the processing core sending data is the sender, and the processing core receiving data is the receiver. The data transfer device includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores. Each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions. The data transfer device uses preset dedicated channels to transmit round-trip data between the processing cores, designating the processing core that needs to send data as the sender and the processing core that needs to receive data as the receiver.

[0021] Heterogeneous systems are systems with different operating systems, such as Linux (a UNIX-like operating system) or RTOS (Real-Time Operating System). In one scenario, the inter-core communication method described above can be applied to two processing cores running heterogeneous systems, where one processing core runs Linux and the other runs an RTOS.

[0022] In a multi-core chip control system, any one of the components can be both a sender and a receiver. We use the generalized definition of "sender" and "receiver" to represent any component currently transmitting data. A component that is a data sender at the current time point may become a data receiver at the next time point. Similarly, a component that is a data receiver at the current time point may become a data sender at the next time point.

[0023] The party with data transmission needs at the current time point is the sender. When any one of the heterogeneous processing cores (at least two processing cores running heterogeneous systems) issues a data transmission command, a preset data transfer device can be triggered to transfer the sender's target data to the receiver. Unlike existing technologies, this embodiment uses a separate data transfer device to transfer the target data, transmitting it through a channel to the receiver's buffer.

[0024] The data transfer device operates independently of the processing cores and is specifically designed to transfer interactive data between the two processing cores. The data transfer device can be of the traditional DMA (Direct Memory Access), RDMA (Remote Direct Memory Access), or P2P DMA (Peer-to-Peer DMA), etc. This application does not limit the specific hardware implementation type of the data transfer device. Their common goal is to break down memory and I / O walls, allowing data to be transferred with maximum efficiency.

[0025] As an example, let's consider DMA as a data transfer mechanism. DMA is a hardware mechanism in computer systems that allows certain hardware subsystems to directly read and write to system memory without central processing unit (CPU) intervention. This frees the CPU from tedious, simple data transfer tasks, allowing it to focus on computation and control. This significantly improves system performance. The CPU is no longer blocked by low-speed I / O operations and can execute other tasks in parallel, significantly increasing the overall system throughput and efficiency. This differs from the problems of shared memory solutions where two cores in a heterogeneous SoC run independently of the heterogeneous system. Shared memory is primarily accessed by the CPU, which performs memory-to-memory copying for data exchange, consuming CPU resources.

[0026] A data transfer device typically has multiple data channels, each with its own independent and complete control register. This application requires at least two DMA channels for data exchange, with the two channels corresponding to two different data flow directions. Two unidirectional dedicated channels transmit round-trip data between two heterogeneous processing cores, with the processing core that needs to send data acting as the sender and the processing core that needs to receive data acting as the receiver.

[0027] Each processing core has its own data transfer driver layer, application layer, and message driver layer. The message driver layer is used to interface the data sending and receiving between the application layer and the data transfer driver layer; the data transfer driver layer is used to interact with the data transfer device and drive the data transfer device to transfer data; the data transfer driver layer is also used to listen for interrupts for its respective processing core, and is also used to allocate or release buffers, including send buffers and receive buffers.

[0028] In a specific scenario, the transport driver layer can be called the DMA driver layer, and the message driver layer can be called the MSG driver layer. The DMA driver layer provides an intermediate layer for interaction between each MSG channel in the MSG driver layer and the DMA hardware (data transport device). The MSG driver layer receives message requests from the user in user space (application layer), passes the send request to the DMA driver layer, and the message transceiver layer in the DMA driver layer requests a consistency buffer from the DMA memory pool in the DMA driver layer to store the send message. When the buffer cannot be stored, it can block the MSG driver layer and the application layer in reverse to prevent the application layer from sending messages without limit, which could lead to memory overflow.

[0029] Specifically, DMA hardware includes a DMA controller circuit integrated into the multi-core chip control system, which performs the actual data transfer operations. The DMA hardware includes a DMA controller, which is integrated into the chip and manages the transfer process. The DMA driver layer is a software module in the processing core, responsible for configuring and managing the DMA controller, including setting the source address, destination address, channel status, and transfer length of the DMA transfer channel, and handling interrupts after the DMA transfer is completed.

[0030] The DMA driver layer and MSG driver layer are designed in a layered manner. By adapting to the differences in DMA peripherals of different multi-core chip control systems, these differences are controlled within the DMA driver layer, achieving functional encapsulation of the DMA channel to adapt to different DMA hardware architectures. DMA channel encapsulation involves abstracting a unified interface to the upper layer. Communication with the MSG message layer is achieved through a unified interface, enabling functional design reuse.

[0031] For example, a channel is called an MSG channel, and the DMA driver layer provides an intermediary layer for interaction between each MSG channel and the DMA hardware. An MSG channel is a set of software protocols and API abstractions built on top of DMA. When transmitting messages, the MSG channel calls the DMA driver layer to move data, rather than copying it to the CPU.

[0032] like Figure 1The diagram shows the core driver architecture. Inter-core communication drivers include the MSG driver layer and the DMA driver layer. The hardware outside the inter-core communication drivers is the DMA hardware layer. MSG_CHN is the message channel; RECV indicates receive, Send indicates send, and CTRL indicates control. TX indicates transmit, and RX indicates receive. DMA_Access indicates the DMA controller's access permissions and access methods to system memory, mainly including access permissions (which memory regions the DMA controller can access), access methods (how to access memory), access granularity (what unit to use for access), and access order (address increment or decrement). DAM_MEMPOOL is a pre-allocated memory pool containing a certain number of fixed-size memory blocks. Using a memory pool can reduce memory fragmentation, improve memory allocation and release efficiency, and ensure that memory can still be allocated under memory pressure. ioremap_area refers to a memory-mapped region created by the kernel function ioremap(). This memory-mapped region maps the device's physical address to the kernel's virtual address space, allowing drivers to access and control hardware devices by reading and writing to this virtual address. ioremap_area is obtained by configuring the MMU (Memory Management Unit), a component in computer hardware, usually integrated inside the CPU. The core responsibility of the MMU is to manage system memory access, implement the translation from virtual addresses to physical addresses, and provide memory protection mechanisms.

[0033] In this embodiment, absolute memory isolation is achieved through MMU configuration. For example, on the RTOS side, the memory attributes and access attributes of the relevant memory space in Linux are set to reserved memory. This way, when the RTOS accidentally manipulates the Linux address space, the MMU will throw an exception and prevent memory access. By introducing a virtual address layer as an intermediary, the MMU prevents a program from easily writing into the memory areas of other programs or even the operating system, thus avoiding system crashes. Achieving absolute memory isolation through MMU configuration solves the problems of poor security and programs being able to corrupt each other.

[0034] like Figure 2The diagram illustrates a layered driver model for the core processing layer, including the application layer, MSG driver layer, and DMA driver layer. The process is encapsulated layer by layer, from application layer system calls to the MSG driver layer and finally to the DMA driver layer. SysCommProc is the system communication processing module, responsible for communication between the application and the kernel, such as the system application layer communication interface. `open()` opens a device or file. `read()` reads data from a device or file. `write()` writes data to a device or file. `close()` closes a device or file. `MsgCh_request()` requests a message channel, `MsgCh_recv()` receives a message, `MsgCh_send()` sends a message, `MsgCh_free()` releases message channel resources, and `MsgCh_kick()` triggers or activates a message channel.

[0035] Taking the sending of data from the Linux kernel (running the Linux operating system) to the RTOS kernel (running the RTOS operating system) as an example, the Linux kernel's application layer calls the `msgCh_send()` API of the MSG driver layer. The MSG driver layer moves the target data from the sending Linux kernel to the receiving RTOS buffer via the DMA driver. The MSG driver layer handles the user-space data transmission and reception and interfaces with the DMA driver layer. When the application layer opens the device using `open()`, it needs to notify the DMA driver layer to prepare the receive buffer for message reception, so that it can be read later via the `read()` interface. When the application layer closes the device using `close()`, it needs to notify the DMA driver layer to promptly finish sending any remaining data in the buffer and unregister the buffer waiting to receive, thus releasing resources.

[0036] Data is sent by calling the DMA driver layer, which uses its blocking mechanism to counteract the application layer's write operations. Message reception uses a counting semaphore to block the application layer's loop read operations, and releases the semaphore via a notification from the DMA driver layer, allowing the application layer to read the data; no additional logic is required.

[0037] Figure 3 This is a flowchart illustrating the inter-core communication method provided in an embodiment of this application. Figure 3 As shown, the method includes the following steps S110-S140: Step S110: In response to the inter-core data transmission instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be sent into the requested transmission buffer.

[0038] The sending direction refers to the direction from the sender to the receiver.

[0039] Taking two cores running Linux and RTOS respectively as an example, the data transfer device is configured with at least two unidirectional dedicated channels. CH1 (channel 1) can be used to send data from the Linux core to the RTOS core, and the data flows from the Linux buffer to the RTOS buffer. CH2 (channel 2) is the opposite, used by the RTOS core to send data from the Linux core to the Linux core, and the data flows from the RTOS buffer to the Linux buffer.

[0040] Taking sending data from the Linux kernel to the RTOS kernel as an example, the Linux kernel is the sender and the RTOS kernel is the receiver. Channel 1, or CH1, is the dedicated target channel for the Linux kernel's transmission direction, pointing from the Linux kernel to the RTOS kernel. In this case, the Linux buffer can be used as the sender's transmit buffer, and the RTOS buffer can be used as the receiver's receive buffer.

[0041] In DMA data transfer scenarios, the DMA driver layer must prepare a batch of free buffers in advance and hand them over to the DMA controller so that the DMA hardware can immediately store the data into memory when it arrives. For example, the Linux kernel's DMA driver layer can request a send buffer for the target data from the corresponding memory pool.

[0042] In one embodiment, step S110 may include steps S1101-S1102: Step S1101: In response to the inter-core data transfer instruction, the sender determines whether there is a free buffer in the corresponding memory pool, wherein the free buffer represents a buffer that can be used by the data transfer device.

[0043] The sender's local memory pool can pre-allocate a dedicated send buffer for the data transfer device. This send buffer, which does not store data, can be referred to as the sender's free buffer. Similarly, the receiver's local memory pool can pre-allocate a dedicated receive buffer for the data transfer device. This receive buffer, which does not store data, can be referred to as the receiver's free buffer.

[0044] In response to an inter-core data transfer command, the sender first checks if a free send buffer exists. In one embodiment, this application uses a memory pool counting mechanism to make the available resources of the memory pool transparent, filling the gap in existing technologies where the memory pool of the processing kernel lacks a counting mechanism. For example, the Linux kernel's DMA memory pool does not have a counting mechanism. This application sets a counting semaphore on the sending Linux side, using a semaphore to constrain the upper limit of memory allocation, thus preventing the kernel from crashing due to unlimited memory pool allocation. During driver initialization, the semaphore is initialized with the queue length.

[0045] Step S1101 includes steps A1-A3: A1. In response to the inter-core data transmission instruction, the sender determines whether the counting semaphore on the sender side is 0, wherein the counting semaphore on the sender side represents the number of free buffers in the corresponding memory pool that can be used by the data transfer device.

[0046] A2. If the counting semaphore is not 0, then it is determined that the free buffer exists in the corresponding memory pool.

[0047] A3. If the counting semaphore is 0, then it is determined that there is no free buffer in the corresponding memory pool.

[0048] The counting semaphore on the Linux kernel side represents the number of free buffers available for data transfer devices in the Linux memory pool. The presence of free buffers in the Linux memory pool is determined by whether the counting semaphore is zero. If the counting semaphore is not zero, it indicates the presence of free buffers in the Linux memory pool; if the counting semaphore is zero, it indicates the absence of free buffers.

[0049] Similarly, the counting semaphore on the RTOS kernel side represents the number of free buffers in the RTOS memory pool available for data transport devices.

[0050] The counting semaphore is decremented by 1 after a buffer is allocated in the memory pool, and incremented by 1 after the buffer is released from the memory pool.

[0051] In one embodiment, each processing core sequentially deploys its own application layer, message-driven layer, and transport-driven layer. The transport-driven layer of the sender can respond to the inter-core data transmission command issued by the message-driven layer by determining whether there is a free buffer in the corresponding memory pool based on whether the counter semaphore on the sender side is 0. Specifically, if the counter semaphore is not 0, it is determined that there is a free buffer in the corresponding memory pool; if the counter semaphore is 0, it is determined that there is no free buffer in the corresponding memory pool. The message-driven layer can receive message transmission requests sent by users from the application layer, thereby generating inter-core data transmission commands.

[0052] Step S1102: If it is determined that the corresponding memory pool has the free buffer, the sender requests the sending buffer from the corresponding memory pool and stores the target data to be sent into the requested sending buffer.

[0053] A buffer can only be requested if a free buffer exists in the memory pool. After determining that a free buffer exists, a free buffer is requested from the Linux memory pool as a send buffer, and the target data that the Linux kernel is preparing to send is stored in the requested send buffer.

[0054] In one embodiment, each processing core sequentially deploys its own application layer, message-driven layer, and data transfer-driven layer, wherein the message-driven layer is used to interface data transmission and reception between the application layer and the data transfer-driven layer; after step S1101, the above inter-core communication method further includes: If it is determined that the corresponding memory pool does not have the free buffer, then the sender's transport driver layer blocks the sender's message driver layer's data transmission request.

[0055] Specifically, when there is no free buffer in the corresponding memory pool, it indicates that there is no extra space for data transmission. Therefore, the data transmission behavior of the sender's message-driven layer is temporarily blocked to prevent the message-driven layer from sending data.

[0056] As can be seen, this solution can avoid data loss or buffer overflow caused by the message-driven layer sending data too quickly and the message-driven layer not having a free buffer to store the data sent by the message-driven layer.

[0057] At this time, when the subsequent sending party's transport driver layer detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, in addition to releasing the sending buffer, it will also notify the sending party's message driver layer to restore the sending party's message driver layer's permission to request data transmission.

[0058] In one embodiment, after step S110, steps B1-B3 are included: Step B1: If the sender's target dedicated channel in its transmission direction is not idle, the sender stores the transmission buffer containing the target data into the sender's transmission queue.

[0059] In this step, the dedicated channel of the processing core may be in an idle or non-idle state. When the sender's dedicated channel is not idle, it means that the channel is being used, and the send buffer containing the target data needs to be pushed into the send queue to temporarily store the data. For example, when the Linux kernel determines that DMA channel 1 is sending, it fills the Linux send buffer containing the target message into the Linux send queue.

[0060] Step B2: When the sender's target dedicated channel in its transmission direction becomes idle, it retrieves a message data from the sender's transmission queue, uses the message data as the target data, and continues execution from the step of configuring the source address of the target dedicated channel as the address of the transmission buffer.

[0061] In this step, when the sender's target dedicated channel becomes idle, the first message data enqueued from the sending queue is taken as the target data. Then, the address of the sending buffer where the target data is located is configured as the source address of the target dedicated channel, and the ready flag of the target dedicated channel is set to trigger the target dedicated channel to transmit the target data.

[0062] Step B3: When the sender's sending queue is not empty, clear the current interrupt flag and return to the step of retrieving a message data from the sender's sending queue to continue execution until the sender's sending queue is empty.

[0063] In this step, if the sender's sending queue is not empty, it means that there is still message data to be sent in the sender's sending queue. At this time, a message data is taken out from the sending queue as the target data, and the address of the sending buffer where the target data is located is configured as the source address of the target dedicated channel. The ready flag of the target dedicated channel is set to trigger the target dedicated channel to transmit the target data until the sender's sending queue is empty.

[0064] Step B4: If the sender's send queue is empty, clear the current interrupt flag.

[0065] In this step, when all data in the sending queue has been sent and is empty, the current interrupt flag is cleared. By clearing the current interrupt flag, the sender can return to a state where it can receive new interrupts. If the current interrupt flag is not cleared, the sender will assume that the current interrupt is still being processed, thus blocking or ignoring subsequent interrupt requests from the data transfer device, resulting in the loss of subsequent interrupts.

[0066] Step S120: When the sender's target dedicated channel in its transmission direction is idle, the sender configures the source address of the target dedicated channel as the address of the transmission buffer, configures the data length of the target dedicated channel, and triggers the target dedicated channel to transmit the target data; the target address of the target dedicated channel is pre-configured by the receiver as the address of the receive buffer.

[0067] In this context, if a channel is not currently transmitting data and is not in use, it is considered idle. If a channel is currently transmitting data and is in use, it is considered active. When a dedicated channel is idle, since the target address of the dedicated channel is pre-configured as the address of the receive buffer by the receiver, as long as one party has data to transmit, only the source address and data length need to be filled in to trigger the data transfer device to start data transfer. Specifically, triggering the transmission of the target data through the dedicated channel may include setting the ready flag of the dedicated channel to trigger the transmission of the target data.

[0068] Before inter-core communication begins, for example after device startup, each processing core can request a receive buffer for its corresponding dedicated channel (the channel used when the processing core acts as the receiver) and configure the target address of that dedicated channel as the address of the receive buffer. During inter-core communication, when the processing core acts as the receiver, it will update the target address based on the data reception status, which will be explained in detail in subsequent steps.

[0069] Specifically, for channel 1, the address of the Linux kernel's send buffer is filled into the source address of channel 1, the data length of the channel is configured, and the ready flag of channel 1 is set to trigger channel 1 to start transmitting data. Channel 1 has a source address and a destination address, which represent the source and destination of the data, respectively. The source address is the location where the data is to be read. In this application, the source address is the address of the send buffer, and the destination address is the address of the buffer where the data is to be written, i.e., the address of the receiver's receive buffer. This destination address has been pre-configured by the receiver. Each time channel 1 transmits data, it only needs to fill in the source address and the data length to trigger data transfer.

[0070] like Figure 4 This is the specific timing diagram of the interaction in Channel 1 (DMA CH1). For Channel 1, the sender SEND is a Linux kernel, and the receiver RECV is an RTOS kernel.

[0071] The Linux kernel acts as the sender, and the RTOS kernel as the receiver, transmitting data through channel 1. The Linux kernel sets the source address for channel 1, and the RTOS kernel sets the destination address for channel 1. Then, channel 1 is enabled for transmission. After transmission is complete, the data transfer device sends an interrupt signal. The Linux kernel releases the send buffer address, prepares a new send buffer to set the source address SrcAddr, and sets DMA enable (Set [DmaEn]). The RTOS kernel prepares the receive buffer address RxAddr and sets the destination address DstAddr again.

[0072] Before communication is established, both parties need to agree on a maximum data packet length (the transport length of the data transport device). Sufficient buffer space should be pre-allocated based on this size, ideally using a memory pool mechanism to quickly switch the receive buffer during interruptions. After preparing the receive buffer, both parties configure the target address for their respective channels. At this point, both parties are ready to receive data. Whenever one party has data to send, it only needs to fill in the source address and data length, and trigger the data transport device to begin data transport.

[0073] After a data transfer is completed, the data transfer device generates an interrupt indicating the completion of the data transfer. At this point, the DMA driver layers of both cores need to simultaneously listen for this interrupt event. Once the interrupt is triggered, the receiver needs to quickly update its target address to prepare for the sender's next transmission. Simultaneously, the buffer containing the stored data is filled into the receive queue, awaiting reading by the application layer. For the sender, the interrupt trigger means that a data packet has been successfully transmitted. At this point, resources for the transmitted data packet are released, and the send queue is checked for any new data packets to be sent. If data is available, transmission continues.

[0074] The timing design of existing shared memory solutions is more complex. It's crucial to strictly prevent two heterogeneous system cores from simultaneously accessing the same variable, such as switching buffer indexes. Atomic operations or internal spinlocks are needed to ensure the independence and integrity of shared resources. Shared memory not only needs to monitor whether its own shared memory is being modified by another system, but also whether the other system is reading it while it's modifying it. Mutual exclusion is required to protect shared resources. Implementing mutual exclusion between heterogeneous systems is slightly more complex, requiring inter-core interrupts to notify each other, refresh state, and ensure timing to avoid access conflicts.

[0075] Unlike the complex timing designs of existing technologies, this application's DMA-accelerated inter-core communication method effectively addresses the shortcomings of complex timing designs in existing technologies. Utilizing the idle channels of the data transfer device frees up CPU resources. Furthermore, due to hardware DMA data transfer, direct CPU-to-CPU access is no longer necessary, and absolute memory isolation can be achieved through Memory Management Unit (MMU) configuration, ensuring system reliability. The core responsibility of the MMU is to manage system memory access, translate virtual addresses to physical addresses, and provide memory protection mechanisms. In this embodiment, absolute memory isolation is achieved through MMU configuration by setting the memory attributes and access attributes of the relevant memory space of the Linux kernel to reserved memory on the RTOS kernel side. Thus, when the RTOS kernel mistakenly manipulates the Linux address space, the MMU throws an exception and blocks memory access. By introducing a virtual address as an intermediate layer, the MMU prevents a program from easily writing into the memory areas of other programs or even the operating system, leading to system crashes. Achieving absolute memory isolation through MMU configuration solves the problems of poor security and programs being able to corrupt each other.

[0076] Simultaneously, utilizing the completion interrupt of the data transfer device as a message notification method simplifies the timing design for both parties. By using the completion interrupt of the data transfer device as a message notification method, after receiving the interrupt, both parties maintain their respective send / receive queues and update their corresponding DMA configurations (source and destination addresses of the corresponding channels), eliminating concerns about resource access conflicts.

[0077] When developing and implementing the DMA driver layer, corresponding DMA channels need to be bound in the Linux device tree for inter-core interaction. Each message node requires at least two DMA channels to complete bidirectional send and receive communication. Similarly, corresponding DMA channels need to be bound in the RTOS device tree for inter-core interaction.

[0078] As an example, a reserved memory segment with the attribute "shared-dma-pool" is reserved in the device trees of both Linux and RTOS for the DMA driver layer, to be used as the memory pool for the DMA driver; alternatively, the consistent memory of CMA (Contiguous Memory Allocator) can be directly used as the driver's memory pool. CMA is specifically designed for allocating large blocks of contiguous physical memory, making it particularly suitable for applications requiring physically contiguous memory, such as DMA, multimedia processing, and GPU buffers. This prevents RTOS / bare-metal programs from accessing the Linux address space, avoiding abnormal access. Linux, by default, cannot access this address space before it is mapped, thus ensuring isolation between the two systems.

[0079] As an example, conversely, if the RTOS kernel needs to send data to the Linux kernel, in response to the inter-kernel data transfer instruction sent by the RTOS kernel's message-driven layer, the RTOS kernel's DMA driver layer configures the source address of the RTOS kernel's dedicated channel as the RTOS buffer address.

[0080] The DMA driver layer will use the sender's dedicated channel to transfer the sender's target data from the source address to the target address, thereby transferring the target data from the sender's buffer to the receiver's buffer.

[0081] In particular, a DMA controller typically has multiple data channels, and each channel has its own independent and complete control registers (destination address, source address, data length, channel enable, and channel status).

[0082] In some embodiments, the DMA controller typically has more than two channels; it can provide multiple completely independent channels for connecting two heterogeneous systems. For example, an 8-channel DMA controller can form four pairs of dedicated channels for data transmission and reception, which can meet applications such as multi-channel concurrency and data isolation between channels.

[0083] Step S130: When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer.

[0084] The two processing cores each monitor for interrupt events that occur upon completion of data transmission. When a data transfer device completes a data transmission, it generates an interrupt indicating that the transmission is finished. Both cores simultaneously monitor this interrupt event. Once an interrupt is triggered, for the sender, it means that a data packet has been successfully transmitted. At this point, resources for the transmitted data packet are released, the transmission buffer is released, and the sender's counter semaphore is incremented by 1.

[0085] Meanwhile, the sender can check if there are any new data packets to be sent in the sending queue. If there is data to be sent, it will trigger to continue sending by updating the source address of the channel and the data length, until all the data in the sending queue is sent and the queue is empty.

[0086] For the receiver, it needs to quickly update its target address to meet the sender's next transmission, and at the same time fill the buffer containing the stored data into the receive queue, waiting to be read.

[0087] Step S140: When the receiver detects the interrupt and determines that there is an available buffer in the receiver's memory pool, it stores the receiving buffer in the receiver's receiving queue for later reading, requests a new receiving buffer, and updates the target address of the target dedicated channel to the address of the new receiving buffer.

[0088] As mentioned above, after the sender requests a transmission buffer for the target data, it decrements the sender's counter semaphore by 1. After the sender releases the transmission buffer, it increments the sender's counter semaphore by 1.

[0089] Correspondingly, the receiver has a similar design for the counting semaphore. When the receiver requests a new receive buffer, the counting semaphore on the receiver side is decremented by 1, and when the receiver releases the receive buffer, the counting semaphore on the receiver side is incremented by 1.

[0090] In one embodiment, step S140 includes steps S1401-S1403: Step S1401: When the receiver detects the interrupt, if the counting semaphore on the receiver side is not 0, it determines that there are available buffers in the receiver's memory pool. Here, the counting semaphore on the receiver side represents the number of free buffers in the corresponding memory pool that can be used by the data transfer device, and the initial value of the counting semaphore on the receiver side is equal to the length of the receiver's receive queue.

[0091] When the data transmission device completes transmission, it initiates an interrupt. The sender and receiver listen for interrupts. When the receiver detects an interrupt, if there is an available buffer in the receiver's memory pool, it indicates that the current memory conditions can support the next reception, meaning there is a new receive buffer to update the channel's target address. At this point, the receive buffer is stored in the receiver's receive queue to await data reading.

[0092] This application utilizes the completion interrupt of the data transfer device as a message notification method. After receiving the interrupt, both parties maintain their respective send / receive queues and update their corresponding DMA configurations, eliminating concerns about resource access conflicts. Existing shared memory methods not only require monitoring whether one's shared memory is being modified by the other, but also whether the other is reading it while one is modifying it. Mutual exclusion is needed to protect shared resources. Mutual exclusion between heterogeneous systems is achieved through inter-core interrupts for back-and-forth notification and state updates, requiring precise timing to avoid access conflicts. Since this application uses a data transfer device to move data, CPUs no longer need direct access; absolute memory isolation can be achieved through MMU configuration, ensuring system reliability. Furthermore, using the DMA completion interrupt as a message notification method simplifies timing design for both parties and accelerates inter-core communication efficiency using DMA hardware peripherals.

[0093] When the receiver detects the interrupt, it determines whether the receiver's counting semaphore is 0.

[0094] If the receiver's counter semaphore is not 0, it indicates that the receiver's transport driver layer can request a receive buffer. At this point, the receiver's transport driver layer pushes the currently received message into the queue and notifies the receiver's message driver layer to drive the corresponding application layer to read the data. However, the receive buffer is not released immediately. Only after the application layer has finished reading the message will the receiver release the receive buffer back to the memory pool for use in the next DMA data reception. Subsequently, the receiver's transport driver layer requests a new receive buffer from the DMA memory pool and sets the ready flag.

[0095] If the receiver's count semaphore is 0, it indicates that there is no buffer available for allocation. Therefore, it is determined that the receiver's memory pool does not have a buffer available for allocation, and no memory pool buffer allocation is performed. The ready flag is not set; instead, the queue blocking flag is set. Queue blocking indicates that a message failed to be received during the interrupt due to insufficient buffer space. Because there is no extra buffer available for the DMA driver layer to receive new messages, it exits directly. At this point, the MSG driver layer and application layer can be blocked in reverse to prevent the application layer from sending messages without limit, which could lead to memory overflow. After the MSG driver layer reads a message, the DMA driver layer releases the receive memory, increments the count semaphore, and stores the receive buffer containing unreceived data into the receiver's receive queue for later reading.

[0096] Two processing cores monitor interrupt events that occur upon data transmission completion. When the sender's transport driver layer receives a transmission completion interrupt, it releases the corresponding send buffer. Simultaneously, the receiver's transport driver layer adds the receiver buffer to the receiver's receive queue for the receiver's application layer to read. When the sender's send queue is empty, it clears the interrupt flag and waits for the next interrupt. When the sender's send queue is not empty, it retrieves a message from the send queue, configures the source address of the sender's dedicated channel to the address of the retrieved message's send buffer and configures the data length, sets the ready flag of the dedicated channel to trigger data transmission through the dedicated channel until the queue is empty.

[0097] Step S1402: Store the receiving buffer in the receiving queue of the receiver for later reading, request a new receiving buffer, update the target address of the target dedicated channel to the address of the new receiving buffer, and decrement the counting semaphore on the receiver side by 1.

[0098] Step S1403: When a message data is read from the receiver's receive queue, the receive buffer is released and the receiver's count semaphore is incremented by 1.

[0099] In this process, the receiving application layer reads a message from the receiving queue, and the receiving transport driver layer can release the receiving buffer. At this time, since the counting semaphore is released, leaving one space in the receiving buffer, the counting semaphore on the receiving side is incremented by 1.

[0100] In one embodiment, the method further includes: When the receiver detects the interrupt, if the counting semaphore on the receiver side is 0, it is determined that the receiver's memory pool does not have an available buffer. The operation of storing the receive buffer into the receiver's receive queue is blocked until a message data is read from the receiver's receive queue. Then, the receive buffer containing the unreceived data is stored into the receiver's receive queue for later reading.

[0101] Specifically, when the receiving party's transport driver layer detects an interrupt, the transport driver layer needs to determine whether the receiving party's counting semaphore is 0. When the receiving party's counting semaphore is 0, it means that there is no available buffer in the receiving party's memory pool. At this time, the transport driver layer needs to block the operation of storing the receiving buffer into the receiving party's receiving queue and set the queue blocking flag of the receiving queue until the message data in the receiving queue is read by the application layer, the queue blocking flag is cleared, and then the receiving buffer containing the unreceived data is stored into the receiving party's receiving queue.

[0102] The following describes the inter-core communication method of this application from the perspective of the recipient: When the receiver in the transport driver layer receives an interrupt, it first checks whether there is a free buffer in the memory pool (i.e., whether the counting semaphore is 0). If there is no free buffer, it sets the receive queue to block and clears the interrupt flag. If there is a free buffer, the transport driver layer puts the receive buffer containing the corresponding message into the receive queue and notifies the message driver layer that a message has entered the receive queue. The application layer reads the message in the receive queue. Then, it requests a new receive buffer, increments the counting semaphore on the receiver side by 1, and updates the new receive buffer to the target address of the corresponding dedicated channel.

[0103] When a message in the receive queue is read, the corresponding buffer is released and the counter semaphore on the receiver side is incremented by 1. At this time, if the receive queue is currently in a blocked state, the receiver's transport driver layer will store the receive buffer containing the unreceived data into the receive queue for later reading.

[0104] The following describes the inter-core communication method of this application from the perspective of the sender: When the sending party's transport driver layer receives a message from the sending party's message driver layer, it first checks whether there is a free buffer in the sending party's memory pool (whether the sending party's counter semaphore is 0). If there is no free buffer, the sending behavior of the message driver layer is blocked. If there is a free buffer, a sending buffer is allocated for the currently sent message, and the message to be sent is saved to the sending buffer, and the counter semaphore is decremented by 1. Then, it checks whether the dedicated channel corresponding to the sending party is sending a message (i.e., whether it is idle). If it is sending a message, the sending buffer is added to the sending party's sending queue. If it is not sending a message, the address of the sending buffer is set to the source address of the dedicated channel, and the ready flag of the dedicated channel is set to trigger the transmission of data through the dedicated channel.

[0105] When the sending party's transport driver layer receives an interrupt initiated by the data transport device, it releases the transmit buffer and increments the counter semaphore. At this time, if the message driver layer is blocked, it restores the sender's message driver layer's permission to request data transmission. Then, it checks whether the sender's transmit queue is empty. If it is empty, it clears the current interrupt flag. If it is not empty, it retrieves a message data from the transmit queue, sets the address of the transmit buffer storing the message data to the source address of the dedicated channel, sets the ready flag of the dedicated channel, and clears the current interrupt flag.

[0106] This application provides an inter-core communication method and a multi-core chip control system. The inter-core communication method is applied to a multi-core chip control system, which includes a data transfer device and at least two processing cores running heterogeneous systems. In any pair of processing cores running heterogeneous systems, the processing core sending data is the sender, and the processing core receiving data is the receiver. The data transfer device includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores. Each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions. In this scheme, the sender independently completes the entire process of requesting a transmission buffer, filling data, configuring the unidirectional channel source address and transmission length, triggering transmission, and releasing the transmission buffer after transmission completion. The receiver independently completes the entire process of pre-configuring the receive buffer, enqueuing the receive queue after receiving a transmission completion interruption, requesting a new receive buffer, and updating the channel target address. Furthermore, this application embodiment... The present application utilizes an interrupt initiated by a data transfer device as a notification method for the completion of data transmission between the sender and receiver. Therefore, in this embodiment, when the sender and receiver communicate between cores, both sides only need to process their own resource and channel configuration logic. This completely avoids the conflict risk caused by concurrent access to shared resources by dual cores at the operational logic level, improving system stability and thus enhancing communication efficiency. Furthermore, with the solution provided in this application, the CPU does not need to manually transfer data. Based on instructions, the data transfer device transfers data between processing cores through a dedicated channel, freeing the CPU from the tedious and simple data transfer work, thereby solving the problem of CPU resource consumption during inter-core communication. Finally, the solution provides that the use of an interrupt initiated by a data transfer device as a notification method for the completion of data transmission between the sender and receiver simplifies the timing design for both parties.

[0107] Figure 5 This is a schematic block diagram of a multi-core chip control system provided in an embodiment of this application. Figure 5 As shown, corresponding to the above inter-core communication method, this application also provides a multi-core chip control system 500. The inter-core communication method is applied to the multi-core chip control system, which includes a data transfer device 501 and at least two processing cores running heterogeneous systems; in any pair of processing cores running heterogeneous systems, the processing core that sends data is the sender 502, and the processing core that receives data is the receiver 503; the data transfer device 501 includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores, and each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions.

[0108] Please see Figure 5 The multi-core chip control system 500 includes a data transfer device 501, a transmitter 502, and a receiver 503, wherein: The sender 502 is used to respond to the inter-core data transfer instruction, request a send buffer from the corresponding memory pool, and store the target data to be sent into the requested send buffer; The sender 502 is further configured to, when the target dedicated channel to which it is sent is idle, configure the source address of the target dedicated channel as the address of the sending buffer, configure the data length of the target dedicated channel, and trigger the target dedicated channel to transmit the target data; the target address of the target dedicated channel is pre-configured by the receiver 503 as the address of the receiving buffer; The sender 502 is also configured to release the sending buffer when it detects an interrupt initiated by the data transport device 501 that indicates the completion of the target data transmission; Receive 503 is configured to, when the interrupt is detected and it is determined that there is an available buffer in the memory pool of Receive 503, store the receive buffer in the receive queue of Receive 503 for later reading, request a new receive buffer, and update the target address of the target dedicated channel to the address of the new receive buffer.

[0109] In some embodiments, the sender 502, in response to an inter-core data transfer instruction, requests a send buffer from the corresponding memory pool and stores the target data to be sent into the requested send buffer, specifically for: In response to an inter-core data transfer instruction, it is determined whether there is a free buffer in the corresponding memory pool, wherein the free buffer represents a buffer that can be used by the data transfer device 501; If it is determined that the corresponding memory pool has the free buffer, the sender 502 requests the sending buffer from the corresponding memory pool and stores the target data to be sent into the requested sending buffer.

[0110] In some embodiments, each processing core sequentially deploys its own application layer, message-driven layer, and data transfer-driven layer. The message-driven layer is used to interface for data transmission and reception between the application layer and the data transfer-driven layer. The sender 502 is further used for: If it is determined that the corresponding memory pool does not have the free buffer, then the transport driver layer of the sender 502 blocks the data transmission request of the message driver layer of the sender 502; At this time, when the sender 502 performs the step of releasing the transmission buffer upon detecting an interrupt initiated by the data transport device 501 indicating the completion of the target data transmission, it specifically performs the following: When the data transfer driver layer of the sender 502 detects an interrupt initiated by the data transfer device 501 that indicates the completion of the target data transmission, it releases the transmission buffer and notifies the message driver layer of the sender 502 to restore the message driver layer of the sender 502's permission to request data transmission.

[0111] In some embodiments, when the sender 502 performs the step of determining whether there is a free buffer in the corresponding memory pool in response to the inter-core data transfer instruction, it is specifically used to: In response to an inter-core data transfer instruction, it is determined whether the counting semaphore on the sender 502 side is 0, wherein the counting semaphore on the sender 502 side represents the number of free buffers in the corresponding memory pool that can be used by the data transfer device 501. If the counting semaphore is not 0, then it is determined that the free buffer exists in the corresponding memory pool; If the counting semaphore is 0, it is determined that there is no free buffer in the corresponding memory pool.

[0112] In some embodiments, in response to an inter-core data transfer instruction, the sender 502 requests a transmission buffer from the corresponding memory pool, stores the target data to be transmitted into the requested transmission buffer, and then decrements the counter semaphore on the sender 502 side by 1. At this time, when the sender 502 detects the interrupt initiated by the data transport device 501 that indicates the completion of the target data transmission, after releasing the transmission buffer, it will also increment the counting semaphore on the sender 502 side by 1.

[0113] In some embodiments, when the receiver 503 detects the interrupt and determines that there is an available buffer in its memory pool, it stores the receive buffer in the receive queue of the receiver 503 for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer. Specifically, this is used for: When the interrupt is detected, if the counting semaphore on the receiving side 503 is not 0, it is determined that there is an available buffer in the memory pool of the receiving side 503. The counting semaphore on the receiving side 503 represents the number of free buffers in the corresponding memory pool that can be used by the data transport device 501. The initial value of the counting semaphore on the receiving side 503 is equal to the length of the receiving queue of the receiving side 503. The receiving buffer is stored in the receiving queue of the receiving 503 for later reading, and a new receiving buffer is requested. The target address of the target dedicated channel is updated to the address of the new receiving buffer, and the counting signal on the receiving 503 side is decremented by 1. When a message data is read from the receive queue of the receiver 503, the receive buffer is released and the count semaphore on the receiver 503 side is incremented by 1.

[0114] In some embodiments, the receiving 503 is further configured to: When the interrupt is detected, if the counting semaphore on the receiving 503 side is 0, it is determined that there is no available buffer in the memory pool of the receiving 503. The operation of storing the receive buffer into the receive queue of the receive 503 is blocked until a message data is read from the receive queue of the receive 503. Then, the receive buffer containing the unreceived data is stored into the receive queue of the receive 503 for reading.

[0115] In some embodiments, after responding to an inter-core data transfer instruction, the sender 502 requests a transmission buffer from the corresponding memory pool and stores the target data to be transmitted into the requested transmission buffer, the sender 502 is further configured to: If the dedicated channel to the target is not idle, the transmission buffer containing the target data is stored in the transmission queue of the sender 502. If the target dedicated channel to which the sender 502 is directed becomes idle, a message data is taken from the sending queue of the sender 502, and the message data is used as the target data. The step of configuring the source address of the target dedicated channel as the address of the sending buffer continues. If the sending queue of the sender 502 is not empty, clear the current interrupt flag and return to the step of retrieving a message data from the sending queue of the sender 502 to continue execution until the sending queue of the sender 502 is empty. If the sender 502's send queue is empty, then the current interrupt flag is cleared.

[0116] This application provides an inter-core communication method and a multi-core chip control system. The inter-core communication method is applied to a multi-core chip control system, which includes a data transfer device 501 and at least two processing cores running heterogeneous systems. In any pair of processing cores running heterogeneous systems, the processing core sending data is the sender 502, and the processing core receiving data is the receiver 503. The data transfer device 501 includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores. Each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions. In this scheme, the sender 502 independently completes the entire process of requesting a transmission buffer, filling data, configuring the unidirectional channel source address and transmission length, triggering transmission, and releasing the transmission buffer after transmission. The receiver 503 independently completes the entire process of pre-configuring the receiver buffer, enqueuing the receiver queue after receiving a transmission completion interruption, requesting a new receiver buffer, and updating the channel target address. The embodiment utilizes an interrupt initiated by the data transfer device 501 as a message notification means for the completion of data transmission between the sender and receiver. It is evident that, in this embodiment, when the sender and receiver perform inter-core communication, both sides only need to process their own resource and channel configuration logic, completely avoiding the conflict risk caused by concurrent access to shared resources by dual cores at the operational logic level, improving system stability, and thus enhancing communication efficiency. Furthermore, through the inter-core communication solution provided in this application, the CPU does not need to manually transfer data. Based on instructions, the data transfer device 501 transfers data between processing cores through a dedicated channel, freeing the CPU from the heavy and simple data transfer work, thereby solving the problem of CPU resource occupation during inter-core communication. Moreover, the solution provided in this application utilizes an interrupt initiated by the data transfer device 501 as a message notification means for the completion of data transmission between the sender and receiver, simplifying the timing design of both parties.

[0117] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned multi-core chip control system and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0118] The aforementioned multi-core chip control system can be implemented as a driver program, which can be used in, for example... Figure 6 It runs on the computer device shown.

[0119] Please see Figure 6 , Figure 6This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 600 can be a terminal or a server. The terminal can be an electronic computer device with communication functions, such as a smartphone, tablet, laptop, desktop computer, personal digital assistant, or wearable computer device. The server can be a standalone server or a server cluster composed of multiple servers.

[0120] The computer device 600 is equipped with a multi-core chip control system, which includes a data transfer device and at least two processing cores running heterogeneous systems. In any pair of processing cores running heterogeneous systems, the processing core that sends data is the sender, and the processing core that receives data is the receiver. The data transfer device includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores, and each pair of dedicated channels includes two unidirectional channels with fixed and opposite directions.

[0121] See Figure 6 The computer device 600 includes a processor 602, a memory, and a network interface 605 connected via a system bus 601. The memory may include a non-volatile storage medium 603 and internal memory 604.

[0122] The non-volatile storage medium 603 may store an operating system 6031 and a driver 6032. The driver 6032 includes program instructions that, when executed, cause the processor 602 to perform inter-core communication.

[0123] The processor 602 provides computing and control capabilities to support the operation of the entire computer device 600.

[0124] The internal memory 604 provides an environment for the operation of the driver 6032 in the non-volatile storage medium 603. When the driver 6032 is executed by the processor 602, it enables the processor 602 to perform an inter-core communication.

[0125] This network interface 605 is used for network communication with other computer devices. Those skilled in the art will understand that... Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 600 to which the present application is applied. The specific computer device 600 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0126] The processor 602 is used to run the driver 6032 stored in memory to perform the following steps: In response to the inter-core data transmission instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be sent into the requested transmission buffer. When the sender's target dedicated channel in its transmission direction is idle, it configures the source address of the target dedicated channel as the address of the transmission buffer and configures the data length of the target dedicated channel, triggering the transmission of the target data through the target dedicated channel; the target address of the target dedicated channel is pre-configured by the receiver as the address of the receive buffer. When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer. When the receiver detects the interrupt and determines that there is an available buffer in its memory pool, it stores the receive buffer in its receive queue for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer.

[0127] It should be understood that in the embodiments of this application, the processor 602 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0128] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a driver instructing related hardware. The driver includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0129] Therefore, this application also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a driver, wherein the driver includes program instructions. When executed by a processor, the program instructions cause the processor to perform the following steps: In response to the inter-core data transmission instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be sent into the requested transmission buffer. When the sender's target dedicated channel in its transmission direction is idle, it configures the source address of the target dedicated channel as the address of the transmission buffer and configures the data length of the target dedicated channel, triggering the transmission of the target data through the target dedicated channel; the target address of the target dedicated channel is pre-configured by the receiver as the address of the receive buffer. When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer. When the receiver detects the interrupt and determines that there is an available buffer in its memory pool, it stores the receive buffer in its receive queue for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer.

[0130] The storage medium can be any computer-readable storage medium that can store program code, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0131] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0133] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0134] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network computer device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0135] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for inter-core communication, characterized in that, An application is made to a multi-core chip control system, the multi-core chip control system including a data transfer device and at least two processing cores running heterogeneous systems; in any pair of processing cores running heterogeneous systems, the processing core that sends data is the sender, and the processing core that receives data is the receiver; the data transfer device includes at least one pair of dedicated channels for bidirectional data transmission between the pair of processing cores, each pair of dedicated channels including two unidirectional channels with fixed and opposite directions, the method including: In response to the inter-core data transmission instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be sent into the requested transmission buffer. When the sender's target dedicated channel in its transmission direction is idle, it configures the source address of the target dedicated channel as the address of the transmission buffer and configures the data length of the target dedicated channel, triggering the transmission of the target data through the target dedicated channel; the target address of the target dedicated channel is pre-configured by the receiver as the address of the receive buffer. When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer. When the receiver detects the interrupt and determines that there is an available buffer in its memory pool, it stores the receive buffer in its receive queue for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer.

2. The method according to claim 1, characterized in that, The sender, in response to the inter-core data transfer instruction, requests a send buffer from the corresponding memory pool and stores the target data to be sent into the requested send buffer, including: In response to the inter-core data transfer instruction, the sender determines whether there is a free buffer in the corresponding memory pool, wherein the free buffer represents a buffer that can be used by the data transfer device; If it is determined that the corresponding memory pool has the free buffer, the sender requests the sending buffer from the corresponding memory pool and stores the target data to be sent into the requested sending buffer.

3. The method according to claim 2, characterized in that, Each processing core sequentially deploys its own application layer, message-driven layer, and data transfer-driven layer. The message-driven layer is used to interface for data transmission and reception between the application layer and the data transfer-driven layer. The method further includes: If it is determined that the corresponding memory pool does not have the free buffer, then the sender's transport driver layer blocks the sender's message driver layer's data transmission request; When the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer, including: When the sending party's transport driver layer detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, it releases the transmission buffer and notifies the sending party's message driver layer to restore the sending party's message driver layer's permission to request data transmission.

4. The method according to claim 2, characterized in that, The sender, in response to the inter-core data transfer instruction, determines whether there is a free buffer in the corresponding memory pool, including: In response to the inter-core data transmission command, the sender determines whether the counting semaphore on the sender side is 0, wherein the counting semaphore on the sender side represents the number of free buffers in the corresponding memory pool that can be used by the data transfer device. If the counting semaphore is not 0, then it is determined that the free buffer exists in the corresponding memory pool; If the counting semaphore is 0, it is determined that there is no free buffer in the corresponding memory pool.

5. The method according to claim 4, characterized in that, In response to an inter-core data transfer instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be transmitted into the requested transmission buffer. The method further includes: Decrement the counting signal quantity on the transmitting side by 1; After the sender detects an interrupt initiated by the data transport device that indicates the completion of the target data transmission, and releases the transmission buffer, the method further includes: Increment the counting signal on the sending side by 1.

6. The method according to claim 1, characterized in that, When the receiver detects the interrupt and determines that its memory pool has an available buffer, it stores the receive buffer in its receive queue for later reading, requests a new receive buffer, and updates the target address of the target dedicated channel to the address of the new receive buffer, including: When the receiver detects the interrupt, if the counting semaphore on the receiver side is not 0, it determines that there is an available buffer in the receiver's memory pool. The counting semaphore on the receiver side represents the number of free buffers in the corresponding memory pool that can be used by the data transfer device. The initial value of the counting semaphore on the receiver side is equal to the length of the receiver's receiving queue. The receiving buffer is stored in the receiving queue of the receiver for later reading, and a new receiving buffer is requested. The target address of the target dedicated channel is updated to the address of the new receiving buffer, and the counting semaphore on the receiver side is decremented by 1. When a message is read from the receiver's receive queue, the receive buffer is released, and the receiver's counter semaphore is incremented by 1.

7. The method according to claim 6, characterized in that, The method further includes: When the receiver detects the interrupt, if the counting semaphore on the receiver side is 0, it is determined that the receiver's memory pool does not have an available buffer. The operation of storing the receive buffer into the receiver's receive queue is blocked until a message data is read from the receiver's receive queue. Then, the receive buffer containing the unreceived data is stored into the receiver's receive queue for later reading.

8. The method according to claim 1, characterized in that, In response to an inter-core data transfer instruction, the sender requests a transmission buffer from the corresponding memory pool and stores the target data to be transmitted into the requested transmission buffer. The method further includes: When the sender's dedicated channel for the target in its transmission direction is not idle, the sender stores the transmission buffer containing the target data into the sender's transmission queue. When the sender's target dedicated channel in its sending direction becomes idle, it retrieves a message data from the sender's sending queue, uses the message data as the target data, and continues to execute the step of configuring the source address of the target dedicated channel as the address of the sending buffer; If the sender's sending queue is not empty, clear the current interrupt flag and return to the step of retrieving a message data from the sender's sending queue to continue execution until the sender's sending queue is empty. If the sender's send queue is empty, then the current interrupt flag is cleared.

9. The method according to any one of claims 1 to 8, characterized in that, Each processing core is sequentially deployed with its own application layer, message-driven layer, and data transfer-driven layer. The message-driven layer is used to connect the data sending and receiving between the application layer and the data transfer-driven layer. The data transfer-driven layer is used to interact with the data transfer device and drive the data transfer device to transfer data. The data transfer-driven layer is also used to listen for interrupts for its respective processing core and to apply for or release buffers, including send buffers and receive buffers.

10. A multi-core chip control system, characterized in that, It includes a data transport device, a memory, and at least two processing cores, wherein the memory stores a driver, and the processing cores execute the driver to implement the steps of the inter-core communication method according to any one of claims 1 to 9.

Images