Multi-core embedded system memory management method and system based on static and dynamic memory configuration

Abstract

The invention provides a multi-core embedded system memory management method and system based on static and dynamic memory configuration, a static configuration file is used for defining a memory area and address information of each core, and a Python script is automatically synchronized to a system link script, so that automation of static memory allocation is realized; for a dynamic memory, an API interface is configured, flexible memory allocation of an application program is supported, it is ensured that the application does not directly access a fixed physical address, and address conflicts are avoided through mutual exclusion verification of a static memory area and a dynamic memory area; shared memory areas are configured in a BRAM area and a DDR area respectively, data sharing and instruction transmission between an RPU and APU cores and between APU cores are achieved, and real-time performance and independence of multi-core data interaction are ensured. According to the invention, the development complexity of the embedded system is reduced, and the security of memory management and the overall communication efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded system memory management, and in particular to a multi-core embedded system memory management method and system based on static and dynamic memory configuration. Background Art

[0002] In modern embedded systems, especially heterogeneous multi-core platforms based on FPGA-CPU, APU (application processing unit) and RPU (real-time processing unit) usually need to run different tasks at the same time, which puts higher requirements on memory management:

[0003] (1) Traditional static memory allocation needs to be configured through complex linker scripts (such as lscript.ld), which is not only difficult to understand and read, but also inconvenient to maintain;

[0004] (2) Dynamic memory allocation usually relies on the operating system's memory management unit (MMU) to implement the mapping of virtual addresses to physical addresses. However, this method requires the development of a complex board support package (BSP), which increases development costs.

[0005] (3) In terms of data interaction between the RPU (real-time processing unit) and the APU (application processing unit), since the RPU and APU can only communicate through the BRAM shared area on the programmable logic (PL) side via the AXI bus, while the APUs share the DDR area, the real-time nature and control complexity of data transmission are particularly prominent.

[0006] Therefore, in the above-mentioned multi-core embedded system, there is an urgent need for a simple and effective memory management solution that can not only solve the complexity of static memory configuration and the BSP-free configuration requirements of dynamic memory, but also optimize the cross-core instruction transfer and shared memory usage between RPU and APU and between APU cores. Summary of the invention

[0007] In view of the defects in the prior art, the object of the present invention is to provide a multi-core embedded system memory management method and system based on static and dynamic memory configuration.

[0008] The multi-core embedded system memory management method based on static and dynamic memory configuration provided by the present invention includes:

[0009] Step 1: Use a static configuration file to define the memory areas and address information of multiple cores, and then write a parsing script to read this configuration information and automatically generate or update the system's link script to automate static memory allocation;

[0010] Step 2: Configure the dynamic memory allocation API interface. The interface is connected to the physical memory pool through the preset dynamic memory allocation function. A memory request is initiated from the application. The API checks the physical memory pool and returns the allocated address or failure information. The application then reads and writes data based on the returned address to meet the application's demand for dynamic memory allocation. This ensures that the application is not visible to the fixed physical address. The available address is defined by the API interface.

[0011] Step 3: Configure multiple shared memory areas, which are located in the block random access memory BRAM and the double data rate synchronous dynamic random access memory DDR, for instruction transmission and multi-core large-scale data sharing;

[0012] Step 4: The real-time processing unit RPU loads the memory allocation table from the static configuration file at startup, and performs a mutual exclusion check on the address ranges of the dynamic and static memory areas, checks the starting address and length of all memory areas, and ensures that there is no address overlap between different areas.

[0013] Preferably, the step 1 comprises:

[0014] Step 1.1: Define the memory regions of each ELF file in an XML or TXT format file, including specifying the region name, start address, size, and linker script corresponding items to provide basic information and path for memory configuration;

[0015] Step 1.2: Read and parse the static configuration file through the code script, and extract the configuration information of the memory address range and size of each core from the static configuration file;

[0016] Step 1.3: Use the parsed configuration information through the code script to update or generate the link script specified in the path, add or modify the link items in the script to adapt to the memory configuration, and after the link script is updated, the static memory configuration is synchronized.

[0017] Preferably, step 2 comprises:

[0018] Step 2.1: In the XML or TXT format configuration file, define the base address and length of the memory area for the application to describe the memory distribution information;

[0019] Step 2.2: The boot loader of each processor unit APU dynamically loads the application APP by parsing the ELF file, determining the entry address and jumping to it; at the same time, it is responsible for storing the ELF file of the APP to the Flash location of the RPU core, and writing the dynamic memory base address and length information into the shared memory area;

[0020] Step 2.3: The application APP applies for memory through the API interface. The API allocates space from the predefined dynamic memory area according to the needs of the APP;

[0021] Step 2.4: The API interface returns the allocated memory address. The application uses the returned memory address to perform data operations and releases the space through the recycling function when the preset conditions are met.

[0022] Preferably, the dynamic memory allocation API interface includes:

[0023] The application calls the API interface to request a specified amount of memory from the dynamic memory management module;

[0024] The API interface checks whether the dynamic memory area has enough space to meet the application requirements. If there is enough memory space, the allocation is successful and the allocated memory address is returned. The application uses this address to read and write the memory. Otherwise, the allocation fails and an allocation failure message is returned, indicating that there is not enough memory space for allocation. The application needs to handle the error, including reapplying for memory or releasing other unnecessary memory.

