Application collaborative switching method and system based on multi-core heterogeneous AMP architecture

Abstract

The invention relates to the field of processor information, in particular to an application program collaborative switching method and system based on a multi-core heterogeneous AMP architecture, and the method comprises the following steps: after receiving an update instruction, firstly executing a preparation process to set a basis or path for loading a master core application program, a slave core application program and a bit stream update file; the method comprises the following steps of: executing an application program switching instruction, executing a bit stream update file synchronization instruction, initializing a main core and a slave core, realizing inter-core update synchronization, and after the dual-core application program is updated, starting the operation of the main core application program and informing the slave core of synchronous operation of the slave core application program. Compared with the prior art, the method provided by the invention solves the technical problem of asynchronous dual-core information.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of processor information processing. More particularly, the present application relates to a method and system for application program cooperative switching based on a multi-core heterogeneous AMP architecture. BACKGROUND

[0002] Linux system is an open source UNIX-like operating system, which is applied to software development, visual monitoring program running industrial products, cloud computing server, desktop operation and other aspects, and is suitable for scenarios requiring complex calculation and network function. RTOS (Real Time Operate System) is a system for data transmission with FPGA (Field-Programmable Gate Array) to run business programs with high real-time requirements, which is commonly used in industrial robot real-time control, brake control and aerospace flight control.

[0003] In order to make the parallel running of the above two systems to support complex industrial application environment (for example, using Linux as the monitoring data transmission / analysis of robot, and assisting with RTOS for real-time control), in the prior art, a Chinese application patent with publication number CN118860514A discloses a method for repeatedly loading from core based on ARM platform AMP architecture, which adopts AMP architecture to realize the parallel execution of the above two systems in master core (Master Core or CPU0) and remote core (Remote Core, Slave Core or CPU1). The above technology can support the independent and parallel execution of the two systems, but it lacks the expansion function of FPGA (Field-Programmable Gate Array) and does not have a direct information sharing / update mechanism for the two systems, resulting in the following shortcomings: (1) In the process of program switching, dynamic update of receiving FPGA bit stream update file is not supported; (2) In the process of program switching, information synchronization update between master core and remote core is not supported.

[0004] The above shortcomings cause the asynchronization of dual-core information processing, which is easy to cause feedback delay based on action or control delay based on analysis result, and seriously reduces the industrial control precision and user experience. SUMMARY

[0005] To solve the technical problem of asynchronization of dual-core information in the prior art, the present application discloses a method and system for application program cooperative switching based on a multi-core heterogeneous AMP architecture.

[0006] In a first aspect, the present application discloses a method for application program cooperative switching based on a multi-core heterogeneous AMP architecture, comprising: in response to the obtaining of the update instruction, a preparation process for supporting initialization of loading the master core application program, the slave core application program and the bitstream update file is executed; in response to completion of the preparation process, an application program switching instruction and a bitstream update file synchronization instruction are executed; in response to completion of the application program switching instruction and the bitstream update file synchronization instruction, a master core program initialization instruction is executed and a slave core program initialization instruction is sent to the slave core to achieve inter-core update synchronization; the master core application program is run and the slave core is informed to run the slave core application program; The bitstream update file synchronization instruction at least includes: The bitstream update file is stored in the non-volatile memory; The bitstream update file stored in the non-volatile memory is read and loaded to the specified interface.

[0007] Beneficial effects: After receiving the update instruction, the method first executes the preparation process to set the basis or path for loading the master core application program, the slave core application program and the bitstream update file, then executes the application program switching instruction, at the same time, executes the bitstream update file synchronization instruction, then initializes the master core and the slave core to achieve inter-core update synchronization, after the dual-core application program update is completed, the master core application program starts running and informs the slave core to run the slave core application program to run synchronously, thereby achieving the technical effect of dual-core information processing synchronization.

