Memory management method and memory controller

Abstract

The invention provides a memory management method and a memory controller. The memory management method is applied to the storage device provided with a memory module and a buffer memory. The method comprises the steps of determining a necessary function and a high-frequency call function as a first type function by analyzing a call relationship of functions in a firmware program, and pre-loading the first type function into a resident storage area of a buffer memory; dividing the rest of the second type functions into a plurality of storage libraries according to the function calling relationship, and storing the rest of the second type functions in a storage module; and when the specific function needs to be executed, dynamically loading the storage library containing the target function into the dynamic storage area of the buffer memory. According to the method, through weight calculation and an intelligent allocation strategy, the number of times of switching of a storage library (Bank) can be reduced, so that the resource utilization rate of a memory is improved, the overall performance of a system is improved, automatic management of firmware codes is achieved, and the complexity and error risk of manual adjustment are reduced.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of storage technology, and in particular, to a memory management method and a memory controller for a storage device configured with a memory module and a buffer memory. BACKGROUND

[0002] In modern storage devices, due to the high cost and limited capacity of random access memory (RAM), the code size of firmware programs usually far exceeds the RAM capacity for executing the code in the storage device, thus it is necessary to selectively load the code to achieve efficient memory management.

[0003] Conventional memory management methods usually divide the code into two main parts: one part is the code in the resident RAM, referred to as common code; the other part is the non-resident RAM code, which is usually stored in a storage bank, and only when a specific time or a specific operation is triggered, the corresponding storage bank is loaded into the RAM for running, which generates a certain time overhead in the process.

[0004] Therefore, there is an urgent need for a memory management method and a memory controller to solve the above problems. SUMMARY

[0005] Therefore, the present disclosure provides a memory management method and a memory controller. According to the call relationship of functions in a firmware program, the functions are divided into two categories: the first category of functions includes system necessary functions and functions with a number of references exceeding a threshold, which are loaded into the resident storage area of the buffer memory; the second category of functions are allocated to multiple storage banks according to the function branching relationship and stored in the memory module. When a second category function needs to be executed, the corresponding storage bank is loaded from the memory module to the dynamic storage area of the buffer memory.

[0006] One or more embodiments of the present disclosure provide a memory management method applied to a storage device configured with a memory module and a buffer memory. The method comprises: determining a plurality of first type functions and a plurality of second type functions according to the function call relationship of a firmware program and / or necessary operations of the storage device; preloading the plurality of first type functions into a resident storage area of the buffer memory; dividing the plurality of second type functions into a plurality of storage banks and storing the plurality of storage banks in the memory module; in response to a target instruction, loading a target storage bank containing a target second type function from the memory module to a dynamic storage area to execute a target operation corresponding to the target instruction.

[0007] One or more embodiments of the present disclosure provide a memory controller for controlling a storage device configured with a memory module. The memory controller comprises a memory interface control circuit electrically connected to the memory module; a buffer memory for buffering data; and a processor electrically connected to the memory interface control circuit and the buffer memory, wherein the processor is further electrically connected to a connection interface circuit of the storage device for electrically connecting to a host system. The processor is configured to determine a plurality of first type functions and a plurality of second type functions according to a function call relationship of a firmware program and / or necessary operations of the storage device; pre-load the plurality of first type functions into a resident storage area of the buffer memory; divide the plurality of second type functions into a plurality of storage banks and store the plurality of storage banks into the memory module; and in response to a target instruction, load a target storage bank containing a target second type function from the memory module into a dynamic storage area to perform a target operation corresponding to the target instruction.

[0008] Based on the above technical solutions, the technical features of the present disclosure are as follows:

[0009] The necessary functions such as start-up functions, power management functions, error handling functions, and interrupt service functions, and functions with reference weight values greater than a predetermined threshold are loaded into the resident storage area, reducing the loading time of these functions and avoiding the overhead of dynamically loading these functions.

[0010] According to the function call relationship, related functions are assigned to the same storage bank. When a function is called by multiple storage banks and the general-purpose weight exceeds the threshold, the function is moved to the resident storage area.

[0011] When the storage bank capacity is exceeded, the function at the end of the function branch in the storage bank is moved to another storage bank with space. When executing a function, if the target function is not in the dynamic storage area, load the storage bank containing the function. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 is a block schematic diagram of a host system and a storage device according to an embodiment of the present disclosure;

[0013] Figure 2 is a flowchart of a memory management method according to an embodiment of the present disclosure;

[0014] Figure 3 is a structural schematic diagram of a buffer memory and a memory module according to an embodiment of the present disclosure;

[0015] Figure 4 is a detailed flowchart of a memory management method according to an embodiment of the present disclosure;

[0016] Figure 5 a schematic diagram of function call relationship of each function shown according to an embodiment of the present disclosure;

[0017] Figure 6 a schematic diagram of function reference relationship of each function shown according to an embodiment of the present disclosure;

[0018] Figure 7 a schematic diagram of function call relationship and assigning function branches to multiple storages shown according to an embodiment of the present disclosure;

[0019] Figure 8 a schematic diagram of function reference weight calculation and assignment shown according to an embodiment of the present disclosure;

[0020] Figure 9 a schematic diagram of high general-purpose function moving to a resident storage shown according to an embodiment of the present disclosure;

[0021] Figure 10 a timing diagram of loading a target storage dynamically according to an instruction shown according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0022] Reference will now be made in detail to the exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or like parts.

[0023] Figure 1 a block schematic diagram of a host system and a storage device shown according to an embodiment of the present disclosure. Please refer to Figure 1 , the host system 10 is, for example, a personal computer, a notebook computer, a server. The host system 10 includes a processor 110 (also referred to as a second processor) and a host memory 120 (also referred to as a host internal memory), a data transfer interface circuit 130. In the present embodiment, the processor 110 is coupled (also referred to as electrically connected) to the host memory 120 and the data transfer interface circuit 130. In another embodiment, the processor 110, the host memory 120 and the data transfer interface circuit 130 are electrically connected to each other by a system bus. In the present embodiment, the processor 110, the host memory 120 and the data transfer interface circuit 130 can be disposed on a host board of the host system 10.

[0024] The storage device 20 includes a memory controller 210, a memory module 220 (also referred to as a rewritable non-volatile memory module), and a connection interface circuit 230. The memory controller 210 includes a processor 211 (also referred to as a first processor), a data management circuit 212, a memory interface control circuit 213, and a buffer memory 214.

[0025] In this embodiment, the host system 10 is electrically connected to the storage device 20 via the data transmission interface circuit 130 and the connection interface circuit 230 of the storage device 20 to perform data access operations. For example, the host system 10 can store data to or read data from the storage device 20 via the data transmission interface circuit 130.

[0026] In this embodiment, the number of data transmission interface circuits 130 can be one or more. Through the data transmission interface circuit 130, the host board can be electrically connected to the storage device 20 via wired or wireless means. The storage device 20 can be, for example, a USB flash drive, a memory card, a solid state drive (SSD), or a wireless memory storage device. The wireless memory storage device can be, for example, a near field communication (NFC) memory storage device, a wireless fidelity (WiFi) memory storage device, a Bluetooth memory storage device, or a Bluetooth low energy memory storage device (e.g., iBeacon), etc. based on various wireless communication technologies. In addition, the host board can also be electrically connected to various I / O devices such as a global positioning system (GPS) module, a network interface card, a wireless transmission device, a keyboard, a screen, a speaker, etc. via a system bus.

[0027] In the present embodiment, the data transfer interface circuit 130 and the connection interface circuit 230 are interface circuits compatible with the Peripheral Component Interconnect Express (PCI Express) standard. Furthermore, data is transferred between the data transfer interface circuit 130 and the connection interface circuit 230 using the Non-Volatile Memory express (NVMe) communication protocol.