[0025] Preferably, step 4 comprises:

[0026] Step 4.1: The real-time processing unit RPU reads the memory configuration file, including static and dynamic configuration files, when the system starts, and obtains the address information of each memory area;

[0027] Step 4.2: Parse the start and end addresses of the memory area defined in the configuration file and output the address range information;

[0028] Step 4.3: Check whether the address ranges of each memory area overlap, ensure that the dynamic memory and static memory areas do not conflict, and that each dynamic memory area is independent of each other;

[0029] Step 4.4: Determine whether the verification is passed. If the verification is passed, it indicates that there is no address conflict, and the system enters the normal startup phase and continues to perform other initialization tasks. If the verification is not passed, it indicates that an address conflict is detected, and the system enters the stop startup phase, returns an error message, prompts the system administrator or triggers the automatic restart logic.

[0030] The multi-core embedded system memory management system based on static and dynamic memory configuration provided by the present invention includes:

[0031] Module M1: Use static configuration files to define the memory areas and address information of multiple cores, and then write a parsing script to read these configuration information and automatically generate or update the system's link script to automate static memory allocation;

[0032] Module M2: Configure the dynamic memory allocation API interface. The interface is connected to the physical memory pool through a preset dynamic memory allocation function. When a memory request is initiated from the application, the API checks the physical memory pool and returns the allocated address or failure information. The application then reads and writes data based on the returned address to meet the application's demand for dynamic memory allocation and ensure that the application is not visible to the fixed physical address. The available address is defined by the API interface.

[0033] Module M3: multiple shared memory areas are configured, which are located in the block random access memory BRAM and the double rate synchronous dynamic random access memory DDR, respectively, for instruction transmission and multi-core large-scale data sharing;

[0034] Module M4: The real-time processing unit RPU loads the memory allocation table from the static configuration file at startup, and performs a mutual exclusion check on the address ranges of the dynamic and static memory areas, checks the starting address and length of all memory areas, and ensures that there is no address overlap between different areas.

[0035] Preferably, the module M1 comprises:

[0036] Module M1.1: Define the memory area of ​​each ELF file in XML or TXT format files, including specifying the area name, starting address, size and link script corresponding items to provide basic information and path of memory configuration;

[0037] Module M1.2: reads and parses the static configuration file through the code script, and extracts the configuration information of the memory address range and size of each core from the static configuration file;

[0038] Module M1.3: Use the parsed configuration information through the code script to update or generate the link script specified in the path, add or modify the link items in the script to adapt to the memory configuration, and after the link script is updated, the static memory configuration is synchronized.

[0039] Preferably, the module M2 comprises:

[0040] Module M2.1: In the XML or TXT format configuration file, define the base address and length of the memory area for the application to describe the memory distribution information;

[0041] Module M2.2: The boot loader of each processor unit APU dynamically loads the application APP by parsing the ELF file, determining the entry address and jumping. At the same time, it is responsible for storing the ELF file of the APP to the Flash location of the RPU core, and writing the dynamic memory base address and length information into the shared memory area;

[0042] Module M2.3: The application APP applies for memory through the API interface. The API allocates space from the predefined dynamic memory area according to the needs of the APP;

[0043] Module M2.4: The API interface returns the allocated memory address. The application uses the returned memory address to perform data operations. When the preset conditions are met, the space is released again through the recycling function.

[0044] Preferably, the dynamic memory allocation API interface includes:

[0045] The application calls the API interface to request a specified amount of memory from the dynamic memory management module;

[0046] The API interface checks whether the dynamic memory area has enough space to meet the application requirements. If there is enough memory space, the allocation is successful and the allocated memory address is returned. The application uses this address to read and write the memory. Otherwise, the allocation fails and an allocation failure message is returned, indicating that there is not enough memory space for allocation. The application needs to handle the error, including reapplying for memory or releasing other unnecessary memory.

[0047] Preferably, the module M4 comprises:

[0048] Module M4.1: The real-time processing unit RPU reads the memory configuration file, including static and dynamic configuration files, when the system starts up, and obtains the address information of each memory area;

[0049] Module M4.2: parses the start and end addresses of the memory area defined in the configuration file and outputs the address range information;

[0050] Module M4.3: Check whether the address ranges of each memory area overlap, ensure that the dynamic memory and static memory areas do not conflict, and that each dynamic memory area is independent of each other;

[0051] Module M4.4: Determine whether the verification is passed. If the verification is passed, it indicates that there is no address conflict, and the system enters the normal startup phase and continues to perform other initialization tasks; if the verification is not passed, it indicates that an address conflict is detected, and the system enters the stop startup phase, returns an error message, prompts the system administrator or triggers the automatic restart logic.

[0052] Compared with the prior art, the present invention has the following beneficial effects:

[0053] (1) The present invention reduces the complexity of memory management in multi-core embedded systems by optimizing memory configuration and data interaction structure, and improves the communication efficiency between RPU and APU cores and the real-time performance of cross-core instruction transmission;