[0008] Preferably, the preparation process for supporting initialization of loading the master core application program, the slave core application program and the bitstream update file comprises: The master core application program, the slave core application program and the bitstream update file to be switched are selected from the non-volatile memory and moved to the specified directory position of the Linux system; The BootLoader program required for switching the application program is written into the specified position of the dynamic random access memory.

[0009] Preferably, the master core program initialization instruction is executed and the slave core program initialization instruction is sent to the slave core to achieve inter-core update synchronization, comprising: The master core program initialization instruction of the master core application program is executed in the Linux system; In response to completion of the master core program initialization instruction, the slave core is woken up based on a preset memory address to execute the slave core program initialization instruction of the slave core application program; In response to completion of the slave core program initialization instruction, a flag bit for informing the slave core application program to run is written into the specified position of the dynamic random access memory.

[0010] Before executing the application program switching instruction and the bit stream update file synchronization instruction, the method further comprises: triggering a slave core reset.

[0011] Preferably, triggering the slave core reset comprises: mapping a physical address of the SLCR to a virtual address; writing an unlock key into an unlock register of the SLCR; writing a slave core reset configuration into a CPU reset register; writing a lock key into a lock register of the SLCR; cleaning up a physical address mapping of the Linux system and releasing hardware resources of the Linux system.

[0012] Preferably, after triggering the slave core reset, the method further comprises: uninstalling a driver of the master core application program; executing a master core reset interrupt.

[0013] Preferably, the specified location comprises a memory address 0x00000000 and a memory address 0xFFFFFF00.

[0014] Preferably, after writing the BootLoader program required for switching the application program into the specified location of the dynamic random memory, the method further comprises: writing a jump instruction into the memory address 0x00000000 to point the PC pointer to the memory address 0xFFFFFF00.

[0015] Preferably, after writing the BootLoader program required for switching the application program into the specified location of the dynamic random memory, the method further comprises: writing a loop waiting instruction into the memory address 0xFFFFFF00.

[0016] In a second aspect, the application further discloses an application program cooperative switching system based on a multi-core heterogeneous AMP architecture, comprising a processor and a memory, and the memory stores computer program instructions, which realize the application program cooperative switching method based on the multi-core heterogeneous AMP architecture when executed by the processor.

[0017] The application has the following advantages: (1) Compared with the prior art, the application method overcomes the technical problem of double-core information asynchronization.

[0018] (2) Compared with the prior art, the application method can realize the cooperative and flexible update of the master core, the slave core and the FPGA under the multi-core heterogeneous AMP architecture and the dynamic update of the application program.

[0019] (3) Compared with the prior art, the system has higher flexibility and maintainability, better user experience, and is suitable for embedded systems in various scenarios such as industrial control and edge computing. BRIEF DESCRIPTION OF DRAWINGS

[0020] The above and other objects, features and advantages of the exemplary embodiments of the present application will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: Figure 1 is a flowchart of the application program cooperative switching method based on the multi-core heterogeneous AMP architecture in the first embodiment of the present application; Figure 2 is a structural schematic diagram of the application program cooperative switching device based on the multi-core heterogeneous AMP architecture in the second embodiment of the present application; Figure 3 is a structural schematic diagram of the application program cooperative switching system based on the multi-core heterogeneous AMP architecture in the third embodiment of the present application. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0022] The present embodiment discloses an application program cooperative switching method and system based on a multi-core heterogeneous AMP architecture, which is used to solve the technical problem of double-core information asynchronization in the prior art.

[0023] The specific embodiments of the present application will be described in detail below with reference to the drawings.

[0024] Embodiment one As shown in the figure, the present embodiment discloses an application program cooperative switching method based on a multi-core heterogeneous AMP architecture, which comprises: Figure 1 S10: In response to the acquisition of the update instruction, a preparation process for supporting the initialization of loading the main-core application program, the slave-core application program and the bitstream update file is executed.

