Processor-related address translation for host memory buffers

Abstract

A module identifier and a request address associated with an access request are received at a host memory buffer (HMB) access module in a solid state drive (SSD) system. Determining a translated address based at least in part on the module identifier and the requested address, including accessing at least one translation table storing (1) address mappings between a plurality of processors in the SSD system and (2) a host memory buffer; each processor of the plurality of processors has non-overlapping memory spaces in the host memory buffer. The access request is executed at the host interface, including accessing a host memory buffer by using the translated address, where the host memory buffer is located in a host memory external to the SSD system.

Description

[0001] Cross-references to other applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 393,461, filed on July 29, 2022, entitled “PROCESSOR-DEPENDENT ADDRESSTRANSLATION FOR HOST MEMORY BUFFER,” which is incorporated herein by reference for all purposes. Background Art

[0003] A solid-state drive (SSD) system includes an SSD controller (e.g., implemented on a system-on-chip (SOC)) and solid-state storage media (e.g., NAND flash media). New technologies that improve the performance and / or reduce the cost of SSD systems would be desirable. For example, such new SSD systems may be able to use less expensive components to provide the same level of performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0005] Figure 1 is a flow chart illustrating an embodiment of a process including performing an access request to a host memory buffer by performing address mapping.

[0006] Figure 2 is a diagram illustrating an embodiment of a solid state drive (SSD) having a host memory buffer (HMB) access module that provides access to a host memory buffer for two processors and one functional module.

[0007] Figure 3 is a diagram showing an embodiment of address mapping between three modules in an SSD controller and a host memory buffer.

[0008] Figure 4 is a diagram illustrating an embodiment of a host memory buffer (HMB) access module.

[0009] Figure 5 is a diagram illustrating an embodiment of the conversion from a request address to a converted address.

[0010] Figure 6 is a diagram illustrating an embodiment of a host memory buffer (HMB) access module that calculates a translated address using a region base address and a remap base address.

[0011] Figure 7is a diagram illustrating an embodiment of error correction encoded data and associated conversion settings in a host memory buffer. DETAILED DESCRIPTION

[0012] The present invention may be implemented in a variety of ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, for example, a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component such as a processor or memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform a task at a given time, or as a specific component manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores that are configured to process data such as computer program instructions.

[0013] A detailed description of one or more embodiments of the present invention is provided below, as well as drawings illustrating the principles of the present invention. The present invention is described in conjunction with these embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses many alternatives, modifications, and equivalents. In order to provide a comprehensive understanding of the present invention, many specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical materials known in the technical field related to the present invention are not described in detail to avoid unnecessarily obscuring the present invention.

[0014] Various embodiments of the technology and / or system for performing and / or managing address translation between a host memory buffer and multiple processors (e.g., which store data in a host memory buffer) are described herein. In an example application, a solid-state drive (SSD) controller is implemented using a system on a chip (SOC) with multiple processors running firmware (e.g., the same firmware image or different firmware images). Those processors can store information in a host memory buffer, and a host memory buffer (HMB) access module provides read and write access to the host memory buffer for those processors (and in some embodiments, additional (e.g., functional) modules in the SSD controller). The module identifier is used to perform address mapping, and (as described in more detail below) at least some HMB access module embodiments support and / or implement non-overlapping memory spaces within the host memory buffer, and segmented memory allocation or assignment of a given processor or functional module within the host memory buffer (e.g., because the host will typically authorize or otherwise allocate segmented memory space within the host memory buffer).

[0015] The following figure shows an example of the process of executing an access request to a host memory buffer, including performing address mapping.

[0016] Figure 1 is a flow chart illustrating an embodiment of a process for executing an access request to a host memory buffer by performing address mapping. In some embodiments, Figure 1 The process is performed by the HMB access module in the SSD controller.

[0017] At 100, a module identifier and a request address associated with an access request are received. For example, multiple processors (e.g., in a SOC with firmware running on each processor) may store data in a host memory buffer, and the access request may be associated with a read from or a write to the host memory buffer. Each module (e.g., one of the processors or a functional module) storing data in the host memory buffer has a (e.g., unique) module identifier provided at step 100.

[0018] The request address received at step 100 is a local and / or perceived address (e.g., relative to or in the context of how the requesting processor or functional module perceives the memory space). For example, a (requesting) processor or functional module may believe that it has or is working with a continuous memory space, but the memory space actually allocated or assigned on the host memory buffer may be segmented into multiple fragments of different sizes.

