Hybrid multi-core system, electronic device, and computer-readable storage medium

Abstract

The application relates to the technical field of communication, in particular to a hybrid multi-core system, an electronic device and a computer readable storage medium. The hybrid multi-core system comprises a plurality of cores, a resource management module, a shared resource pool module and a simulation module, the plurality of cores at least comprising a master core and a slave core, each core being provided with an independent interrupt channel; the resource management module is used for allocating static resources for the plurality of cores in a system booting stage; the shared resource pool module is used for performing access control on preset shared resources based on a dynamic application and release mechanism in a system running stage; and the simulation module is used for running the task of a target processor core in a simulation environment independent of other processor cores in response to a debugging instruction or a fault event for the target processor core during the running of the hybrid multi-core system. The application can solve the resource contention problem in the hybrid multi-core system, improve the system stability and fault tolerance, and greatly improve the debugging efficiency of the multi-core system.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a hybrid multi-core system, electronic device, and computer-readable storage medium. Background Technology

[0002] In the field of embedded systems, multi-core processor architectures are mainly divided into two modes: SMP (Symmetric Multi-Processing) and AMP (Asymmetric Multi-Processing). In SMP architecture, all cores share the same memory space and have symmetrical resource access permissions, exhibiting good compatibility and ease of use in a single operating system environment. However, its resource isolation has inherent limitations, making it difficult to achieve hardware-level isolation between the master core running Linux and the slave cores running bare kernels or real-time operating systems (RTOS). AMP architecture allows different cores to run their own operating systems or bare kernel programs independently. Each core can have its own dedicated interrupt channels, memory regions, and peripheral resources. However, existing AMP management frameworks mostly use static partitioning, lacking dynamic scheduling mechanisms for shared peripherals, and have shortcomings in inter-core communication efficiency and cache coherency maintenance.

[0003] Current hybrid multi-core systems suffer from the following technical defects: First, the resource isolation mechanism is imperfect. Critical resources such as interrupts, memory, and peripherals are statically partitioned, lacking dynamic perception and adjustment capabilities, which easily leads to resource conflicts. Second, there is a risk of conflict when accessing shared resources, as there is a lack of a unified scheduling and arbitration mechanism among multiple cores. Third, the system has weak fault tolerance, and single-core failures can easily spread to the entire system. Fourth, debugging methods are inflexible, lacking independent simulation capabilities for single-core environments, resulting in low efficiency in problem localization. Summary of the Invention

[0004] This application provides a hybrid multi-core system, an electronic device, and a computer-readable storage medium that can solve the resource contention problem in hybrid multi-core systems, improve system stability and fault tolerance, and significantly enhance the debugging efficiency of multi-core systems. Firstly, this application provides a hybrid multi-core system, comprising multiple cores, a resource management module, a shared resource pool module, and a simulation module. The multiple cores include at least a master core and slave cores, each with an independent interrupt channel. The resource management module is connected to the multiple cores and is used to allocate static resources to the multiple cores during the system boot phase. The shared resource pool module is connected to the multiple cores and is used to perform access control on preset shared resources based on a dynamic allocation and release mechanism during system operation. The simulation module is connected to the multiple cores and is used to run the target processor core's tasks in a simulation environment independent of other processor cores during the operation of the hybrid multi-core system, in response to debugging instructions or fault events targeting the target processor core, to independently debug or analyze the fault status of the target processor core.

[0005] In some implementations, the resource management module includes an interrupt resource allocation unit, which is used to allocate different interrupt channels to the core during the boot phase and determine the priority of each interrupt channel according to the interrupt task type. During the system operation phase, it determines the interrupt channel of the target core corresponding to the shared interrupt signal to be responded to and performs interrupt priority control according to the priority of the interrupt channel.

[0006] In some implementations, the resource management module includes a memory resource allocation unit, which performs at least one of the following: pre-allocates an independent memory region for each core during the boot phase; predefines a shared memory region for inter-core communication; and maintains cache consistency through a hardware cache coherency mechanism or a software synchronization mechanism.

