An executable file loading system and chip based on multi-core heterogeneity

Abstract

This invention discloses an executable file loading system and chip based on multi-core heterogeneity. The executable file loading system includes at least one slave core and at least one master core, wherein the memory capacity of the slave core's running space is smaller than the memory capacity of the master core's running space, and the operating frequency of the slave core is lower than the operating frequency of the master core; the slave core and the master core are communicatively connected; the master core is used to receive a loading request triggered by the slave core, the loading request carrying an identifier of the executable file to be run; the master core is used to load the corresponding executable file into the master core's running space to run the corresponding executable file, or to load the corresponding executable file into the slave core's running space to run the corresponding executable file, based on the identifier of the executable file to be run carried in the loading request.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an executable file loading system and chip based on multi-core heterogeneity. Background Technology

[0002] With the development of computer technology, the improvement of chip design capabilities, and the increasing demands of applications, multi-core systems are being used more and more widely in products. Current multi-core heterogeneous systems generally include multiple processing cores such as large cores and small cores. Large cores have their own independent resources, including external DDR memory and SRAM, and can be single-core or multi-core. Small cores also have their own independent resources, including RAM, and are generally single-core. Small cores are typically general-purpose MCU-level processing cores with limited memory resources.

[0003] On the one hand, the access frequency of large cores is much higher than that of small cores. The pipeline resources and processing bit width of small cores are relatively limited, and their basic capacity is at the KB level. Therefore, when small cores are faced with functional code with excessive computational load (such as processing a batch of data in a loop without being interrupted), they cannot maintain the normal operation of the functional code with excessive computational load. In fact, the amount of computation required by the functional code may exceed the maximum amount of computation that small cores can handle. Thus, small cores do not have an advantage over large cores in terms of computing power.

[0004] On the other hand, when the amount of code to be executed is large (in functional code with a very large structural design, there are many branches and conditional transfer steps in the instructions to be executed, requiring a large cache space), the internal storage resources of the small core cannot meet the application requirements of a large amount of code. It only has the characteristic of fast response speed in real-time control at various stages of operation. Although the access frequency of the large core is higher, it does not have an advantage over the small core in real-time response because it loads more resources at a time, has longer pipeline resources, and longer bus scheduling time. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention discloses an executable file loading system and chip based on a multi-core heterogeneous processor architecture. It balances the application requirements of large code volumes and high computational demands by complementing a main core (large-core system) with a large operating space and high operating frequency with a slave core (small-core system) with a small operating space and low operating frequency. The specific technical solution is as follows:

[0006] The executable file loading system based on multi-core heterogeneity includes at least one slave core and at least one master core. The slave core's runtime memory capacity is smaller than that of the master core's runtime memory capacity, and the slave core's operating frequency is lower than that of the master core. The slave core and the master core are communicatively connected. The master core is used to receive a loading request triggered by the slave core, the loading request carrying an identifier of the executable file to be run. The master core is used to load the corresponding executable file into its runtime space to run the corresponding executable file, or to load the corresponding executable file into the runtime space of the slave core to run the corresponding executable file, based on the identifier of the executable file to be run carried in the loading request.

[0007] Further, the executable file includes a first executable file and a second executable file; the first executable file is first read from preset memory by the main core and then loaded into the main core's runtime space, and runs in the main core's runtime space; the second executable file is first read from preset memory by the main core and then loaded into the slave core's runtime space, and runs in the slave core's runtime space; wherein, the amount of code corresponding to one first executable file is less than the amount of code corresponding to a preset number of second executable files, and the computing power required by one first executable file is greater than the computing power required by one second executable file; wherein, the content of the first executable file includes a set of functions corresponding to a first preset algorithm; wherein, the content of the second executable file includes a portion of functions divided by the second preset algorithm; the content of a preset number of second executable files constitutes a set of functions corresponding to the second preset algorithm; wherein, the first and second executable files originate from the memory of the main core's peripheral device and are read into the preset memory by the main core; the preset memory is the memory space set up inside the main core, which is different from the main core's runtime space.

[0008] Furthermore, when the main core loads the first executable file into its runtime space, the main core controls the first executable file to run within its runtime space; wherein, the first executable file is determined by the slave core to trigger the calculation of the corresponding function; wherein, the operating frequency of the main core matches the computing power required to run the first executable file.

[0009] Furthermore, the slave core's operating space includes an address reuse area; when a preset number of second executable files that run at different times are assigned to the same address reuse area, before each second executable file is run, the master core first loads the second executable file into the operating address of the address reuse area, overwriting the original content stored in the operating address, and then the slave core runs the second executable file, so as to realize the time-sharing reuse of the slave core's operating space.

[0010] Furthermore, before the slave core runs the second executable file corresponding to the first function, the master core reads the second executable file corresponding to the first function from the preset memory and loads it into the running address of the address reuse area; then, before the slave core runs the second executable file corresponding to the second function, the master core reads the second executable file required by the second function from the preset memory and loads it into the running address of the address reuse area, overwriting the second executable file corresponding to the first function, and the slave core stops running the second executable file corresponding to the first function, thus realizing time-sharing multiplexing of the address reuse area; wherein, the first function and the second function are two functions that are not allowed to run simultaneously; wherein, the second executable file corresponding to the first function is the second executable file required to execute the first function, and the second executable file corresponding to the second function is the second executable file required to execute the second function.

