Multi-core deployment method of NvM and multi-core device

Abstract

The embodiment of the invention discloses an NvM multi-core deployment method and a multi-core device. The complexity of NvM multi-core deployment can be simplified. The method comprises the following steps: deploying an NvM module in a main core, and setting the NvM module as a global module so that all cores can call an application programming interface (API) of the NvM module; setting a request queue corresponding to each slave core in the NvM module, wherein the slave core writes a first NvM request of the slave core into the request queue by calling an API (Application Program Interface) of the NvM module; and calling a main function of the NvM module in the main core to transfer the first NvM request in the request queue to an NvM standard queue or an NvM immediate queue, and executing the NvM request in the NvM standard queue or the NvM immediate queue.

Description

Technical Field

[0001] The present invention relates to storage technology, and in particular to a multi-core deployment method and a multi-core device of NvM (Nonvolatile RAM Manager, non-volatile storage management). Background Art

[0002] In AUTOSAR (AUTomotive Open System Architecture), NvM (Non-volatile Memory Management) is responsible for managing and maintaining non-volatile data, ensuring that these data can be correctly synchronized to the RAM (Random Access Memory) area during the system startup and shutdown phases, and that the data will not be lost after the system is powered off, and the data can still be read through the interface after powering on again. The implementation of NvM functions requires the deployment of the NvM stack, because the implementation of the NvM stack depends on the underlying memory communication bus. In AUTOSAR, multiple cores cannot drive the communication bus at the same time. Therefore, in a multi-core architecture, the NvM stack is deployed in one core. However, other cores also have read and write requirements for the NvM block, so multi-core deployment of NvM is required. However, the current NvM multi-core deployment solution has the problem of complex implementation. Summary of the invention

[0003] In view of this, an embodiment of the present invention provides a multi-core deployment method and a multi-core device of NvM, which can simplify the complexity of NvM multi-core deployment.

[0004] Specifically, an embodiment of the present invention provides a multi-core deployment method for a non-volatile storage manager NvM, including: deploying an NvM module in a master core and setting it to be callable by a slave core; setting request queues corresponding to each slave core in the NvM module, respectively, for storing a first NvM request written by the slave core by calling the NvM module; executing the NvM module in the master core to transfer the first NvM request in the request queue to an NvM standard queue or an NvM immediate queue, and performing corresponding operations according to the NvM requests in the NvM standard queue or the NvM immediate queue.

[0005] In some implementations, the second NvM request of the master core is directly written into the NvM standard queue or the NvM immediate queue.

[0006] In some implementations, the NvM request includes: a request to read, write, and erase an NvM block, but does not include: a request to obtain and set a state of an NvM block.

[0007] In some implementations, the request queue is a circular queue, and first and second global variables are set to manage the first NvM request entering and exiting the request queue, the first global variable represents a count value of an entry operation, and the second global variable represents a count value of an exit operation.

[0008] In some implementations, when the first NvM request in the request queue is transferred to the NvM standard queue or the NvM immediate queue, the main core is prohibited from writing the second NvM request into the NvM standard queue or the NvM immediate queue.

[0009] In some implementations, the NvM request includes: an NvM block identity, used to determine whether to write the NvM request into the NvM standard queue or the NvM immediate queue; and an operation indication, used to indicate whether to perform a read, write or erase operation on the NvM block.

[0010] In some implementations, the NvM request further includes: a time when the request is issued, which is used to determine the transfer order of the first NvM request according to the time when the request is issued when the first NvM request is transferred.

[0011] In some implementations, an array for storing the status of each NvM block is defined in the NvM module, and a software component in each core obtains and sets the status of the NvM block by calling an API of the NvM module.