[0028] Furthermore, in another embodiment, the connection interface circuit 230 can be packaged in a chip with the memory controller 210, or the connection interface circuit 230 can be disposed outside a chip that includes the memory controller 210.

[0029] In the present embodiment, the host memory 120 is used to temporarily store instructions or data executed by the processor 110. In the present embodiment, the host memory 120 can be a Dynamic Random Access Memory (DRAM), a Static Random Access Memory (SRAM), or the like. However, it must be understood that the present disclosure is not limited thereto, and the host memory 120 can also be other suitable memories.

[0030] The memory controller 210 is used to execute a plurality of logic gates or control instructions implemented in a hardware type or a firmware type and perform operations such as writing, reading, and erasing data in the memory module 220 according to instructions of the host system 10.

[0031] In more detail, the processor 211 in the memory controller 210 is a hardware with computing capability, which is used to control the overall operation of the memory controller 210. Specifically, the processor 211 is programmed with a plurality of control instructions / program codes, and when the storage device 20 is in operation, the control instructions / program codes are executed to perform operations such as writing, reading and erasing data. In addition, the processor 211 is configured to: determine a plurality of first type functions from a plurality of functions of a firmware program corresponding to the storage device 20 according to a function call relationship of the plurality of functions or necessary operations of the storage device 20; pre-load the plurality of first type functions into a resident storage area of the buffer memory 214; divide a plurality of second type functions other than the plurality of first type functions in the firmware program into a plurality of storage repositories according to the function call relationship, and store the plurality of storage repositories in the memory module 220; and when a target second type function is called in response to an instruction and the target second type function does not exist in a dynamic storage area of the buffer memory 214, load a target storage repository containing the target second type function from the memory module 220 to the dynamic storage area.

[0032] In other embodiments, the control instructions / program codes corresponding to the data reading method can be implemented as circuit units in hardware form to achieve the memory management method provided by the present disclosure.

[0033] It is worth mentioning that in the present embodiment, the processor 110 and the processor 211 are, for example, a central processing unit (CPU), a micro-processor, or other programmable processing units (Microprocessor), a digital signal processor (DSP), a programmable controller, an application specific integrated circuit (ASIC), a programmable logic device (PLD), or other similar circuit components, and the present disclosure is not limited thereto.

[0034] In the present embodiment, as described above, the memory controller 210 further includes the data management circuit 212 and the memory interface control circuit 213. It should be noted that the operations performed by the components of the memory controller 210 can also be considered as operations performed by the memory controller 210.

[0035] The data management circuit 212 is electrically connected to the processor 211, the memory interface control circuit 213, and the connection interface circuit 230. The data management circuit 212 is configured to accept instructions from the processor 211 to perform data transfer. For example, data is read from the host system 10 (e.g., the host memory 120) via the connection interface circuit 230, and the read data is written into the memory module 220 via the memory interface control circuit 213 (e.g., performing corresponding write operations according to write instructions from the host system 10). For another example, data is read from one or more physical units of the memory module 220 (the data can be read from one or more memory cells of the one or more physical units) via the memory interface control circuit 213 according to read instructions from the host system 10, and the read data is written into the host system 10 (e.g., the host memory 120) via the connection interface circuit 230. In another embodiment, the data management circuit 212 can be integrated into the processor 211.

[0036] The memory interface control circuit 213 is configured to accept instructions from the processor 211 to perform write (also referred to as programming), read, or erase operations on the memory module 220 in cooperation with the data management circuit 212.

[0037] In addition, data to be written into the memory module 220 is converted into a format acceptable to the memory module 220 via the memory interface control circuit 213. Specifically, if the processor 211 wants to access the memory module 220, the processor 211 sends corresponding instruction sequences to the memory interface control circuit 213 to instruct the memory interface control circuit 213 to perform corresponding operations. For example, the instruction sequences can include write instruction sequences to instruct writing of data, read instruction sequences to instruct reading of data, erase instruction sequences to instruct erasing of data, and corresponding instruction sequences to instruct various memory operations. The instruction sequences can include one or more signals, or data on a bus. The signals or data can include instruction codes or program codes. For example, in a read instruction sequence, identification codes of reading, memory addresses, physical addresses, and the like are included.

[0038] In addition, the memory controller 210 establishes a mapping table to record the mapping information between the logical addresses and the physical addresses. In conventional memory management, the memory controller usually establishes a logical to physical address mapping table and a physical to logical address mapping table, which are used to find the physical unit (e.g., physical erase unit / physical block, physical page) mapped by a logical unit (e.g., logical block, logical page) and find the logical unit mapped by a physical unit, respectively. In addition, the physical to logical address mapping table can also be used to determine the valid data and invalid data in a specific physical block.

[0039] The buffer memory 214 is electrically connected to the processor 211 and is used to temporarily store data and instructions from the host system 10, data from the memory module 220, and various system data for managing the storage device 20.

[0040] In the present embodiment, the buffer memory 214 includes a resident storage area and a dynamic storage area. The resident storage area is used to store the plurality of first type functions, and the resident storage area includes a first resident sub-area and a second resident sub-area. The first resident sub-area is kept powered in the low power mode of the storage device 20, and the second resident sub-area is powered off in the low power mode. The dynamic storage area is used to dynamically load target storage libraries containing target second type functions according to instruction requirements. The buffer memory 214 is configured to provide the cache space required for function storage and dynamic loading when the processor 211 executes the memory management method of the present disclosure.

[0041] It should be noted that the present disclosure is not limited to two resident sub-areas, and one or more resident sub-areas can be set according to hardware specifications or firmware requirements by those skilled in the art. In addition, in other embodiments, the dynamic storage area can also load more target storage libraries according to different hardware specifications. The present disclosure is not limited to the size of each resident storage area and the dynamic storage area.

[0042] The processor 211 is configured to analyze the function call relationship of the firmware program, calculate the reference weight value of each function, and determine a plurality of essential functions and a plurality of performance optimization functions as the first type functions. The processor 211 is also configured to divide the second type functions into a plurality of storage libraries according to function branches, and each storage library corresponds to a complete function implementation branch. When the capacity of the storage library is insufficient, the processor 211 is configured to reassign the selected functions to other storage libraries with the largest available space.

[0043] In this embodiment, the memory module 220 is a NAND Flash memory module. The memory module 220 is electrically connected to the memory controller 210 (specifically, to the memory interface control circuit 213). Specifically, the memory module 220 includes a plurality of chips, each of which is further subdivided into a plurality of planes, and each of which contains a plurality of physical blocks. In addition, each physical block in the memory module 220 further includes a plurality of physical pages, each of which contains a plurality of memory cells. It should be noted that the present disclosure is not limited to the size of each physical page and logical page.

[0044] In this embodiment, the memory module 220 is used to store user data sent by the host system 10. In addition, the memory module 220 can also store a plurality of repositories, each of which is used to store a partial function (also referred to as a program segment, a program module, or a subroutine module) of the firmware program of the corresponding storage device 20, and the memory module 220 can also be used to store system data (such as various types of mapping tables, function call relationships, and the like, which are used to manage data or information of the storage device 20).

[0045] Figure 2 is a flowchart of a memory management method according to an embodiment of the present disclosure.

[0046] Referring to Figure 2 First, in step S210, the processor 211 determines a plurality of first-type functions and a plurality of second-type functions according to the function call relationships of a plurality of functions of the firmware program of the corresponding storage device 20 and / or the necessary operations of the storage device 20.

[0047] For the sake of clarity, the "function" described in the present disclosure refers to a program code function, a subroutine, or a code block in the firmware program, rather than a function in the mathematical sense. Each function contains an executable code segment of a specific function, has an independent entry point and an exit point, and can be called by other functions to implement a specific operation. The functions are dependent on each other through call instructions, forming a logical structure of program execution.