[0011] Furthermore, the address reuse area is divided into multiple parallel execution address segments; each parallel execution address segment is a non-overlapping memory region; before running multiple second executable files simultaneously within the address reuse area, the main core first reads multiple second executable files that are allowed to run simultaneously from the preset memory, then loads the contents of each read second executable file into a corresponding parallel execution address segment, and then the slave core runs the second executable files within each parallel execution address segment simultaneously; wherein, the second executable files within each parallel execution address segment are allowed to be overwritten by the most recently loaded second executable file, such that the number of second executable files that have run within the corresponding parallel execution address segment is equal to the preset number.

[0012] Furthermore, if the slave core does not trigger a load request, the master core loads the first executable file into its runtime space, and the master core does not load the second executable file into the slave core's runtime space, so that neither the first executable file nor the second executable file runs.

[0013] Furthermore, the slave core's operating space includes a resident area, and the executable file includes a third executable file; after the executable file loading system is powered on and started, before the master core receives the loading request triggered by the slave core, the master core reads the third executable file from the peripheral memory and loads it into the resident area, and then the slave core controls the third executable file to run in the resident area; wherein, the third executable file is not stored in the preset memory, and continues to run after the executable file loading system is started; wherein, the third executable file originates from the master core's peripheral memory.

[0014] Furthermore, after the executable file is loaded into the execution space of the main kernel or the execution space of the slave kernel, the functions to be called within the executable file are first registered to a structure with global variables and global functions by executing the entry function, so as to call the registered functions in different memory areas; wherein, the functions to be called within the executable file come from the same executable file and / or different executable files; each function is configured to correspond to a specific function.

[0015] Furthermore, after the main core starts up, before receiving the load request triggered by the slave core, the contents of all executable files are stored in the preset memory according to a preset file management format; wherein, after the function called in the executable file finishes running in the main core's runtime space, the main core transfers the calculation result of the function called in the executable file to the shared memory, and then notifies the slave core to complete the calculation; the function called in the executable file is determined by the load request triggered by the slave core; wherein, the shared memory is located between the main core and the slave core, and the capacity of the shared memory is smaller than the capacity of the slave core's runtime space.

[0016] Furthermore, all executable files are configured by the main kernel to be managed by a file system. The file system records, but is not limited to, the offset address, file length, checksum, address of the entry function, execution address, and identifier of each executable file. Each executable file's identifier is configured as a unique number to facilitate the main kernel's search for the required executable file. After the main kernel starts, before receiving a load request triggered by the slave kernel, it reads the file system into the preset memory. Executable files are binary files compiled from code and allocated execution addresses during compilation, allowing them to run at the corresponding execution addresses. Before being read by the main kernel, all executable files are stored in the main kernel's peripheral memory in a pre-defined file management format, enabling the main kernel to use the file system to search for the required executable file. The information included in the pre-defined file management format originates from the contents recorded by the file system, facilitating loading by the main kernel into the specified execution address.

[0017] Furthermore, the slave core and the master core notify each other of a load request via a hardware interrupt. The type of the load request is associated with a pre-configured communication protocol, and the interaction instructions between the slave core and the master core are configured to be transmitted through the shared memory. When the slave core triggers the load request to the master core, the slave core is configured to send a message queue containing an identifier of the executable file to be run to the master core.

[0018] A chip comprising the multi-core heterogeneous executable file loading system disclosed in the aforementioned technical solution.

[0019] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0020] To address the challenges of executing computationally intensive code, this invention loads a first executable file onto the main core, leveraging the main core's large storage space and high operating speed to help the slave cores accelerate the calculation of functions included in the first executable file. This solves the problem of insufficient computing power in the associated microcontroller (equivalent to a low-performance slave core) through memory space transfer, without sacrificing the real-time performance of the slave core.

[0021] In addition, in order to cope with the execution of code with a long process (code programs with a large amount of code but excluding loop functions), the present invention loads a second executable file into the slave kernel and performs time-sharing multiplexing or parallel execution of the second executable files in different address ranges in the running space of the slave kernel. Thus, by dynamically loading executable files in the kernel with small memory resources, the execution of firmware with a large amount of code can be guaranteed.

[0022] Specifically, the first executable file and the second executable file are moved to different kernels to run the relevant algorithms. Both the first executable file and the second executable file are loaded into the corresponding kernel's runtime space by the main kernel and run the relevant algorithms in the corresponding kernel's runtime space in a way that is adapted to the working frequency level and memory resources. This allows large firmware (with a large amount of code) to run in a time-sharing multiplexing manner in a small memory environment, and also allows the use of large memory space to help run code with a large amount of computation (high computation speed requirements) from the slave kernel. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of an executable file loading system based on multi-core heterogeneity disclosed in an embodiment of the present invention. Detailed Implementation

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

[0025] Furthermore, the terms "system" and "network" are often used interchangeably in this paper. The term "and / or" in this paper merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this paper generally indicates that the preceding and following related objects have an "or" relationship.

[0026] In existing multi-core heterogeneous systems or multi-core processors, different cores run different operating systems. Generally, there is no resource parameter sharing between cores running different operating systems. Regardless of whether the code data corresponding to the required function is directly copied to the execution space of the small core or to the execution space of the large core, it is difficult to ensure that the small core can run large-scale code normally when running algorithms of the same scale (or supporting the same scale of computing power), and it is also difficult to ensure that the large core can process large-scale code in real time. Therefore, it is urgent to design a complementary system with a large execution space and high operating frequency (large core system) and a small execution space and low operating frequency (small core system) to meet the application requirements of large code volume and high computing speed.