[0019] In one example of step 100, a (requesting) processor wants to perform a write to a host memory buffer; to do so, the requesting processor sends its module identifier (ie, associated with that processor) and the requested (eg, write) address to the HMB access module.

[0020] At 102, determining a translated address based at least in part on a module identifier and a request address includes accessing at least one translation table storing address mappings between (1) a plurality of processors in a solid state drive (SSD) and (2) a host memory buffer, wherein each of the plurality of processors has non-overlapping memory space in the host memory buffer.

[0021] For example, to ensure that one processor does not overwrite data stored in the host memory buffer by another processor, each processor has non-overlapping memory space in the host memory buffer. Each module that stores data in the host memory buffer has its own mapping between its local and / or requested addresses and corresponding and / or translated addresses in the host memory buffer. In a conceptually simple example, each module that stores data in the host memory buffer has its own translation table, so in some embodiments, step 102 includes selecting a translation table corresponding to a module identifier, and then looking up the requested address in the selected translation table to obtain the translated address.

[0022] At 104, an access request is performed, including accessing a host memory buffer using the converted address, wherein the host memory buffer is located in a host memory external to the SSD. For example, there may be some interface via which the SSD device (which includes an SSD controller and solid-state storage media) communicates with the host, and the access request (e.g., including the converted address) is exchanged via, such as a host-SSD device interface. In some embodiments, the access request is a read request, and step 104 includes the HMB access module returning the read data (e.g., data read from the converted address in the host memory buffer) to the requester module.

[0023] Although some other SSD systems store address mapping information in host memory, those other systems do not support SSD systems with multiple processors (or more generally, multiple modules storing information in a host buffer) where each processor (module) has non-overlapping memory space in the host memory buffer.

[0024] Show execution Figure 1 An example system of the process may be helpful. The following figure shows one such example, where the SSD includes an HMB access module, and the modules in the SSD controller access their data in the host memory buffer through the HMB access module.

[0025] Figure 2 The present invention is a diagram showing an embodiment of a solid state drive (SSD) having a host memory buffer (HMB) access module that provides access to a host memory buffer for two processors and a functional module. In this example, a solid state drive (SSD) (200) includes an SSD controller (202) and a solid state storage medium (204). The SSD controller (202) reads data from and writes data to the solid state storage medium (204) according to instructions from a host (206).

[0026] When the host (206) sends a read or write instruction to the SSD controller (202) to read from or write to the solid state storage medium (204), the host uses the logical address. On the solid state storage medium (204), data (which may be segmented, interleaved, and error correction encoded before being stored on the solid state storage medium (204)) is stored in physical addresses. The SSD controller (202) must keep track of this logical to physical address mapping, and for simplicity and ease of explanation, this mapping or conversion information is referred to in this example as a "logical to physical address mapping table."

[0027] Historically, the logical-to-physical address mapping table is stored (e.g., locally) in memory on the SSD (200). However, host memory (208) located in the host (206) provides cheaper memory than memory (not shown) in the SSD (200). In order to take advantage of the cheaper host memory (208), the logical-to-physical address mapping table (212) is stored in the host memory (208), specifically, in the host memory buffer (210).

[0028] In some embodiments, host memory (208) contains instructions (e.g., programs) and data used by the host processor, and may contain data used by devices within the system (e.g., SSD) or devices connected to the host system (e.g., network attached devices). Host memory buffers (in at least some embodiments) are used in cooperation with the host operating system and are typically requested by device drivers for use by associated devices. Some (e.g., other) host memory buffers may be used by both the device and the host, such as graphics buffers that may be written to by host software and read by a graphics adapter device (e.g., for display). Typically, (SSD) host memory buffers (e.g., 208) are allocated by device drivers, but are dedicated to the SSD (200).

[0029] In this example, the SSD controller (202) includes three modules that need to access the logical-to-physical mapping table (212) and / or other information thereof in the host memory (208): processor 1 (214a), processor 2 (214b), and (e.g., hardware) functional module (216) (e.g., a module built or otherwise designed for a specific function and / or service). For example, the three exemplary modules (214a, 214b, and 216) may need to respond to and / or support an instruction from the host (206) to access the solid-state storage medium (204), which instruction needs to access the logical-to-physical address mapping table (212) stored in the host memory buffer (210).