[0025] ​In the embodiment, the obtaining of the update instruction can be a manual update based on manual clicking, or an automatic check update of the master core application periodically or according to a set condition. The master core application refers to an application running in a Linux operating system of the master core, used to provide a network service for a user and interact with the slave core. The slave core application refers to an RTOS system running in the slave core, used to transmit data with the FPGA and support running of a service with high real-time performance (for example, real-time regulation of a motor, adjustment of an aviation path, or brake control, etc.). The bitstream update file is a binary file used to update a configuration of the FPGA, which contains configuration information of internal logic circuits of the FPGA (for example, internal logic units, interconnection resources, and I / O configuration, etc.).

[0026] It should be noted that the method in the embodiment is implemented by using a Zynq-7000 series platform. When the configuration information of the internal logic circuits of the FPGA is changed, the bitstream update file is generated and stored in the non-volatile memory (which can be a FLASH), and a preparation process mounted from the non-volatile memory is used for subsequent reading and loading.

[0027] Specifically, the step S10 includes: S11: selecting the master core application, the slave core application, and the bitstream update file to be switched from the non-volatile memory, and moving to a specified directory position of the Linux system.

[0028] In the embodiment, the non-volatile memory is the FLASH, and the step S11 selects the master core application, the slave core application, and the bitstream update file to be switched from the FLASH and moves to the specified directory position of the Linux system, thereby providing a basis for execution or reading paths of the master core application, the slave core application, and the bitstream update file.

[0029] S12: writing a BootLoader program required for switching the application into a specified position of a dynamic random access memory (shared memory).

[0030] It should be explained that the BootLoader program is a code required by the method in the embodiment when updating the slave core application. If the code is missing, the slave core can only execute an application loaded in an initialization stage after power-on, and cannot update a subsequent application.

[0031] The specified position of the step S12 includes a memory address 0x00000000 and a memory address 0xFFFFFF00.

[0032] More specifically, after the step S12, the method of the embodiment includes: S13: write a jump instruction to the memory address 0x00000000 to point the PC pointer to the memory address 0xFFFFFF00.

[0033] It needs to be explained that after the master core is reset, the PC pointer will point to the memory address 0x00000000, and the instruction will be executed after the master core is reset, so that the master core starts running from the memory address 0xFFFFFF00.

[0034] S14: write a loop waiting instruction to the memory address 0xFFFFFF00.

[0035] It needs to be explained that when the above-mentioned loop waiting instruction is executed, the memory address 0xFFFFFFF0 will be emptied first, and then the slave core will wait for the value in the memory address 0xFFFFFFF0 to be modified. Once the value in the memory address 0xFFFFFFF0 is modified, the PC pointer points to the value in the memory 0xFFFFFFF0. At this time, the value in the memory 0xFFFFFFF0 is the entry address of the RTOS application program that the slave core needs to execute. The slave core will jump to the entry address and run the switched RTOS application program.

[0036] Through the steps S11-S14, the execution of the preparation process provides a reliable basis or path for loading the master core application program, the slave core application program and the bitstream update file.

[0037] After the step S10, in the embodiment, the following technical effects can be achieved by triggering the reset of the slave core: (1) Ensure state consistency. Specifically, before switching the application program or updating the bitstream update file, resetting the slave core can ensure that the slave core is in a known and consistent state, which helps to avoid potential problems caused by residual states of the previously running application program.

[0038] (2) Clear potential errors. Specifically, if the previously running application program of the slave core has errors or exceptions, the reset can clear these error states to provide a clean running environment for the new application program.

[0039] (3) Resetting the slave core can simplify the inter-core synchronization mechanism. Specifically, after the slave core is reset, CPU0 can more easily control the startup and initialization process of the slave core, ensuring that the application programs of both parties can start running synchronously.

[0040] In other embodiments, if it is necessary to maintain state information of the slave core and reduce reset overhead, the slave core can be considered not to be reset.

[0041] More specifically, the above-mentioned trigger of the slave core reset comprises: S100: mapping the physical address of the SLCR to a virtual address.

[0042] S101: writing the unlock key into the unlock register of the SLCR.

[0043] It should be explained that by the above-mentioned step S101, the unlock key is written into the unlock register of the SLCR to unlock the SLCR, otherwise the reset CPU related register cannot be written.