[0048] Specifically, the processor 211 first acquires firmware program information, analyzes the code of the firmware program and a plurality of functions, acquires the function call relationship and the function reference relationship of each function, and acquires the function call relationship corresponding to the plurality of functions. The function call relationship is used to indicate the other functions called by each function. The function reference relationship is used to indicate which other functions call (call) each function.

[0049] The function call relationship can be implemented using various data structures, such as a tree structure (e.g., a call graph), a directed graph, or the like. Figure 7a mapping table, a list, a graph structure, an adjacency matrix, an adjacency list, a call stack structure, a hierarchical index table, an associative array, or a linked structure.

[0050] Figure 5 A schematic diagram of function call relationship for each function shown according to an embodiment of the disclosure.

[0051] Referring to Figure 5 In one embodiment, the processor 211 obtains the function call relationship by analyzing the firmware program. As shown in Figure 5 , the function call relationship records which other functions each function calls and the number of times it calls them. For example, the main function, as the entry point of the firmware program, calls function 1 C01 times, function 2 C02 times, and so on. Function 1 further calls function 3 C13 times, function 2 calls function 3 C23 times and function 4 C24 times, function 4 calls function 5 C45 times and function 6 C46 times.

[0052] By establishing such a call relationship structure and the code order within the firmware program, the processor 211 can track the downstream dependency relationship of each function and identify the function call sequence in the function execution path. The function call relationship provides basic data for subsequent repository division, ensuring that function-related functions can be reasonably organized in the same repository.

[0053] Figure 6 A schematic diagram of function reference relationship for each function shown according to an embodiment of the disclosure.

[0054] Referring to Figure 6 In one embodiment, the processor 211 can obtain the function reference relationship based on the function call relationship or by analyzing the firmware program. As shown in Figure 6 , the function reference relationship records which other functions each function is referenced by and the number of times it is referenced.

[0055] For example, function 1 is referenced by the main function R01 times, function 2 is referenced by the main function R02 times, function 3 is referenced by function 1 R13 times and by function 2 R23 times, function 4 is referenced by function 2 R24 times, function 5 is referenced by function 4 R45 times, and function 6 is referenced by function 4 R46 times.

[0056] By referencing the function call relationship and the code sequence within the firmware program, the processor 211 can calculate the total number of references for each function, identify the function call sequence in the function execution path, and identify the high-utility function frequently called by multiple different functions. The reference relationship data provides an important basis for reference weight calculation and function allocation in the resident storage area 310, so that frequently referenced functions can be preferentially loaded into the resident storage area 310, reducing the need for dynamic loading.

[0057] Please refer back to Figure 2 In the operation of step S210, the processor 211 also identifies key system functions such as startup functions, power management functions, error handling functions, and interrupt service functions according to the necessary operation requirements of the storage device 20. These key system functions are classified as first-type functions.

[0058] In addition, in an embodiment, based on the function call relationship and / or the function reference relationship, the processor 211 further calculates the reference weight value of each function, and filters out multiple high-weight functions with high reference frequency as multiple performance optimization functions according to a predetermined reference weight threshold.

[0059] Through the above analysis process, the processor 211 determines multiple first-type functions including necessary functions and performance optimization functions, and multiple second-type functions in the firmware program other than the multiple first-type functions.

[0060] At the same time, the processor 211 constructs a function call tree structure according to the function call relationship, and identifies the remaining functions other than the first-type functions as second-type functions. The processor 211 preliminarily groups the second-type functions based on the functional correlation of the function branches, laying the foundation for subsequent storage allocation. Specifically, the processor 211 traverses each function branch from the main function, identifies function combinations with functional correlation, and ensures that functions belonging to the same functional implementation path can be uniformly managed.

[0061] Next, in step S220, the processor 211 preloads the multiple first-type functions into the resident storage area of the buffer storage 214.

[0062] Figure 3 The structure diagram of the buffer storage and the memory module shown according to the embodiments of the present disclosure.

[0063] Referring to Figure 3 In an embodiment, the buffer storage 214 adopts a hierarchical storage architecture, including a resident storage area 310 and a dynamic storage area 320.

[0064] Specifically, the processor 211 reads the plurality of first type functions determined in step S210 from the memory module 220 and loads them into the resident storage area 310 of the buffer storage 214. As shown in Figure 3 The resident storage area 310 includes a first resident sub-area 311 and a second resident sub-area 312, wherein the first resident sub-area 311 remains powered in the low power consumption mode of the storage device 20 and is not affected by the power mode, and the second resident sub-area 312 is powered off in the low power consumption mode. The processor 211 prioritizes the most critical functions (such as startup functions and interrupt service functions) to the first resident sub-area 311 according to the importance and access frequency of each first type function, and assigns less important first type functions to the second resident sub-area 312 when the available space of the first resident sub-area 311 is exhausted.

[0065] It should be noted that during the loading process, the processor 211 reserves a predetermined proportion (such as 10% or other proportions) of idle space in the resident storage area 310 for subsequent optimization adjustment. Specifically, the aforementioned reserved idle space can be used to prevent the required storage space from becoming larger due to changes in the functions of the current storage area.

[0066] Next, in step S230, the processor 211 divides the plurality of second type functions into a plurality of storage libraries 330(1)-330(N) and stores the plurality of storage libraries 330(1)-330(N) in the storage library area 330 of the memory module 220. The storage library area 330 can be located in the system security storage area of the memory module 220.

[0067] As shown in Figure 3 The memory module 220 includes a storage library area, which includes a plurality of independent storage libraries 330(1)-330(N), respectively identified as storage library 1 330(1), storage library 2 330(2), storage library 3 330(3), and so on to storage library N 330(N). The processor 211 obtains a plurality of function branches based on the function call relationship, traverses each function branch from the main function, and assigns one or more function branches belonging to the same function to the same storage library, ensuring that function-related functions can be stored in the same storage library, reducing cross-storage library function calls.

[0068] When the predetermined capacity of a certain memory repository (e.g., the first memory repository) is not enough to accommodate the entire function branch configured to the memory repository, the processor 211 performs a memory repository overflow process: selecting the terminal function located at the end of the function branch in the memory repository, and re-allocating it to another memory repository (e.g., the second memory repository) with the largest available space. Through this allocation strategy, the processor 211 sequentially divides the plurality of second-type functions into the plurality of memory repositories 330(1)-330(N) and stores them in the memory module 220.

[0069] Figure 7 A schematic diagram of function call relationship and allocation of function branches to memory repositories according to an embodiment of the present disclosure.

[0070] Please refer to Figure 5 , Figure 6 and Figure 7 In an embodiment, the processor 211 constructs a tree structure of function call relationship based on the aforementioned acquired function call relationship and function reference relationship, and divides the plurality of second-type functions into corresponding memory repositories accordingly.

[0071] As shown in Figure 7 In an embodiment, the processor 211 establishes a tree structure with the main function 711 (function 0) as the root function according to the function call data shown in Figure 5 and Figure 6 In this tree structure, the main function 711 serves as the entry point of the firmware program, and calls a plurality of branch main functions downward, including function 1 721 and function 2 722. Function 1 721 further calls function 3 731 downward, forming function 1 branch 701. Function 2 722 calls function 3 731 and function 4 732 downward, among which function 4 732 continues to call function 5 741 and function 6 742, which together constitute function 2 branch 702. In this tree structure, function 3 731, function 5 741 and function 6 742 are identified as terminal functions, i.e., the deepest terminal nodes in the corresponding function branch that do not call other functions.