[0007] In some implementations, the resource management module includes a peripheral resource allocation unit, which allocates independent I / O ports and DMA channels to each core during the boot phase and synchronizes reusable shared peripherals to the shared resource pool module.

[0008] In some implementations, the shared resource pool module is used to: define reusable peripherals as a shared resource pool during the system boot phase, and expose the shared peripherals to multiple cores through a general call interface; respond to a shared peripheral usage request initiated by any of the multiple cores at runtime, determine whether to grant usage rights based on the current peripheral status, task priority, and allocation strategy, and set a resource occupancy flag according to the usage rights granting result; and change the resource occupancy flag in response to a release command sent by any of the multiple cores after usage is completed.

[0009] In some implementations, the system further includes a conflict detection module, which is connected to both the resource management module and the shared resource pool module. This module is used to: perform consistency checks on the static resource table and the shared resource table during the boot phase; these consistency checks are used to detect unauthorized reuse and unauthorized address mappings; and execute access status check logic, which is used to determine in real time whether a resource is already occupied by the core. If an access conflict occurs, a rescheduling process or a resource reclamation process is triggered.

[0010] In some implementations, the memory resource allocation unit further includes a memory conflict detection subunit, which is used to: impose access boundary constraints on the dedicated memory region of each core to prevent out-of-bounds access; and record the source core, timestamp, and data block range of read and write operations accessing the shared memory region.

[0011] In some implementations, the simulation module includes: an independent simulation environment construction unit, connected to each core, for providing an independent simulation environment for each core, ensuring that the simulation operation of each core does not interfere with each other, and supporting individual viewing and modification of the register and memory states of each core without affecting the normal operation of other cores; and a core fault simulation unit, connected to each core, for automatically isolating the faulty core when any core is suspended due to a fault, suspending the faulty core's access to shared resources, and automatically entering simulation mode to read the register and memory states of the faulty core and restore the state before the fault occurred.

[0012] Secondly, this application provides a chip for performing the methods described in any of the first aspects above.

[0013] Thirdly, this application provides an electronic device including a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the method as described in any of the first aspects above. Alternatively, Electronic devices include chips as described in the second aspect.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any of the first aspects above.

[0015] Fifthly, this application provides a computer program product storing a computer program that, when executed by a processor, implements the method as described in any of the first aspects above.

[0016] The technical solution provided in this application forms a modular architecture of "core layer - resource management layer - simulation layer" by setting up a resource management module, a shared resource pool module, and a simulation module, thereby achieving functional decoupling and reducing system complexity. During the boot phase, the resource management module statically pre-allocates independent interrupt channels, memory regions, and peripheral resources to each core, avoiding runtime resource contention and coordinating inter-core access cooperation to ensure the determinism of real-time tasks. The shared resource pool module incorporates reusable peripherals into unified management, achieving dynamic resource allocation and cross-core reuse through a unified access interface, improving resource utilization, and ensuring data consistency through a mutual exclusion mechanism. Each core has an independent interrupt channel to achieve interrupt signal isolation. The simulation module provides an independent simulation environment for each core, supporting independent single-core debugging. In the event of a core failure, it automatically isolates the faulty core and recreates the fault scenario, while other cores continue to operate normally. The technical solution provided in this application achieves unified management of resource isolation and sharing, improved system fault tolerance, and optimized debugging efficiency, and can solve the problems of resource contention, fault propagation, and debugging in hybrid multi-core systems. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the structure of a hybrid multi-core system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a resource allocation and isolation structure for a hybrid multi-core system provided in an embodiment of this application; Figure 3 This is a schematic diagram of a shared resource pool module management process for a hybrid multi-core system provided in an embodiment of this application; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be 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.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] In the field of embedded systems, multi-core processor architectures are mainly divided into two modes: SMP and AMP. The two have fundamental differences in design philosophy, resource management methods and applicable scenarios.