[0030] In some embodiments, the processors (214a and 214b) are symmetric multiprocessing (SMP) processors running the same and / or the same firmware. An SMP implementation may be desirable in some applications because it is easier to scale up or down by changing the number of processors in the SSD controller system on chip (SOC). In at least some embodiments, the HMB access module (218) supports and / or implements non-overlapping memory usage within the host memory buffer (210) so that if processor 1 (214a) is an SMP processor, it will use a set of memory locations in the host memory buffer (210) that do not overlap with the set of memory locations used by processor 2 (214b), which is also an SMP processor in this example. For example, if processor 1 (214a) is to write to a memory location in the host memory buffer (210) used by processor 2 (214b) and overwrite the data of processor 2, data consistency issues will be undesirably generated. Regardless of the number of (e.g., SMP) processors, the rules and / or properties of non-overlapping memory space apply. To ensure data consistency, this rule also applies to the functional modules (216) (e.g., so that the functional modules (216) do not overwrite data of one of the processors in the host memory buffer (210), and vice versa). Note that the techniques described herein are not necessarily limited to SMP processors (i.e., these techniques work even if the processors are running different firmware images).

[0031] In some embodiments, the functional module (216) is a direct memory access (DMA) module that allows or otherwise supports access to host memory (208), such as host memory buffer (210), independently of the processor (214a and 214b) (e.g., without requiring guidance and / or processing resources from the processor). For example, the DMA module can be programmed and / or configured by the processor (e.g., 214a and / or 214b) to act as an agent for firmware (e.g., running on the processor (214a and / or 214b)). Once configured, the DMA module can provide memory access services to other (hardware) functional modules (not shown) in the SSD controller (202) without requiring resources, intervention, and / or guidance from the firmware and / or processor (214a and 214b). Because a DMA module (or other functional module) may store information in the host memory buffer (210) and / or the host memory (208), the HMB access module (218) provides those services to functional modules (216) such as the DMA module in addition to providing address translation and / or memory access services to the processors (214a and 214b).