[0072] In one embodiment, the processor 211 performs repository allocation of function branches based on the tree structure described above. For example, the processor 211 allocates all functions in the function 1 branch 701 (including function 1 721 and function 3 731) as one functional unit to the repository 1 330(1) as a whole via the allocation process shown by the arrow A71. Similarly, the processor 211 allocates all functions in the function 2 branch 702 (including function 2 722, function 3 731, function 4 732, function 5 741 and function 6 742) as another functional unit to the repository 2 330(2) as a whole via the allocation process shown by the arrow A72. It should be noted that one repository can have one or more function branches (functional units).

[0073] It is worth noting that the function 3 731 exists in both the function 1 branch 701 and the function 2 branch 702, which indicates that the function is called by multiple branches. In this embodiment, the processor 211 stores the function 3 731 in the repository 1 330(1) and the repository 2 330(2) respectively, ensuring the functional integrity of each repository. Through this branch-level repository allocation strategy, when the system needs to execute the functions or functions related to the function 1 branch 701, only the repository 1 330(1) needs to be loaded; when the functions or functions related to the function 2 branch 702 need to be executed, only the repository 2 330(2) needs to be loaded, thereby minimizing the frequency of repository switching.

[0074] It is worth noting that when the firmware program is adjusted, debugged or new functions are added, it may cause the repository where these functions originally exist to overflow, or the repository where the new functions are placed to overflow, thereby causing compilation failure.

[0075] In one embodiment, when a repository (such as the repository 2 330(2)) cannot completely accommodate a branch due to repository capacity limitations, the processor 211 preferentially retains the branch main function and intermediate functions in the branch, and reallocates the end functions (such as the function 3 731, the function 5 741 and the function 6 742) to other repositories with the largest available space, ensuring the integrity of the core function path.

[0076] Through the above function branch allocation mechanism based on the tree structure, the present disclosure realizes function-oriented repository organization, enabling associated functions to be centrally managed, reducing repository switching overhead in the dynamic loading process, and improving system execution efficiency.

[0077] Back to Figure 2Then, in step S240, when responding to the target instruction, the processor 211 loads a target repository containing a target second-type function into the dynamic storage area 320 from the memory module 220 to perform a target operation corresponding to the target instruction.

[0078] In particular, in one embodiment, when performing a target operation corresponding to a target instruction, a target second-type function is determined to be required according to the target instruction, and the target second-type function is not present in the dynamic storage area 320 of the buffer memory 214, the processor 211 loads a target repository containing the target second-type function into the dynamic storage area 320 from the memory module 220, and executes the target second-type function. In this way, dynamic loading and execution of functions are achieved.

[0079] In more detail, in one embodiment, upon receiving a target instruction, the processor 211 performs instruction analysis and function requirement identification. Specifically, the processor 211 analyzes the functional requirements of the target instruction, and determines a complete set of functions required for executing the target instruction, which typically includes two sources of functions: first-type functions in the resident storage area 310 and specific target second-type functions. The processor 211 first checks the resident storage area 310 to confirm the availability of first-type functions (such as system call functions, basic management functions, etc.) required for executing the target instruction, and then identifies the location of a target repository containing the required target second-type function through a repository mapping table. When it is confirmed that the target second-type function is not present in the current dynamic storage area 320, the processor 211 initiates a dynamic loading process to load the target repository into the dynamic storage area 320. Through this dual-source function identification and classification loading mechanism, the system ensures that the target instruction can obtain complete function support required for execution.

[0080] In one embodiment, in this step, when the host system 10 sends an instruction requiring a call to a specific second-type function, the processor 211 first checks whether the target second-type function is already present in the dynamic storage area 320 of the buffer memory 214. If the target second-type function is not present in the currently loaded repository, the processor 211 determines a target repository containing the target second-type function through a repository mapping table, and reads the target repository from the memory module 220 through the memory interface control circuit 213. The processor 211 loads the target repository into the dynamic storage area 320.

[0081] In another embodiment, the target second type function refers to one or more of the second type functions required by the target instruction to perform the target operation but not present in the dynamic storage area of the buffer memory. The processor 211 accurately locates the required target second type function according to the functional requirements of the target instruction, and loads the complete storage library where the target second type function is located into the dynamic storage area 320. This achieves flexible configuration of memory resources through a dynamic loading mechanism.

[0082] In an embodiment, if the dynamic storage area 320 is insufficient in space, other storage libraries currently loaded are replaced.

[0083] In an embodiment, after the loading is completed, the processor 211 executes the target second type function and returns the execution result to the host system 10. Through this on-demand loading mechanism, the system can optimize the use efficiency of the buffer memory 214 while ensuring functional integrity. It is worth mentioning that when the host system 10 sends an instruction requiring a call to a first type function, the processor 211 directly acquires and executes the first type function from the resident storage area 310.

[0084] Through the coordinated execution of the above four steps, the memory management method of the present disclosure realizes intelligent function allocation and dynamic loading, which can effectively reduce the number of storage library switching and improve the overall performance of the storage device 20.

[0085] Figure 4 A detailed flowchart of the memory management method according to the embodiment of the present disclosure is shown.

[0086] Reference Figure 4 In another embodiment, the memory management method provided by the present disclosure adopts a detailed execution flow to ensure the optimization of function allocation and the automatic processing of storage library overflow.

[0087] Step S410: The processor 211 acquires firmware program information to analyze function call relationships and necessary operations.

[0088] In an embodiment, the processor 211 reads the code file and related configuration information of the firmware program from the memory module 220. The processor 211 analyzes the function definition, function call instruction and jump relationship of the firmware program through a code parsing algorithm, and establishes a complete function call relationship database. At the same time, the processor 211 identifies the key functions corresponding to the necessary operations such as startup sequence, power management and interrupt processing according to the system configuration of the storage device 20. This step provides basic data support for subsequent function classification and allocation.

[0089] Step S420: The processor 211 determines a plurality of first type functions.

[0090] Based on the analysis result obtained in step S410, the processor 211 performs a determination process of the first type functions. The processor 211 first identifies a plurality of essential functions including a start-up function, a power management function, an error handling function, and an interrupt service function according to the necessary operation requirements of the storage device 20.

[0091] Next, the processor 211 calculates the reference weight values of the functions. Specifically, the processor 211 first determines a set of object functions to be calculated for the weight, which contains only the functions with the reference times greater than 1, and excludes the functions with the reference times of 1 to avoid interference with the weight calculation. For each object function in the set of object functions, the processor 211 calculates its reference weight value according to the reference weight formula Wi = Ci / ∑(Cj), where Wi represents the reference weight value of the i-th object function, Ci represents the reference times of the i-th object function, and ∑(Cj) represents the sum of the reference times of all object functions in the set of object functions.

[0092] Further, the processor 211 filters a plurality of performance optimization functions with the reference weight values greater than a predetermined reference weight threshold value from the calculation result. Through the above analysis, the processor 211 determines a plurality of first type functions containing the essential functions and the performance optimization functions.

[0093] Figure 8 A schematic diagram of the function reference weight calculation and distribution according to the embodiment of the present disclosure.

[0094] Referring to Figure 8 In one specific embodiment, the processor 211 performs quantitative analysis and distribution decision of the reference weight values of the functions by using the weight analysis table T81.

[0095] For example, in the process of determining the first type functions, as shown in Figure 8 The processor 211 can establish a weight analysis table T81 containing three fields of function name, reference times, and reference weight value. In this embodiment, the processor 211 uses a predetermined reference weight threshold value (e.g., 0.15) as the judgment standard to distinguish between high weight functions and low weight functions.

[0096] For example, the processor 211 first counts the reference times of the functions: assuming that function 1 is referenced 15 times, function 2 is referenced 12 times, function 3 is referenced 8 times, function 4 is referenced 5 times, and functions 5 and 6 are each referenced only once. Based on the calculation method of the reference weight formula, the processor 211 determines that the set of object functions contains only functions 1 to 4 with the reference times greater than 1, and functions 5 and 6 are marked as "N / A (not calculated)" because of the reference times of 1, and do not participate in the weight calculation process.