[0026] SMP architecture is a multi-core processing model where all cores share the same physical memory space and have symmetrical resource access permissions, meaning each core can equally access all memory addresses and peripheral resources. This architecture achieves multi-core task scheduling and load balancing through shared resources, exhibiting good compatibility and ease of use in a single operating system environment. However, the core characteristics of SMP architecture inherently limit its resource isolation. All cores share the interrupt controller, memory management unit, and peripheral interfaces, making it difficult to achieve hardware-level isolation between the master core running Linux and the slave cores running bare kernels or real-time operating systems (RTOS). This makes it unsuitable for the needs of multi-operating system deployments in hybrid mission-critical systems.

[0027] The AMP architecture allows different cores to run their own operating systems or bare-metal programs independently. Each core can have its own dedicated interrupt channel, memory region, and peripheral resources, offering greater flexibility and determinism, making it particularly suitable for scenarios where real-time and general-purpose tasks are deployed together. However, existing AMP management frameworks still have significant room for improvement in fine-grained resource management. Current implementations mostly use static partitioning, where resource allocation is completed and then fixed during system startup, lacking a dynamic scheduling mechanism for shared peripherals. Furthermore, they suffer from shortcomings in inter-core communication efficiency and cache consistency maintenance, thus limiting the overall performance of heterogeneous multi-core systems.

[0028] The Linux operating system boasts deep technical expertise in multi-core task scheduling, memory management, and system security, and is widely used in embedded systems and server environments. However, it should be noted that the Linux kernel's scheduler and resource management strategies are primarily designed and optimized for SMP architectures, and have inherent limitations in handling cross-core resource isolation and ensuring the determinism of real-time tasks. In hybrid deployment scenarios where the Linux kernel coexists with bare kernels or RTOS kernels, traditional Linux mechanisms struggle to effectively prevent non-real-time kernels from preempting the hardware resources required by the real-time kernel, and cannot provide lightweight, deterministic runtime environment guarantees for bare-kernel tasks.

[0029] J-Link emulator-based debugging solutions provide crucial support for the development and testing of multi-core systems. Through J-Link, developers can perform real-time debugging of ARM processors, including setting breakpoints, single-stepping, and viewing register and memory status, facilitating in-depth analysis of program execution. This technology supports multiple interfaces such as SWD (Serial Wire Debug) and JTAG (Joint Test Action Group), offering strong compatibility and applicability to various ARM architecture chips. In multi-core system development, J-Link emulation assists developers in controlling the startup and debugging processes of each core, facilitating task scheduling analysis, exception handling and localization, and system collaborative operation verification.

[0030] Based on the above analysis, current hybrid multi-core embedded systems generally suffer from the following technical deficiencies in hardware resource isolation and management: First, the resource isolation mechanism is inadequate. In existing multi-core systems, critical hardware resources such as interrupts, memory, and peripherals are typically allocated using a static partitioning method, meaning they remain fixed after configuration during system startup. This coarse-grained resource management lacks the ability to dynamically perceive and adjust runtime resource usage, easily leading to resource conflicts or low utilization. For example, when multiple cores compete for the same interrupt channel, or when the dedicated memory area required by the RTOS kernel is interfered with by the Linux kernel's cache coherency operations, system stability and real-time performance will be significantly affected.

[0031] Secondly, shared resource access presents conflicts and security risks. The lack of a unified scheduling and arbitration mechanism for shared resources among multiple cores, especially during access to shared peripherals and shared memory, easily leads to problems such as concurrent access conflicts, inconsistent cached data, or unordered resource preemption. Taking shared peripherals as an example, when two cores simultaneously operate on the same UART controller or GPIO pin, without an effective mutual exclusion mechanism, data corruption or abnormal hardware states will occur. Such problems directly affect the predictability of system operation and data reliability.