[0027] Real-time performance can be defined as the system's responsiveness within a specified time. Generally, applications with real-time requirements have two prominent characteristics: strong time-sensitivity, such as short switching times between different tasks, fast interrupt response, and low latency. The fewer pipeline resources and the smaller the bit width of a processor core, the stronger its real-time performance; therefore, smaller cores have better real-time control than larger cores. Computing power is a unit of measurement for the amount of data processed by a single processor core within a given communication time. It is related to the processor's operating frequency and computational bit width. The magnitude of computing power represents the speed at which the processor architecture can process binary information. In this invention, it is related to the amount of data that an executable file can process per unit time during execution.

[0028] This invention discloses an executable file loading system based on multi-core heterogeneity. The system includes at least one slave core and at least one master core. The memory capacity of the slave core's execution space is smaller than that of the master core, and the slave core's operating frequency is lower than that of the master core. Specifically, when the slave core is an ARM Cortex-M0 series microcontroller core, the master core is an ARM Cortex-A7 series processor core. In this case, the memory capacity of the slave core's execution space is significantly smaller than that of the master core, and the slave core's operating frequency is significantly lower than that of the master core. Each slave core and each master core can be assigned a corresponding number, i.e., a core number. Both the slave core and the master core belong to the processing cores of a multi-core processor. (See also...) Figure 1It is understood that the slave core and the master core are communicatively connected. A memory is mounted on the periphery of the master core as its peripheral memory, used to store executable files. This memory is code storage and can be FLASH memory. The slave core and the master core can communicate with each other through a shared memory, where both can access the instruction information cached in the shared memory. The executable file loading system is a multi-core heterogeneous system, with the master core being a large core and the slave cores being small cores. The master core receives loading requests triggered by the slave cores. These loading requests carry the identifier of the executable file to be run. To execute a computationally intensive or code-intensive executable file, the slave core triggers a loading request to the master core, including data and computation requests, which involve loading which executable files and running which functions within those files. Then, the master core loads the executable file and triggers either the master core or the slave core to call the corresponding function for computation. Each request type has a custom protocol. In this embodiment, the master core is used to read the executable file according to the identifier of the executable file to be run carried in the loading request. Specifically, it reads the corresponding executable file from the preset memory set inside the master core and loads it into the execution space of the master core, so that the slave core can use the master core to run the corresponding executable file. Generally, multiple master cores are designed in this executable file loading system to share the large amount of computation. Specifically, when loaded into the execution space of the master core (specifically loaded into the execution address), the slave core can use the master core to run functions with high computing power, or even functions that exceed the maximum computing power (which can be regarded as the computing speed) that the slave core can bear. This allows the master core to help the slave core execute functions, share the computing power of the slave core without affecting the real-time performance (performance of real-time data processing) of the slave core. This solves the problem of insufficient computing power of the associated microcontroller (equivalent to the low computing power slave core) by transferring memory space. In addition, the main core can also load the read executable file into the execution space of the slave core according to the identifier of the executable file to be run carried in the loading request, so as to run the corresponding executable file. The corresponding executable file is read from the preset memory set in the main core and loaded into the execution space of the slave core. Specifically, time-sharing multiplexing can be performed on a specified address range in the execution space to complete the calculation of functions with a large amount of code according to a certain time period. Thus, under the reading action of the main core, the movement or copying of the executable file in different memory spaces is controlled. When loaded into the execution space of the slave core (specifically loaded into the execution address), the execution space in the slave core is time-sharing multiplexed to meet the application requirements of functions with many branches, so as to ensure the execution of large amounts of code firmware in a kernel with small memory resources.

[0029] It should be noted that the small core is configured to actively send request commands to the large core, and the large core is configured to be in a passive response state. In this embodiment, the aforementioned small core is configured as a slave core, and the aforementioned large core is configured as a master core.

[0030] In the above embodiments, the executable file to be run includes a first executable file and a second executable file; the first executable file is first read from preset memory by the main core and then loaded into the main core's runtime space, and runs in the main core's runtime space. Specifically, the corresponding functions in the first executable file are loaded by the main core before they start running, used to execute computationally intensive algorithm functions that should originally be executed by the slave core. The main core's runtime space can store executable files and data; the second executable file is first read from preset memory by the main core and then loaded into the slave core's runtime space. Within the execution space of the slave core, the execution begins only after the corresponding functions in the second executable file are loaded by the main core. Multiple second executable files are loaded according to a certain clock cycle. These second executable files are the complete executable files compiled from the code corresponding to a pre-defined algorithm. To facilitate the execution of the algorithm by the slave core with limited memory resources, each second executable file is configured as an executable file corresponding to a functional module defined by the pre-defined algorithm. Optionally, the slave core runs multiple second executable files in batches within the same execution space using a time-sharing multiplexing method. It should be noted that the first and second executable files originate from the memory of the main core's peripheral devices and are read into the preset memory by the main core. The preset memory is a memory space set up internally by the main core, used to store executable files originating from the memory of the main core's peripheral devices, and is different from the main core's execution space.