[0097] For each function in the object function set, the processor 211 calculates its reference weight value. Assume that the calculated reference weight value for function 1 is 0.25, for function 2 is 0.20, for function 3 is 0.13, and for function 4 is 0.08.

[0098] Based on the calculation result and a preset reference weight threshold value 0.15, the processor 211 performs a function allocation decision. Since the reference weight values of function 1 (weight value 0.25) and function 2 (weight value 0.20) are both greater than the threshold value 0.15, they are identified as high-weight performance optimization functions, such as Figure 8 As indicated by the arrows, they are allocated to the resident storage area 310. In contrast, the reference weight values of function 3 (weight value 0.13) and function 4 (weight value 0.08) are lower than the threshold value 0.15, together with function 5 and function 6 that do not participate in the weight calculation, are allocated to the corresponding storage libraries based on their branch attribution in the function call relationship.

[0099] Through the weight-driven allocation mechanism, the present disclosure ensures that frequently referenced functions are preferentially loaded into the resident storage area 310, while functions with lower access frequency are dynamically loaded from the storage library on demand, achieving optimal utilization of memory resources.

[0100] Please refer back to Figure 4 Step S430: The processor 211 loads the plurality of first-type functions into the resident storage area 310.

[0101] Specifically, the processor 211 reads the plurality of first-type functions determined in step S420 from the memory module 220 and preloads them into the resident storage area 310 of the buffer storage 214. During the loading process, the processor 211 allocates the most critical necessary functions to the first resident sub-area 311 and the less important performance optimization functions to the second resident sub-area 312 according to the importance and access frequency of the functions. The processor 211 reserves a predetermined proportion of idle space in the resident storage area 310 to reserve resources for subsequent dynamic optimization adjustment.

[0102] Step S440: The processor 211 determines a plurality of second-type functions and allocates the plurality of second-type functions to a plurality of storage libraries.

[0103] Specifically, the processor 211 identifies all remaining functions in the firmware program other than the first-type functions as second-type functions. Based on the function call relationship, the processor 211 combines second-type functions belonging to the same functional branch and allocates them to the corresponding storage library. The processor 211 ensures that each storage library contains a complete set of functions required to implement a specific function according to the branch integrity principle, thereby minimizing the need for cross-storage library function calls.

[0104] Step S450: Processor 211 determines whether there is a first storage library with insufficient space.

[0105] Specifically, in the process of assigning multiple second-type functions to corresponding storage libraries, processor 211 checks the capacity usage of each storage library, and determines whether there is a first storage library with insufficient capacity to accommodate the assigned multiple second-type functions. This determination step is the key decision point of the storage library overflow processing, ensuring that the system can automatically respond to capacity limitation problems. If the determination result is "No", step S460 is executed; if the determination result is "Yes", step S470 is executed.

[0106] Step S460: Processor 211 dynamically loads the corresponding target storage library into dynamic storage area 320 according to the instruction requirements.

[0107] Specifically, when all storage libraries have sufficient capacity (all second-type functions have been successfully assigned to the assigned storage libraries), processor 211 enters normal operation mode. When receiving an instruction from host system 10 that requires calling a specific second-type function, processor 211 determines the target storage library containing the function through the storage library mapping table, and loads it from memory module 220 to dynamic storage area 320 of buffer memory 214. This on-demand loading mechanism ensures the integrity of system functions and optimizes the efficiency of buffer memory 214 usage.

[0108] Step S470: Processor 211 moves at least one end function of the first storage library to a second storage library, wherein the second storage library has available space.

[0109] Specifically, when detecting insufficient storage library capacity, processor 211 executes an automatic overflow processing mechanism. Processor 211 identifies end functions located at the end of function branches in the first storage library with insufficient capacity, and selects these end functions that have the least impact on the overall function (e.g., the deepest) as the objects to be moved. Processor 211 scans the available space of all storage libraries and determines a second storage library with the largest available space as the target location. Then, processor 211 reassigns the selected end functions (also referred to as selected functions) from the first storage library to the second storage library, ensuring that the first storage library can accommodate the core function branches while maintaining the accessibility of all functions. After the move is complete, the system returns to step S450 to recheck the capacity until all storage libraries meet the capacity requirements.

[0110] It is worth mentioning that in one embodiment, processor 211 establishes and maintains a storage library mapping table to record the correspondence between functions and storage libraries, to support efficient dynamic loading operations.

[0111] Specifically, in an embodiment, the storage repository mapping table adopts a hierarchical mapping architecture, including a branch mapping layer and a function mapping layer.

[0112] In the branch mapping layer, the processor 211 takes the branch master function of each function branch as the main mapping object, and records the mapping relationship between each branch master function and its corresponding storage repository. For example, when function 1 721 is taken as the branch master function of function 1 branch 701, the mapping table records the mapping relationship of "function 1 721→storage repository 1 330(1)"; when function 2 722 is taken as the branch master function of function 2 branch 702, the mapping table records the mapping relationship of "function 2 722→storage repository 2 330(2)". Through the branch mapping layer, the processor 211 can quickly locate the corresponding target storage repository based on the branch master function.

[0113] In an embodiment, in the function mapping layer, the processor 211 further records the detailed mapping relationship between all non-branch master functions in each function branch and its branch master function. The function mapping layer contains information such as function identifier, branch identifier to which it belongs, and hierarchical relationship with the branch master function, forming a complete function branch call relationship data structure. Through this mapping layer, any non-branch master function can be traced back to the function branch to which it belongs, and then the corresponding branch master function and target storage repository are determined.

[0114] In the dynamic loading process, when the host system 10 sends an instruction to call a specific second-type function, the processor 211 first queries the storage repository to which the function belongs through the branch mapping layer. If the function is the branch master function of a certain function branch, the processor 211 can directly determine the target storage repository to be loaded through the branch mapping layer. If the function is a non-master function of a certain branch, the processor 211 further confirms the function branch to which the function belongs and its corresponding branch master function through the function mapping layer, and then determines the target storage repository to be loaded through the branch mapping layer. This mapping mechanism can quickly find the key branch master function to determine the corresponding target storage repository, and can also ensure that all related functions in the function branch are loaded as a complete functional unit, avoiding execution errors caused by missing function dependency relationships.

[0115] Through the design of the above-mentioned double-layer mapping architecture, the present disclosure realizes an efficient lookup mechanism from function to storage repository, provides specific implementation support for on-demand dynamic loading, and ensures the quick positioning and correct execution of all second-type functions under the premise of minimizing the storage repository switching overhead.

[0116] In an embodiment, the processor 211 implements a dynamic resident area optimization mechanism, realizes adaptive memory management based on actual usage patterns through periodic performance analysis and function redistribution strategies.

[0117] Specifically, the processor 211 establishes a function access statistics mechanism, which continuously records the calling frequency and access timestamps of each function during the normal operation of the storage device 20. The processor 211 sets a predetermined statistics period (e.g., every 24 hours or every 10000 function calls), and at the end of each statistics period, the processor 211 analyzes the collected access data and calculates the actual usage frequency of each function in the period.

[0118] Based on the statistics analysis result, the processor 211 performs a candidate performance optimization function identification process. The processor 211 scans all functions currently classified as the second type of function, identifies specific functions whose access frequency exceeds a predetermined dynamic threshold, and marks these functions as new candidate performance optimization functions. The dynamic threshold can be adaptively adjusted according to the overall access pattern of the system, ensuring that functions with high access value are truly identified.

[0119] When a new candidate performance optimization function is identified, the processor 211 evaluates the available capacity of the resident storage area 310. If the resident storage area 310 has sufficient idle space, the processor 211 directly migrates the candidate performance optimization function from its current storage repository to the resident storage area 310, completing the dynamic optimization process.