[0032] Third, the system has weak fault tolerance. Under the existing architecture, once a core fails due to a program error, resource deadlock, or hardware anomaly, its abnormal behavior often propagates to other cores through the shared bus, memory, or peripherals, causing the entire system to crash or enter an unpredictable state. The lack of an effective core-level fault isolation mechanism makes it impossible to quickly cut off the faulty core's access to shared resources when a fault occurs, and it is also difficult to preserve the state of the faulty core and perform subsequent recovery, severely restricting the system's continuous operation capability.

[0033] Fourth, debugging and simulation methods are inflexible. Current multi-core system debugging heavily relies on the coordinated operation of the entire system, making it difficult for developers to independently simulate and locate individual cores in an isolated environment. When a system malfunctions, it is impossible to read the register status, memory data, or instruction execution trajectory of the faulty core without affecting the operation of other cores. This results in a complex and inefficient debugging process, making it difficult to quickly distinguish and locate the root causes of inter-core interaction problems and internal single-core anomalies.

[0034] In view of this, this application provides a hybrid multi-core system that can solve the resource contention problem in hybrid multi-core systems, improve system stability and fault tolerance, and significantly improve the debugging efficiency of multi-core systems.

[0035] Figure 1 This is a schematic diagram of the structure of a hybrid multi-core system provided in an embodiment of this application. Figure 1 As shown, the hybrid multi-core system includes multiple cores 110, a resource management module 120, a shared resource pool module 130, and a simulation module 140.

[0036] The multi-core 110 includes at least a master core and slave cores, and each core has an independent interrupt channel.

[0037] The main core can run a Linux system to perform critical tasks such as scheduling and communication; the slave cores can run bare-metal programs or a real-time operating system (RTOS) to perform dedicated application tasks such as real-time control and data acquisition. Each core has an independent interrupt channel to ensure that interrupt signals from different cores do not interfere with each other.

[0038] The resource management module 120 is connected to multiple cores 110 and is used to allocate static resources to the multiple cores 110 during the system boot phase. It also coordinates access cooperation between the multiple cores; the static resources include interrupt resources, memory resources, and peripheral resources.

[0039] The resource management module 120 can perform static configuration of resources through configuration files during the boot phase (such as the U-Boot phase), and achieve flexible scheduling of resources through a dynamic collaboration mechanism during the runtime phase.

[0040] The shared resource pool module 130 is connected to multiple cores 110 and is used to perform access control on preset shared resources based on a dynamic application and release mechanism during system operation.

[0041] The shared resource pool module 130 establishes a shared resource pool to include some non-critical, reusable peripherals (such as GPIO, UART, SPI, I2C, etc.) under unified management, supporting the core to dynamically apply for, use, and release shared peripheral resources at runtime, thereby improving resource utilization efficiency.

[0042] Simulation module 140 is connected to multiple cores 110 to run tasks of the target processor core in a simulation environment independent of other processor cores during operation of a hybrid multi-core system, in response to debugging instructions or fault events targeting the target processor core, so as to independently debug or analyze the fault status of the target processor core.

[0043] The simulation module 140 supports independent debugging of a single core, allowing users to view and modify the core's register and memory states without affecting the normal operation of other cores. When a core fails, the simulation module 140 can automatically isolate the faulty core and read its status information through the simulation interface to recreate the fault scenario.

[0044] The technical solution provided in this application adopts a modular architecture of "core layer - resource management layer - simulation layer" by setting up a resource management module, a shared resource pool module, and a simulation module, thereby achieving functional decoupling and reducing system complexity. During the boot phase, the resource management module statically pre-allocates independent interrupt channels, memory regions, and peripheral resources to each core, avoiding runtime resource contention and coordinating inter-core access cooperation to ensure the determinism of real-time tasks. The shared resource pool module incorporates reusable peripherals into unified management, achieving dynamic resource allocation and cross-core reuse through a unified access interface, improving resource utilization, and ensuring data consistency through a mutual exclusion mechanism. Each core has an independent interrupt channel to achieve interrupt signal isolation. The simulation module provides an independent simulation environment for each core, supporting independent single-core debugging. In the event of a core failure, it automatically isolates the faulty core and recreates the fault scenario, while other cores continue to operate normally. The technical solution provided in this application achieves unified management of resource isolation and sharing, improved system fault tolerance, and optimized debugging efficiency, solving the problems of resource contention, fault propagation, and debugging in hybrid multi-core systems.