[0012] In addition, an embodiment of the present invention provides a multi-core device compliant with the AUTOSAR architecture, including a first core and at least one second core, wherein an NvM module is set in the basic software layer of the multi-core device, and the NvM module is a global module so that all cores can call the application programming interface API of the NvM module; wherein the NvM module includes: a queue to be processed; at least one request queue, each corresponding to at least one second core, for storing a first NvM request written by a second software component of an application layer in the second core; an queuing unit, for periodically transferring the first NvM request in the at least one request queue to the queue to be processed; and a queue processing unit, for executing the NvM request in the queue to be processed.

[0013] In some implementations, the pending queue includes: an NvM standard queue and an NvM immediate queue, and the first and second NvM requests are used to request to perform a read, write or erase operation on an NvM block.

[0014] In some embodiments, the pending queue, the queue entry unit, and the queue processing unit are deployed in the first core, and the first core directly writes its second NvM request into the pending queue; in the first core, the queue entry unit is called to transfer the second NvM request to the pending queue, and the queue processing unit and the underlying non-volatile storage driver are called to execute the NvM requests in the pending queue.

[0015] In addition, an embodiment of the present invention provides a computer device / equipment / system, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described in the embodiment of the present invention.

[0016] In addition, an embodiment of the present invention provides a computer-readable storage medium having a computer program / instruction stored thereon, wherein the computer program / instruction, when executed by a processor, implements the method described in the embodiment of the present invention.

[0017] In addition, an embodiment of the present invention provides a computer program product, including a computer program / instruction, which implements the method of the embodiment of the present invention when executed by a processor.

[0018] Beneficial effects of the embodiments of the present invention:

[0019] The NvM module is deployed in the master core, but is set to be called by the slave core, and the request queue corresponding to the slave core is set, so that the slave core can write its NvM request into the request queue by calling the NvM module. Then, the NvM request in the request queue is transferred to the NvM standard queue or the NvM immediate queue to process the NvM request of the slave core. In this way, only a simple modification to the NvM module (setting it to be called by the slave core, adding the request queue and transferring the content related to the NvM request) is required to realize the multi-core deployment of NvM, thereby simplifying the complexity of NvM multi-core deployment and making it easy to implement. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Other details and advantages of the present invention will become apparent from the detailed description provided below. It should be understood that the following drawings are merely illustrative and thus cannot be considered as limiting the present invention, and the following will be described in detail with reference to the drawings, wherein:

[0021] Figure 1 is a schematic structural diagram of an embodiment of a multi-core device of the present invention;

[0022] Figure 2 is a schematic structural diagram of another embodiment of a multi-core device of the present invention;

[0023] Figure 3It is a schematic diagram of the structure of an embodiment of a request queue of the present invention;

[0024] Figure 4 It is a flow chart of an embodiment of the NvM multi-core deployment method of the present invention;

[0025] Figure 5 is a schematic diagram of a flow chart of an embodiment of the present invention of writing an NvM request into a queue;

[0026] Figure 6 is a flow chart of an embodiment of a write request queue of the present invention;

[0027] Figure 7 is a flow chart of an embodiment of periodically processing requests in a queue according to the present invention;

[0028] Figure 8 is a flow chart of an embodiment of releasing a request queue of the present invention; and

[0029] Fig. 9 It is a schematic diagram of the structure of an embodiment of a computer device / equipment / system of the present invention. DETAILED DESCRIPTION

[0030] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0031] In the description of the present invention, it is to be understood that the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. Moreover, the terms "first", "second", etc. are applicable to distinguishing similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein.

[0032] like Figure 1 , which is a schematic diagram of the structure of an embodiment of a multi-core device 10. In this embodiment, the multi-core device 10 implements multi-core deployment of NvM (non-volatile memory management) based on an agent. Figure 1 Taking the three cores shown in the figure as an example, core 1 is the main core where the NvM stack is deployed, that is, the core where the NvM module is located. Figure 1In the example, the NvM module is not a global module and can only be called by core 1 but not directly by other cores. Cores 2 and 3 are slave cores without NvM stack deployed. Core 1 can directly implement NvM function because it has NvM stack deployed, while cores 2 and 3 need core 1 to implement NvM function.