[0054] (2) The present invention is applicable to the field of memory management of multi-core embedded systems, especially the memory configuration and sharing interaction of heterogeneous platforms. It can also be widely used in autonomous driving, communication equipment, industrial control and other aspects, providing a new lightweight memory management solution for multi-core embedded systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0056] Figure 1 Configure and synchronize flow charts for static memory;

[0057] Figure 2 Configure flow chart for dynamic memory;

[0058] Figure 3 It is a mutual exclusion safety verification flow chart;

[0059] Figure 4 Use the flow chart for the dynamic memory allocation API interface;

[0060] Figure 5 This is a static configuration file in TXT format.

[0061] Figure 6 This is an example of the XML format of a static configuration file;

[0062] Figure 7 This is a TXT format example of a dynamic configuration file;

[0063] Figure 8 This is an example of the XML format for a dynamic configuration file;

[0064] Fig. 9 Examples of linker scripts (lscript.ld) and linker items (LinkItem);

[0065] Fig.10 The following is a schematic diagram of the data communication instruction format between RPU and APU;

[0066] Fig.11 An example of implementing the dynamic memory API call interface. DETAILED DESCRIPTION

[0067] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0068] Example

[0069] The present invention provides a method for implementing static memory allocation configuration in an FPGA-CPU heterogeneous system. The method writes a static memory area into a link script (lscript.ld) and compiles it into a target ELF file to ensure that each module of the system has consistent memory layout information during the compilation and linking stage. The present embodiment defines the memory area through TXT and XML configuration files, and synchronizes the configuration to the lscript.ld file using a Python script. The purpose of this design is to implement the static configuration of the memory area in the FPGA-CPU heterogeneous platform to achieve the consistency effect of memory access. Through this step, the accuracy of cross-core memory interaction can be effectively improved, and access conflicts caused by inconsistent memory mapping can be avoided.

[0070] The method comprises the following steps:

[0071] 1. Configuration file preparation: First, prepare the configuration file of the memory area. The system supports two formats, namely TXT format and XML format. The content of the TXT format file includes the static memory area name, start address, length, link script path and link items, such as APU boot loader area, shared memory area and RPU exclusive memory area. The configuration content of the XML file provides the corresponding field information through nested tags to facilitate automatic script parsing.

[0072] 2. Parse the configuration file: Use Python script to parse the XML configuration file, read the starting address, size, link script path and other information of each memory area, and store it in the data structure for subsequent synchronous updates.

[0073] 3. Synchronize to lscript.ld file: The script reads the lscript.ld file content corresponding to each memory area, searches for the "MEMORY" definition area, and locates the specific location of each configuration item. According to the parsed configuration data, the starting address and length of the matching link item are updated to ensure configuration consistency.

[0074] 4. Compile and generate ELF file: After the configuration is completed, compile the updated lscript.ld file to generate the target ELF file to make the static memory configuration effective.

[0075] The static memory allocation configuration method proposed in this embodiment solves the problem of inconsistent multi-core memory access in FPGA-CPU heterogeneous systems, and can be widely used in embedded system designs with heterogeneous multi-core processing units. This embodiment realizes synchronization and update of memory configuration by combining configuration files with script automation.

[0076] In this embodiment, a method for dynamic memory allocation configuration is provided, which mainly includes the definition of dynamic memory area, loading of configuration files, and mutual exclusion security verification process to ensure that the memory usage of each module in the FPGA-CPU heterogeneous platform is safe and reliable. This embodiment defines two formats of dynamic configuration files, namely ˋdynamic_mem_cfg.txtˋ and ˋdynamic_mem_cfg.xmlˋ, which are used to record the dynamic memory allocation area of ​​the APP module. The TXT format file is mainly used for recording the dynamic memory area, but the RPU (R5 core) reads the XML format file by default, so the TXT format file is for reference only and is not used for actual memory configuration loading. The XML format file describes the starting address and allocation length of the dynamic memory, which facilitates the RPU to write the memory information to a specific memory area (ˋMEM_ASSIGN_DDRˋ) and provide it to the APU for memory management when the system starts. During the system startup process, the RPU in this embodiment loads the static and dynamic memory area configuration files from the SD card, and performs mutual exclusion security verification on the dynamic and static memory areas of each module. The verification steps are as follows: RPU first reads the memory allocation configuration table, which contains the static and dynamic memory address and length information of each module. Compare each memory area in the dynamic configuration file with the static memory area one by one to ensure that the memory address and length do not conflict with each other. If there is no overlap in the memory area, the verification passes and the system will continue to load. This mutual exclusion security check is intended to ensure that the memory allocation of each APP module is independent and secure, and to avoid memory overlay problems. Through this step, the security and stability of the system memory can be effectively guaranteed, providing protection for the normal operation of the FPGA-CPU heterogeneous platform. The dynamic memory allocation configuration method provided in this embodiment can meet the memory management requirements of each APP module in the FPGA-CPU heterogeneous platform, and can be widely used in memory configuration in multi-core heterogeneous computing environments.