[0045] Figure 2 This is a schematic diagram of a resource allocation and isolation structure for a hybrid multi-core system provided in an embodiment of this application.

[0046] like Figure 2 As shown, in some embodiments, the resource management module 120 may further include an interrupt resource allocation unit 121. The resource allocation unit 121 can be used to allocate different interrupt channels to the cores during the boot phase and determine the priority of each interrupt channel according to the interrupt task type. During system operation, it determines the interrupt channel of the target core corresponding to the shared interrupt signal to be responded to and performs interrupt priority control according to the priority of the interrupt channel. The priorities corresponding to multiple cores are not completely the same. The interrupt resource allocation unit 121 allocates an independent interrupt channel (Interrupt Vector Table) to each core through a configuration file to ensure that the interrupt signals of each core do not interfere with each other.

[0047] In practical implementation, resource allocation unit 121 can allocate high-priority interrupt channels to the main kernel (running the Linux kernel) for real-time response to critical tasks (such as scheduling and communication); resource allocation unit 121 can allocate low-priority interrupt channels to slave kernels (running bare kernels or RTOS) for dedicated application tasks (such as data acquisition). During the boot phase, priorities are assigned according to task importance, and global interrupt priority rules are predefined, for example: real-time control task interrupt > network communication interrupt > system monitoring interrupt.

[0048] The interrupt resource allocation unit 121 may also be equipped with a shared interrupt routing mechanism to ensure that shared interrupt signals can be routed to the target core according to task requirements. For example, if multiple cores simultaneously receive peripheral interrupt signals (such as network interrupts), the signals are preferentially transmitted to the interrupt controller for processing through routing rules, and the interrupt controller determines which core should respond according to the rules.

[0049] like Figure 2 As shown, in some embodiments, the resource management module 120 may further include a memory resource allocation unit 122, which can be used to pre-allocate an independent memory region for each core during the boot phase, defined by a configuration file, to avoid memory conflicts.

[0050] In practice, the main kernel memory region (such as the Linux kernel) is responsible for scheduling tasks and sharing data storage (e.g., 1GB-2GB); the secondary kernel memory region (bare kernel / RTOS) is used for application tasks (e.g., 500MB-1GB). The memory allocation principle prioritizes ensuring the high-bandwidth memory required by real-time tasks, and the size of the static region can be adjusted according to the task scenario.

[0051] The memory resource allocation unit 122 can also predefine a shared memory region for inter-core communication. This shared region supports synchronization mechanisms for concurrent access by multiple cores (such as shared flags or atomic operations) and adopts a circular buffer design to optimize data transfer efficiency. To solve the multi-core cache coherency problem, the memory resource allocation unit 122 maintains cache coherency through hardware cache coherency mechanisms (such as Cache Coherency in the ARM Cortex series) or software synchronization mechanisms.

[0052] like Figure 2 As shown, in some embodiments, the resource management module 120 includes a peripheral resource allocation unit 123, which is used to allocate independent I / O ports and DMA channels to each core during the boot phase and to entrust the management of reusable shared peripherals to the shared resource pool module 130.

[0053] In implementation, the master core is allocated Ethernet ports and SPI interfaces for communication and data transmission; the slave cores are allocated UART ports and ADC interfaces for data acquisition. An access arbitration mechanism is set up for shared I / O ports (such as GPIO) to ensure safe and orderly concurrent operations across multiple cores. Based on task requirements, DMA channel resources are allocated during the boot phase: high-bandwidth tasks (such as video encoding) are given priority for multi-channel DMA resources. Regarding timer resources, the master core is allocated high-precision system timers for scheduling and critical tasks; the slave cores are allocated general-purpose timers for short-cycle tasks.