[0031] In this embodiment, the amount of code corresponding to a first executable file is less than the amount of code corresponding to a preset number of second executable files. That is, the amount of code for functions included in a first executable file is less than the sum of the amount of code for functions included in a preset number of second executable files. The computational power required for a first executable file is greater than the computational power required for a second executable file; that is, the computational power required to run a first executable file is greater than the computational power required to run a second executable file. The content of the first executable file includes a set of functions corresponding to a first preset algorithm, including loop functions, to implement large loop control functionality. This affects the computational speed of the corresponding kernel. The requirements are high, and a loop function cannot be arbitrarily split into multiple functional functions, especially in loop functions with many steps. The content of the second executable file includes some functions divided by the second preset algorithm. When the content of the second executable file is a function that performs a single function (simple arithmetic operations) and is not a loop function, one second executable file can be used as the executable file for running a unit function. The content of a preset number of second executable files forms a set of functions corresponding to the second preset algorithm. In addition, the preset number is negatively correlated with the memory size occupied by the executable file used to run the unit function. Therefore, under the loading request triggered by the slave core, the executable file loading system can load the first executable file into the main core through the main core to execute algorithms with high computational power, or it can load the second executable files into the slave cores sequentially through the main core to execute algorithms with large code size.

[0032] It should be noted that both the first executable file and the second executable file are read and loaded by the main core, and the program code run by the main core is also loaded into the specified memory space by the main core at the request of the slave core.

[0033] In one embodiment, when the master core loads the first executable file into its runtime space, the master core controls the first executable file to run within its runtime space. Based on a loading request triggered by the slave core, the master core, upon receiving the loading request, can replace the slave core in running functions with higher computational power. The first executable file is determined by the slave core to trigger the master core to calculate the corresponding function, utilizing the memory space specified by the master core to run the algorithm corresponding to that function. In some embodiments, in loop operations that should originally be executed by the slave core, if the computational load (computational speed) required for the slave core to run the related loop operations within the same specified time easily exceeds the maximum computational load (computational speed) that the slave core can handle, then the computational time cannot meet the computational speed requirements of the related loop operations. This is because the runtime space of the slave core in this embodiment is a low-speed memory space. The operating frequency of the main core is matched with the computing power required to run the first executable file. In particular, the processing speed of the main core is equal to the computing speed required to run the first executable file, so that the main core can run a first executable file completely within the corresponding clock cycle. Compared with the slave core with a lower operating frequency, the main core can more easily achieve the function of its corresponding function within a specified time.

[0034] It should be noted that the load address of the first executable file is configured to be equal to the running address of the first executable file in the running space of the main core. Before the first executable file starts running, the functions included in the first executable file and the data required for its operation and debugging have been loaded from the preset memory into the running address in the running space of the main core. Therefore, before each execution of a function included in the first executable file corresponding to a certain function, the contents of the first executable file are copied to the running address, and then the first executable file is run.

[0035] On the other hand, in existing technologies, if a large amount of algorithmic code is run in a small core (the slave core), the small core cannot provide sufficient runtime memory resources. If a complete system function is run in a large core, all the required functions are loaded onto the large core. Due to the excessively long pipeline structure, bus scheduling, and numerous execution steps of the large core, its real-time control data and branch scheduling efficiency are inferior to that of the small core. Especially when designing complex functions, there is often a situation where the memory available for newly developed functions is insufficient. In this case, it is necessary to optimize the runtime space according to the actual functional requirements.

[0036] As one example, combined with Figure 1It is understood that the execution space of the slave core includes an address reuse area. When the preset number of second executable files that do not run simultaneously are assigned to the same address reuse area, before running each second executable file, the master core first loads the second executable file into the execution address of the address reuse area, overwriting the original content stored at that execution address, and then the slave core runs the second executable file. Specifically, the execution addresses loaded into the time-division multiplexed second executable files are the same, their execution spaces assigned by the master core are the same and can be reused, and correspondingly, the contents of each time-division multiplexed second executable file are mutually exclusive, i.e., they are not allowed to run simultaneously at the same execution address, thus realizing the time-division multiplexing of the slave core's execution space.

[0037] Based on the above embodiments, before the slave core runs the second executable file corresponding to the first function, the master core reads the second executable file corresponding to the first function from the preset memory and loads it into the running address of the address reuse area. Then, the currently recorded second executable file runs in the running address of the address reuse area to implement the first function. Alternatively, after the slave core finishes running the second executable file corresponding to the first function, before the slave core runs the second executable file corresponding to the second function, the master core reads the second executable file corresponding to the second function from the preset memory and loads it into the running address of the address reuse area, overwriting the first function. In some embodiments, the second executable file corresponding to the first function can be cleared according to actual memory requirements. The slave core stops running the second executable file corresponding to the first function, and then the slave core runs the second executable file corresponding to the second function. The second executable file corresponding to the first function is the second executable file required to execute the first function, and the second executable file corresponding to the second function is the second executable file required to execute the second function. The first function and the second function are two functions that cannot run simultaneously; they can be the same two functions or two different functions, thus achieving time-sharing multiplexing of the address reuse area. In this way, only by copying the corresponding second executable file to the same running address in the address reuse area after any function is switched and before execution, the reuse of the address reuse area can be achieved, allowing some code to only need to run during a certain time period or under certain scenarios.

[0038] It should be noted that the second executable file required to run the first function is placed in the address segment of the preset memory, and the second executable file required to run the second function is placed in the address segment of the preset memory. Under the command of the master core, if the second executable file corresponding to the first function and the second executable file corresponding to the second function are loaded simultaneously in the slave core, they will occupy two memory spaces, which will consume a lot of running space in the slave core. This embodiment solves this problem by specifying that the running address of the first function and the running address of the second function both point to the same memory space in the slave core, that is, the loading address both point to the running address of the address reuse area, which is the running address specified by the master core in the slave core for each second executable file.