[0077] In this embodiment, a system method for ELF address parameter acquisition and shared memory communication in an FPGA-CPU heterogeneous platform is provided. In this method, it is first clarified that the application program (APP) is dynamically loaded. The BootLoader of each APU core implements the jump by parsing the entry address of the ELF file, thereby dynamically loading the APP, and the RPU core writes the Flash storage address of the ELF file, the available dynamic memory base address of the APP, and the length into the shared memory area. The shared memory area mainly realizes the information transmission between the RPU and the APU, thereby meeting the independent communication requirements between modules in the multi-core system. Since the shared memory between the RPU and the APU can only be accessed through the AXI bus through the BRAM defined by the PL end, and the APUs share the same DDR area. Therefore, two shared memory areas are opened up through a static configuration file. They are defined as follows: ˋBRAM_1ˋ: The size is 4KB, which can be written by the RPU core and read by the APU core to realize the instruction transmission from RPU to APU. ˋDDR_0's SHARED_DDR_BASEADDRˋ: This shared area is accessible to all APU cores, of which the first APU core is responsible for writing and other APU cores are responsible for reading, so as to realize multi-core information sharing. The control instruction consists of two parts, ˋFlagˋ and ˋDataˋ, and the format is as follows: ˋFlagˋ: The first byte is used to indicate the message type or status. ˋDataˋ: The remaining bytes (bytes 2 to 4096) are used to store specific data information. The control instruction is written by the RPU core into ˋBRAM_1ˋ, and the first APU core receives the instruction by reading this area. Then, the first APU core writes the received instruction into the ˋDDR_0's SHARED_DDR_BASEADDRˋ shared area for other APU cores to read, so as to realize the communication between RPU and multi-core APU. In order to realize independent communication between each core, each APU core is allocated a different shared data area, which is specifically defined as follows: ˋStartAddr:1,Length=sizeof(ElfData)ˋ: The shared data area of ​​the first APU core. ˋStartAddr:sizeof(ElfData)*1+1,Length=sizeof(ElfData)ˋ: The second APU core shared data area. And so on, to ensure that each core has an independent shared space. Structure definition: The ELF information format stored in the shared data area is defined by the structure ˋElfDataˋ, including ˋnameˋ, ˋflash_baseaddrˋ, ˋflash_lengthˋ, ˋmem_baseaddrˋ, ˋmem_lengthˋ, which correspond to the area name, the location where ELF is loaded from flash, the length of ELF in flash, the starting address and length of the defined dynamic memory area.In this embodiment, DATA_SIZE is set to 4096 bytes to meet the data requirements of shared memory transmission; FLAG_INDEX is set to 0 for flag storage; DATA_START_INDEX is set to 1 to point to the start byte of the data. The purpose of this design is to achieve independent and secure memory area communication between the RPU and APU multi-core systems. By setting up a shared data area, an APU core can forward instructions transmitted by the RPU core to other APU cores, thereby effectively supporting multi-core application requirements.

[0078] In this embodiment, a method for implementing the "my_malloc" function for dynamic memory allocation of APU core applications is provided. This method solves the problem of uncertain memory demand of applications in multi-core systems by providing a customized dynamic memory allocation API interface for applications. Through this method, the program can allocate memory on demand and effectively reclaim memory space. The method includes the following steps: 1) Memory pool initialization: First, initialize the memory pool by calling the "my_malloc_init" function. The function receives two parameters: "mem_baseaddr" (the starting address of the memory pool) and "mem_length" (the total length of the memory pool), and configures the memory pool to ensure that the memory area is available for allocation. 2) Memory allocation: When dynamic memory allocation is required, call the "my_malloc" function and specify the allocated memory size. For example, the first call "my_malloc(128)" allocates 128 bytes of memory. If the allocation is successful, the function returns the pointer address pointing to the allocated area; if the allocation fails, it returns "NULL" and outputs an error message. 3) Data storage: Convert the allocated pointer to a pointer of a specific data type to facilitate data storage and reading. For example, convert ptr1 to an int* type pointer and write the data to the memory. 4) Memory recovery and reset: When the program completes the use of the memory, the memory space at a specific address is released through the my_free function, or the entire memory pool is reset by calling the my_malloc_reset function for subsequent reallocation. In this embodiment, the parameters of my_malloc_init are set to elf_data.mem_baseaddr and elf_data.mem_length. Among them, mem_baseaddr is used to specify the starting address of the memory pool, and mem_length is set to the length of the entire available memory space to ensure the allocation order and address range after the memory pool is initialized. This parameter configuration is set according to the system memory distribution and application requirements to ensure the rationality of the allocated space. The purpose of this design is to implement the dynamic allocation and management of memory pools in multi-core systems to meet the needs of A53 core applications for memory allocation and recycling, and to achieve reasonable memory usage efficiency. Through the dynamic allocation and release mechanism, memory resource waste can be effectively avoided. After testing, the operating effect of this embodiment is as follows: 128 bytes of memory are successfully allocated, and the integer values ​​42 and 84 are correctly stored in the allocated space, verifying the effectiveness of the allocation mechanism. After calling my_malloc_reset, the memory pool is successfully reset, indicating that the memory resource recycling function is normal.

[0079] Figure 1 The process of configuring and synchronizing static memory to a linked file consists of four main steps:

[0080] Step 1. Static configuration file definition