[0120] If the available space of the resident storage area 310 is insufficient to accommodate the new candidate performance optimization function, the processor 211 performs a re-evaluation process of existing performance optimization functions. The processor 211 analyzes the actual access frequency of all performance optimization functions in the current resident storage area 310, and identifies infrequently used performance optimization functions whose access frequency is much lower than the new candidate performance optimization function. Specifically, the processor 211 calculates the access frequency difference between each existing performance optimization function and the candidate performance optimization function, and when the difference exceeds a predetermined replacement threshold, the corresponding existing performance optimization function is marked as a candidate migration function.

[0121] Then, the processor 211 performs a function migration operation. The processor 211 removes the identified infrequently used performance optimization function from the resident storage area 310, and reassigns it to the corresponding function branch in the appropriate storage repository according to the calling relationship of the infrequently used performance optimization function. During the assignment process, the processor 211 preferentially selects a storage repository that contains other functions having a calling relationship with the function, ensuring the logical integrity of the function branch. After the migration is complete, the processor 211 loads the new candidate performance optimization function into the released space of the resident storage area 310.

[0122] In another embodiment, the processor 211 also implements an access pattern learning mechanism to predict future access trends by analyzing the function access patterns of different time periods. Based on the prediction results, the processor 211 can actively adjust the function configuration of the resident storage area 310, preloading relevant high-frequency functions into the resident storage area 310 before the access peak period arrives, further improving the system response performance. That is, according to the different time periods of the system, the commonly used performance optimization functions in that time period are adaptively loaded into the resident storage area 310.

[0123] Through the above dynamic resident area optimization mechanism, the present disclosure realizes the continuous adaptive adjustment of the memory management strategy. This mechanism can dynamically optimize the function storage efficiency and access efficiency of the resident storage area 310 according to the actual usage of the storage device 20, ensuring that the most commonly used functions always remain in the high-speed access resident area, and the functions with declining access frequency are intelligently migrated to the on-demand loading repository, thereby realizing the optimal utilization of memory resources and continuous improvement of system performance.

[0124] In addition, the dynamic optimization mechanism also has self-correction ability. When the subsequent access frequency of a function migrated to the repository increases again, the system can re-identify the function as a candidate performance optimization function in the next statistical period and reload it into the resident storage area 310, ensuring that the storage management strategy always matches the actual usage pattern best.

[0125] Through the above process, the memory management method of the present disclosure can analyze function call relationships, determine first-type functions according to reference times and necessary operations, allocate remaining functions to repositories according to branches, handle repository overflow, and dynamically load repositories as needed, thereby improving the efficiency of the executing program of the storage device.

[0126] Figure 9 A schematic diagram of moving high-usage functions to a resident storage area according to an embodiment of the present disclosure.

[0127] Referring to Figure 9 In one specific embodiment, the processor 211 implements a high-usage function identification mechanism to identify and optimize functions commonly referenced by multiple repositories by analyzing the cross-repository call patterns of the functions.

[0128] In detail, the processor 211 first preliminarily groups multiple remaining functions in the firmware program, except for multiple necessary functions, into multiple initial repositories based on their function call relationships. In this preliminary grouping process, the processor 211 performs allocation according to the integrity principle of functional branches, ensuring that each initial repository contains a complete set of functions required to implement a specific function.

[0129] As Figure 9As shown, after the initial grouping, function 3 731 is assigned to both initial repository 1 330(1) and repository 2 330(2). Specifically, function 3 731 is assigned to repository 1 330(1) as part of function 1 branch 701, and is assigned to repository 2 330(2) as part of function 2 branch 702. This duplication ensures the integrity of the function execution, but results in redundant use of storage space.

[0130] Next, processor 211 performs a generality weight statistics process. Processor 211 iterates through all remaining functions, and counts the total number M of different initial repositories 330 that call each function. In combination with the total number N of initial repositories 330, processor 211 calculates a generality weight value for each function according to the ratio M / N. In this embodiment, assume that the system contains 2 initial repositories 330, and that function 3 731 is called by both repository 1 330(1) and repository 2 330(2) (M = 2), its generality weight value is 2 / 2 = 1.0, while other functions (e.g., function 1 721, function 2 722, function 4 732, function 5 741, function 6 742) are called by a single repository (M = 1), their generality weight values are 1 / 2 = 0.5.

[0131] In one embodiment, based on the statistics, processor 211 sets a predetermined generality weight threshold (e.g., the threshold is set to 0.8), and determines the functions whose generality weight values are greater than the threshold as the performance optimization functions. In this embodiment, the generality weight value of function 3 731 is 1.0, which exceeds the predetermined threshold 0.8, and thus function 3 731 is identified as a high generality function. This ratio calculation method can more accurately reflect the importance of a function in the entire repository system, and can maintain the consistency and comparability of the generality evaluation when the number of repositories changes.

[0132] In one embodiment, after identifying the high generality function, processor 211 performs a function optimization migration process. As shown by arrow A91, processor 211 migrates the identified high generality function (e.g., function 3 731) from its original location to the resident storage area 310. This migration process enables centralized management of function access, so that functions that are commonly needed by multiple repositories can be continuously available in the resident storage area 310, avoiding the waste of space caused by repeated loading. Figure 9

[0133] In one embodiment, processor 211 also removes the high generality function from multiple initial repositories 330 at the same time. As shown by arrow A92, processor 211 removes function 3 731 from repository 1 330(1) and repository 2 330(2). This removal process ensures that the high generality function is only stored in the resident storage area 310, and is not stored in the initial repositories 330, thereby avoiding the redundant use of storage space. Figure 9 ​As shown, function 3 731 is removed (marked with "X" to indicate removal) from storage library 1 330(1) and storage library 2 330(2) after the migration to the resident storage area 310 is completed. Through this removal operation, the processor 211 obtains the optimized final storage library, eliminating the space waste caused by the repeated storage of high-generic functions.

[0134] Through the above-mentioned identification and migration mechanism of high-generic functions, the present disclosure realizes the following technical advantages:

[0135] The functions called by multiple storage libraries are removed from each storage library and placed in the resident storage area, saving the space of repeated storage. For example, after function 3 is removed from storage library 1 and storage library 2, the corresponding storage space is released.

[0136] When the storage library is loaded into the dynamic storage area, its call to the high-generic function is directly met through the resident storage area without the need for additional storage library switching.

[0137] At runtime, when storage library 1 330(1) or storage library 2 330(2) is loaded into the dynamic storage area 320, its call to function 3 731 will be directly met through the resident storage area 310 without the need for additional storage library switching operations, thereby realizing the overall optimization of memory management.

[0138] Figure 10 The timing diagram for dynamically loading the target storage library according to the instructions according to the embodiment of the present disclosure is shown.

[0139] Referring to Figure 10 In one specific embodiment, the present disclosure shows the complete timing process of dynamically loading the target storage library 330 according to instructions, which involves coordinated interaction between the host system 10, the processor 211, the buffer storage 214, and the memory module 220.

[0140] [Initial system state]

[0141] S1010: In the normal running state of the system, the resident storage area 310 of the buffer storage 214 has loaded a plurality of first type functions, and the dynamic storage area 320 currently loads storage library 1 (assuming that storage library 1 has been loaded at present)

[0142] [Instruction receiving and analysis phase]

[0143] S1020: The host system 10 sends an instruction to the processor 211, which requires calling a specific target second type function. The instruction can come from the functional request of a user application program, system maintenance operation, or background task execution requirement.

[0144] S1030: After receiving the instruction, the processor 211 immediately executes the instruction resolution process. The processor 211 analyzes the instruction content and identifies the function identifier of the target second-type function to be invoked and other key information.