[0039] Preferably, when the preset quantity is equal to 2, the slave core will by default allocate two different memory spaces for loading addresses: one is the memory space occupied by the second executable file corresponding to the first function, and the other is the memory space occupied by the second executable file corresponding to the second function. The size of the memory space pointed to by the running address within the address reuse area is the maximum of the two. Each second executable file records the specified loading address and running address information. The first function and the second function can constitute all the functions of a complete algorithm.

[0040] In another embodiment, the address reuse area is divided into multiple parallel execution address segments; each parallel execution address segment is a non-overlapping memory region; before running multiple second executable files simultaneously in the address reuse area, the main core first reads multiple second executable files that are allowed to run simultaneously from the preset memory, then loads the contents of each read second executable file into a corresponding parallel execution address segment, and then the slave core runs the second executable files in each parallel execution address segment simultaneously, so as to achieve the purpose of running multiple second executable files in parallel in the address reuse area.

[0041] In this embodiment, the second executable file loaded on each parallel execution address segment is allowed to be overwritten by the most recently loaded second executable file, realizing time-sharing multiplexing of the address reuse area. This further ensures that the number of second executable files that have run within the corresponding parallel execution address segment equals the preset number. In some implementations, the memory space capacity of the address reuse area is 64KB, and the preset number is a positive integer multiple of 2. The first second executable file is loaded in the first 3KB of the parallel execution address segment, and the second second executable file is simultaneously loaded in the last 32KB of the parallel execution address segment. Then, when the preset number is greater than 2, the executable files in the first 3KB of the parallel execution address segment are overwritten and updated by the second executable files loaded in subsequent cycles. Similarly, the executable files in the last 3KB of the parallel execution address segment are overwritten and updated by the second executable files loaded in subsequent cycles. Therefore, running in a low-speed memory space like the address reuse area in a time-sharing or parallel execution manner can process the code corresponding to algorithms with large amounts of code and many branch steps in a short time.

[0042] As one example, combined with Figure 1 It is understood that the slave core's operating space includes a resident area, and the executable file includes a third executable file. After the executable file loading system powers on and before the master core receives the loading request triggered by the slave core, the master core reads the third executable file from the peripheral memory and loads it into the resident area, without needing to move it to the preset memory. The slave core then controls the third executable file to run in the resident area. The third executable file originates from the master core's peripheral memory; it is not stored in the preset memory and remains running after the executable file loading system starts. It should be noted that the code corresponding to the third executable file is resident code, which originates from the software application layer, hardware driver layer, and some common function libraries in the operating system. After the master core loads the third executable file into the slave core, regardless of whether the slave core triggers the loading request to the master core, the third executable file remains running in the resident area to maintain the normal operation of the operating system and associated hardware devices where the slave core resides, allowing the slave core's processing core to remain active.

[0043] In the foregoing embodiments, if the slave core does not trigger the load request, the master core does not load the first executable file into its runtime space, and the functions (including related data and variables) included in the first executable file are not copied from the preset memory to the master core's runtime space, so that the functions included in the first executable file are not called by the master core; the master core also does not load the second executable file into the slave core's runtime space, and the slave core does not call the functions included in the second executable file; thus, neither the first nor the second executable file runs, but the third executable file can remain running in the resident area. Therefore, the load request serves as startup and runtime information for the specified algorithm function, notifying the master and slave cores of corresponding data or computation requests.

[0044] In summary, the aforementioned embodiments employ a complementary system of a main core (large-core system) with a large operating space and high operating frequency, and a slave core (small-core system) with a small operating space and low operating frequency, to address the application requirements of large code volumes and high computational demands. To handle the execution of computationally intensive code, a first executable file is loaded onto the main core, leveraging its large storage space and high operating speed to help the slave core accelerate the function calculations included in the first executable file. This addresses the insufficient computing power of the associated microcontroller (equivalent to the low-computing-power slave core) through memory space transfer without sacrificing the real-time performance of the slave core. Furthermore, to handle the execution of lengthy code (code with a large amount of code but excluding loop functions), a second executable file is loaded onto the slave core. The running space of the slave core is time-division multiplexed or used to run the second executable file in parallel within different address ranges. This ensures the completion of large-scale code firmware execution even in a kernel with limited memory resources. Specifically, the first and second executable files are moved to different kernels to run the relevant algorithms. Both the first and second executable files are loaded into the corresponding kernel's runtime space by the main kernel. Alternatively, developers can choose whether to execute the first or second executable file based on their actual programming needs. The algorithms run in the corresponding kernel's runtime space in a manner adapted to the operating frequency and memory resources. This allows for time-sharing of large firmware (code with many execution steps) in a small memory environment, and also enables the use of large memory space to help small cores run computationally intensive code (requiring high processing speed). Therefore, by allocating executable files with matching computing power and code size to the corresponding kernels to implement complex algorithm functions, dynamic loading can be achieved on multiple processing cores with relevant performance capacity in multi-core processors (or multi-core heterogeneous systems). This also resolves the contradiction between computing power and real-time performance in multi-core heterogeneous systems, enhances the flexibility of embedded system development models, and allows multi-core heterogeneous systems to fully utilize their multi-core, multi-processing capabilities.

[0045] As one embodiment, after an executable file is loaded into the execution space of the main core or the execution space of the slave core, at the corresponding execution address, the functions to be called within the executable file are first registered to a structure with global variables and global functions by executing the entry function, forming specified linking information and completing the binding between different executable files. This allows the main core or slave core to call the registered functions in different memory regions. During the execution of one executable file, functions registered as global functions in other executable files can be called. Thus, the executable file loading system possesses linking and loading functions. When a function call occurs, the executable file loading system transmits the name of the executable file, the function's number within the executable file, the core number of the main core or slave core, and the function parameters, then parses them, and finally completes the function call. This allows the execution address and data length information to be obtained through the global variables in the linking information, facilitating the transfer of registered function information (parameters and variables) when switching between second executable files required for different functions, and also facilitating mutual calls between registered functions in the first and third executable files.