[0081] Define the memory area of ​​each ELF file in XML or TXT format files, including base address, length, link script path, link items, etc. The goal of this step is to provide basic information and path of memory configuration for subsequent parsing and use.

[0082] Step 2. Static configuration parsing

[0083] The above static configuration file is read and parsed through the code script. Configuration information such as the memory address range and size of each core is extracted from the file to provide a basis for the next step.

[0084] Step 3. Linker script generation

[0085] Use the parsed configuration information through the code script to update or generate the link script specified in the path (such as lscript.ld). Add or modify link items (LinkItem) in the script to adapt to the memory configuration.

[0086] Step 4. Memory configuration synchronization completed

[0087] After the link script is updated, the static memory configuration is synchronized. This stage marks the entry of the memory configuration update into the subsequent processing stage.

[0088] Figure 2 The dynamic memory configuration process is divided into four steps:

[0089] Step 1. Dynamic configuration file definition

[0090] In the XML or TXT format configuration file, define the base address and length of the memory area for the application. This is the initial step of dynamic memory allocation and is used to describe memory distribution information.

[0091] Step 2. Dynamic APP loading and parameter passing

[0092] The bootloader of each processor unit (APU) dynamically loads the APP by parsing the ELF file, determining the entry address and jumping. At the same time, it is responsible for storing the ELF file of the APP to the Flash location of the RPU core and writing the dynamic memory base address and length information into the shared memory area.

[0093] Step 3. Dynamically allocate API calls

[0094] Application programs (APPs) apply for memory through the API interface. The API allocates space from the predefined dynamic memory area based on the needs of the APP.

[0095] Step 4. Memory address returned

[0096] The API returns the allocated memory address. The application uses the returned memory address to perform data operations and releases the space through the recovery function when necessary.

[0097] Figure 3 This is a mutually exclusive security verification process, which is mainly used to perform address conflict checks on static and dynamic memory configuration areas when the system starts up to ensure the security of memory allocation. The specific process steps are as follows:

[0098] Step 1. Start loading the memory configuration file

[0099] The RPU (Real-time Processing Unit) reads the memory configuration file (including static and dynamic configuration files) when the system starts up and obtains the address information of each memory area. This step provides a complete memory area description for subsequent steps.

[0100] Step 2. Address range resolution

[0101] Parse the start and end addresses of the memory area defined in the configuration file. Output clear address range information to provide data support for conflict detection.

[0102] Step 3. Mutual Exclusion Check

[0103] Check whether the address ranges of each memory area overlap, ensure that the dynamic memory and static memory areas do not conflict, and that each dynamic memory area is independent of each other.

[0104] Step 4. Determine whether the verification is passed

[0105] Yes (Pass): If there is no address conflict, the system enters the normal startup phase and continues to execute other initialization tasks.

[0106] No (failed): If an address conflict is detected, the system enters the stop-start phase. An error message is returned. The startup process is stopped, prompting the system administrator or triggering the automatic restart logic.

[0107] Figure 4 This is the usage process of the dynamic memory allocation API interface. Its purpose is to describe how applications request and manage dynamic memory allocation through a custom API interface. The specific process is as follows:

[0108] Step 1. API call to request memory

[0109] The application calls the API interface to request a specified amount of memory from the dynamic memory management module.

[0110] Step 2. API checks available space

[0111] The API interface checks whether the dynamic memory area has enough space to meet the application requirements.

[0112] Step 3. Determine whether the allocation is successful or not

[0113] If there is enough memory space, the allocation is successful and the allocated memory address is returned. The application can use this address to read and write the memory.

[0114] Otherwise, the allocation fails. A failure message is returned, indicating that there is not enough memory space for allocation. The application needs to handle this error, such as reapplying for memory or releasing other unnecessary memory.

[0115] Figure 5 The static memory allocation configuration in a complex embedded system is defined in TXT format, including the memory start address, length, purpose, and related linker script location and associated storage resources of different functional modules. These configurations are compiled into the ELF file through the linker script (.ld file) to ensure that each module can correctly access its exclusive memory area when the system is running.

[0116] The specific distribution is as follows:

[0117] (1) Boot loader for A53 core (BootLoader0-3)

[0118] Each A53 core has an independent bootloader, which is responsible for initializing the core's operating environment. Each Bootloader is allocated a memory space of 0x4000000 (64MB).

[0119] Starting address and allocation logic:

[0120] A53-0: Starts at 0x0, used for core startup.

[0121] A53-1: Start at 0x60000000.

[0122] A53-2: Starts at 0x40000000.

[0123] A53-3: Starts at 0x50000000.

[0124] Each bootloader uses psu_ddr_0_MEM_0 as the memory link entry.

[0125] (2) Static memory allocation of application modules

[0126] Each application module has an independent memory area for loading specific business logic. APP0 (picture receiving module):

[0127] Starting address: ˋ0x5000000ˋ, length: ˋ0x30000000ˋ(768MB).

[0128] Mainly stores and processes image receiving tasks.

[0129] APP1 (identification module):

[0130] Starting address: ˋ0x65000000ˋ, length: ˋ0x4000000ˋ(64MB).