[0033] Specifically, in core 1, SWC (Software Component) 0 can directly call NvM module 11 to implement operations such as reading and writing NvM blocks. Among them, NvM block refers to a storage unit managed in NvM. In cores 2 and 3, when SWC1 to 4 have NvM requests, they first call the API interface in the local NvM agent 13 or 14 (such as read, write, erase, get status, set status, etc. interfaces), and these API interfaces call the corresponding functions in CDD (Complex Driver) _NvM agent 123 through RTE (Runtime Environment), which will store the request information in the queue unique to each slave core. An NvM agent main function 10 capable of calling the CDD_NvM agent 123 is set in the RTE of the master core. The NvM agent main function 10 calls the corresponding functions (read function, write function, status acquisition function, etc.) in the NvM module 11 according to the information in the queue unique to each slave core, thereby completing the NvM request of each slave core.

[0034] In other words, the NvM requests of cores 2 and 3 will be passed to the NvM agent main function 10 via the NvM agent 13 or 24 and the CDD_NvM agent 123 in turn, and then the NvM agent main function 10 will call the NvM module 11 on its behalf, thereby implementing NvM operations such as reading, writing, and obtaining the status of the NvM block by cores 2 and 3.

[0035] exist Figure 1 In the proxy solution, it is necessary to set NvM agent 13 or 24 in the application layer of each core, set CDD_NvM agent 123 in the BSW (Basic Software) layer, and set NVM agent main function 10 in the RTE layer. Therefore, Figure 1 The NvM multi-core deployment solution requires deploying a large amount of code in different locations, which is complex to implement. Figure 1 The scheme not only proxies the read, write and erase operations of the NvM block, but also proxies the get and set operations of the status of the NvM block. Therefore, the proxy content is large, which further increases the complexity of the implementation.

[0036] On this basis, an embodiment of the present invention provides a multi-core deployment solution for NvM. This solution does not adopt a proxy approach, but improves the NvM module itself, adds a request queue corresponding to the slave core to temporarily store the NvM requests from the slave core, and transfers the NvM requests in the request queue to the NvM standard queue or the NvM immediate queue to achieve the purpose of processing the NvM requests of the slave core. In this way, fine-tuning the NvM internally can be achieved by deploying a small amount of code, so the complexity of NvM multi-core deployment can be simplified. In addition, the request queue of an embodiment of the present invention can only be for reading, writing and erasing in the NvM function to further simplify the complexity. For obtaining and setting the status of the NvM block, it can be achieved by setting a global NvM array.

[0037] The solutions of the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0038] like Figure 2 , which is a schematic structural diagram of an embodiment of a multi-core device 20 of the present invention.

[0039] The multi-core device 20 may be, for example, a high performance computer (HPC), a zone controller (ZCU), a central gateway, a domain controller (DCU), an electronic control unit (ECU), or other equipment in a vehicle. The multi-core device 20 includes a plurality of cores. Figure 2 Only three are shown, namely cores 1 to 3, but this is only an example and not a limitation. In addition, a core may also refer to a partition. In some implementations, a core may be divided into multiple partitions to achieve a multi-core-like usage mode. Therefore, the core in this embodiment should include the meaning of a partition.

[0040] The multi-core device 20 complies with the AUTOSAR architecture, and may include, for example, an application layer, an RTE layer, and a BSW layer. The NvM module of this embodiment is located in the BSW layer. Figure 2 As shown, the solution of this embodiment does not require any special settings for the application layer and the RTE layer, such as no need to set up a proxy module. It achieves the purpose of simplifying the multi-core deployment solution of NvM by improving the NvM module 10 itself.