[0046] It should be noted that whenever a function in an executable file is detected to be registered in the global variable area, a local function within a single executable file can be defined as a global function that can be called by all executable files. This definition is known to the main kernel to support function calls by various executable files during runtime. Other executable files can then call this global function. The global variable area can be composed of a pre-defined global variable function structure, recorded in the executable file. Whenever a function is registered in the global variable area, a corresponding global function declaration is added to the global variable function structure. Specifically, the name, function type, parameter types, number, and order of the newly registered function are notified to the main kernel and / or the slave kernel. This allows the executable file loading system to perform a check when an executable file calls the function, without allocating new memory. The functions to be called within each executable file originate from the same executable file and / or different executable files; each function is configured to correspond to a specific function.

[0047] It should be noted that the address of the first instruction executed by the entry function is called the function's entry address, through which the interface function can be located. The interface functions required within the executable file originate from the same executable file and / or different executable files, including but not limited to the first, second, and third executable files. Each function is configured to correspond to a specific function, namely a computational function. After a function is compiled, it becomes a series of instructions recorded in the executable file. When the corresponding function is called, the function instruction code (binary data) occupies a storage unit in the runtime space. When an interface function is called, the flow jumps to that interface function to continue execution. When the interface function is called, the linking information can realize the linking relationship between that interface function and the interface functions of executable files in different runtime spaces, enabling the executable file to achieve dynamic linking and configuration of all functions in the operating system, achieving dynamic maintenance and expansion of the system functions of the executable file loading system.

[0048] As one embodiment, after the main core starts up, before receiving the loading request triggered by the slave core, the main core first reads all executable files from the memory of the main core's peripheral device into the preset memory, and controls the read executable files to be saved in the preset memory in a pre-set file management format, so that the main core directly reads the executable files from the preset memory and encapsulates them into the corresponding running space according to the file management format. Preferably, the aforementioned third executable file is excluded. The read executable file is a set of related function variables saved in the preset memory. In particular, for two or more executable files that will not run at the same time, they can also be specified to be loaded into the preset memory. They can be loaded as parameters into the running space of the main core and / or the running space of the slave core to speed up the implementation of the corresponding algorithm functions. Therefore, the master core does not need to read the executable file from the external storage space of the master core when the slave core triggers the request. Instead, it can directly access the preset memory inside the master core. When the preset memory is DDR memory, the master core can complete the loading of the executable file in the corresponding running space in microseconds, ensuring the real-time interaction between the master core and the slave core and the shared memory respectively.

[0049] In the foregoing embodiments, after the functions called in the executable file have finished running in the execution space of the master core or the execution space of the slave core, the master core transfers the calculation results of the functions called in the executable file to shared memory, and then notifies the slave core to complete the calculation. The functions called in the executable file are determined by a load request triggered by the slave core, and are agreed upon by the slave core and the master core before the executable file runs, specifically determining which executable file functions to implement. In some embodiments, after the first executable file has finished running in the master core, the functions included in the first executable file output corresponding calculation results. Then, the master core transfers the calculation results of the functions included in the first executable file to the shared memory, and then notifies the slave core of the completion of the calculation, so that the slave core and the master core share the calculation results of the corresponding functions.

[0050] It should be noted that the shared memory is located between the main core and the slave core. The shared memory is located outside the main core and also outside the slave core. The capacity of the shared memory is smaller than the capacity of the running space of the slave core. This creates a shared instruction information area with sufficient memory capacity between the main core and the slave core to accommodate various types of communication instructions and calculation results, thereby accelerating the information interaction between the two on-chip hardware components, the main core and the slave core. Specifically, it accelerates the transmission of requests from the slave core to an executable file in the corresponding running space.

[0051] As one embodiment, all executable files are configured by the main kernel to be managed by the file system. In this embodiment, all executable files are binary files compiled from corresponding code. Specifically, they are compiled by a compiler and stored in a dedicated code storage area of ​​the main kernel's peripheral device. That is, the executable files compiled by the compiler are first stored in the memory of the main kernel's peripheral device. During compilation, all executable files are assigned running addresses and recorded in the contents of the file system, ensuring that the main kernel accurately loads the executable files into the corresponding running addresses for execution. In this embodiment, after the main core starts up, before receiving the load request triggered by the slave core, it reads the file system from the main core's peripheral memory into the preset memory, so that the main core can use the file system to search for the executable file to be run. The file system records, but is not limited to, the executable file's offset address, file length, file checksum, address of the executable file's entry function (for function calls between different executable files), the executable file's running address, and the executable file's identifier. Before the relevant executable file is read into the preset memory, it is stored in the main core's peripheral memory in a pre-defined file management format. The information included in the pre-defined file management format comes from the content recorded by the file system, so that it can be obtained by the main core and loaded into the specified running address. Each executable file is configured with a unique identifier, so that the main core can search for the required executable file from the dedicated code storage area or the preset memory. In this embodiment, after the main core starts up, before receiving the load request triggered by the slave core, the file system is read into the preset memory. During the same reading phase, the executable file is also read into the preset memory, which can speed up the loading process of the slave core request.

