Method and system for memory management in multi-core embedded systems based on static and dynamic memory configuration

Abstract

The application provides a kind of multi-core embedded system memory management method and system based on static and dynamic memory configuration, utilizes static configuration file to define the memory area and address information of each core, and is automatically synchronized to system link script through Python script, realizes the automation of static memory allocation;For dynamic memory, configure API interface, support application flexible allocation of memory, ensure that application does not directly access fixed physical address, and avoid address conflict through static and dynamic memory area mutual exclusion verification;By configuring shared memory area in BRAM and DDR area respectively, realize the data sharing and instruction transmission between RPU and APU core, and between APU core, ensure the real-time and independence of multi-core data interaction.The application reduces the complexity of embedded system development, improves the security of memory management and the overall communication efficiency of system.

Description

TECHNICAL FIELD

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

[0002] In modern embedded systems, especially in FPGA-CPU-based heterogeneous multi-core platforms, APU (application processing unit) and RPU (real-time processing unit) often 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 a complex link script (such as 'lscript.ld'), which is difficult to understand and has poor readability, making it inconvenient to maintain;

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

[0005] (3) In terms of data interaction between RPU (real-time processing unit) and APU (application processing unit), RPU and APU can only communicate through the BRAM shared area of the programmable logic (PL) end via the AXI bus, while APU shares the DDR area, resulting in real-time and control complexity problems in data transmission.

[0006] Therefore, in the above multi-core embedded system, a simple and effective memory management scheme is needed, which not only solves the complexity of static memory configuration and the non-BSP configuration requirement of dynamic memory, but also optimizes the cross-core instruction transfer and shared memory usage between RPU and APU and between APU cores. SUMMARY

[0007] In view of the defects in the prior art, the purpose of the present application 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 application comprises:

[0009] Step 1: Define the memory area and address information of multiple cores using a static configuration file, then write a parsing script to read these configuration information and automatically generate or update the link script of the system, realizing the automation of static memory allocation;

[0010] Step 2: configure a dynamic memory allocation API interface, which is connected to the physical memory pool through a preset dynamic memory allocation function, initiates a memory request from an application program, checks the physical memory pool, and returns an allocated address or failure information, and the application program reads and writes data based on the returned address to meet the application program's demand for dynamic memory allocation, ensuring that the application program is invisible to the fixed physical address, and the available address is defined by the API interface;

[0011] Step 3: configure multiple shared memory areas in the block random access memory (BRAM) and double data rate synchronous dynamic random access memory (DDR) for instruction transfer and multi-core 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 mutual checking on the address ranges of dynamic and static memory areas, checks the start 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 areas of each ELF file in an XML or TXT format file, including specifying the area name, start address, size, and corresponding item of the link script to provide basic information and path for memory configuration;

[0015] Step 1.2: read and parse the static configuration file through a 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: update or generate the link script specified in the path using the parsed configuration information through the code script, add or modify the link items in the script to adapt to the memory configuration, and after updating the link script, the static memory configuration is synchronized.

[0017] Preferably, the step 2 comprises:

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

[0019] Step 2.2: the bootloader of each processor unit (APU) determines the entry address and jumps by parsing the ELF file, thereby dynamically loading the application program (APP); 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 to the shared memory area;

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

[0021] Step 2.4: The API interface returns the allocated memory address, and the application program uses the returned memory address for data operation. When the preset condition is met, the space is released through the recycling function.

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

[0023] The application program calls the API interface to apply for memory of a specified size to the dynamic memory management module;

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

[0025] Preferably, the step 4 comprises:

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

[0027] Step 4.2: The start address and end address of the memory area defined in the configuration file are parsed, and the address range information is outputted;

[0028] Step 4.3: The address ranges of the memory areas are checked to ensure that the dynamic memory and the static memory areas do not conflict with each other, and each dynamic memory area is independent of each other;

[0029] Step 4.4: It is judged whether the verification passes. If the verification passes, it indicates that there is no address conflict, and the system enters the normal startup stage and continues to perform other initialization tasks. If the verification fails, it indicates that an address conflict is detected, and the system enters the stop startup stage and returns an error information to prompt the system administrator or trigger an automatic restart logic.

[0030] According to the multi-core embedded system memory management system based on static and dynamic memory configuration provided by the application, comprising:

[0031] Module M1: The memory areas and address information of multiple cores are defined using a static configuration file, and then a parsing script is written to read these configuration information and automatically generate or update the link script of the system, realizing the automation of static memory allocation;

[0032] Module M2: configure dynamic memory allocation API interface, interface through the preset dynamic memory allocation function and physical memory pool connection, from the application program initiates memory request, API checks the physical memory pool and returns the allocated address or failure information, the application program is based on the returned address read and write data, to meet the application program to dynamic memory allocation requirements, ensure that the application program to fixed physical address invisible, by API interface definition available address;

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

[0034] Module M4: real-time processing unit RPU in the start from the static configuration file loading memory allocation table, and the address range of dynamic and static memory area mutual exclusion verification, check all memory area starting address and length, ensure that there is no address overlap between different regions.

[0035] Preferably, the module M1 comprises:

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

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

[0038] Module M1.3: through the code script, the configuration information parsed is used to update or generate the link script specified in the path, add or modify the link item in the script to adapt to the memory configuration, after updating the link script, the static memory configuration is completed synchronization.

[0039] Preferably, the module M2 comprises:

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

[0041] Module M2.2: the bootloader of each processor unit APU determines the entry address and jumps through parsing the ELF file, so as to dynamically load the application program APP; at the same time, responsible for storing the ELF file of APP to the Flash position of RPU kernel, and writing the dynamic memory base address and length information into the shared memory area;

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

[0043] Module M2.4: the API interface returns the allocated memory address, the application program uses the returned memory address for data operation, and re-releases the space through the recycling function when the preset condition is met.

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

[0045] The application program calls the API interface to apply for memory of a specified size to the dynamic memory management module;

[0046] The API interface checks whether there is enough space in the dynamic memory area to meet the application demand, if there is enough memory space, the allocation is successful, and the allocated memory address is returned, the application program uses the address to read and write the memory; otherwise, the allocation fails, and the allocation failure information is returned, prompting that there is not enough memory space for allocation, and the application program needs to handle the error, including re-applying 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 at system startup, including static and dynamic configuration files, to obtain the address information of each memory area;

[0049] Module M4.2: the starting address and ending address of the memory area defined in the configuration file are parsed, and the address range information is outputted;

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

[0051] Module M4.4: it is judged whether the verification passes, if the verification passes, it indicates that there is no address conflict, the system enters the normal startup stage, and continues to execute other initialization tasks; if the verification fails, it indicates that an address conflict is detected, the system enters the stop startup stage, and returns error information to prompt the system administrator or trigger the automatic restart logic.

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

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

[0054] (2) The application is suitable for the field of memory management of multi-core embedded systems, in particular, memory configuration and shared interaction of heterogeneous platforms, and can be widely applied to automatic driving, communication equipment and industrial control, etc., and provides a new light memory management solution for multi-core embedded systems. BRIEF DESCRIPTION OF DRAWINGS

[0055] Other features, objects, and advantages of the application will become more apparent from the following detailed description of non-limiting embodiments, when read in conjunction with the accompanying drawings:

[0056] Figure 1 Static memory configuration and synchronization flowchart;

[0057] Figure 2 Dynamic memory configuration flowchart;

[0058] Figure 3 Mutual exclusion safety check flowchart;

[0059] Figure 4 Dynamic memory allocation API interface usage flowchart;

[0060] Figure 5 Static configuration file TXT format example;

[0061] Figure 6 Static configuration file XML format example;

[0062] Figure 7 Dynamic configuration file TXT format example;

[0063] Figure 8 Dynamic configuration file XML format example;

[0064] Figure 9 Link script (lscript.ld) and link item (LinkItem) example;

[0065] Figure 10 RPU and APU data communication instruction format;

[0066] Figure 11 Dynamic memory API interface implementation example. DETAILED DESCRIPTION

[0067] The application will be described in detail below with specific embodiments. The following embodiments will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be noted that for those skilled in the art, without departing from the concept of the application, a number of changes and improvements can be made. These are within the scope of the application.

[0068] EMBODIMENT

[0069] The application provides a method for implementing static memory allocation configuration in an FPGA-CPU heterogeneous system, which writes a static memory region 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 in the compilation and linking stage. The embodiment defines a memory region through a TXT and XML configuration file and synchronizes the configuration to the lscript.ld file by using a Python script. The purpose of the design is to implement static configuration of the memory region in the FPGA-CPU heterogeneous platform to achieve the consistency effect of memory access. Through the step, the accuracy of cross-core memory interaction can be effectively improved, and the access conflict caused by inconsistent memory mapping can be avoided.