[0041] Among them, core 1 is the core where the NvM module 10 is mainly deployed. Core 1 can call the NvM main function (MainFunction) and call the driver of the underlying non-volatile storage (such as Flash, EEPROM), so it can be called the main core. Cores 2 and 3 are cores that need to store local requests in the request queue to wait for core 1 to process, which can be called slave cores or satellite cores. As shown in the figure, the NvM module 10 is mainly deployed in core 1, for example, its queue entry unit 101, queue processing unit 102 and queue to be processed 103 are all deployed therein, but it is a global module and can be called by cores 2 and 3.

[0042] like Figure 2 As shown, in the NvM module 10, in addition to the original NvM standard queue (NvM Standard Queue) and NvM immediate queue (NvM Immediately Queue), a request queue is also set for each slave core, such as request queues 1 and 2 corresponding to cores 2 and 3 respectively. The request queues are used to store the NvM requests of the corresponding slave cores, for example, when SWC1 or 2 on core 2 or 3 calls a function to write an NvM block, the corresponding NvM request can be written into request queue 1 or 2.

[0043] Based on the request queues 1 and 2, an entry queue unit 101 is further provided in the NvM module 10, which is used to transfer the NvM requests in the request queues 1 and 2 to the NvM standard queue or the NvM immediate queue. For example, the entry queue unit 101 can periodically traverse the request queues 1 and 2, and then transfer the NvM requests in the request queues 1 and 2 to the NvM standard queue or the NvM immediate queue. Among them, the entry queue unit 101 can decide whether to put the NvM request into the NvM standard queue or the NvM immediate queue based on the ID (Identity Document) of the NvM block carried in the NvM request.

[0044] In addition, because core 1 is the main core deployed by the NvM module 10, the SWC0 on core 1 can directly write the NvM request into the NvM standard queue or the NvM immediate queue without passing through the queue entry unit 101. That is to say, both SWC0 and the queue entry unit 101 can write the NvM request into the NvM standard queue or the NvM immediate queue. In order to avoid the problem of inaccurate written data caused by SWC0 and the queue entry unit 101 writing the NvM request at the same time, when the queue entry unit 101 transfers the NvM request to the NvM standard queue or the NvM immediate queue, the SWC0 on the main core can be prohibited from writing the NvM request to the NvM standard queue or the NvM immediate queue, for example, by calling the Suspend_All_Interrupt() function to achieve this purpose. In addition, as an optional replacement, a request queue can also be set for core 1, and the NvM request of core 1 can be transferred from the request queue to the standard queue or the immediate queue by transfer.

[0045] The NvM requests in the standard queue and the immediate queue are processed by the queue processing unit 102. The manner and process of the queue processing unit 102 processing the NvM requests in the standard queue and the immediate queue are familiar to those skilled in the art, and the details can be referred to the relevant description of AUTOSAR, which will not be repeated here.

[0046] Furthermore, the queue processing unit 102 can be executed periodically, and before the queue processing unit 102 is executed, it first triggers the execution of the queue entry unit 101, and then executes the processing of the standard queue and the immediate queue after the queue entry unit 101 is executed. For example, the queue processing unit 102 and the queue entry unit 101 can be placed in the main function of NvM, and the transfer and NvM processing operations can be periodically executed by periodically calling the main function.

[0047] Furthermore, the operations on the NvM block generally include: reading, writing, erasing, obtaining status and setting status. The NvM request in the request queue may only involve the read, write and erase operations, but not the obtain and set status operations, so as to simplify the complexity of the solution. For obtaining and setting the status of the NvM block, based on setting the NvM module as a global module, that is, all cores can access the NvM code and global variables, the NvM module defines an array for storing the status of each NvM block, so the NvM block status can be obtained and set by directly calling the corresponding API of the NvM module. In addition, reading and setting the status of the NvM block will not interfere with each other, because based on the design principle that an NvM block belongs to only one SWC, setting the NvM status is also only executed in one SWC, and there will be no scheduling conflict. In other words, the reading, writing and erasing of the NvM block are implemented in the form of a request queue, and for obtaining and setting the status of the NvM block, the corresponding API of NvM can be directly called. In this way, the complexity of the NvM multi-core deployment solution is further reduced.