[0052] It should be noted that the code for the relevant functions is compiled within the CPU. After compilation, multiple executable files are generated. The longer the code, the more executable files of the corresponding type are compiled, such as the second executable file mentioned in the previous embodiment. The CPU then organizes these executable files using a custom-formatted file system to organize and manage them, creating a file system, which is then stored in the flash memory space of the main core peripheral (the dedicated code storage area). After the main core starts up, before receiving the loading request triggered by the slave core, both the executable files and the file system are read from the flash memory space of the main core peripheral into the preset memory. The main core accesses any executable file through the custom file system. Because the file system records every detail, if the main core is interrupted during a loading process or function call, it can directly backtrack and reorganize the interrupted part based on these records in the file system, without having to spend time checking other parts. Therefore, the reorganization speed is quite fast, requiring almost no time.

[0053] Based on the above embodiments, the slave core and the master core notify each other of a load request via a hardware interrupt, wherein the type of the load request is associated with a pre-configured communication protocol; the interaction instructions between the slave core and the master core are configured to be transmitted through the shared memory; in some embodiments, when the slave core triggers the load request to the master core, the slave core is configured to send a message queue containing the identifier of the executable file to be run to the master core, thereby reducing the waiting time in the logical flow.

[0054] In some embodiments, after the master core starts up, before receiving the loading request triggered by the slave core, the master core interacts with the slave core through a pre-configured communication protocol to determine the executable file to be loaded and run and the functions to be executed. Then, the master core first reads the executable file under the agreement into the preset memory, and then loads the executable file stored in the shared memory into the execution space of the slave core as relevant parameters of the runnable calculation function. After the executable file finishes running in the execution space of the main core or the slave core, the functions called by the executable file will output the corresponding calculation results. Then, the main core will transfer the calculation results of the functions included in the first executable file to the shared memory, and then notify the slave core to complete the calculation through a hardware interrupt. This allows the slave core and the main core to share the calculation results of the corresponding functions. In this way, the executable file loading system can run the relevant algorithm functions in the execution space of the corresponding kernel in a way that is adapted to the working frequency level and memory resources. This promotes the running of large firmware in a time-sharing manner in a small memory environment (the execution space of the slave core), and can also use a large memory space (the execution space of the main core) to speed up the execution of computationally intensive code and algorithm tasks that cannot be achieved by the computing power speed of the slave core.

[0055] It should be noted that hardware interrupts can generate an asynchronous signal indicating that attention or a change is needed in the execution of a synchronous event. Hardware interrupts are a way to avoid wasting valuable processor time by polling loops and waiting for external events. As a separate, controlled thread system within the executable loading system, they can be implemented in hardware or integrated into the slave core's memory subsystem. Preferably, hardware interrupts generally refer to interrupt requests issued by computer peripherals, such as keyboard interrupts, printer interrupts, timer interrupts, etc.

[0056] Based on the foregoing embodiments, a chip is also disclosed, comprising the multi-core heterogeneous executable file loading system mentioned in the foregoing embodiments, thereby constituting a multi-core heterogeneous chip. When the chip is a multi-core processor, the slave core is a processing core with a smaller operating space and lower operating frequency belonging to the multi-core processor, and the master core is a processing core with a larger operating space and higher operating frequency belonging to the multi-core processor. The chip is designed as a complementary system of a master core (large-core system) with a large operating space and high operating frequency and a slave core (small-core system) with a small operating space and low operating frequency to meet the application requirements of large code volume and high computational load. To cope with the execution of computationally intensive code, the chip loads a first executable file to the master core, leveraging the advantages of the master core's large storage space and high operating speed to help the slave core accelerate the completion of function calculations included in the first executable file. This solves the problem of insufficient computing power of the associated microcontroller (equivalent to the low-computing-power slave core) through memory space transfer, without sacrificing the real-time performance of the slave core. In addition, in order to handle the execution of code with a long process (a large amount of code but excluding loop functions), the chip loads a second executable file into the slave core and performs time-sharing multiplexing or parallel execution of the second executable file in different address ranges within the running space of the slave core. This ensures the completion of the execution of firmware with a large amount of code in a kernel with limited memory resources.

[0057] Therefore, in order to implement complex algorithm functions, executable files with matching computing power and code size are allocated to the corresponding kernels. Dynamic loading can be achieved on multiple processing cores with relevant performance capacity of the chip. This also solves the contradiction between computing power and real-time performance of chips under multi-core heterogeneity, allowing chips under multi-core heterogeneity to give full play to their multi-core and multi-processing capabilities.

[0058] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0059] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0060] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. An executable file loading system based on multi-core heterogeneity, characterized in that, The executable file loading system includes at least one slave core and at least one master core, wherein the memory capacity of the slave core's running space is smaller than that of the master core's running space, and the slave core's operating frequency is lower than that of the master core's operating frequency; the slave core and the master core are connected in communication. The main core is used to receive a loading request triggered by the slave core, the loading request carrying an identifier of the executable file to be run; The main core is used to load the corresponding executable file into the main core's running space to run the corresponding executable file, or to load the corresponding executable file into the running space of the slave core to run the corresponding executable file, based on the identifier of the executable file to be run carried in the loading request. The executable file includes a first executable file and a second executable file; The first executable file is first read from the preset memory by the main core and then loaded into the main core's running space, and then run in the main core's running space; The second executable file is first read from the preset memory by the main core and then loaded into the execution space of the slave core, and then run in the execution space of the slave core; Among them, the amount of code corresponding to a first executable file is less than the amount of code corresponding to a preset number of second executable files, and the computing power required for a first executable file is greater than the computing power required for a second executable file; The contents of the first executable file include a set of functions corresponding to the first preset algorithm; The content of the second executable file includes a portion of the functions divided by the second preset algorithm; the content of a preset number of second executable files constitutes a set of functions corresponding to the second preset algorithm; The first executable file and the second executable file originate from the memory of the main core peripheral device and are read into the preset memory by the main core; the preset memory is the memory space set up inside the main core, which is different from the main core's running space.