[0070] The method comprises the following steps:

[0071] 1. Configuration file preparation: first, a configuration file of a memory region is prepared, and the system supports two formats, namely a TXT format and an XML format. The content of the TXT format file includes a static memory region name, a start address, a length, a link script path and a link item, for example, APU boot loader region, shared memory region and RPU exclusive memory region and the like. The configuration content of the XML file is provided by nesting tags to provide corresponding field information, facilitating automatic parsing of the script.

[0072] 2. Parsing the configuration file: the XML configuration file is parsed by using a Python script, the start address, size, link script path and the like of each memory region are read, and are stored in a data structure, so as to be updated synchronously subsequently.

[0073] 3. Synchronization to the lscript.ld file: the script reads the content of each memory region corresponding to the lscript.ld file, finds the “MEMORY” definition region, and locates the specific position of each configuration item. According to the parsed configuration data, the start address and length of the matched link item are updated to ensure the consistency of the configuration.

[0074] 4. Compiling to generate an ELF file: after the configuration is completed, the updated lscript.ld file is compiled to generate a target ELF file, so that the static memory configuration takes effect.

[0075] The static memory allocation configuration method provided in the embodiment solves the problem of inconsistent memory access in the FPGA-CPU heterogeneous system, and can be widely applied to embedded system design with a heterogeneous multi-core processing unit. The embodiment realizes synchronization and update of the memory configuration by combining the configuration file and the script automation.

[0076] In the embodiment, a method for dynamic memory allocation configuration is provided, mainly including the definition of dynamic memory region, the loading of configuration file, and the process of mutual exclusion safety check, to ensure the safe and reliable memory use of each module in the FPGA-CPU heterogeneous platform. The 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 region of the APP module. The TXT format file is mainly used for the record of dynamic memory region, but the RPU (R5 core) reads the XML format file by default, so the TXT format file is only for reference 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 into a specific memory region ('MEM_ASSIGN_DDR') and provide it to the APU for memory management at system startup. In the system startup process, the RPU in the embodiment loads the static and dynamic memory region configuration files from the SD card, and performs mutual exclusion safety check on the dynamic and static memory regions of each module. The steps of the check are as follows: the RPU first reads the memory allocation configuration table, which contains the static and dynamic memory address and length information of each module. Each memory region in the dynamic configuration file is compared with the static memory region one by one to ensure that the memory address and length do not conflict. If there is no overlap of the memory region, the check is passed and the system will continue to load. The mutual exclusion safety check is designed to ensure the independent and safe memory allocation of each APP module and avoid the problem of memory overlap. Through this step, the safety 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 the embodiment can meet the memory management needs of each APP module in the FPGA-CPU heterogeneous platform and can be widely applied to the memory configuration in the multi-core heterogeneous computing environment.

[0077] In the embodiment, a system method for ELF address parameter acquisition and shared memory communication in FPGA-CPU heterogeneous platform is provided. In the method, it is first determined that an application program (APP) is dynamically loaded. A BootLoader of each APU core realizes jump by analyzing an entry address of an ELF file, thereby dynamically loading the APP, and a RPU core writes a flash storage address of the ELF file, a base address and a length of available dynamic memory of the APP into a shared memory region. The shared memory region mainly realizes information transmission between the RPU and the APU, thereby meeting the independent communication requirement between modules in a multi-core system. Since the RPU and the APU can only access the shared memory through a BRAM defined by a PL end through an AXI bus, and the APU share a same DDR region, two shared memory regions are opened through a static configuration file. They are defined as follows: 'BRAM_1': 4 KB in size, available for the RPU core to write and the APU core to read, so as to realize instruction transmission from the RPU to the APU. 'DDR_0 SHARED_DDR_BASEADDR': the shared region is available for all APU cores to access, wherein the first APU core is responsible for writing, and the other APU cores read, so as to realize multi-core information sharing. A control instruction includes two parts, 'Flag' and 'Data', and has the following format: 'Flag': the first byte is used to represent a message type or a state. 'Data': the remaining bytes (the 2nd to 4096th bytes) are used to store specific data information. The control instruction is written into 'BRAM_1' by the RPU core, and the first APU core receives the instruction by reading the region. Then, the first APU core writes the received instruction into the 'DDR_0 SHARED_DDR_BASEADDR' shared region, which is available for the other APU cores to read, thereby realizing communication between the RPU and the multi-core APU. In order to realize independent communication of each core, different shared data regions are allocated to each APU core, and are defined as follows: 'StartAddr:1,Length=sizeof(ElfData)': the shared data region of the first APU core. 'StartAddr:sizeof(ElfData)*1+1,Length=sizeof(ElfData)': the shared data region of the second APU core. In this way, each core has an independent shared space. Structure body definition: the ELF information format stored in the shared data region is defined through a structure body 'ElfData', which includes 'name', 'flash_baseaddr', 'flash_length','mem_baseaddr','mem_length', which respectively correspond to a region name, a position of ELF loading from a flash, a length of ELF occupying the flash, a start address of a defined dynamic memory region, and a length.In the embodiment, 'DATA_SIZE' is set to 4096 bytes to accommodate the data requirement of shared memory transmission; 'FLAG_INDEX' is set to 0 for the storage of flag bits; and 'DATA_START_INDEX' is set to 1 to point to the start byte of data. The purpose of this design is to realize independent and safe memory area communication between the RPU and APU multi-core systems. By setting the shared data area, a certain APU core can forward the instructions transmitted by the RPU core to other APU cores, thereby effectively supporting the multi-core application requirement.