[0054] Figure 3 This is a schematic diagram illustrating the management process of a shared resource pool module in a hybrid multi-core system, provided as an embodiment of this application. The shared resource pool module 130 is used to execute the following management process: Step S301: During the system boot phase, reusable peripherals are defined as a shared resource pool, and the shared peripherals are exposed to multiple cores through a general call interface.

[0055] Shared resource definition and initialization. During the system boot phase (U-Boot), reusable peripherals (such as GPIO, UART, SPI, I2C, etc.) are defined as a shared resource pool. Shared peripherals are exposed to all cores through a unified abstract interface and are in an unallocated state by default.

[0056] Step S302: In response to a shared peripheral usage request initiated by any one of the multiple cores during runtime, determine whether to grant usage rights based on the current peripheral status, task priority, and allocation strategy, and set the resource occupancy flag bit according to the usage rights granting result.

[0057] If the kernel needs to use a shared peripheral during runtime, it initiates a resource request to the shared resource pool module 130 through the system's preset access mechanism. The shared resource pool module 130 determines whether to grant the right to use the peripheral based on factors such as the current peripheral status, task priority, and allocation strategy, and sets a resource occupancy flag (such as a hardware flag or software lock).

[0058] Occupancy flags and mutual exclusion access. Shared peripherals use atomic operations to read and write access flags, ensuring mutual exclusion when multiple cores access the resource simultaneously. Once a core successfully requests a resource, other cores will be blocked or denied access to that resource, avoiding hardware conflicts.

[0059] Step S303: In response to a release command sent after any one of the multiple cores has finished using the resource, change the resource occupancy flag.

[0060] After resource usage is complete, the core explicitly releases the peripheral resource through a designated interface. The shared resource pool module 130 clears the occupancy flag, releasing the resource for use by other cores. Access to unreleased resources will be marked as "potential leakage" and logged.

[0061] In some embodiments, the hybrid multi-core system provided in this application may further include a conflict detection module 150, which is connected to the resource management module 120 and the shared resource pool module 130, and is used to introduce a resource conflict detection mechanism from multiple stages of the system to ensure the security and correctness of the resource allocation and access process.

[0062] Consistency verification during the boot phase: During system initialization (U-Boot), the conflict detection module 150 performs consistency verification on the static resource table and the shared resource table to check for illegal reuse, unregistered or illegal address mapping, and ensure the legality of the resource layout.

[0063] Runtime access conflict monitoring: The conflict detection module 150 adds access status checking logic inside the resource access interface to determine in real time whether the resource has been occupied by other cores. If a conflict occurs, it records detailed information (access time, core ID, requested peripheral number, etc.) and decides whether to issue a warning, block, or interrupt the task based on the system policy.

[0064] System-level error reporting and recovery mechanism: After a conflict is triggered, the conflict detection module 150 reports the information to the anomaly monitoring module and feeds it back to the system scheduler to trigger rescheduling or resource reclamation to ensure the continuous and stable operation of the system.

[0065] Regarding memory resources, the memory resource allocation unit 122 also includes a memory conflict detection subunit 1221. This subunit is used to: constrain the access boundaries of the dedicated memory region of each core through the hardware mechanism of the memory protection unit (MPU) or the memory management unit (MMU) to prevent access from going out of bounds; record the source core, timestamp, and data block range of read and write operations for the shared memory region used for multi-core communication to detect access contention behavior; and manage access timing by combining the cache coherence mechanism and software layer locking mechanism of the ARM architecture to reduce the probability of concurrent conflicts.

[0066] In some embodiments, the simulation module 140 may further include an independent simulation environment construction unit 141 and a core fault simulation unit 142.