[0131] Used for image recognition tasks.

[0132] APP2(Tracking Module-1):

[0133] Starting address: ˋ0x45000000ˋ, length: ˋ0x4000000ˋ(64MB).

[0134] The first submodule for tracing functionality.

[0135] APP3(Tracking Module-2):

[0136] Starting address: ˋ0x55000000ˋ, length: ˋ0x4000000ˋ(64MB).

[0137] The second submodule of the tracking function.

[0138] (3) Shared memory area

[0139] Provides shared memory between A53 cores and between A53 and PL (programmable logic).

[0140] 1) A53 core shared memory:

[0141] Starting address: ˋ0x70000000ˋ, length: ˋ0x30000ˋ(192KB).

[0142] Allows A53 cores to exchange data.

[0143] 2)YOLO output memory:

[0144] Starting address: ˋ0x410010000ˋ, length: ˋ0x2000ˋ(8KB).

[0145] Used to store YOLO target detection results.

[0146] 3) PL-DDR4 shared storage:

[0147] Starting address: ˋ0x400000000ˋ, length: ˋ0x10000000ˋ(256MB).

[0148] Used for large data transfers between the A53 core and the PL, such as image cache.

[0149] 4) R5 core exclusive memory

[0150] The R5 core is allocated an independent dedicated memory area that is not shared with the A53 core.

[0151] Starting address: ˋ0x100000ˋ, length: ˋ0x7FE00000ˋ(2GB-1MB).

[0152] This memory area is associated with the link script through the link item ˋpsu_r5_ddr_0_MEM_0ˋ. 5) Interactive memory between A53-0 and R5-0

[0153] Defines the control instruction interaction memory between A53-0 and R5-0 cores.

[0154] Starting address: ˋ0x80000000ˋ, length: ˋ0x1000ˋ(4KB).

[0155] Used to exchange control instructions and support dual-core collaborative work.

[0156] like Figure 6 , gives the above static memory configuration example in XML format.

[0157] Figure 7 The allocation of dynamic memory areas configured in TXT format is given, which mainly includes four specific partitions (APP0, APP1, APP2, APP3) of the application business logic memory (APP), as well as their respective start addresses and length information. The configuration of these memory areas is written to MEM_ASSIGN_DDR after being loaded by the R5 core through XML files, and is obtained and used when the APU starts.

[0158] The specific distribution is as follows:

[0159] APP0

[0160] Starting address: ˋ0x5000000ˋ

[0161] Length: 0x30000000 (768MB)

[0162] Description: This is the largest area in the business logic memory, which allocates a large dynamic memory space specifically for a certain type of application.

[0163] APP1

[0164] Starting address: ˋ0x65000000ˋ

[0165] Length: 0x4000000 (64MB)

[0166] Description: A smaller memory partition used for specific business application logic.

[0167] APP2

[0168] Starting address: ˋ0x45000000ˋ

[0169] Length: 0x4000000 (64MB)

[0170] Description: Similar to APP1, this is also a smaller partition used for specific tasks.

[0171] APP3

[0172] Starting address: ˋ0x55000000ˋ

[0173] Length: 0x4000000 (64MB)

[0174] Description: This is also a 64MB memory area that supports another business logic module.

[0175] like Figure 8 , gives the above dynamic memory configuration example in XML format.

[0176] Fig. 9 Examples of linker scripts (lscript.ld) and linker items (LinkItem);

[0177] The attached figure shows part of the contents of a linker script file ˋlscript.ldˋ and an example of its memory allocation definition and configuration. The linker script content is analyzed as follows:

[0178] (1) File header description:

[0179] Provides the version information (2018.3) and copyright information (Xilinx) generated by the script. Note that this script is used for link configuration of the ARMv8 architecture.

[0180] (2) Stack Configuration (Lines 6–10)

[0181] Defines the size of the stack: `_STACK_SIZE` and `_HEAP_SIZE` define the size of the stack and heap, which are `0x2000` and `0x2000` bytes respectively.

[0182] (3) Memory area definition (MEMORY block, Lines 16–25):

[0183] Defines different memory areas in the system and their sizes and starting addresses:

[0184] `axi_bram_ctrl_1_Mem0`:

[0185] Starting address: `0x80000000`

[0186] Size: `0x1000` (4KB)

[0187] `psu_ddr_0_MEM_0`:

[0188] Starting address: `0x00000000`

[0189] Size: `0x200000000` (8GB, usually DDR storage)

[0190] Other memory areas such as DDR, PSRAM or shared memory also define their addresses and sizes. These memory area definitions will be used to allocate data for specific segments, such as code segment (text), data segment (data), stack, etc.

[0191] (4) Default program entry (Line 28):

[0192] Set the default program entry point (`_vector_table`). This is usually the address of the first instruction executed when the program starts.

[0193] (5) Segment and memory mapping (SECTION block, Lines 32–end):

[0194] `text` segment: stores program code (read-only).

[0195] `data` segment: stores initialized data (read and write) in the program.

[0196] `bss` segment: stores uninitialized global or static variables.

[0197] The LinkItem here is psu_ddr_0_MEM_0. The code script only needs to replace the address here with the address defined in the static configuration file.