[0048] In this embodiment, by adding an in-queue unit 101 and a request queue corresponding to a slave core in the NvM module 10, the processing of the slave core NvM request can be implemented, thereby realizing multi-core deployment of NvM in a low-complexity manner.

[0049] In this embodiment, the schematic structure of the request queue can be as follows: Figure 3 As shown, it adopts a circular queue method with head-to-tail connection. Among them, Release_Cnt%Max_CNT and Request_Cnt%Max_CNT are used to indicate the position of the queue entry and the queue exit. Among them, Max_CNT is the size of the request queue, that is, the maximum number of NvM requests that the request queue can contain. Release_Cnt and Request_Cnt are global variables, which represent the count value of the queue entry operation and the count value of the queue exit operation respectively. Their initial values ​​are 0. After executing a queue entry or a queue exit, they are increased by 1 accordingly. "%" is the remainder symbol.

[0050] The structure of the NvM request stored in the request queue can also be as follows: Figure 3As shown, it includes: ID, operation type, Ram Ptr (Ram pointer) and time. Among them, ID is the identity of the NvM block; the operation type is used to indicate the operation performed on the NvM block, such as read, write or erase. Ram Ptr represents a pointer to the NvM Ram block. Time is optional information, indicating the time when the request is issued. In some embodiments, when transferring NvM requests in a request queue, the order of transfer of NvM requests can be determined based on the time information of the request issuance. However, this may require caching the NvM requests in each request queue in advance, which will increase the complexity of the solution and occupy more resources, so the time information is only optional information.

[0051] exist Figure 2 In the example, each core (core 1 to 3) can call the read, write and erase functions provided by the NvM module 10 to request to write the corresponding NvM request. In this embodiment, it can be determined based on the identity of the core that calls these functions which queue the NvM request is written into, that is, the standard queue or the immediate queue, or the request queue. Specifically, Figure 5 As shown, first, an NvM request from a core is received (step S50), where the SWC in the core can call the API interface provided by the NvM module to initiate the NvM request. Next, the ID of the core, i.e., the identity, is obtained (step S51). Then, based on the core ID, it is determined whether the core is the main core (step S52). If it is the main core, the NvM request is written into the NvM standard queue or the immediate queue (step S53). If it is not the main core, the NvM request is written into the corresponding request queue.

[0052] exist Figure 2 In the example, core 1 (main core) writes the NvM request into the standard queue or the immediate queue, and other cores write the NvM request into the corresponding request queue. The process of writing the NvM request into the request queue can be referred to Figure 6 As shown. First, determine whether the difference between Release_Cnt and Request_Cnt is less than Max_Cnt (step S60). As mentioned above, the meanings of Release_Cnt, Request_Cnt and Max_Cnt are as mentioned above. When the difference between Release_Cnt and Request_Cnt is less than Max_Cnt, it means that the queue still has space to store NvM requests, so the NvM request is written into the Release_Cnt%Max_CNTth element in the request queue (step S61), and then Release_Cnt is increased by 1 (step S62).

[0053] exist Figure 2In the example, the queue enqueue unit 101 can periodically process NvM requests in the request queue to transfer the NvM requests to the standard queue or the emergency queue. The queue processing unit 102 can periodically process NvM requests in the standard queue and the immediate queue to realize the reading, writing and erasing of the NvM block. Among them, before executing, the queue processing unit 102 can first trigger the execution of the queue enqueue unit 101, and then execute after the queue enqueue processing unit 101 is executed, thereby unifying the cycles of the queue enqueue unit 101 and the queue processing unit 102. For example, in the main function of the NvM module 10, the queue enqueue processing and the queue processing are executed in sequence, and the main function is called periodically, thereby realizing the operation of periodically executing the queue enqueue and processing the requests in the queue. Specifically, as Figure 7 As shown, the request queue is released periodically (step S70), and the NvM requests in the NvM standard queue or the immediate queue are processed periodically (step S72).