[0067] The independent simulation environment construction unit 141 is connected to each core, providing an independent simulation environment for each core. The simulation operation of each core is independent and can be debugged independently. The simulation environment includes functions such as program loading, register state simulation, and interrupt simulation, ensuring that the simulation results are consistent with the real operating environment. During debugging, it is possible to view and modify the registers and memory states of a specific core individually without affecting the normal operation of other cores.

[0068] The core fault simulation unit 142 is connected to each core and is used to automatically isolate the core when it is suspended due to a fault, suspend its access to shared resources, and automatically enter simulation mode to read the register state and memory state of the suspended core, restore the state before the fault occurred, and support the rapid location of the problem through simulation tools.

[0069] The simulation module 140 may also include a running status monitoring unit 143 and a debugging and optimization unit 144.

[0070] The runtime status monitoring unit 143 is used to: independently manage the task queue and resources of each core, ensuring that the suspension or failure of a core does not affect the runtime status of other cores; monitor the runtime status of each core in real time, and when an anomaly is detected in a core, isolate the faulty core, suspend its access to shared resources, and provide developers with an independent simulation interface for quick recovery and troubleshooting.

[0071] The debugging and optimization unit 144 is used to: provide a register operation interface for a single core, allowing developers to independently read and modify the core register state in simulation mode without interfering with the normal operation of other cores; support multi-core step-by-step simulation debugging, selectively debug the code segment or execution flow of a certain core, reproduce the core running path through simulation records, and restore the problem scenario; support multiple simulation modes such as independent simulation mode (debugging a single core), integrated simulation mode (testing multi-core collaborative tasks), and fault recovery simulation mode (simulating the running of its task queue after the core is suspended to verify the fault repair effect).

[0072] Through the above mechanism, the simulation module 140 significantly reduces the impact of core suspension on the overall system operation, improves the fault tolerance of multi-core systems, makes debugging more efficient, avoids the complexity of full system debugging, and ensures that the system still runs stably in the event of a core failure.

[0073] It should be understood that, provided there are no logical conflicts, the above-described embodiments can be combined and implemented to adapt to actual application needs. These combined embodiments or implementation schemes are still within the scope of protection of this application.

[0074] The order of the steps in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0075] Based on the same inventive concept, embodiments of this application also provide an electronic device.

[0076] Figure 4 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 4 As shown, the electronic device 40 of this embodiment includes: at least one processor 410 ( Figure 4 Only one is shown in the diagram), memory 420, and communication module 430. Memory 420 stores a computer program 440 that may run on processor 410. When processor 410 executes computer program 440, it implements the steps corresponding to each module in the above-described hybrid multi-core system embodiment, for example... Figure 1 As shown in 110 to 140. Communication module 430 can be a separate communication unit for communicating with external servers or terminal devices.

[0077] Electronic device 40 may include, but is not limited to, a processor 410 and a memory 420. Those skilled in the art will understand that... Figure 4 This is merely an example of electronic device 40 and does not constitute a limitation on electronic device 40. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 40 may also include input transmitting devices, network access devices, buses, etc.

[0078] The processor 410 can be a central processing unit (CPU), or 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 can be a microprocessor or any conventional processor.

[0079] In some embodiments, memory 420 may be an internal storage unit of electronic device 40, such as a hard disk or memory of electronic device 40. Memory 420 may also be an external storage device of electronic device 40, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on electronic device 40. Memory 420 may also include both internal and external storage units of electronic device 40. Memory 420 is used to store operating systems, applications, bootloaders, data, and other programs, such as the program code of computer program 440. Memory 420 may also be used for temporary storage of data that has been sent or will be sent.

[0080] Furthermore, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. In the various embodiments of this application, each functional unit 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0081] This application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the steps described in the various method embodiments above.

[0082] This application provides a chip, which includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps in the various method embodiments described above.

[0083] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the steps described in the various method embodiments above.

[0084] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or 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. A general-purpose processor can be a microprocessor or any conventional processor.