[0145] [Function positioning and repository identification]

[0146] S1040: The processor 211 checks the location status of the target second-type function in the buffer memory 214 through the repository mapping table. The processor 211 first queries the resident storage area 310 (e.g., using the resident storage area mapping table) to confirm whether the target function is a first-type function; if not, it further queries the currently loaded repositories in the dynamic storage area 320.

[0147] S1050: The buffer memory 214 returns the query result to the processor 211, confirming that the target second-type function does not exist in the current buffer memory 214. For example, the target function belongs to the function branch allocated to repository 3 (repository 3 becomes the target repository), and the current dynamic storage area 320 only loads repository 1, so the repository switching operation needs to be performed.

[0148] [Repository switching decision and execution]

[0149] S1060: Based on the function positioning result, the processor 211 determines that repository switching is needed. The processor 211 evaluates the capacity status of the current dynamic storage area 320 and confirms that repository 3 needs to be loaded to replace the current repository 1 to meet the execution requirements of the target function.

[0150] S1070: The processor 211 sends a load request to the memory module 220 through the memory interface control circuit 213, specifying the target repository (repository 3) that needs to be loaded. The request may, for example, include the repository identifier and the expected load location.

[0151] S1080: After receiving the load request, the memory module 220 performs the repository positioning process. The memory module 220 locates the specific location of repository 3 in the physical storage space through an internal address mapping mechanism (e.g., through the repository physical address list) and prepares data transmission operations.

[0152] S1090: After completing the positioning and data preparation of repository 3, the memory module 220 returns a data ready confirmation signal to the processor 211. This signal indicates that the data of repository 3 has been prepared and can be transmitted to the buffer memory 214.

[0153] [Repository loading and updating]

[0154] S1100: The processor 211 controls the loading of the storage 3 from the memory module 220 to the dynamic storage area 320 of the buffer memory 214. During the loading process, the storage 3 replaces the original storage 1, realizing the updating of the content of the dynamic storage area 320.

[0155] S1110: After the buffer memory 214 completes the storage loading operation, the content updating of the dynamic storage area 320 is completed, the storage 3 is successfully loaded and in an accessible state. This state change makes all the second-type functions in the storage 3 directly callable and executable by the processor 211.

[0156] S1120: The buffer memory 214 sends a loading completion confirmation signal to the processor 211, indicating that the storage switching operation has been successfully completed, and the target second-type function is now available for execution.

[0157] [Function execution and result return]

[0158] S1130: The processor 211 accesses and executes the target second-type function from the dynamic storage area 320. Since the target function is now located in the cache memory 214, the execution process has the optimal access speed and response performance.

[0159] S1140: After the processor 211 completes the execution of the target second-type function, the execution result is returned to the host system 10. This result return completes the entire dynamic loading and function execution cycle.

[0160] Through the above dynamic loading timing process, the present disclosure realizes the following technical advantages:

[0161] Only when the target function to be executed is not in the current cache memory, the storage switching is performed. The storage mapping table is used to determine the storage where the target function is located, and the storage is loaded into the dynamic storage area. The functions in the resident storage area do not need to be loaded and can be directly executed.

[0162] It is worth mentioning that in an embodiment, the memory controller 210 further includes a management firmware program, which is pre-loaded in a reserved management area (not shown) of the buffer memory 214. The reserved management area is independent of the resident storage area 310 and the dynamic storage area 320, has the highest access priority, and is kept in a powered state in any power mode. In addition, the management firmware program is also stored in the system security storage area of the memory module, which cannot be accessed by the host system 10 and is only used by the memory controller 210.

[0163] The management firmware program is configured to be executed automatically when the storage device 20 is powered on, to analyze the call relationship of the functions of the firmware program, to calculate the reference weight value of each function according to a predetermined algorithm, to assign the first type of functions to the resident storage area 310, to assign the second type of functions to the plurality of storage libraries 330, to monitor the runtime storage library switching frequency, and to re-optimize the function assignment strategy when performance degradation is detected.

[0164] In another embodiment, the execution of the management firmware program includes the following occasions:

[0165] System startup execution: when the storage device 20 is powered on for the first time, the management firmware program is executed immediately after hardware initialization is completed, to perform initial analysis and function assignment on the firmware program.

[0166] Firmware update execution: when the firmware program is updated, debugged, or new functions are added, the management firmware program automatically detects firmware changes, reanalyzes the function call relationship, and updates the function assignment strategy.

[0167] In another embodiment, the buffer memory 214 further includes a reserved management area, for example, to store the management firmware program, which has the highest access priority and uses a dedicated storage space that is not affected by the capacity limitations of the resident storage area and the dynamic storage area. The reserved management area is powered in all power modes to ensure the continuous availability of the management firmware program.

[0168] In an embodiment, the management firmware program is integrated into the card opening program of the memory controller 210. The card opening program is stored in the dedicated read-only memory (ROM) or boot area of the processor 211 and is executed automatically when the storage device 20 is powered on.

[0169] In an embodiment, the card opening program may include the following modules, for example:

[0170] A hardware initialization module for configuring the basic parameters of the memory interface control circuit 213, the data management circuit 212, and the buffer memory 214;

[0171] A system configuration module for establishing a communication interface with the host system 10;

[0172] A memory management module containing the management firmware program for analyzing the function call relationship of the firmware program and performing storage library assignment.

[0173] By integrating the management firmware program into the card opening program, the memory management method is automatically executed every time the storage device 20 is powered on, without the need for an additional loading mechanism.

[0174] In an embodiment, the execution sequence of the card opening program includes:

[0175] Step 1: the storage device 20 is powered on, and the processor 211 loads the card opening program from the ROM or the boot area;

[0176] Step 2: the hardware initialization module is executed to configure the memory module 220 and the buffer memory 214;

[0177] Step 3: the system configuration module is executed to establish the data transmission interface with the host system 10;

[0178] Step 4: the memory management module is executed to start the management firmware program;

[0179] Step 5: the management firmware program analyzes the firmware program information to determine the first type of functions and the second type of functions;

[0180] Step 6: the first type of functions are preloaded into the resident storage area 310;

[0181] Step 7: the second type of functions are divided into the plurality of storage repositories 330 and stored in the memory module 220;

[0182] Step 8: the card opening program is executed, and the storage device 20 enters the normal operation state.

[0183] In another embodiment, the management firmware program adopts a phased execution mechanism:

[0184] Initialization phase: as a component of the card opening program, the function analysis and initial allocation are executed at system startup;

[0185] Runtime phase: the runtime monitoring and dynamic adjustment functions are resident in the reserved management area of the buffer memory 214, continuously monitoring the system performance;

[0186] Update phase: when a firmware program change is detected, the memory management module in the card opening program is reactivated to perform reanalysis and allocation. This phased execution mechanism takes advantage of the booting capability of the card opening program and ensures the continuous effectiveness of the management functions.

[0187] The embodiment also provides a computer program product, including computer readable code or a non-volatile computer readable storage medium carrying the computer readable code, when the computer readable code is executed in a processor, the processor executes the steps of the above memory management method. The computer program product can be specifically implemented by hardware, firmware, software or a combination thereof. In an optional embodiment, the computer program product is specifically embodied as a computer storage medium, and in another optional embodiment, the computer program product is specifically embodied as a software product, such as a software development kit (Software Development Kit, SDK) and the like.

[0188] To sum up, the memory management method and the memory controller provided by the present disclosure realize automatic classification of functions and allocation of storage libraries by analyzing the function call relationship of the firmware program.