[0198] Fig.10 The following is a diagram of the format of the data communication instruction between RPU and APU. It consists of two parts, `Flag` and `Data`, and the format is as follows: `Flag`: The first byte is used to indicate the message type or status. `Data`: The remaining bytes (bytes 2 to 4096) are used to store specific data information.

[0199] Fig.11 An example of implementing the dynamic memory API call interface.

[0200] This code gives an example of implementing a custom dynamic memory call API interface. 1) Memory pool initialization: First, initialize the memory pool by calling the `my_malloc_init` function. This function receives two parameters: `mem_baseaddr` (the starting address of the memory pool) and ˋmem_lengthˋ (the total length of the memory pool), and configures the memory pool to ensure that the memory area is available for allocation. 2) Memory allocation: When dynamic memory allocation is required, call the ˋmy_mallocˋ function and specify the size of the allocated memory. For example, the first call ˋmy_malloc(128)ˋ allocates 128 bytes of memory. If the allocation is successful, the function returns the pointer address pointing to the allocated area; if the allocation fails, ˋNULLˋ is returned and an error message is output. 3) Data storage: Convert the allocated pointer to a pointer of a specific data type to facilitate data storage and reading. For example, convert ˋptr1ˋ to a ˋint*ˋ type pointer and write the data to the memory. 4) Memory recovery and reset: When the program completes the use of memory, the memory space at a specific address is released through the ˋmy_freeˋ function, or the entire memory pool is reset by calling the ˋmy_malloc_resetˋ function for subsequent reallocation. In this embodiment, the parameters of ˋmy_malloc_initˋ are set to ˋelf_data.mem_baseaddrˋ and ˋelf_data.mem_lengthˋ. Among them, ˋmem_baseaddrˋ is used to specify the starting address of the memory pool, and ˋmem_lengthˋ is set to the length of the entire available memory space to ensure the allocation order and address range after the memory pool is initialized. After testing, the running effect of this code is as follows: 128 bytes of memory are successfully allocated, and the integer values ​​ˋ42ˋ and ˋ84ˋ are correctly stored in the allocated space, verifying the effectiveness of the allocation mechanism. After calling ˋmy_malloc_resetˋ, the memory pool is successfully reset, indicating that the memory resource recovery function is normal.

[0201] Those skilled in the art know that, in addition to implementing the system, device and its various modules provided by the present invention in a purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and its various modules provided by the present invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing the method and structures within the hardware component.

[0202] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A multi-core embedded system memory management method based on static and dynamic memory configuration, characterized in that: include: Step 1: Use a static configuration file to define the memory areas and address information of multiple cores, and then write a parsing script to read this configuration information and automatically generate or update the system's link script to automate static memory allocation; Step 2: Configure the dynamic memory allocation API interface. The interface is connected to the physical memory pool through the preset dynamic memory allocation function. A memory request is initiated from the application. The API checks the physical memory pool and returns the allocated address or failure information. The application then reads and writes data based on the returned address to meet the application's demand for dynamic memory allocation. This ensures that the application is not visible to the fixed physical address. The available address is defined by the API interface. Step 3: Configure multiple shared memory areas, which are located in the block random access memory BRAM and the double data rate synchronous dynamic random access memory DDR, for instruction transmission and multi-core large-scale data sharing; Step 4: The real-time processing unit RPU loads the memory allocation table from the static configuration file at startup, and performs a mutual exclusion check on the address ranges of the dynamic and static memory areas, checks the starting address and length of all memory areas, and ensures that there is no address overlap between different areas.

2. The multi-core embedded system memory management method based on static and dynamic memory configuration according to claim 1, characterized in that: The step 1 comprises: Step 1.1: Define the memory regions of each ELF file in an XML or TXT format file, including specifying the region name, start address, size, and linker script corresponding items to provide basic information and path for memory configuration; Step 1.2: Read and parse the static configuration file through the code script, and extract the configuration information of the memory address range and size of each core from the static configuration file; Step 1.3: Use the parsed configuration information through the code script to update or generate the link script specified in the path, add or modify the link items in the script to adapt to the memory configuration, and after the link script is updated, the static memory configuration is synchronized.

3. The multi-core embedded system memory management method based on static and dynamic memory configuration according to claim 1, characterized in that: The step 2 comprises: Step 2.1: In the XML or TXT format configuration file, define the base address and length of the memory area for the application to describe the memory distribution information; Step 2.2: The boot loader of each processor unit APU dynamically loads the application APP by parsing the ELF file, determining the entry address and jumping to it; at the same time, it is responsible for storing the ELF file of the APP to the Flash location of the RPU core, and writing the dynamic memory base address and length information into the shared memory area; Step 2.3: The application APP applies for memory through the API interface. The API allocates space from the predefined dynamic memory area according to the needs of the APP; Step 2.4: The API interface returns the allocated memory address. The application uses the returned memory address to perform data operations and releases the space through the recycling function when the preset conditions are met.