[0032] Temporarily return to Figure 1 , the HMB access module (218) is executed Figure 1 For example, the system or device may be configured to process the following process: Figure 2 214a), processor 2 ( Figure 2 214b) or functional module ( Figure 2 216) receiving the module identifier and the request address (e.g., in Figure 1 Then, the HMB access module ( Figure 2 218) to determine the converted address (see e.g. Figure 1 ), and the host interface (220) performs the access request (see, e.g. Figure 1 Step 104 in step 104), including accessing the host memory buffer by using the translated address ( Figure 2 In some embodiments, the SSD controller ( Figure 2 202) is a system on chip (SOC), and the HMB access module ( Figure 2 218) is a hardware functional module on the SOC.

[0033] Note that the need to store the logical-to-physical mapping table (212) in the host memory buffer (210) and / or access such a mapping table is merely exemplary and is not intended to be limiting. In other words, the HMB access module (218) can be used to access any type of information stored in the host memory (208) and / or the host memory buffer (210).

[0034] Similarly, the number of modules and the combination of module types shown here (i.e., two processors (214a and 214b) and one functional module (216)) are merely exemplary and are not intended to be limiting. Any number and / or combination of modules may store data in the host memory (208) and thus interface with the HMB access module (218) to access data in the module host memory (208).

[0035] The following figure shows an example of address mapping between exemplary modules in an SSD controller, namely, processors (214a and 214b) and functional modules (216) and a host memory buffer (210).

[0036] Figure 3 is a diagram showing an embodiment of address mapping between three modules in an SSD controller and a host memory buffer. Figure 2 , where processors 1 and 2 (214a and 214b) and functional modules (216) store data in a host memory buffer (210). In this example, processor 1 (P1) has a memory map (300a) that includes an apparent (e.g., from the perspective of and / or perceived by processor 1) HMB memory space (302a). As shown in this example, the apparent HMB memory space (302a) is a contiguous memory space. However, within the (e.g., actual) host memory buffer (304), the apparent HMB memory space (302a) associated with processor 1 is divided or otherwise segmented into two non-contiguous segments: P1 segment 1 (306a) and P1 segment 2 (306b).

[0037] Similarly, the apparent HMB memory space (302b) within the processor 2 (P2) memory map (300b) is a single continuous space, but is segmented within the host memory buffer (e.g., see P2 fragment 1 (307a) and P2 fragment 2 (307b)), and the apparent HMB memory space (302c) within the functional module (FM) memory map (300c) is a single continuous space, but is segmented within the host memory buffer (e.g., see FM fragment 1 (308a) and FM fragment 2 (308b)). The number and size of the fragments (306a / b-308a / b) and apparent HMB memory space (302a-302c) shown here are merely exemplary, and any number and / or size may be used. In some embodiments, in order to simplify the design and / or keep the size of the HMB access module at a manageable size, there are some restrictions (e.g., maximum values) on the number and / or size of the fragments in the host memory buffer.

[0038] As shown in this example, in some embodiments, a contiguous apparent HMB memory space (e.g., 302a) associated with a given one of a plurality of processors (e.g., processor 1) corresponds to multiple non-contiguous fragments (e.g., 306a and 306b) in a host memory buffer (e.g., 304).

[0039] The figure below shows an example block diagram of an HMB access module.

[0040] Figure 4 is a diagram illustrating an embodiment of a host memory buffer (HMB) access module. In some embodiments, Figure 2 The HMB access module (218) in is implemented as shown here. In this example, the HMB access module (400) receives an access request (410) including a module identifier and a request address. For example, if the access request is a write request, the write request will also include write data (e.g., to be written into the host memory buffer).

[0041] In the HMB access module (400), a conversion controller (404) accesses one or more conversion tables (402) and uses the module identifier and the request address to determine the converted access. In a simple example, the conversion table (402) has a separate table for each module identifier, and the appropriate conversion table is selected based on the module identifier. Then, the entry with the request address in the selected conversion table is identified and accessed to obtain the (e.g., corresponding) converted address.

[0042] In some embodiments, the conversion table (402) includes a single table, wherein entries corresponding to different module identifiers share (e.g., only) space within the conversion table, and entries are added when they are created and / or arrived. Sharing a single conversion table between all processors and / or modules can reduce the amount of conversion logic in the HMB access module, which can be desirable in some applications. In some such embodiments (i.e., where there is a single conversion table), each entry can include a module identifier corresponding to a given entry.

[0043] The HMB access module (400) also includes a conversion setting (406) that (at least in some embodiments) affects how the conversion controller (404) performs conversions and / or executes host requests (412). For example, as will be described in more detail below, in some embodiments, any data stored in the host (408) is interleaved and error-correction encoded, wherein the error-correction encoding adds parity information to the stored data, so that the encoded data stored on the host (408) is larger than the (e.g., original) payload. In some embodiments, the conversion setting (406) controls whether only the payload and / or the original data (e.g., without parity information) is returned in response to a read request, or whether the parity information is returned together with the payload and / or the original data. For example, this may depend on whether the requesting processor or requesting module has access to error correction decoding capabilities and / or whether the previously returned read data contains (or is suspected of containing) errors.

[0044] The conversion controller (404) outputs the converted address to the host interface (I / F) (411a), which generates a host request (412) including the converted address. If the host request is associated with a write request, the host request (412) may also include write data. In this example, any interleaving and error correction coding is handled by a module other than the HMB access module (400), so the HMB access module (400) does not need to perform error correction coding.

[0045] The host (408) receives the host request (412) and returns a host response (414) to the HMB access module (400) via the host I / F (411b). In response to receiving the host response (414), the HMB access module (400) generates an access response (416) and sends it to a requesting processor (not shown) or a requesting module (not shown). For example, if a read is being performed, the host response (414) and the access response (416) may include read data (e.g., data read from the host buffer module). If a write is being performed, the host response (414) may include a (written) converted address, and this information is stored in the conversion table (402).

[0046] The following figure shows some examples of conversions from a request address (eg, included in an access request (410)) to a converted address (eg, included in a host request (412)).

[0047] Figure 5 is a diagram showing an embodiment of the conversion from a request address to a converted address. In this example, the processor 1 (P1) memory map (500) includes an apparent HMB memory space (502) with 20 addresses, ranging from 5 (P1) to 24 (P1). To indicate that the context or reference frame of these addresses is processor 1 (P1), these addresses are appended with "(P1)".

[0048] In the host memory buffer (510), the apparent HMB memory space (502) corresponds to P1 segment 1 (512a) and P1 segment 2 (512b). P1 segment 1 (512a) includes 15 addresses: 15 (HMB) to 29 (HMB); P1 segment 2 (512b) includes 5 addresses: 750 (HMB) to 754 (HMB). In order to indicate that the context or reference system of these addresses is the host memory buffer (HMB), these addresses are appended with "(HMB)".

[0049] In the first example, assume that the request address is 19 (P1) (504). In this example, the following equation is used to calculate the converted address 29 (HMB) (514) based on the request address 19 (P1) (504):

[0050] Converted address = requested address - requested area base address + remapped base address

[0051] Wherein the request region base address is the starting address of the region in the request address space, and the remap base address is the starting address in the translated address space.

[0052] Therefore, for the request address 19(P1) (504), the translated address will be calculated as:

[0053] Converted address = 19(P1)-5(P1)+15(HMB)

[0054] =29(HMB)

[0055] Wherein in the above equation, address 5(P1) (518) is the request region base address of P1 segment 1 (512a), and 15(HMB) (520) is the remapped base address of P1 segment 1 (512a).

[0056] In the second example, assume that the request address is 20(P1) (506). In this example, the following equation is used to calculate the converted address 750(HMB) (516) based on the request address 20(P1) (506):

[0057] Converted address = 20(P1)-20(P1)+750(HMB)

[0058] =750(HMB)

[0059] Wherein in the above equation, address 20(P1) (506) is the request region base address of P1 segment 2 (512b), and 750(HMB) (516) is the remapped base address of P1 segment 2 (512b).

[0060] The following figure shows an example of the HMB access module that selects the correct request region base address and the correct remap base address to calculate the translated address.

[0061] Figure 6 6 is a diagram illustrating an embodiment of a host memory buffer (HMB) access module that uses a region base address and a remap base address to calculate a translated address. In this example, the HMB access module (600) includes a translation table entry manager (602) that inputs a module identifier. The translation table entry manager (602) tracks which entries in a translation table (e.g., at least 604a) belong to which module identifier. The entry corresponding to the (e.g., received) module identifier is output by the translation table entry manager (602) and passed to a request region selector (606).

[0062] The request region selector (606) is responsible for providing the request region base address to the arithmetic module (608). To this end, the request region selector (606) inputs the request address and the entry corresponding to the module identifier. The request region selector (606) then accesses those (e.g., enabled) entries in the translation table (604a) specified by the translation table entry manager (602) and compares the request address with the (e.g., enabled) request region size (610) and the request region base address (612) to determine which request region the request address falls into. For example, if the request address is 19 (P1), then the request address falls into a request region having a request region base address (612) of 5 (P1) and a request region size (610) of 15. If the request address is 20 (P1), then the request address falls into a request region having a request region base address (612) of 20 (P1) and a request region size (610) of 5.

[0063] In addition to outputting the request region base address to the arithmetic module (608), the request region selector (606) also passes the selected entry (e.g., which row in the translation table (604a)) to the remap base selector (614). The remap base selector (614) uses the selected entry to access the associated entry in the translation table (604b), which stores the remap base address (616) corresponding to the selected entry (e.g., the request region entry) in the translation table (604a). For example, if the request address is 19 (P1), the remap base address (616) of 15 (HMB) is selected and passed to the arithmetic module (608); if the request address is 20 (P1), the remap base address (616) of 750 (HMB) is selected and passed to the arithmetic module (608).

[0064] The arithmetic module (608) inputs the request address, the request region base address, and the remap base address, and performs the arithmetic function: converted address = requested address - request region base address + remap base address. The converted address is then output by the arithmetic module (608) to other logic (618), such as a host interface, which uses the converted address to assemble a host request. This additional logic (618) is not core to the technology described herein, and for the sake of brevity, is not described herein. In some embodiments, existing message generation and / or host interface modules and / or logic may be (re)used to provide this functionality.

[0065] In some applications, it may be (e.g., technically) acceptable to map a request address to multiple identical translated addresses (i.e., the translation logic outputs multiple answers, all of which are the same), but undesirable due to design verification rules (e.g., performed during the SOC design process using a SOC computer-aided design (CAD) tool). In this example, in order to make design verification run more smoothly (i.e., not trigger design verification errors or warnings associated with multiple solutions being valid answers or outputs), a single translated address is output by the arithmetic module (608) such that (only) a single answer is selected (e.g., based on some set of defined priorities and / or prioritizations) to ensure that the translation resolves to a unique (and therefore consistent and / or repeatable) translated address. For example, the request region selector (606) and / or the remapping base selector (614) may include an n-to-1 multiplexer that outputs only a single selection, even if multiple inputs to the multiplexer are (e.g., logically) feasible and / or acceptable.

[0066] In some embodiments, if no solution is found (i.e., the HMB access module (600) cannot identify a translated address that corresponds to the request address and the module identifier), the translated address returned is the same address as the request address. For example, this would indicate that the translated address may not be found. In some such embodiments (i.e., when no translated address is identified), the host request (e.g., Figure 4 412) is not sent to the host (for example, Figure 4 408 in the request), and includes an access response to the requested address (e.g., Figure 4 416) is returned to the requesting processor or requesting module.

[0067] As shown in this example, in some embodiments, the use of an apparent HMB memory space that is contiguous (e.g., Figure 5 502) and associated with the host memory buffer (e.g., Figure 5 510) in a plurality of non-contiguous segments (e.g., Figure 5 The translated address (e.g., output by arithmetic module (608)) is calculated using the remapped base address associated with one of the remapped base selectors (614) (e.g., output by arithmetic module (608)).

[0068] Note that in this example, the arithmetic calculations performed (i.e., converted address = request address - request region base address + remap base address) are such that all values ​​of the request region size (610), request region base address (612), and remap base address (616) stored in the conversion tables (604a and 604b) are positive values. Storing only positive values ​​(and no negative values) may be desirable because no bit needs to be allocated for a sign bit, and the conversion tables (604a and 604b) may be utilized more efficiently.

[0069] As shown in this example, in some embodiments, at least one conversion table (e.g., Figure 1 ) mentioned in step 102 of ) includes multiple request area base addresses (e.g., 612) that are all positive values, multiple request area sizes (e.g., 610) that are all positive values, and multiple remapping base addresses (e.g., 616) that are all positive values.

[0070] As described above, in some embodiments, data stored in the host memory buffer is interleaved and error correction encoded, the latter creating associated parity information. The following figure shows an example of associated conversion settings that may affect the conversion processor and / or host requests sent to the host.

[0071] Figure 7702a) is a diagram illustrating an embodiment of error correction encoded data and associated conversion settings in a host memory buffer. In this example, all data stored on the host memory buffer (700) is interleaved and error correction encoded. In this example, the error correction code is a systematic code, where the payload (e.g., payload 1 (702a)) is included or otherwise replicated in the encoded data stored in the host memory buffer (e.g., payload 1 (702b) in the host memory buffer (700)).

[0072] In this example, the error correction code has a code rate of 7 / 8, thereby generating 1 unit of parity information for every 7 bits of payload information. Therefore, for an exemplary payload (702a / b and 704a / b) having a length of 7 units, parity information (706 and 708) having a length of 1 unit is generated. The payload (702a / b and 704a / b) and parity (706 and 708) in this example are associated with one of the processors (Processor 1 (not shown)) in the SSD system.

[0073] The storage of parity (706 and 708) in the host memory buffer (700) affects the converted addresses generated by the HMB access module. For example, the conversion setting (710) shown here has a false value for whether parity should be retrieved for processor 1 (712). Therefore, if processor 1 requests a read access, the HMB access module (not shown) will need to generate converted addresses and / or lengths for accessing payload 1 (702b), skipping parity 1 (706), accessing payload 2 (704b), skipping parity 2 (708), etc. If error correction encoding is not performed, the payload for processor 1 will be "tighter" packed in the host memory buffer, resulting in a "tighter" or smaller range of converted addresses within the host memory buffer.

[0074] Temporarily return to Figure 4 , in some embodiments, Figure 4 The conversion settings (406) in include Figure 7 For example, the value of the code rate (714), which in this example is 7 / 8, can be used during the calculation of the converted address (e.g., by "shifting" the converted address to account for the extra space in the host memory buffer consumed by the parity information), or can affect the length or range of the address specified by the access request.

[0075] In some embodiments, the module storing information in the host memory buffer (e.g., processor 1) can access error correction decoding services, and therefore it is useful for the requesting module (e.g., processor 1) to receive parity (e.g., in addition to the payload). For example, if the requesting module (e.g., processor 1) previously requested only the payload, but determined that the returned payload contained errors, the "Retrieve Parity?" setting (712) can be changed from false to true, and the read request can be executed again to perform another read, this time also returning parity information. Alternatively, in some cases, the requesting module may not be able to access error correction decoding services, and its "Retrieve Parity?" setting remains false.

[0076] As shown in this example, in some embodiments, error correction encoded data (e.g., 702b, 706, 704b, and 708) is stored on a host memory buffer (e.g., 700), and determining the converted address is also based at least in part on a coding rate (e.g., 714) associated with the error correction encoded data.

[0077] As shown in this example, in some embodiments, an access request (e.g., Figure 1 ) includes a read request; error correction coded data including a payload portion (e.g., 702 b and 704 b) and a parity portion (e.g., 706 and 708) is stored on a host memory buffer (e.g., 700); and performing the access request includes determining, based at least in part on a setting (e.g., 712), whether to return (1) only the payload portion or (2) both the payload portion and the parity portion in response to the read request.

[0078] Although the foregoing embodiments have been described in some detail for the purpose of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative rather than restrictive.

Claims

1. A solid state drive (SSD) system, comprising: Multiple processors; A host memory buffer (HMB) access module, wherein the HMB access module performs the following operations: receiving a module identifier and a request address associated with an access request; and Determining a translated address based at least in part on the module identifier and the request address includes accessing at least one translation table that stores address mappings between (1) a plurality of processors in the SSD system and (2) a host memory buffer, wherein each processor in the plurality of processors has non-overlapping memory space in the host memory buffer; as well as A host interface, wherein the host interface performs an access request including accessing a host memory buffer by using the translated address, wherein the host memory buffer is located in a host memory external to the SSD system.

2. The SSD system of claim 1, wherein the plurality of processors comprises a plurality of symmetric multi-processing (SMP) processors running the same firmware.

3. The SSD system of claim 1, wherein the one or more logical-to-physical address mapping tables are stored in a host memory buffer.

4. The SSD system according to claim 1, wherein: A plurality of processors, an HMB access module, and a host interface are included in the SSD controller; and The SSD controller is implemented in a system on chip (SOC).

5. The SSD system according to claim 4, wherein: The SSD controller also includes a hardware function module; and At least one translation table also stores address mappings between (1) hardware functional modules and (2) host memory buffers.

6. The SSD system of claim 5, wherein the hardware function module comprises a direct memory access (DMA) module.

7. The SSD system of claim 1, wherein a contiguous apparent HMB memory space associated with a given one of the plurality of processors corresponds to a plurality of non-contiguous segments in the host memory buffer.

8. The SSD system of claim 7, wherein the translated address is calculated using a request region base address associated with the contiguous apparent HMB memory space and a remap base address associated with one of the plurality of non-contiguous segments in the host memory buffer.

9. The SSD system of claim 8, wherein the at least one translation table comprises a plurality of request region base addresses that are all positive values, a plurality of request region sizes that are all positive values, and a plurality of remapping base addresses that are all positive values.

10. The SSD system of claim 1, wherein the error correction coded data is stored on a host memory buffer, and determining the translated address is further based at least in part on a coding rate associated with the error correction coded data.

11. The SSD system according to claim 1, wherein: Access requests include read requests; The error correction coded data including the payload portion and the parity portion is stored on a host memory buffer; and Executing the access request includes determining, based at least in part on the settings, whether to return in response to the read request: (1) only the payload portion or (2) the payload portion and the parity portion.

12. A method comprising: receiving, at a host memory buffer (HMB) access module in a solid-state drive (SSD) system, a module identifier and a request address associated with an access request; At the HMB access module, determining a translated address based at least in part on the module identifier and the request address includes accessing at least one translation table that stores address mappings between (1) a plurality of processors in the SSD system and (2) a host memory buffer, wherein each processor in the plurality of processors has non-overlapping memory space in the host memory buffer; as well as An access request is performed at a host interface, including accessing a host memory buffer by using the translated address, wherein the host memory buffer is located in a host memory external to the SSD system.

13. The method of claim 12, wherein a contiguous apparent HMB memory space associated with a given one of the plurality of processors corresponds to a plurality of non-contiguous segments in the host memory buffer.

14. The method of claim 12, wherein the error correction encoded data is stored on a host memory buffer, and determining the converted address is further based at least in part on a coding rate associated with the error correction encoded data.

15. The method of claim 12, wherein: Access requests include read requests; The error correction coded data including the payload portion and the parity portion is stored on a host memory buffer; and Executing the access request includes determining, based at least in part on the settings, whether to return in response to the read request: (1) only the payload portion or (2) the payload portion and the parity portion.

Images