[0078] In this embodiment, a method for implementing the'my_malloc' function for APU core application dynamic memory allocation is provided. This method addresses the problem of uncertain memory requirements of applications in a multi-core system by providing a custom dynamic memory allocation API interface for the application. Through this method, the program can allocate memory on demand and effectively recycle memory space. The method includes the following steps: 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 region is available for allocation. 2) Memory allocation: when dynamic memory allocation is needed, call the'my_malloc' function and specify the size of the allocated memory. For example, the first call to'my_malloc(128)' allocates 128 bytes of memory. If the allocation is successful, the function returns a pointer to the allocated region; if the allocation fails, it returns 'NULL' and outputs an error message. 3) Data storage: convert the allocated pointer to a specific data type pointer to facilitate data storage and reading. For example, convert 'ptr1' to an 'int*' type pointer and write data to memory. 4) Memory recycling and resetting: when the program is finished using the memory, release the memory space at a specific address through the'my_free' function, or reset the entire memory pool 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 initialization. This parameter configuration is based on the system memory distribution and application requirements to ensure the rationality of the allocated space. The purpose of this design is to achieve the dynamic allocation and management of the memory pool in a multi-core system 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 running 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 For the process of static memory configuration and synchronization to the link file, there are four main steps:

[0080] Step 1. Static Configuration File Definition

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

[0082] Step 2. Static Configuration Parsing

[0083] Read and parse the above static configuration file through code scripts. Extract the memory address range and size of each core from the file, providing a basis for the next step.

[0084] Step 3. Link Script Generation

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

[0086] Step 4. Memory Configuration Synchronization Completion

[0087] After updating the link script, the static memory configuration is synchronized. This phase marks the start of the subsequent processing phase of memory configuration updates.

[0088] Figure 2 For the dynamic memory configuration process, it is divided into four steps:

[0089] Step 1. Dynamic Configuration File Definition

[0090] Define the base address and length of the memory region for the application in the configuration file in XML or TXT format. This is the initial step of dynamic memory allocation, describing memory distribution information.

[0091] Step 2. Dynamic APP Loading and Parameter Passing

[0092] The BootLoader of each processor unit (APU) determines the entry address and jumps by parsing the ELF file, thereby dynamically loading the APP. 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 to the shared memory area.

[0093] Step 3. Dynamic Allocation API Call

[0094] The application (APP) applies for memory through the API interface. The API allocates space from the predefined dynamic memory region according to the APP's needs.

[0095] Step 4. Memory address return

[0096] The API interface returns the allocated memory address. The application uses the returned memory address for data operations and re-releases the space through the recycling function if necessary.

[0097] Figure 3 For mutual exclusion safety verification process, mainly used for address conflict checking of static and dynamic memory configuration areas at system startup, to ensure the safety of memory allocation. The specific process steps are as follows:

[0098] Step 1. Start loading memory configuration file

[0099] RPU (Real-Time Processing Unit) reads the memory configuration file (including static and dynamic configuration files) at system startup, and obtains the address information of each memory area. This step provides complete memory area description for subsequent steps.