[0054] When releasing the request queue, that is, transferring the NvM requests in the request queue to the standard queue or the immediate queue, the request queues corresponding to the slave cores may be traversed in sequence to realize the transfer of the NvM requests in the request queue. Specifically, Figure 8 As shown, each time the request queue is released, the slave core ID is set to 0 (step S80). In this embodiment, IDs 0, 1, 2, etc. may be assigned to each slave core. Figure 2 For example, ID=0 can be assigned to core 2, and ID=1 can be assigned to core 3. Next, determine the slave core ID and Max_ID (the number of slave cores, Figure 2 Example 2), if it is greater than or equal to Max_ID, it indicates that the request queues corresponding to all slave cores have been released (step S86). If it is less than Max_ID, the request queue corresponding to the current slave core ID is released. Specifically, first determine whether the difference between Release_Cnt and Request_Cnt is greater than 0. If it is less than or equal to 0, it indicates that the NvM request in the request queue has been released, and the slave core ID is increased by 1 (step S85). If it is greater than 0, the Release_Cnt%MAX_Cnt element is written to the NvM standard queue or the immediate queue (step S84), and then Release_Cnt is increased by 1 (step S84). Among them, it can be decided to transfer the NvM request to the standard queue or the immediate queue based on the ID in the NvM request.

[0055] With the help of the above description, the structure of the multi-core device 20 of the embodiment of the present invention and the operations involved therein are described in detail. In addition, the embodiment of the present invention also provides a multi-core deployment method of NvM, which can be applied to the multi-core device 20 mentioned above, and its process is as follows: Figure 4 As shown, the following steps are included:

[0056] Step S40: deploy the NvM module in the master core and set it to be callable by the slave core.

[0057] Step S42: setting request queues corresponding to the respective slave cores in the NvM module, for storing the first NvM request written by the slave core by calling the NvM module.

[0058] Step S44: executing the NvM module in the main core to transfer the first NvM request in the request queue to the NvM standard queue or the NvM immediate queue, and performing corresponding operations according to the NvM request in the NvM standard queue or the NvM immediate queue.

[0059] In this embodiment, the NvM module is deployed in the master core but can be called by the slave core, so the slave core can write its NvM request into the request queue by calling the NvM module. In the core, the NvM request in the request queue can be transferred to the NvM standard queue or the immediate queue by executing the NvM module, and then the NvM request of the slave core can be executed. This method does not require modifying the SWC in the application layer, but only requires a small amount of modification to the NvM module, which can meet the read and write operations of the slave core on the NvM block, so the multi-core deployment of NvM is realized in a simple deployment manner.

[0060] In addition, the relevant detailed description of the method steps of this embodiment has been explained in the above embodiments and will not be repeated here.

[0061] like Fig. 9 , is a schematic diagram of the structure of an embodiment of a computer device / equipment / system 9 of the present invention. The computer device / equipment / system 9 includes a memory 90, a processor 92 and a computer program / instruction stored in the memory. The processor 92 executes the computer program to implement the method of the embodiment of the present invention.

[0062] In addition, an embodiment of the present invention further provides a computer-readable storage medium on which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, the method described in the embodiment of the present invention is implemented.

[0063] In addition, an embodiment of the present invention further provides a computer program product, including a computer program / instruction, which implements the method of the embodiment of the present invention when executed by a processor.

[0064] The description of the above device, equipment, system, storage medium and program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device, equipment, system, storage medium and program product embodiments of this application, please refer to the description of the method embodiment of this application for understanding.

[0065] The processor may be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, a microprocessor, etc. It is understandable that the electronic device that implements the function of the processor may also be other, and the embodiments of the present application are not specifically limited.