2. The executable file loading system according to claim 1, characterized in that, When the main kernel loads the first executable file into the main kernel's running space, the main kernel controls the first executable file to run within the main kernel's running space; The first executable file is determined by the slave kernel to trigger the computation of the corresponding function; The operating frequency of the main core is matched with the computing power required to run the first executable file.

3. The executable file loading system according to claim 1, characterized in that, The operating space of the slave core includes an address reuse area; When a preset number of second executable files that run at different times are assigned to the same address reuse area, before each second executable file is run, the main core first loads the second executable file into the running address of the address reuse area, overwriting the original content stored in the running address, and then the slave core runs the second executable file to realize time-sharing reuse of the running space of the slave core.

4. The executable file loading system according to claim 3, characterized in that, Before the slave core runs the second executable file corresponding to the first function, the master core reads the second executable file corresponding to the first function from the preset memory and loads it into the running address of the address reuse area; Then, before the slave core runs the second executable file corresponding to the second function, the master core reads the second executable file required by the second function from the preset memory and loads it into the running address of the address reuse area, overwriting the second executable file corresponding to the first function, and the slave core stops running the second executable file corresponding to the first function, thereby realizing the time-sharing multiplexing of the address reuse area; Among them, the first function and the second function are two functions that are not allowed to run at the same time; The second executable file corresponding to the first function is the second executable file required to execute the first function, and the second executable file corresponding to the second function is the second executable file required to execute the second function.

5. The executable file loading system according to claim 3, characterized in that, The address reuse area is divided into multiple parallel running address segments; each parallel running address segment is a non-overlapping memory region. Before running multiple second executable files simultaneously in the address reuse area, the main core first reads the multiple second executable files that are allowed to run simultaneously from the preset memory, then loads the contents of each second executable file into a corresponding parallel execution address segment, and then the slave core runs the second executable files in each parallel execution address segment simultaneously. In this context, the second executable file within each parallel execution address segment is allowed to be overwritten by the most recently loaded second executable file, such that the number of second executable files that have been run within the corresponding parallel execution address segment is equal to the preset number.

6. The executable file loading system according to claim 1, characterized in that, If the slave core does not trigger a load request, the master core loads the first executable file into its runtime space, and the master core does not load the second executable file into the slave core's runtime space, so that neither the first executable file nor the second executable file runs.

7. The executable file loading system according to claim 1, characterized in that, The kernel's runtime space includes a resident region, and the executable file includes a third executable file; After the executable file loading system is powered on and started, before the main core receives the loading request triggered by the slave core, the main core reads the third executable file from the peripheral memory and loads it into the resident area, and then the slave core controls the third executable file to run in the resident area; The third executable file is not stored in the preset memory, and continues to run after the executable file loading system starts. The third executable file originates from the memory of the main core peripheral.

8. The executable file loading system according to claim 1, characterized in that, After the executable file is loaded into the execution space of the main core or the execution space of the slave core, the entry function is executed first to register the functions to be called in the executable file to a structure with global variables and global functions, so as to call the registered functions in different memory areas. The functions to be called within the executable file originate from the same executable file and / or different executable files; each function is configured to correspond to a specific purpose.

9. The executable file loading system according to any one of claims 1 to 6, characterized in that, After the main core starts up, before receiving the loading request triggered by the slave core, the contents of all executable files are stored in the preset memory according to the preset file management format; In this process, after the function called in the executable file finishes running in the main core's runtime space, the main core transfers the calculation result of the function called in the executable file to shared memory, and then notifies the slave core to complete the calculation; the function called in the executable file is determined by the load request triggered by the slave core. The shared memory is located between the master core and the slave core, and the capacity of the shared memory is smaller than the capacity of the slave core's running space.

10. The executable file loading system according to any one of claims 1 to 8, characterized in that, All executable files are configured by the main kernel to be managed by the file system; The file system records, but is not limited to, the offset address of the executable file, the file length of the executable file, the file checksum, the address of the entry function of the executable file, the running address of the executable file, and the identifier of the executable file; each executable file is configured with a unique identifier to facilitate the main kernel in searching for the executable file to be run. After the main core starts up, before receiving the load request triggered by the slave core, it reads the file system into the preset memory; An executable file is a binary file generated by compiling code. During compilation, a runtime address is allocated to the executable file, allowing it to run within that address. Before being read by the main kernel, all executable files are stored in the memory of the main kernel's peripheral device in a pre-defined file management format, so that the main kernel can use the file system to search for the executable files to be run. The information included in the pre-defined file management format comes from the content recorded in the file system, so that it can be loaded by the main kernel to the specified running address.

11. The executable file loading system according to claim 9, characterized in that, The slave core and the master core notify each other of a load request via a hardware interrupt. The type of the load request is associated with a pre-configured communication protocol, and the interaction instructions between the slave core and the master core are configured to be transmitted through the shared memory. When the slave core triggers the load request to the master core, the slave core is configured to send a message queue containing the identifier of the executable file to be run to the master core.

12. A chip, characterized in that, The executable file loading system based on multi-core heterogeneity as described in any one of claims 1 to 9.

Images