[0044] S102: writing the slave core reset configuration to the CPU reset register.

[0045] It should be explained that by the above-mentioned step S102, the CPU1 enters the soft reset state and stops its clock to ensure stable reset.

[0046] S103: writing the lock key into the lock register of the SLCR.

[0047] It should be explained that by the above-mentioned step S103, the system crash caused by accidental writing is prevented.

[0048] S204: cleaning up the physical address mapping of the Linux system and releasing the hardware resources of the Linux system.

[0049] It should be explained that by the above-mentioned step S104, it is ensured that the system resources are correctly released and reconfigured, avoiding resource conflicts or residual states affecting subsequent operations.

[0050] Further, in order to improve the synchronization rate of the master and slave cores, after the above-mentioned trigger of the slave core reset, the method of the embodiment can further comprise: uninstalling the driver of the master core application and executing the master core reset interrupt.

[0051] Specifically, the above-mentioned general operation of uninstalling the driver of the master core application comprises deleting device nodes, deleting device classes and cleaning up mapping resources, etc. By uninstalling the driver of the master core application, the problem of repeated loading of the driver when the master core runs the application in the Linux operating system is avoided, the occupation of system memory resources is reduced, and the response speed of the whole processing system is improved. The above-mentioned master core reset interrupt mainly refers to cleaning up the pending bit of the related interrupt register to ensure that the interrupt system can correctly respond to new events, avoid repeated processing of the same interrupt, and maintain system stability.

[0052] S20: in response to the completion of the preparation process, executing the application switching instruction and the bitstream update file synchronization instruction.

[0053] In the embodiment, the application program switching instruction can refer to switching the application program currently running in the master core or the slave core. For example, when the unmanned aerial vehicle is in an environment with relatively large signal interference, the application program with high transmission power and anti-interference is switched; when the signal environment is good, the application program with low power consumption is switched; the two application programs with different power consumptions have the same function, and data synchronization / update is required when switching.

[0054] Further, the bitstream update file synchronization instruction at least includes: storing the bitstream update file in the non-volatile memory; reading the bitstream update file stored in the non-volatile memory and loading it to the specified interface.

[0055] It should be noted that after the bitstream update file synchronization instruction is executed, the bitstream update file is written to the non-volatile memory, and is loaded when the BootLoader program is executed.

[0056] For example, according to step S11, the RTOS application program, such as the RTOS.bin file, is written to the starting address of the shared memory allocated for the slave core to run, assuming that the starting address is 0x20000000. The bitstream update file (.bit) is converted into a bin file format and written through the FPGA reserved interface fpga_manager to update the FPGA.

[0057] More specifically, the bitstream update file synchronization instruction is used to update the bitstream update file stored in the non-volatile memory. When the program needs to be switched, the bitstream update file synchronization instruction is used to read the file system Linux from the non-volatile memory and write it to the corresponding interface fpga_manage. When the bitstream update file is updated, its more specific internal process is: 1. The master core Linux application program directly loads the bitstream update file from the non-volatile memory.

[0058] 2. The slave core is written into the memory (which is a dynamic random access memory, different from the non-volatile memory) by the master core first, and then the slave core loads the bitstream update file from the memory.

[0059] 3. The bitstream update is written into the interface connected with the FPGA provided by the Linux by the master core, thereby realizing the update.

[0060] In essence, the three are first read from the non-volatile memory the file that needs to be switched, and then loaded to the specified position respectively.

[0061] S30: In response to the application switching instruction and the completion of the bitstream update file synchronization instruction, execute the main core program initialization instruction and send the slave core program initialization instruction to the slave core to realize the inter-core update synchronization.

[0062] wherein the step S30 comprises: S31: Execute the main core program initialization instruction of the main core application in the Linux system.

[0063] S32: In response to the completion of the main core program initialization instruction, wake up the slave core to execute the slave core program initialization instruction of the slave core application based on the preset memory address.

