Heterogeneous multi-core system, method of operating the same, electronic device, and medium
By packaging real-time and non-real-time core programs of heterogeneous multi-core systems into a unified program package and utilizing shared memory areas for version detection and data verification, the problems of version inconsistency and complex data exchange in heterogeneous multi-core processors are solved, achieving efficient program management and system stability.
Patent Information
- Application Number
- CN202511678149.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-17
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2045-11-17
AI Technical Summary
In heterogeneous multi-core processors, real-time cores and non-real-time cores run different operating systems, making data exchange complex and inefficient. Program updates require separate maintenance, which can easily lead to version inconsistencies and system instability. Traditional data exchange methods have high system overhead, complex program loading processes, and difficulty in ensuring synchronization.
Real-time and non-real-time kernel programs are packaged into a unified program package. Version detection and updates are achieved through a shared memory area to ensure version consistency. The program is automatically separated and loaded at startup, and a data verification mechanism is set up to ensure data accuracy.
It simplifies program management and version update processes, improves the stability of version updates and data exchange efficiency, reduces system maintenance costs, and ensures the synchronization between real-time and non-real-time cores and system reliability.
Smart Images

Figure CN121704911B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of heterogeneous multicore system technology, and in particular to a heterogeneous multicore system and its operating method, electronic device and medium. Background Technology
[0002] With the development of embedded systems, heterogeneous multi-core processors are widely used in industrial control, intelligent devices, and other fields. Currently, heterogeneous multi-core processors suffer from the following problems: In heterogeneous systems, real-time cores and non-real-time cores run different operating systems, resulting in complex and inefficient data exchange; program updates require maintaining separate programs for both cores, easily leading to version inconsistencies or system instability; traditional data exchange methods require complex communication protocols, resulting in high system overhead; and the program loading process is complex, making it difficult to guarantee the synchronization of the two core programs. Summary of the Invention
[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a heterogeneous multi-core system and its operating method, electronic devices, and media, which can ensure version consistency among the various cores.
[0004] A first aspect, according to an embodiment of the present invention, a method for operating a heterogeneous multi-core system, wherein the heterogeneous multi-core system includes a real-time core, a non-real-time core, and a shared memory region, the method comprising: Package real-time kernel programs and non-real-time kernel programs into a unified package; When the heterogeneous multi-core system starts up, the real-time kernel program and the non-real-time kernel program are separated according to the unified program package; Version detection is performed on the real-time core and the non-real-time core; When the version information of the non-real-time core is inconsistent with the version information of the real-time core, version update information is written to the shared memory region through the non-real-time core; The real-time core is updated according to the version update information; When the version information of the non-real-time kernel is consistent with the version information of the real-time kernel, the real-time kernel program and the non-real-time kernel program are loaded and run respectively.
[0005] According to some embodiments of the present invention, after the step of loading and running the real-time kernel program and the non-real-time kernel program respectively when the version information of the non-real-time kernel is consistent with the version information of the real-time kernel, the method further includes: Data is written to the shared memory region by the sender in the real-time core and the non-real-time core, and data verification is performed in the shared memory region. Once the data verification is successful, the data is read from the shared memory area through the receiver in the real-time core and the non-real-time core.
[0006] According to some embodiments of the present invention, when the heterogeneous multi-core system starts up, separating the real-time kernel program and the non-real-time kernel program according to the unified package includes: When the heterogeneous multi-core system starts up, it reads the unified package; the unified package includes description information. Verify the integrity of the unified package; When the verification is successful, the description information is read, and the real-time kernel program and the non-real-time kernel program are separated according to the description information.
[0007] According to some embodiments of the present invention, after the step of verifying the integrity of the unified package, the method further includes: When validation fails, error handling should be performed. During error handling, the unified program package is not executed; instead, data recovery is performed on the heterogeneous multi-core system, and the original program is executed.
[0008] According to some embodiments of the present invention, updating the real-time core according to the version update information includes: Lock the shared memory region and back up the current data of the real-time core; Update the real-time core to a new version; After a successful update, the shared memory region will be unlocked.
[0009] According to some embodiments of the present invention, after the step of updating the real-time core, the method further includes: If the update fails, restore the current data from the backup; Unlock the shared memory region.
[0010] According to some embodiments of the present invention, when the communication between the real-time core and the non-real-time core times out, the method further includes: Clear the communication flags and reset the communication status; Log errors.
[0011] Secondly, according to an embodiment of the present invention, a heterogeneous multi-core system includes: a real-time core, a non-real-time core, and a shared memory region, wherein the heterogeneous multi-core system is used to implement the operation method of the heterogeneous multi-core system as described in the first aspect embodiment.
[0012] Thirdly, according to an embodiment of the present invention, a storage medium includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, the instructions being executed by the at least one control processor to enable the at least one control processor to perform the operation method of the heterogeneous multi-core system as described in the first aspect embodiment.
[0013] Fourthly, according to an embodiment of the present invention, the storage medium stores computer-executable instructions for causing a computer to execute the method for operating a heterogeneous multi-core system as described in the first aspect embodiment.
[0014] The heterogeneous multi-core system and its operating method, electronic device and medium according to embodiments of the present invention have at least the following beneficial effects: by packaging the real-time core program and the non-real-time core program into a unified program package, it is convenient to manage the real-time core program and the non-real-time core program at the same time, ensuring that when updating the system version, it is not necessary to maintain the real-time core and the non-real-time core at the same time; at the same time, when the system starts up, it will further detect the versions of the real-time core and the non-real-time core to ensure that the versions of the two are consistent.
[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of the heterogeneous multi-core system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the specific structure of the heterogeneous multi-core system according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the steps of operating a heterogeneous multi-core system according to an embodiment of the present invention. Figure 4 This is a flowchart illustrating the communication process between the real-time core and the non-real-time core in an embodiment of the present invention. Figure 5 This is a flowchart illustrating the process of reading a unified package according to an embodiment of the present invention; Figure 6 This is a flowchart of an updated version of an embodiment of the present invention; Figure 7 This is a flowchart illustrating error handling in an embodiment of the present invention. Detailed Implementation
[0017] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.
[0018] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.
[0019] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0020] In this invention, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0021] With the development of embedded systems, heterogeneous multi-core processors are widely used in industrial control, intelligent devices, and other fields. Currently, heterogeneous multi-core processors suffer from the following problems: In heterogeneous systems, real-time cores and non-real-time cores run different operating systems, resulting in complex and inefficient data exchange; program updates require maintaining separate programs for both cores, easily leading to version inconsistencies or system instability; traditional data exchange methods require complex communication protocols, resulting in high system overhead; and the program loading process is complex, making it difficult to guarantee the synchronization of the two core programs.
[0022] To this end, embodiments of the present invention provide a heterogeneous multi-core system and its operating method, electronic device and medium. By packaging real-time core programs and non-real-time core programs into a unified program package, it is convenient to manage real-time core programs and non-real-time core programs at the same time, ensuring that when updating the system version, it is not necessary to maintain real-time cores and non-real-time cores at the same time. At the same time, when the system starts up, it will further detect the versions of real-time cores and non-real-time cores to ensure that the versions of the two are consistent.
[0023] The following describes in detail, with reference to the accompanying drawings, the heterogeneous multi-core system and its operating method, electronic device and medium according to embodiments of the present invention.
[0024] like Figure 1 As shown in the illustration, this application provides a heterogeneous multi-core system, which includes a real-time kernel, a non-real-time kernel, and a shared memory region. The real-time kernel (RTOS) is an operating system kernel designed to ensure tasks are completed within strictly defined time limits. A non-real-time kernel, on the other hand, does not guarantee task completion within strict time limits; its primary focus is on average system performance and high throughput, rather than the predictability of each task execution. Common non-real-time kernels include Linux and Windows kernels. In this example, the Linux kernel is used as an example of a non-real-time kernel. The shared memory region is mainly used for automatic synchronization of data structures and providing data consistency checks. Figure 2 As shown, the non-real-time kernel includes a program code area and a data area, while the shared memory area includes a description information area, a data exchange area, and a status flag area. The description information area records information such as the system version, the data exchange area enables communication between the real-time and non-real-time kernels, and the status flag area records the system status. Figure 1 and Figure 2 The heterogeneous multi-core system shown in this application presents a method for operating such a system, as follows: Figure 3 As shown, the method includes the following steps: Step S100: Package the real-time kernel program and the non-real-time kernel program into a unified program package; Specifically, real-time kernel programs and non-real-time kernel programs can be merged into a unified package by writing automated scripts. This unified package contains consistent version information and data structure definitions to ensure version consistency between the real-time and non-real-time kernels, and that their communication data structures are consistent. Furthermore, packaging the two programs into a unified package eliminates the need to maintain separate real-time and non-real-time programs during updates, reducing the difficulty of version updates and improving their stability.
[0025] Step S200: When the heterogeneous multi-core system starts up, the real-time kernel program and the non-real-time kernel program are separated according to the unified program package; It should be noted that a fixed location within the unified package contains descriptive information to distinguish between real-time kernel programs and non-real-time kernel programs, making it easy to separate real-time kernel programs from non-real-time kernel programs. Step S300: Perform version detection on real-time and non-real-time cores; After separating the real-time core and the non-real-time core, it is necessary to further confirm that the version information of the two is consistent so that the system can run normally. Therefore, version detection is required for the real-time core and the non-real-time core.
[0026] Step S400: When the version information of the non-real-time core is inconsistent with the version information of the real-time core, the version update information is written to the shared memory area through the non-real-time core. When a version discrepancy is detected between the non-real-time core and the real-time core, the non-real-time core writes version update information to the shared memory region, allowing the real-time core to subsequently read this update information from the shared memory region. It's important to note that the non-real-time core is the system's main core, and the version of the real-time core must be consistent with that of the non-real-time core.
[0027] Step S500: Update the real-time core according to the version update information; Specifically, when the real-time core obtains the version update information of the shared memory region, it checks whether its version is consistent with that of the non-real-time core. If they are inconsistent, the real-time core is updated until the versions of the real-time core and the non-real-time core are consistent.
[0028] Step S600: When the version information of the non-real-time kernel is consistent with the version information of the real-time kernel, load and run the real-time kernel program and the non-real-time kernel program respectively.
[0029] Once the version information of the non-real-time kernel matches that of the real-time kernel, the real-time kernel program and the non-real-time kernel program can be loaded and run normally, allowing the system to function properly.
[0030] According to the heterogeneous multi-core system operation method of the present application embodiment, by packaging the real-time core program and the non-real-time core program into a unified program package, it is convenient to manage the real-time core program and the non-real-time core program at the same time, and ensure that when the system is updated, it is not necessary to maintain the real-time core and the non-real-time core at the same time; at the same time, when the system starts, it will further detect the versions of the real-time core and the non-real-time core to ensure that the versions of the two are consistent.
[0031] Furthermore, in some embodiments of this application, when both the real-time core and the non-real-time core are loaded and running normally, they can communicate, with the real-time core sending data and the non-real-time core receiving data, or vice versa. Specifically, as... Figure 4 As shown, communication between the real-time core and the non-real-time core includes the following two steps: Step S710: Write data to the shared memory region through the sender in the real-time core and the non-real-time core, and perform data verification in the shared memory region; Step S720: After the data verification is successful, the data is read from the shared memory area through the receiver in the real-time core and the non-real-time core.
[0032] Specifically, during communication between the real-time core and the non-real-time core, the party sending data is the sender, and the party receiving data is the receiver. The sender writes the data to be sent into a shared memory area. The shared memory area verifies the data to see if it conforms to a preset data structure definition. If it does, the receiver can read the data from the shared memory area. This scheme completes communication between the real-time core and the non-real-time core and ensures data accuracy. If the verification fails, error handling is performed; the specific error handling methods are described later.
[0033] Furthermore, in some embodiments of this application, such as Figure 5 As shown, step S200 above: When the heterogeneous multi-core system starts, the real-time kernel program and the non-real-time kernel program are separated according to the unified program package, including the following three steps: When a heterogeneous multi-core system starts up, it reads a unified package; the unified package includes descriptive information. Verify the integrity of the unified package; When the verification passes, the description information is read, and the real-time kernel program and the non-real-time kernel program are separated according to the description information.
[0034] Specifically, in this example, upon system startup, the unified package is first read. Then, the integrity of the unified package is verified. If the verification passes, the real-time kernel program and the non-real-time kernel program are separated according to the description information in the unified package. This allows the real-time kernel program and the non-real-time kernel program to be loaded, initialized, and run normally, enabling the system to operate normally. If the integrity verification of the unified package fails, error handling is performed. During error handling, the unified package is not executed; instead, data recovery is performed on the heterogeneous multi-core system, allowing the system to execute the original program and preventing system malfunction.
[0035] Furthermore, such as Figure 6As shown, in some embodiments of this application, step S600 above: updating the real-time core according to the version update information, includes: Lock the shared memory region and back up the current data of the real-time core; Update the real-time core version; After the update is successful, the shared memory area will be unlocked.
[0036] Specifically, when updating the real-time core, the shared memory region is locked first to ensure data consistency and prevent system crashes. The shared memory region is then unlocked after the real-time core has completed the update. Simultaneously, the current data of the real-time core is backed up before the update, allowing for data restoration in case of update failure and preventing non-real-time core crashes. If a non-real-time core update fails, its backup data is restored, and the shared memory region is unlocked. At the same time, system error handling is performed to investigate the cause of the update failure and resolve any issues.
[0037] like Figure 7 As shown, in some embodiments of this application, the system can automatically handle some errors, including error types such as checksum errors, program exceptions, and communication timeouts. The specific processing flow is as follows: Figure 7 As shown: When a CRC check error occurs, the CRC is recalculated. If the check is successful, the system resumes normal operation. If the check fails, data recovery is initiated and an error log is recorded. When a program exception occurs, the context information is preserved, the exception program is isolated, the core corresponding to the exception program is restarted, and an error log is recorded. When a communication timeout occurs, the communication flag is cleared, the communication status is reset, and an error log is recorded.
[0038] The method for operating a heterogeneous multi-core system according to embodiments of this application can package real-time core programs and non-real-time core programs into a unified program package. This unified program package contains unified version information and data structure definitions, and can automatically separate and load the real-time and non-real-time core programs upon system startup. By setting a shared memory area, automatic data structure synchronization can be achieved, and data consistency verification is provided. Unified version number management is implemented, and automatic version compatibility checks and data structure upgrade schemes are performed. Furthermore, an error handling mechanism is included to perform various anomaly detections, achieve automatic system recovery, and record error logs. This method simplifies the development process of heterogeneous systems, improves data exchange efficiency, reduces program maintenance costs, enhances system reliability, and achieves unified program management.
[0039] On the other hand, embodiments of the present invention also provide an electronic device, including at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, the instructions being executed by the at least one control processor to enable the at least one control processor to perform the operation method of the heterogeneous multi-core system as described above.
[0040] On the other hand, embodiments of the present invention also provide a storage medium, which is a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for operating a heterogeneous multi-core system.
[0041] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate, and may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0042] Although specific embodiments are described herein, those skilled in the art will recognize that many other modifications or alternative embodiments are also within the scope of this disclosure. For example, any of the functions and / or processing capabilities described in connection with a particular device or component can be performed by any other device or component. Furthermore, while various exemplary embodiments and architectures have been described according to embodiments of this disclosure, those skilled in the art will recognize that many other modifications to the exemplary embodiments and architectures described herein are also within the scope of this disclosure.
[0043] The foregoing description, with reference to block diagrams and flowcharts of systems, methods, systems, and / or computer program products according to exemplary embodiments, has described certain aspects of this disclosure. It should be understood that one or more blocks in the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by executing computer-executable program instructions, respectively. Similarly, according to some embodiments, some blocks in the block diagrams and flowcharts may not need to be executed in the order shown, or may not all need to be executed. Furthermore, additional components and / or operations beyond those shown in the blocks in the block diagrams and flowcharts may exist in some embodiments.
[0044] Therefore, blocks in block diagrams and flowcharts support combinations of means for performing a specified function, combinations of elements or steps for performing a specified function, and program instruction means for performing a specified function. It should also be understood that each block in a block diagram and flowchart, and combinations of blocks in block diagrams and flowcharts, can be implemented by a dedicated hardware computer system or a combination of dedicated hardware and computer instructions that performs a specific function, element, or step.
[0045] The program modules, applications, etc., described herein may include one or more software components, including, for example, software objects, methods, data structures, etc. Each such software component may include computer-executable instructions that, in response to execution, cause at least a portion of the functionality described herein (e.g., one or more operations of the exemplary methods described herein) to be performed.
[0046] Software components can be coded using any of a variety of programming languages. An exemplary programming language could be a low-level programming language, such as assembly language associated with a specific hardware architecture and / or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before being executed by the hardware architecture and / or platform. Another exemplary programming language could be a higher-level programming language that is portable across multiple architectures. Software components including higher-level programming languages may need to be converted into an intermediate representation by an interpreter or compiler before execution. Other examples of programming languages include, but are not limited to, macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, or report writing languages. In one or more exemplary embodiments, a software component containing instructions from one of the above-described programming language examples can be executed directly by the operating system or other software components without first being converted into another form.
[0047] Software components can be stored as files or other data storage structures. Software components of similar type or related function can be stored together in a specific directory, folder, or library. Software components can be static (e.g., pre-defined or fixed) or dynamic (e.g., created or modified at runtime).
[0048] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.
Claims
1. A method for operating a heterogeneous multi-core system, characterized in that, The heterogeneous multi-core system includes a real-time core, a non-real-time core, and a shared memory region. The shared memory region includes a description information area, a data exchange area, and a status flag area. The description information area is used to record the system version, the data exchange area is used to enable communication between the real-time core and the non-real-time core, and the status flag area is used to record the system status. The method includes: The real-time kernel program and the non-real-time kernel program are packaged into a unified program package; the unified program package contains unified version information and data structure definitions to ensure that the versions of the real-time kernel and the non-real-time kernel are consistent, and that the data structures of the real-time kernel and the non-real-time kernel are consistent when they communicate. When the heterogeneous multi-core system starts up, the real-time kernel program and the non-real-time kernel program are separated according to the unified program package; Version detection is performed on the real-time core and the non-real-time core; When the version information of the non-real-time core is inconsistent with the version information of the real-time core, version update information is written to the shared memory region through the non-real-time core; The real-time core is updated according to the version update information; When the version information of the non-real-time kernel is consistent with the version information of the real-time kernel, the real-time kernel program and the non-real-time kernel program are loaded and run respectively.
2. The method for operating a heterogeneous multi-core system according to claim 1, characterized in that, After the step of loading and running the real-time kernel program and the non-real-time kernel program respectively when the version information of the non-real-time kernel is consistent with the version information of the real-time kernel, the method further includes: Data is written to the shared memory region by the sender in the real-time core and the non-real-time core, and data verification is performed in the shared memory region. Once the data verification is successful, the data is read from the shared memory area through the receiver in the real-time core and the non-real-time core.
3. The method for operating a heterogeneous multi-core system according to claim 1, characterized in that, When the heterogeneous multi-core system starts up, the separation of the real-time kernel program and the non-real-time kernel program according to the unified program package includes: When the heterogeneous multi-core system starts up, it reads the unified package; the unified package includes description information. Verify the integrity of the unified package; When the verification is successful, the description information is read, and the real-time kernel program and the non-real-time kernel program are separated according to the description information.
4. The method for operating a heterogeneous multi-core system according to claim 3, characterized in that, After the step of verifying the integrity of the unified package, the method further includes: When validation fails, error handling should be performed. During error handling, the unified program package is not executed; instead, data recovery is performed on the heterogeneous multi-core system, and the original program is executed.
5. The method for operating a heterogeneous multi-core system according to claim 1, characterized in that, The step of updating the real-time core according to the version update information includes: Lock the shared memory region and back up the current data of the real-time core; Update the real-time core to a new version; After a successful update, the shared memory region will be unlocked.
6. The method for operating a heterogeneous multi-core system according to claim 5, characterized in that, After the step of updating the real-time core, the method further includes: If the update fails, restore the current data from the backup; Unlock the shared memory region.
7. The method for operating a heterogeneous multi-core system according to claim 1, characterized in that, When the communication between the real-time core and the non-real-time core times out, the method further includes: Clear the communication flags and reset the communication status; Log errors.
8. A heterogeneous multi-core system, characterized in that, include: The heterogeneous multi-core system includes a real-time core, a non-real-time core, and a shared memory region, and is used to implement the operation method of the heterogeneous multi-core system as described in any one of claims 1-7.
9. An electronic device, characterized in that, It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which, when executed by the at least one control processor, enable the at least one control processor to perform the operation method of the heterogeneous multicore system as described in any one of claims 1 to 7.
10. A storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to execute the method of operating a heterogeneous multi-core system as described in any one of claims 1-7.
Citation Information
Patent Citations
Communication method between real-time operating system and non-real-time operating system on multi-core processor
CN103942178A
Heterogeneous multi-core system and inter-core communication method thereof, chip and storage medium
CN116028422A