4. The multi-core embedded system memory management method based on static and dynamic memory configuration according to claim 1, characterized in that: The dynamic memory allocation API interface includes: The application calls the API interface to request a specified amount of memory from the dynamic memory management module; The API interface checks whether the dynamic memory area has enough space to meet the application requirements. If there is enough memory space, the allocation is successful and the allocated memory address is returned. The application uses this address to read and write the memory. Otherwise, the allocation fails and an allocation failure message is returned, indicating that there is not enough memory space for allocation. The application needs to handle the error, including reapplying for memory or releasing other unnecessary memory.

5. The multi-core embedded system memory management method based on static and dynamic memory configuration according to claim 1, characterized in that: The step 4 comprises: Step 4.1: The real-time processing unit RPU reads the memory configuration file, including static and dynamic configuration files, when the system starts, and obtains the address information of each memory area; Step 4.2: Parse the start and end addresses of the memory area defined in the configuration file and output the address range information; Step 4.3: Check whether the address ranges of each memory area overlap, ensure that the dynamic memory and static memory areas do not conflict, and that each dynamic memory area is independent of each other; Step 4.4: Determine whether the verification is passed. If the verification is passed, it indicates that there is no address conflict, and the system enters the normal startup phase and continues to perform other initialization tasks. If the verification is not passed, it indicates that an address conflict is detected, and the system enters the stop startup phase, returns an error message, prompts the system administrator or triggers the automatic restart logic.

6. A multi-core embedded system memory management system based on static and dynamic memory configuration, characterized in that: include: Module M1: Use static configuration files to define the memory areas and address information of multiple cores, and then write a parsing script to read these configuration information and automatically generate or update the system's link script to automate static memory allocation; Module M2: Configure the dynamic memory allocation API interface. The interface is connected to the physical memory pool through a preset dynamic memory allocation function. When a memory request is initiated from the application, the API checks the physical memory pool and returns the allocated address or failure information. The application then reads and writes data based on the returned address to meet the application's demand for dynamic memory allocation and ensure that the application is not visible to the fixed physical address. The available address is defined by the API interface. Module M3: multiple shared memory areas are configured, which are located in the block random access memory BRAM and the double rate synchronous dynamic random access memory DDR, respectively, for instruction transmission and multi-core large-scale data sharing; Module M4: The real-time processing unit RPU loads the memory allocation table from the static configuration file at startup, and performs a mutual exclusion check on the address ranges of the dynamic and static memory areas, checks the starting address and length of all memory areas, and ensures that there is no address overlap between different areas.

7. The multi-core embedded system memory management system based on static and dynamic memory configuration according to claim 6, characterized in that: The module M1 comprises: Module M1.1: Define the memory area of ​​each ELF file in XML or TXT format files, including specifying the area name, starting address, size and link script corresponding items to provide basic information and path of memory configuration; Module M1.2: reads and parses the static configuration file through the code script, and extracts the configuration information of the memory address range and size of each core from the static configuration file; Module M1.3: Use the parsed configuration information through the code script to update or generate the link script specified in the path, add or modify the link items in the script to adapt to the memory configuration, and after the link script is updated, the static memory configuration is synchronized.

8. The multi-core embedded system memory management system based on static and dynamic memory configuration according to claim 6, characterized in that: The module M2 comprises: Module M2.1: In the XML or TXT format configuration file, define the base address and length of the memory area for the application to describe the memory distribution information; Module M2.2: The boot loader of each processor unit APU dynamically loads the application APP by parsing the ELF file, determining the entry address and jumping. At the same time, it is responsible for storing the ELF file of the APP to the Flash location of the RPU core, and writing the dynamic memory base address and length information into the shared memory area; Module M2.3: The application APP applies for memory through the API interface. The API allocates space from the predefined dynamic memory area according to the needs of the APP; Module M2.4: The API interface returns the allocated memory address. The application uses the returned memory address to perform data operations. When the preset conditions are met, the space is released again through the recycling function.

9. The multi-core embedded system memory management system based on static and dynamic memory configuration according to claim 6, characterized in that: The dynamic memory allocation API interface includes: The application calls the API interface to request a specified amount of memory from the dynamic memory management module; The API interface checks whether the dynamic memory area has enough space to meet the application requirements. If there is enough memory space, the allocation is successful and the allocated memory address is returned. The application uses this address to read and write the memory. Otherwise, the allocation fails and an allocation failure message is returned, indicating that there is not enough memory space for allocation. The application needs to handle the error, including reapplying for memory or releasing other unnecessary memory.

10. The multi-core embedded system memory management system based on static and dynamic memory configuration according to claim 6, characterized in that: The module M4 comprises: Module M4.1: The real-time processing unit RPU reads the memory configuration file, including static and dynamic configuration files, when the system starts up, and obtains the address information of each memory area; Module M4.2: parses the start and end addresses of the memory area defined in the configuration file and outputs the address range information; Module M4.3: Check whether the address ranges of each memory area overlap, ensure that the dynamic memory and static memory areas do not conflict, and that each dynamic memory area is independent of each other; Module M4.4: Determine whether the verification is passed. If the verification is passed, it indicates that there is no address conflict, and the system enters the normal startup phase and continues to perform other initialization tasks; if the verification is not passed, it indicates that an address conflict is detected, and the system enters the stop startup phase, returns an error message, prompts the system administrator or triggers the automatic restart logic.

Images