[0064] S33: In response to the completion of the slave core program initialization instruction, write a flag bit for informing the running of the slave core application to the specified position of the dynamic random access memory.

[0065] Specifically, in the steps S31-S33, first, according to the step S11, run the Linux application of the main core (i.e., the main core application based on the Linux system) in the specified directory position, execute the main core program initialization instruction therein. After the initialization is completed, wake up the slave core to run the RTOS application by writing 0x20000000 to the memory address 0xFFFFFFF0. The slave core is woken up and runs the initialization part in the RTOS application, and after the initialization is completed, writes a flag bit to the specified position of the dynamic random access memory to inform the main core and the slave core that the initialization is completed and the subsequent application can be executed.

[0066] It should be noted that the first execution instruction of the main core program initialization instruction and the slave core program initialization instruction drives / calls the BootLoader program to load the bitstream update file.

[0067] S40: Run the main core application and inform the slave core to run the slave core application.

[0068] Specifically, after the step S40 is executed, the main core and the slave core start to continue to execute the subsequent application of each. The initial starting order and the wake-up mechanism of the main core and the slave core are set by the BootLoader program.

[0069] Through steps S10-S40 above, the method of this embodiment runs a Linux system application on the master core and an RTOS system on the slave core, with an integrated FPGA. By managing CPU resources, non-volatile memory, and system control registers, coordinated dynamic switching / updating of the master and slave core applications and FPGA logic (bitstream update file) is achieved. This embodiment's method includes, after the master core receives an update instruction, reading the Linux application, RTOS application, and bitstream update file to be switched from the storage medium, writing the RTOS application to a specified memory address, and updating the FPGA via a Linux reserved interface. Subsequently, the master and slave cores are reset, and with the help of a pre-written BootLoader program, the slave core re-runs the updated RTOS application, achieving inter-core synchronization through non-volatile memory.

[0070] Compared to existing technologies, the method of this invention enables rapid updates and switching of applications and FPGAs under the AMP architecture without interrupting network services, significantly improving the system's flexibility and maintainability, enhancing the user experience, and making it suitable for embedded systems in various scenarios such as industrial control and edge computing.

[0071] Example 2 like Figure 2 As shown in Embodiment 1, this embodiment discloses an application collaborative switching device based on a multi-core heterogeneous AMP architecture, including a master core (CPU0), a slave core (CPU1), FLASH (a type of non-volatile memory), shared memory (RAM), and FPGA.

[0072] The master core is used to run the Linux system and applications suitable for running in the Linux environment. The slave core is used to run RTOS applications. Both the master and slave cores can load bitstream update files from FLASH through the BootLoader program. The FPGA has a reserved interface fpga_manager that connects to the master and slave cores respectively to read and configure the FPGA from FLASH and apply the bitstream update files to the master and slave core applications for updates.

[0073] Example 3 like Figure 3 As shown, this embodiment discloses an application collaborative switching system based on a multi-core heterogeneous AMP architecture, including a processor and a memory. The memory stores computer program instructions. When the computer program instructions are executed by the processor, the application collaborative switching method based on a multi-core heterogeneous AMP architecture described in Embodiment 1 is implemented.

[0074] The system also includes other components such as a communication interface, which are well known to those skilled in the art, the arrangement and function of which are known in the art and thus will not be described here.

[0075] In the present application, the aforementioned memory can be any tangible medium that contains or stores a program which can be used by or in connection with an instruction execution system, system or device. For example, the computer readable storage medium can be any appropriate magnetic storage or magneto-optical storage such as, for example, non-volatile memory (FLASH), resistive random access memory RRAM (Resistive Random Access Memory), dynamic random access memory RAM (Random Access Memory), i.e. the aforementioned shared memory that loses power loss, static random access memory SRAM (Static Random-Access Memory), enhanced dynamic random access memory EDRAM (Enhanced Dynamic Random Access Memory), high bandwidth memory HBM (High-Bandwidth Memory), hybrid memory cube HMC (Hybrid Memory Cube) and the like, or any other medium that can be used to store the desired information and can be accessed by an application, a module or both. Any such computer storage medium can be part of the device or accessible or connectable to the device. Any application or module described in the present application can be implemented using computer readable / executable instructions that can be stored or otherwise held by such computer readable medium.