[0189] The present disclosure establishes three mutually coordinated technical mechanisms. First, the function classification mechanism identifies essential functions (including startup functions, power management functions, error handling functions, and interrupt service functions) and performance optimization functions by analyzing the function call relationship and the necessary operations of the system, forming a first type function set. Second, the weight calculation mechanism calculates the weight value of each function using the reference weight formula and determines the general-purpose weight by counting the number of times the function is called by different storage libraries, providing a quantitative basis for function allocation. Third, the dynamic storage management mechanism divides the buffer memory into a resident storage area and a dynamic storage area, where the resident storage area includes a first resident sub-area that remains powered in low-power mode and a second resident sub-area that stops power supply, and the dynamic storage area loads target storage libraries according to instruction requirements.

[0190] In terms of storage library management, the present disclosure adopts an allocation strategy based on function branches. The system allocates functions belonging to the same function branch to the same storage library, reducing cross-storage library function calls. When the storage library capacity is insufficient, the system reassigns the end functions to other storage libraries with the largest available space. For high-general-purpose functions that are called by multiple storage libraries, the system migrates them to the resident storage area to avoid repeated storage.

[0191] Through the above technical solutions, the present disclosure can reduce the number of storage library switches, improve storage space utilization, and ensure the immediate availability of critical functions through the preload mechanism. The system supports adjusting the function allocation strategy according to the actual access mode, adapting to different use scenarios and hardware configurations.

[0192] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for part or all of the technical features; and these modifications or substitutions do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A memory management method applied to a storage device configured with a memory module and a buffer memory, characterized in that, The method comprises: determining a plurality of first type functions and a plurality of second type functions according to function call relations of a firmware program and / or necessary operations of the storage device; preloading the plurality of first type functions into a resident storage area of the buffer storage; dividing the plurality of second type functions into a plurality of storage libraries and storing the plurality of storage libraries into the memory module; in response to a target instruction, loading a target storage library containing a target second type function from the memory module into a dynamic storage area to perform a target operation corresponding to the target instruction.

2. The memory management method of claim 1, wherein, The step of determining the plurality of first type functions comprises: determining a plurality of necessary functions as part of the first type functions according to the necessary operations; and determining a plurality of performance optimization functions as another part of the first type functions according to the function call relations.

3. The memory management method of claim 2, wherein, The step of determining the plurality of performance optimization functions comprises: calculating a reference weight value of each function of the firmware program according to a number of references of the function; and determining the plurality of performance optimization functions from the plurality of functions of the firmware program as a plurality of high weight functions whose reference weight values are greater than a predetermined reference weight threshold.

4. The memory management method of claim 2, wherein, The step of determining the plurality of performance optimization functions comprises: preliminarily grouping a plurality of remaining functions of the firmware program other than the plurality of necessary functions into a plurality of initial storage libraries; counting a total number of different initial storage libraries calling each function to determine a generality weight of the function; and determining a plurality of performance optimization functions from the plurality of remaining functions as a plurality of high generality functions whose generality weight values are greater than a predetermined generality weight threshold.

5. The memory management method of claim 4, wherein, The method further comprises: removing the plurality of high generality functions from the plurality of initial storage libraries to obtain the plurality of storage libraries.

6. The memory management method of claim 1, wherein: the resident storage area comprises a first resident sub-area and a second resident sub-area, the first resident sub-area is kept powered in a low power consumption mode of the storage device, and the second resident sub-area is powered off in the low power consumption mode, the first type functions related to operation of the low power consumption mode are configured in the first resident sub-area.

7. The memory management method of claim 1, wherein, The method further comprises: when a total size of at least one second type function allocated to a first storage library is greater than a predetermined capacity of the first storage library, removing a selected function from the first storage library, wherein the selected function is a terminal function not calling other functions in at least one function branch corresponding to the first storage library; and re-allocating the selected function to a second storage library having a largest available space.

8. The memory management method of claim 1, wherein, The step of preloading the first type functions into the resident storage area comprises: reserving a predetermined proportion of idle space in the resident storage area.

9. The memory management method of claim 3, wherein, The step of calculating the reference weight value of the function comprises: determining a set of object functions to be calculated for weight, wherein the set of object functions only contains functions whose number of references is greater than 1. According to reference information of the object functions, a reference weight value of each of the object functions is calculated, wherein the reference information comprises a reference frequency of each of the object functions and the reference frequency of the object functions in the object function set.

10. The memory management method of claim 1, wherein, The method further comprises: In a running state of the storage device, periodically counting actual calling frequencies of the plurality of functions; and According to the actual calling frequencies, dynamically adjusting the first type functions configured in the resident storage area.

11. A memory controller for controlling a memory device configured with a memory module, the memory controller comprising: The memory controller comprises: a memory interface control circuit electrically connected to the memory module; a buffer memory for buffering data; and a processor electrically connected to the memory interface control circuit and the buffer memory, wherein the processor is further electrically connected to a connection interface circuit of the storage device to be electrically connected to a host system, wherein the processor is configured to: determine a plurality of first type functions and a plurality of second type functions according to function calling relationships of a firmware program and / or necessary operations of the storage device; pre-load the plurality of first type functions into a resident storage area of the buffer memory; divide the plurality of second type functions into a plurality of storage libraries and store the plurality of storage libraries into the memory module; in response to a target instruction, load a target storage library containing a target second type function from the memory module into a dynamic storage area to perform a target operation corresponding to the target instruction.

12. The memory controller of claim 11, wherein, The step of determining the plurality of first type functions comprises: determine a plurality of necessary functions as a part of the first type functions according to the necessary operations; and determine a plurality of performance optimization functions as another part of the first type functions according to the function calling relationships.

13. The memory controller of claim 12, wherein, The step of determining the plurality of performance optimization functions comprises: calculate a reference weight value of each function of the firmware program according to a reference frequency of the function; and determine the plurality of performance optimization functions as a plurality of high weight functions from the plurality of functions of the firmware program whose reference weight values are greater than a predetermined reference weight threshold value.

14. The memory controller of claim 12, wherein, The step of determining the plurality of performance optimization functions comprises: preliminarily group a plurality of remaining functions of the firmware program other than the plurality of necessary functions into a plurality of initial storage libraries; count a total number of different initial storage libraries calling each function to determine a generality weight of the function; and determine the plurality of performance optimization functions as a plurality of high generality functions from the plurality of remaining functions whose generality weight values are greater than a predetermined generality weight threshold value.

15. The memory controller of claim 14, wherein, The processor is further configured to: remove the plurality of high generality functions from the plurality of initial storage libraries to obtain the plurality of storage libraries.

16. The memory controller of claim 11, wherein the resident storage area comprises a first resident sub-area and a second resident sub-area, the first resident sub-area is kept powered in a low power consumption mode of the storage device, and the second resident sub-area is stopped powered in the low power consumption mode, wherein the first type functions related to the operation of the low power mode are configured in the first resident sub-area.

17. The memory controller of claim 11, wherein, wherein the processor is further configured to: remove a selected function from the first storage library when the total size of at least one second type function allocated to the first storage library is greater than a predetermined capacity of the first storage library, wherein the selected function is a terminal function that does not call other functions in at least one function branch corresponding to the first storage library; and and reallocate the selected function to a second storage library having the largest available space.

18. The memory controller of claim 11, wherein, wherein the step of preloading the first type functions into the resident storage area comprises: reserving a predetermined proportion of idle space in the resident storage area.

19. The memory controller of claim 13, wherein, wherein the step of calculating the reference weight values of the functions comprises: determining a set of object functions to be calculated for weight, wherein the set of object functions only contains functions that are referenced more than once; calculating a reference weight value of each object function according to reference information of the object function, wherein the reference information includes the number of times each object function is referenced and the number of times the object function in the set of object functions is referenced.

20. The memory controller of claim 11, wherein, wherein the processor is further configured to: periodically count actual call frequencies of the functions in a running state of the storage device; and dynamically adjust the first type functions configured in the resident storage area according to the actual call frequencies.

Images