[0085] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0087] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0088] 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, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0089] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0090] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0091] 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0092] 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 computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a large-screen device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0093] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included 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 hybrid multi-core system, characterized in that, The hybrid multi-core system includes multiple cores, a resource management module, a shared resource pool module, and a simulation module. The multiple cores include at least a master core and a slave core, and each core has an independent interrupt channel. The resource management module is connected to the multiple cores and is used to allocate static resources to the multiple cores during the system boot phase. The shared resource pool module is connected to the multiple core modules and is used to perform access control on preset shared resources based on a dynamic application and release mechanism during system operation. The simulation module is connected to the plurality of cores and is used to run the tasks of the target processor core in a simulation environment independent of other processor cores during the operation of the hybrid multi-core system, in response to debugging instructions or fault events for the target processor core, so as to independently debug or analyze the fault status of the target processor core.

2. The hybrid multi-core system according to claim 1, characterized in that, The resource management module includes an interrupt resource allocation unit, which is used to allocate different interrupt channels to the core during the boot phase and determine the priority of each interrupt channel according to the interrupt task type. During the system operation phase, it determines the interrupt channel of the target core corresponding to the shared interrupt signal to be responded to and performs interrupt priority control according to the priority of the interrupt channel.

3. The hybrid multi-core system according to claim 1, characterized in that, The resource management module includes a memory resource allocation unit, which is configured to perform at least one of the following: During the boot phase, a separate memory region is pre-allocated for each core; Predefined shared memory regions for inter-core communication; Cache consistency can be maintained through hardware cache consistency mechanisms or software synchronization mechanisms.

4. The hybrid multi-core system according to claim 1, characterized in that, The resource management module includes a peripheral resource allocation unit, which is used to allocate independent I / O ports and DMA channels to each core during the boot phase and synchronize reusable shared peripherals to the shared resource pool module.

5. The hybrid multi-core system according to claim 1, characterized in that, The shared resource pool module is used for: During the system boot phase, reusable peripherals are defined as a shared resource pool, and the shared peripherals are exposed to the multiple cores through a general call interface; In response to a shared peripheral usage request initiated by any one of the multiple cores during runtime, the system determines whether to grant usage rights based on the current peripheral status, task priority, and allocation strategy, and sets a resource occupancy flag based on the usage rights granting result. In response to a release command sent after any one of the plurality of cores has finished using the resource occupancy flag, the resource occupancy flag is changed.

6. The hybrid multi-core system according to claim 1, characterized in that, The system further includes a conflict detection module, which is connected to both the resource management module and the shared resource pool module, and is used for: During the boot phase, consistency checks are performed on the static resource table and the shared resource table. These consistency checks are used to detect illegal reuse and illegal address mapping. The access status check logic is executed to determine in real time whether the resource has been occupied by the core. If an access conflict occurs, a rescheduling process or a resource reclamation process is triggered.

7. The hybrid multi-core system according to claim 3, characterized in that, The memory resource allocation unit further includes a memory conflict detection subunit, which is used for: Access boundary constraints are applied to the dedicated memory region of each core to prevent out-of-bounds access. Record the source core, timestamp, and data block range of read and write operations accessing the shared memory region.

8. The hybrid multi-core system according to any one of claims 1 to 7, characterized in that, The simulation module includes: An independent simulation environment construction unit is connected to each of the cores to provide an independent simulation environment for each core. The simulation operation of each core does not interfere with each other. It supports viewing and modifying the register state and memory state of each core separately without affecting the normal operation of other cores. The core fault simulation unit is connected to each of the cores and is used to automatically isolate the faulty core when any core is suspended due to a fault, suspend the faulty core's access to shared resources, and automatically enter simulation mode to read the register state and memory state of the faulty core and restore the state before the fault occurred.

9. An electronic device, characterized in that, It includes a processor and a memory, the processor being used to execute a computer program stored in the memory to implement a hybrid multicore system as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements a hybrid multi-core system as described in any one of claims 1 to 7.

Images