[0076] In the description of the present specification, the meaning of "a plurality of" is at least two, such as two, three or more, etc., unless otherwise explicitly specifically limited.

[0077] Although the present specification has shown and described a number of embodiments of the present application, it will be apparent to those skilled in the art that many modifications, variations, and alternatives, to the present application can be made in the light of the above teachings. It is therefore to be understood that changes can be made in the form, details, and / or arrangements of the herein described embodiments of the application without departing from the spirit and intent of the application.

Claims

1. A method for cooperative switching of applications based on a multi-core heterogeneous AMP architecture, characterized in that, The method comprises the following steps: in response to the acquisition of the update instruction, a preparation process for supporting the initialization of loading the master core application, the slave core application and the bitstream update file is executed; in response to the completion of the preparation process, an application switching instruction and a bitstream update file synchronization instruction are executed; in response to the completion of the application switching instruction and the bitstream update file synchronization instruction, a master core program initialization instruction is executed and a slave core program initialization instruction is sent to the slave core to realize the inter-core update synchronization; the master core application is run and the slave core is informed to run the slave core application; wherein the bitstream update file synchronization instruction at least comprises: storing the bitstream update file in the non-volatile memory; reading the bitstream update file stored in the non-volatile memory and loading it to the specified interface. 2.The method of claim 1, wherein, The preparation process for supporting the initialization of loading the master core application, the slave core application and the bitstream update file comprises the following steps: selecting the master core application, the slave core application and the bitstream update file to be switched from the non-volatile memory and moving to the specified directory position of the Linux system; writing the BootLoader program required for switching the application into the specified position of the dynamic random access memory.

3. The method of claim 2, wherein the method further comprises: The master core program initialization instruction is executed and the slave core program initialization instruction is sent to the slave core to realize the inter-core update synchronization, comprising the following steps: executing the master core program initialization instruction of the master core application in the Linux system; in response to the completion of the master core program initialization instruction, the slave core program initialization instruction of the slave core application is executed based on the preset memory address; in response to the completion of the slave core program initialization instruction, a flag bit for informing the running of the slave core application is written into the specified position of the dynamic random access memory.

4. The method of claim 1, wherein the method further comprises: Before executing the application switching instruction and the bitstream update file synchronization instruction, the method further comprises triggering the slave core reset.

5. The method of claim 4, wherein the method further comprises: Triggering the slave core reset comprises the following steps: mapping the physical address of the SLCR to the virtual address; writing the unlocking key into the unlocking register of the SLCR; writing the slave core reset configuration into the CPU reset register; writing the locking key into the locking register of the SLCR; cleaning up the physical address mapping of the Linux system and releasing the hardware resources of the Linux system.

6. The method of claim 5, wherein the method further comprises: After triggering the slave core reset, the method further comprises: uninstalling the driver of the master core application; executing the master core reset interrupt.

7. The method of claim 2, wherein the method further comprises: The specified position comprises the memory address 0x00000000 and the memory address 0xFFFFFF00.

8. The method of claim 7, wherein the method further comprises: After writing the BootLoader program required for switching the application into the specified position of the dynamic random access memory, the method further comprises: writing the jump instruction into the memory address 0x00000000 to point the PC pointer to the memory address 0xFFFFFF00.

9. The method of claim 7, wherein the method further comprises: After writing the BootLoader program required for switching the application into the specified position of the dynamic random access memory, the method further comprises: writing the loop waiting instruction into the memory address 0xFFFFFF00.

10. A system for cooperative switching of applications based on a multi-core heterogeneous AMP architecture, characterized in that, The application relates to a computer program product, comprising a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the application program cooperative switching method based on a multi-core heterogeneous AMP architecture is realized.

Images