[0100] Step 2. Address range resolution

[0101] Resolve the start address and end address 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 verification

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

[0104] Step 4. Determine if the verification passes

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

[0106] No (not passed): If address conflict is detected, the system enters the stop startup phase. Return error information. Stop the startup process and prompt the system administrator or trigger the automatic restart logic.

[0107] Figure 4 For the usage process of dynamic memory allocation API interface, the purpose is to describe how the application requests and manages dynamic memory allocation through custom API interface. The specific process is as follows:

[0108] Step 1. API calls request memory

[0109] The application calls the API interface to apply for a specified size of memory to the dynamic memory management module.

[0110] Step 2. API checks available space

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

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

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

[0114] Otherwise, the allocation fails. Return the failure information, 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 A complex embedded system's static memory allocation configuration is defined in TXT format, including the memory start address, length, purpose of different functional modules, and related link script positions and associated storage resources. These configurations are compiled into ELF files through link scripts (ˋ.ldˋ files) to ensure that each module can correctly access its dedicated memory area during system runtime.

[0116] The specific allocation is as follows:

[0117] (1) A53 core BootLoader (BootLoader 0-3)

[0118] Each A53 core has an independent BootLoader responsible for initializing the core's runtime environment. Each BootLoader allocates a memory space of ˋ0x4000000ˋ (64MB) size.

[0119] Start address and allocation logic:

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

[0121] A53-1: starts 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 item.

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

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

[0127] Start address: '0x5000000', Length: '0x30000000' (768 MB).

[0128] Mainly stores and processes image receiving tasks.

[0129] APP1 (recognition module):

[0130] Start address: '0x65000000', Length: '0x4000000' (64 MB).

[0131] Used for image recognition tasks.

[0132] APP2 (tracking module-1):

[0133] Start address: '0x45000000', Length: '0x4000000' (64 MB).

[0134] First submodule of tracking function.

[0135] APP3 (tracking module-2):

[0136] Start address: '0x55000000', Length: '0x4000000' (64 MB).

[0137] Second submodule of tracking function.

[0138] (3) Shared memory area

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

[0140] 1) A53 core shared memory:

[0141] Start address: '0x70000000', Length: '0x30000' (192 KB).

[0142] Allows data exchange between A53 cores.

[0143] 2) YOLO output memory:

[0144] Start address: '0x410010000', Length: '0x2000' (8 KB).

[0145] Used to store YOLO target detection results.

[0146] 3) PL-DDR4 shared storage:

[0147] Start address: '0x400000000', length: '0x10000000'(256MB).

[0148] For a large amount of data transmission between A53 core and PL, such as image buffer.

[0149] 4) R5 core exclusive memory

[0150] R5 core is allocated an independent dedicated memory area, which is not shared with A53 core.

[0151] Start 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'.

[0153] The control instruction interaction memory between A53-0 and R5-0 cores is defined.

[0154] Start address: '0x80000000', length: '0x1000'(4KB).

[0155] Used for exchanging control instructions, supporting two-core cooperation.

[0156] As Figure 6 The above static memory configuration example is given in XML format.

[0157] Figure 7 The allocation of dynamic memory areas configured in TXT format is given, mainly including four specific partitions of application business logic memory (APP0, APP1, APP2, APP3) and their respective start addresses and length information. The configuration of these memory areas is written by R5 core through XML file loading 'MEM_ASSIGN_DDR', which is obtained and used at APU startup.

[0158] The specific allocation is as follows:

[0159] APP0

[0160] Start address: '0x5000000'

[0161] Length: '0x30000000'(768MB)

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

[0163] APP1

[0164] Start Address: '0x65000000'

[0165] Length: '0x4000000' (64 MB)

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

[0167] APP2

[0168] Start Address: '0x45000000'

[0169] Length: '0x4000000' (64 MB)

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

[0171] APP3

[0172] Start Address: '0x55000000'

[0173] Length: '0x4000000' (64 MB)

[0174] Description: Another 64 MB memory region supporting another business logic module.

[0175] As Figure 8 the above dynamic memory configuration example is given in XML format.

[0176] Figure 9 For Link Script (lscript.ld) and Link Item examples;

[0177] The figure shows a part of the link script file 'lscript.ld' and its memory allocation definition and configuration example. The link script content analysis is as follows:

[0178] (1) File header description:

[0179] Provides version information (2018.3) and copyright information (Xilinx) for script generation. It indicates that this script is used for link configuration of 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, respectively, as `0x2000` and `0x2000` bytes.

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

[0183] The different memory regions in the system are defined, along with 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, typically DDR memory)

[0190] Other memory regions such as DDR, PSRAM, or shared memory are also defined with their addresses and sizes. These memory region definitions will be used to allocate specific segments of data, such as the code segment (text), data segment (data), stack, etc.

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

[0192] The default program entry point (`_vector_table`) is set. This is typically the first instruction address that the program executes when it starts.

[0193] (5) Section and memory mapping (SECTIONS block, Lines 32-end):

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

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

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

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

[0198] Figure 10 The format of the RPU and APU data communication instruction is shown in the figure, which includes two parts, `Flag` and `Data`, as follows: `Flag`: the first byte is used to represent the message type or status. `Data`: the remaining bytes (2nd to 4096th bytes) are used to store specific data information.

[0199] Figure 11 For dynamic memory call API interface implementation example.

[0200] This code gives an example of custom dynamic memory call API interface implementation. 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 needed, call the `my_malloc` function and specify the size of the allocated memory. For example, the first call to `my_malloc(128)` allocates 128 bytes of memory. If the allocation is successful, the function returns a pointer to the allocated region; if the allocation fails, it returns `NULL` and outputs error information. 3) Data storage: Convert the allocated pointer to a specific data type pointer to facilitate data storage and reading. For example, convert `ptr1` to an `int*` type pointer and write data to memory. 4) Memory recycling and resetting: When the program is finished using the memory, release the memory space at a specific address through the `my_free` function, or reset the entire memory pool by calling the `my_malloc_reset` function to allow subsequent reallocation. In this example, 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 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.

[0201] Those skilled in the art know that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the same program can also be implemented in the form of logic gate, switch, special integrated circuit, programmable logic controller and embedded microcontroller, etc. by logically programming the method steps. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures in the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing methods and structures in the hardware component.

[0202] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily without conflict.

Claims

1. A memory management method for a multi-core embedded system 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, 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 connects 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 needs for dynamic memory allocation. This ensures that the application is invisible to fixed physical addresses. The available addresses are defined by the API interface. Step 3: Configure multiple shared memory areas, located in block random access memory (BRAM) and double data rate synchronous dynamic random access memory (DDR), for instruction transfer 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, checking the starting address and length of all memory areas to ensure 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 paths for memory configuration; Step 1.2: Use a code script to read and parse the static configuration file, and extract the memory address range and size configuration information 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. 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 includes: 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 layout information; Step 2.2: The boot loader of each processor unit (APU) dynamically loads the application program (APP) by parsing the ELF file, determining the entry address and jumping to it. At the same time, it is responsible for storing the APP's ELF file in the Flash location of the RPU core and writing the dynamic memory base address and length information to the shared memory area. Step 2.3: The application program APP requests memory through the API interface. The API allocates space from the predefined dynamic memory area based on the application's needs. 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 interfaces include: 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 re-applying 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: When the system starts, the real-time processing unit (RPU) reads the memory configuration file, including static and dynamic configuration files, to obtain 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 it 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 it fails, 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, 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; Module M2: Configures the dynamic memory allocation API interface. The interface connects 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. This ensures that the application is invisible to fixed physical addresses. The available addresses are defined by the API interface. Module M3: Configures multiple shared memory areas, located in block random access memory (BRAM) and double-data-rate synchronous dynamic random access memory (DDR), for instruction transfer 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, performs 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 includes: Module M1.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 paths for memory configuration; Module M1.2: Reads and parses the static configuration file through a code script, and extracts the memory address range and size configuration information 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. 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 includes: Module M2.1: Defines the base address and length of the memory area for the application in the XML or TXT format configuration file to describe the memory distribution information; Module M2.2: The boot loader of each processor unit (APU) dynamically loads the application program (APP) by parsing the ELF file, determining the entry address and jumping to it. At the same time, it is responsible for storing the APP's ELF file in the Flash location of the RPU core and writing the dynamic memory base address and length information to the shared memory area. Module M2.3: The application program 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 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 interfaces include: 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 re-applying 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 includes: Module M4.1: The real-time processing unit (RPU) reads the memory configuration files, 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: Checks whether the address ranges of each memory area overlap, ensuring 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: Determines 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 fails, 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