[0066] The above-mentioned computer storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0067] It should be noted that the above description is only for example and not for limitation of the present invention. In other embodiments of the present invention, the method may have more, fewer or different steps, and the order, inclusion and function of each step may be different from that described and illustrated. For example, generally multiple steps can be combined into a single step, and a single step can also be divided into multiple steps. For those of ordinary skill in the art, without paying creative work, the sequential changes of each step are also within the scope of protection of the present invention.

[0068] The technical solution of the present invention, in essence or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor or a microcontroller to perform all or part of the steps of the method described in each embodiment of the present invention.

[0069] Those skilled in the art will appreciate that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed.

[0070] Although the present invention has been disclosed as above with preferred embodiments, the present invention is not limited thereto. Any changes and modifications made by any person skilled in the art without departing from the spirit and scope of the present invention should be included in the protection scope of the present invention, and therefore the protection scope of the present invention should be subject to the scope defined by the claims.

Claims

1. A multi-core deployment method of non-volatile memory management NvM, characterized in that: include: Deploy the NvM module in the master core and set it to be callable by the slave core; Setting request queues corresponding to the respective slave cores in the NvM module, for storing the first NvM request written by the slave core by calling the NvM module; The NvM module is executed in the main core to transfer the first NvM request in the request queue to the NvM standard queue or the NvM immediate queue, and corresponding operations are performed according to the NvM requests in the NvM standard queue or the NvM immediate queue.

2. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: The second NvM request of the master core is directly written into the NvM standard queue or the NvM immediate queue.

3. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: The NvM request includes: a request to read, write and erase an NvM block, but does not include: a request to obtain and set the status of an NvM block.

4. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: The request queue is a circular queue, and the first and second global variables are set to manage the first NvM request entering and exiting the request queue. The first global variable represents the count value of the queue entry operation, and the second global variable represents the count value of the queue exit operation.

5. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: When transferring the first NvM request in the request queue to the NvM standard queue or the NvM immediate queue, the main core is prohibited from writing the second NvM request into the NvM standard queue or the NvM immediate queue.

6. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: The NvM request includes: an identity of the NvM block, which is used to determine whether to write the NvM request into the NvM standard queue or the NvM immediate queue; and an operation indication, which is used to indicate whether to perform a read, write or erase operation on the NvM block.

7. The multi-core deployment method of NvM as claimed in claim 6, characterized in that: The NvM request further includes: a time when the request is issued, which is used to determine the transfer order of the first NvM request according to the time when the request is issued when the first NvM request is transferred.

8. The multi-core deployment method of NvM as claimed in claim 1, characterized in that: An array for storing the status of each NvM block is defined in the NvM module, and a software component in each core obtains and sets the status of the NvM block by calling an API of the NvM module.

9. A multi-core device compliant with the AUTOSAR architecture, comprising a first core and at least one second core, characterized in that: An NvM module is set in the basic software layer of the multi-core device, and the NvM module is a global module so that all cores can call the application programming interface API of the NvM module; Wherein, the NvM module includes: Pending queue; at least one request queue, corresponding to each of the at least one second core, and used to store the first NvM request written by the second software component of the application layer in the second core; an queuing unit, configured to periodically transfer the first NvM request in the at least one request queue to the queue to be processed; and The queue processing unit is used to execute the NvM requests in the queue to be processed.

10. The multi-core device according to claim 8, wherein: The queue to be processed includes: an NvM standard queue and an NvM immediate queue, and the first and second NvM requests are used to request to perform a read, write or erase operation on an NvM block.

11. The multi-core device according to claim 9, wherein: The pending queue, the queue entry unit and the queue processing unit are deployed in the first core, and the first core directly writes its second NvM request into the pending queue; in the first core, the queue entry unit is called to transfer the second NvM request to the pending queue, and the queue processing unit and the underlying non-volatile storage driver are called to execute the NvM requests in the pending queue.

12. A computer device / equipment / system comprising a memory, a processor and a computer program / instruction stored in the memory, characterized in that: The processor executes the computer program to implement the method of any one of claims 1 to 8.

13. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

14. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images