Efficient avoidance of row cache miss

Abstract

The invention relates to effectively avoiding row cache miss. A system is described that includes a row cache; a memory device; and a processing device that executes firmware to detect that received events are located in an event list, where events stored in the event list are associated with a key function that occurs no more than one time per threshold number of days and timeout after between 15 microseconds and a predetermined number of hundreds of milliseconds. The firmware is further to enable access to the row cache and execute a key function associated with the received event from a always-on-load region of the row cache.

Description

[0001] Information about divisional applications

[0002] This case is a divisional application. The parent case of this divisional application is a Chinese invention patent application with the invention name “Effectively Avoiding Row Cache Misses”, the application date is December 23, 2019, and the application number is 201980103441.5. Technical Field

[0003] Embodiments of the present disclosure relate generally to memory subsystems, and more particularly, to efficiently avoiding row cache misses. Background Art

[0004] The memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. In general, the host system may utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The present disclosure will be more fully understood according to the detailed description given below and the accompanying drawings of various embodiments of the present disclosure.

[0006] Figure 1A An example computing system including a memory subsystem according to an embodiment of the present disclosure is shown.

[0007] Figure 1B A more detailed computing system including a memory subsystem and a line cache is shown according to an embodiment.

[0008] Figure 2 is a block diagram illustrating the use of multiple caches in memory paths of various memory devices according to an embodiment.

[0009] Figure 3A is a logic diagram of hardware in which clock domain crossing may occur according to some embodiments.

[0010] Figure 3B for Figure 3A A logical diagram of a device including network and data path delay terms according to various embodiments.

[0011] Figure 4 To show Figures 3A to 3B 0 is a diagram of the timing of clock signals of , which illustrates clock domain issues according to an embodiment.

[0012] Figures 5A to 5B is a flow chart of an example method for performing efficient line cache miss avoidance according to various embodiments.

[0013] Fig. 6AA block diagram of a cache-on region and other cache-off regions of a line cache according to an embodiment.

[0014] Figure 6B According to the embodiment Fig. 6A Block diagram of a row cache where the cache open region is always open or always loaded with critical functions.

[0015] Figure 7 is a block diagram of the functionality of a manual function swap engine with respect to a line cache according to an embodiment.

[0016] Figure 8 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0017] Various aspects of the present disclosure relate to effectively avoiding row cache misses in a memory subsystem. The memory subsystem may be a storage device, a memory module, or a mixture of a storage device and a memory module. Examples of storage devices and memory modules are described below in conjunction with FIG. 1. In general, a host system may utilize a memory subsystem that includes one or more memory devices that store data. The host system may provide data to be stored at the memory subsystem, and may request retrieval of data from the memory subsystem.

[0018] The memory subsystem may include multiple memory devices or memory devices that can store data from the host system. The row cache is designed to speed up data extraction efficiency, which can have the effect of improving the execution efficiency of the host system (e.g., host processor). With the row cache enabled, data acquisition by the host system (e.g., host processor) can hit the row cache, and therefore does not need to access data from the memory component or memory device, which will take considerable time. However, data extraction by the host system may also miss the row cache, which results in the row cache engine of the row cache needing to extract the data in the burst from the memory device of the host system. Once extracted, this data can then be stored in the row cache until evicted.

[0019] A miss at the row cache has at least two effects on the host system. First, a miss at the row cache causes the row cache to fetch data from the memory device, which takes time, as mentioned. In addition, a miss at the row cache can introduce row cache hardware problems, which can cause the host system to crash in some cases. In at least one example of such a row cache hardware problem, a clock domain crossover (CDC) between the buffer manager (of the memory subsystem) and the host system can cause instructions (or function code) that should be pulled into the row cache to arrive, for example, asynchronously, and therefore late. As a result, the host system may read incorrect information or jump to an incorrect location in the instruction code, which can cause errors that in some cases crash the host system and must be restarted.

[0020] Because it has been determined that row cache misses can trigger such errors and, in some cases, system crashes, embodiments of the present invention disclose how to avoid row cache misses from the perspective of the host system. In one embodiment, an always-on region of a row cache can be preloaded with critical functions that are likely to cause CDC-based row cache hardware issues. Critical functions herein are those functions that occur infrequently (e.g., no more than a threshold number of days) and are timing sensitive (e.g., time out after between 15 microseconds and a predetermined number of hundreds of milliseconds), which will be discussed in more detail. If the total size of the critical function does not fit into the always-on region of the row cache, the memory subsystem firmware can implement a manual function swap engine that can trigger the preloading of multiple rows of the row cache for the critical function before executing the critical function. In either method, code for the critical function is preloaded into the row cache, effectively avoiding row cache misses for the critical function.

[0021] Advantages of the present disclosure include, but are not limited to, improving the speed and functionality of the host system by preloading critical functions into the row cache, thus avoiding system slowdowns that would otherwise occur. Furthermore, by preloading critical functions into the row cache, known CDC-based row cache hardware problems, such as corresponding system crashes that can occur in some cases, can be avoided. Other advantages in the features of avoiding row cache misses discussed below will be apparent to those skilled in the art.

[0022] Figure 1A An example computing system 100A is shown that includes a memory subsystem 110 according to some embodiments of the present disclosure. The memory subsystem 110 may include media such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination thereof. Each memory device 130 or 140 may be one or more memory components.

[0023] The memory subsystem 110 may be a storage device, a memory module, or a mixture of storage devices and memory modules. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0024] The computing system 100A can be a computing device, such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, drone, train, car, or other transportation vehicle), an Internet of Things (IoT)-enabled device, an embedded computer (e.g., an embedded computer included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes a memory and a processing device.

[0025] The computing system 100A may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, the host system 120 is coupled to memory subsystems 110 of different types. Figure 1A An example of a host system 120 coupled to one memory subsystem 110 is shown. As used herein, "coupled to" or "coupled with" generally refers to a connection between components or devices, which may be an indirect communication connection or a direct communication connection (e.g., without intervening components or devices), whether wired or wireless, including, for example, electrical connections, optical connections, magnetic connections, etc.

[0026] The host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 120 uses, for example, the memory subsystem 110 to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0027] The host system 120 may be coupled to the memory subsystem 110 via a physical host interface that may communicate on the system bus 150. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, a Small Computer System Interface (SCSI), a Serial Attached SCSI (SAS), a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM socket interface supporting a Double Data Rate (DDR)), etc. The physical host interface may be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 through a PCIe interface, the host system 120 may further utilize an NVM Express (NVMe) interface to access memory components (e.g., the memory device 130). The physical host interface may provide an interface for transferring control, address, data, and other signals between the memory subsystem 110 and the host system 120.

[0028] The memory devices may include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0029] Some examples of non-volatile memory devices (e.g., memory device 130) include NAND-type flash memory and write-in-place memory, such as three-dimensional cross-point ("3D cross-point") memory. A cross-point array of non-volatile memory can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-grid data access array. In addition, in contrast to many flash-based memories, cross-point non-volatile memory can perform write-in-place operations, where non-volatile memory cells can be programmed without pre-erasing the non-volatile memory cells.

[0030] Each memory device 130 may include one or more memory cell arrays. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), triple-level cells (TLC), and quad-level cells (QLC), may store multiple bits per cell. In some embodiments, each memory device 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion of memory cells, as well as an MLC portion, a TLC portion, or a QLC portion. The memory cells of the memory device 130 may be grouped into pages, which may refer to a logical unit of a memory device used to store data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0031] Although non-volatile memory components such as 3D cross-point type and NAND type memory are described, the memory device 130 can be based on any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM), self-selected memory, other chalcogenide-based memory, ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), or non-(NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0032] The memory subsystem controller 115 (or simply controller 115) can communicate with the memory device 130 to perform operations, such as reading data, writing data, or erasing data and other such operations performed at the memory device 130. The memory subsystem controller 115 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware may include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or other suitable processor.

[0033] The memory subsystem controller 115 may include a processor 117 (e.g., a processing device) configured to execute instructions stored in a local memory 119. In the illustrated example, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines for controlling the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 120.

[0034] In some embodiments, local memory 119 may include memory registers that store memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1A The example memory subsystem 110 in FIG. 1 has been shown as including a memory subsystem controller 115, but in another embodiment of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may instead rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0035] In general, the memory subsystem controller 115 may receive commands or operations from the host system 120 and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical addresses (e.g., logical block addresses (LBA), name space) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may further include a host interface circuit system to communicate with the host system 120 via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions to access the memory device 130 and convert responses associated with the memory device 130 into information for the host system 120.

[0036] The memory subsystem 110 may also include additional circuitry or components not shown. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0037] In some embodiments, the memory device 130 includes a local media controller 135 that operates in conjunction with the memory subsystem controller 115 to perform operations on one or more memory cells of the memory device 130. An external controller (e.g., the memory subsystem controller 115) may externally manage the memory device 130 (e.g., perform media management operations on the memory device 130). In some embodiments, the memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., the local controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0038] In some embodiments, the controller 115 includes an error correction code (ECC) encoder / decoder 111. The ECC encoder / decoder 111 may respectively perform ECC encoding on data written to the memory device 130, and ECC decoding on data read from the memory device 130. The ECC decoding may be performed to decode the ECC codewords to correct errors in the original read data, and in many cases also report the number of bit errors in the original read data.

[0039] Figure 1B A more detailed computing system 100B is shown that includes a memory subsystem 115 and a row cache 118 according to an embodiment. In the disclosed embodiment, the row cache 118 may include a row cache engine 118A. The processor 117 may further include a SATA controller 122 (to control SATA devices), a buffer manager 124 (to control memory devices 140), and a flash controller 126 (to control NAND or other flash devices). The memory subsystem controller 115 may further include a turbo mode driver 113, a SATA physical layer (PHY) circuit 123, a memory (MEM) PHY circuit 125, and a NAND PHY circuit 127. In alternative embodiments, the PHY components may be located away from the memory subsystem controller 115 but still within the memory subsystem 110. In the disclosed embodiment, SATA PHY circuit 123 is a connector between SATA controller 122 and the SATA devices of memory device 130; MEM PHY 125 is a connector between buffer manager 124 and the memory components of memory device 140; and NAND PHY 127 is a connector between flash controller 126 and the flash devices of memory device 130. The memory components of memory device 140 may be double data rate (DDR) (or other high-speed memory) DIMMs, and thus MEMPHY 125 may be, for example, a DDR PHY, or some other high-speed memory PHY.

[0040] As shown, the row cache 118 may be coupled between the buffer manager 124 and the system bus 150. The row cache engine 118A may interface with the host system 120 and the buffer manager 124 to write data into the row cache 118 (e.g., when fetched from one of the memory devices 140 in response to a row cache miss) and read data from the row cache 118 (e.g., when sent to the host system 120 in the event of a row cache hit). In an embodiment, the row cache engine 118A reads (and writes) data in bursts of the granularity of a cache row partition, which is typically 64 bytes, but may be greater or less than 64 bytes of data depending on the implementation.

[0041] In the disclosed embodiment, the turbo mode driver 113 may be firmware that can be executed by the processor 117 to operate in a faster (e.g., turbo) mode, which includes fetching code and data (including execution of critical functions) from the row cache 118. The turbo mode thus has a direct impact on increasing the execution speed of timing-sensitive functions. In contrast, the normal mode includes fetching code and data (and execution of other functions) from one of the memory devices 140 at a much slower speed. The present disclosure will describe a situation in which the turbo mode driver 113 can be called to enter a turbo operating mode, such as to enable access to the row cache 118 in order to execute functions out of the row cache 118. Likewise, the turbo operating mode can be disabled, such as to disable access to the row cache 118 during normal operation.

[0042] Figure 2 A block diagram illustrating the use of multiple caches in the memory path of various memory devices according to an embodiment. In an embodiment related to the present disclosure, the example computing environment 100B further includes at least two host processors (CPU0 and CPU1) within the host system 120, and the system bus 150 may be an Advanced Host Bus Lite (AHBL) protocol bus for communicating with the memory subsystem 110. Within the memory subsystem 110, the row cache memory path begins with the buffer manager (BM) 124, passes through the BM row cache interface 204, the row cache BM arbiter 208, the read cache 212, and the BM row cache arbiter 216 coupled to the AHBL protocol bus. In one embodiment, the BM row cache arbiter 216 is the same as the row cache engine 118A, and the read cache 212 is the row cache 118 (Figure 1).

[0043] In various embodiments, the read cache 212 may include several 64-byte cache lines, but cache lines of different sizes are contemplated. In an embodiment, only reads are performed on the read cache 212. The starting address of each cache line may be aligned to 64 bytes. If a miss occurs in a CPU access, one cache line may be invalidated and a 64-byte burst request to the buffer manager 124 is generated. The invalidated cache line may be selected based on an LRU (least recently used) scheme, where the LRU is shared between the dual CPU cores (CPU0 and CPU1). When data is returned from the memory device 140, the CPU wait state may be released and the data may be presented back to the system bus 150. The cache logic (e.g., the line cache BM arbiter 208) may continue to store all 64 bytes from memory into the cache line.

[0044] Figure 3A1 is a logic diagram of hardware in which clock domain crossing (CDC) may occur according to some embodiments. For example, the logic circuitry shown will check the last data arrival from the buffer manager 124 and compare it to the data count, for example, to determine when enough data has accumulated for a burst communication to CPU0 or CPU1. Figure 3A 1 , the two incoming signals include data from the buffer manager 124 (e.g., “from BM”) and a clock signal from the controller 115 (e.g., “hdc_clk,” where “hdc” represents the host device controller and “clk” represents the clock). The hdc_clk signal may enter a count done (e.g., cnt_done) circuit that may track when enough code has arrived for a burst communication to CPU0 or CPU1. On the right, a last count signal (LastCnt) may be output based on inputs from two of the aforementioned blocks of circuitry, namely, the S1 count done (cnt_done_s1) and S2 count done (cnt_done_s2) circuits. The S1 and S2 count done circuits may be driven by the CPU clock (cpu_clk) from CPU0 or CPU1 of the host system 120.

[0045] In various embodiments, because the timing between the cnt_done circuit and the cnt_done_s1 circuit is not checked (e.g., the circuits have asynchronous clock domains), setup and hold time violations may occur between the cnt_done circuit and the cnt_done_s1 circuit, for example, due to non-deterministic operation of the cnt_done_s1 circuit caused by CDC. The dotted line refers to the host system 120 domain, and the rest of the logic diagram refers to the memory subsystem 110 domain.

[0046] Figure 3B for Figure 3A , which includes network and data path delay terms according to various embodiments. Figure 3A , showing the relationship between data arrival time and clock network delay for the cnt_done_s1 circuit. For example, the data arrival time may be equal to the clock network delay (CND_BM) of bm_clk plus the data path delay (DPD). The clock network delay (CND_CPU) may be equal to the cpu_clk signal. If data arrives within the unstable window of the rising edge of the cpu_clk signal, then there is a chance of obtaining metastability, such as where a digital electronic system may persist in an unstable equilibrium or metastable state for an unbounded time. The unstable window may be roughly between (cpu_lk rising edge - setup time) and (cpu_clk rising edge and hold time), which is visually indicated by Figure 4 The setup and hold time windows are shown.

[0047] Figure 4 To show Figures 3A to 3B 1 is a diagram of the timing of clock signals of the host system 120, which illustrates the clock domain issues according to an embodiment. From top to bottom: i) the buffer manager (BM) 124 clock (bm_clk); ii) the signal at the cnt_done circuit; iii) the clock of CPU0 or CPU1 of the host system 120 (cpu_clk); iv) the signal at the cnt_done_s1 circuit; v) the signal at the cnt_done_s2 circuit; and vi) the signal output as the last count (LastCnt)

[0048] A setup and hold time window (e.g., two full clock cycles) is shown between the cnt_done signal and the cpu_clk signal, during which the signals at the cnt_done_s1 and cnt_done_s2 circuits may transition. For example, cnt_done may change within the setup / hold time window of cpu_clk of cnt_done_s1. Due to the setup / hold time violation, cnt_done_s1 may rise slowly, thereby satisfying the margin value around the threshold voltage (Vth) in the setup / hold time window of cnt_done_s2. Therefore, cnt_done_s1 may keep rising after the #2 clock edge. Since cnt_done_s2 captures cnt_done_s1 at a high clock value (#2 clock edge), cnt_done_s2 rises slowly. Due to the marginal value of cnt_done_s1 at clock edge #2, the LastCnt pulse is not captured at clock edge #2 as expected. Thus, LastCnt is low at clock edge #2 and still low at clock edge #3 when triggered by the value of cnt_done_s2. A low value of LastCnt when it should be high can cause the instruction code to arrive late at either CPU0 or CPU1, regardless of which CPU requested the instruction code. As discussed, this late arrival of the instruction code can cause errors, which in some cases can cause a crash of the host system 120.

[0049] Figures 5A to 5BFlowchart of an example method 500 for performing effective avoidance of row cache misses according to various embodiments. Method 500 may be performed by a processing logic that may include hardware (e.g., a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, method 500 is performed by a controller 115 (e.g., a turbo mode driver 113) of FIG. 1 . Although shown in a particular order or sequence, the order of the process may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood only as examples, and the illustrated processes may be performed in different orders, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0050] refer to Figure 5A , at operation 510, method 500 may begin with processing logic (e.g., firmware of controller 115) running in normal mode. As discussed, normal mode may include fetching code and data (as well as execution of other functions or firmware instructions) from one of memory devices 140 (rather than from line cache 118). At operation 520, processing logic may receive one or more events related to the execution of instructions. In some embodiments, the events are detected as or correspond to certain types of functions that may be executed in firmware. Such detection may include identification of code segments or specific firmware functions.

[0051] At operation 530, processing logic may determine whether the received event is in a critical event list. For example, a database or data structure (e.g., stored in local memory 119) may include a critical event list. Critical events may be sufficiently sensitive to timing to run in row cache 118 and require global resources to accelerate the execution of corresponding critical functions. For example, these critical events may include multiple record events, clear commands, smart command transfer commands, write uncorrectable commands, download firmware commands, and trim commands. Critical functions may be associated with these events and executed to implement the critical events.

[0052] In various embodiments, the corresponding critical functions are functions that are executed infrequently (e.g., no more than once per a threshold number of days, such as several days, a week, or several weeks) and are timing sensitive (e.g., time out after a predetermined number of between 15 microseconds and hundreds of milliseconds, up to and including one or more seconds). For example, the SATA COMRESET timeout value is eight seconds; the clean power cycle recovery time is 100 milliseconds (ms); the dirty power cycle recovery time is one second; and for dirty power shortage, the SSD drive should complete the content preservation work within 15ms. In some embodiments, the critical functions may include, but are not limited to, for example, drive startup sequence related functions, a clean handle function (Sanitize_Handle_Func()), a smart command transmission function (SCT_Handle_Func()), a write uncorrectable handle function (WUNC_Handle_Func()), a firmware image download function (DM_Segmented()), and a trim handle function (Trim_Handle_Func()).

[0053] If the received event is not in the critical event list, the processing logic may loop back to operation 510 and continue to run in normal mode. In contrast, if the received event is in the critical event list, then at operation 540, the processing logic may enable access to the row cache 118. In one example, access to the row cache 118 is enabled by setting one or more registers in the local memory 119, which will contain the range of code and data stored in the memory device 140 that can be used for row cache access. Event handling should be as short as possible to reduce the probability of encountering CDC hardware problems during the row cache enable cycle.

[0054] At operation 545, in response to being directed to execute the critical function associated with the critical event, the processing logic may continue to operate in turbo mode to execute the critical function. Directed to execute the critical function may be executed by a function call or by setting the program counter address to the start address of the critical function. As discussed, turbo mode may include fetching code and data (including execution of the critical function associated with the critical event) from the row cache 118 on behalf of the host system 120. The enabling of turbo mode may be performed globally, and thus code and data located in the row cache range (e.g., according to registers of the local memory 119) may be fetched by the host system 120 (e.g., CPU0 or CPU1) via the row cache 118 and not directly from the memory device 140.

[0055] In various embodiments, critical events may be handled differently depending on the size of the critical function compared to the size of the always-on region of the line cache, as will be described with reference to Figure 5B6. At operation 560, processing logic may detect the termination of execution of a pending critical function and, therefore, handle the pending critical event. If not all critical events (or functions) have been fully handled, method 500 may loop back to operation 530 and continue to handle additional events as described with respect to operations 530 to 545. If all critical events (or functions) have been fully handled, at operation 570, processing logic may disable access to the row cache. In one embodiment, access to the row cache is disabled by updating or removing the code and data ranges of the registers of the local memory 119 that define the always-on region of the row cache.

[0056] Additional references Figure 5B After operation 545, at operation 550, processing logic may determine whether the total size of the critical function is less than or equal to the always-on region of the row cache. In one embodiment, the size of the always-on region of the row cache is 32 rows by 64 bytes per row, or 2048 bytes, e.g., about 2 kilobytes (KB) in size (although different sizes are contemplated depending on implementation and / or processing mode). Fig. 6A is a block diagram of a cache-on region 110 and other cache-off regions 104A, 104B of a line cache 118 according to an embodiment.

[0057] Figure 6B According to the embodiment Fig. 6A 1, wherein the cache open region 110 of the row cache 118 is converted to an always open region 112. Being always open means that it is always accessible to store code and data to accelerate data fetching and critical instruction execution that can be performed directly from the row cache 118.

[0058] In the disclosed embodiment, if the total size of the critical functions is less than or equal to the always-on region 112 of the row cache, then at operation 552, the processing logic may preload the critical functions into the always-on region 112 of the row cache 118. Operation 552 may further convert the always-on region 112 of the row cache into an always-loaded region of the cache, e.g., always loaded with the critical functions (at least until a system reset). In some embodiments, operation 552 is performed at boot time of the host system 120. In other embodiments, operation 552 is performed at initialization of the controller 115.

[0059] At operation 554, processing logic may execute a critical function associated with the received event out of the always-loaded area of ​​the row cache. In this way, execution of the critical function will not miss at the row cache because the critical function will always be loaded in the row cache 118, e.g., from the start of the host system 120.

[0060] Continue to refer Figure 5B If, at operation 550 , the total size of the critical functions is greater than the always-on region 112 of the row cache 118 , then the method 500 may proceed to an alternative embodiment in which the always-on region 112 is not always loaded with all critical functions. More specifically, the firmware of the controller 115 may implement a manual function swap engine 700 . Figure 7 1 is a block diagram of the functionality of a manual function swap engine 700 with respect to a line cache 118 according to an embodiment. The manual function swap engine 700 may be operable to swap out data in a line of a line cache (e.g., based on a least recently used or similar algorithm) and swap in a critical function associated with a received event before allowing the processor 117 to execute a critical function out of the line cache 118. The critical function may be stored from the memory device 140 and swapped in accordingly. This may be as described in Figure 5B The alternative branch is described in the implementation.

[0061] At operation 562, processing logic may verify that the critical function is not larger than the size of the always-on region of the row cache, e.g., so that processing logic knows that the critical function may be stored in the always-on region 112 of the row cache 118. If this verification fails, but is not illustrated for the sake of brevity, method 500 may loop back to operation 510, and normal execution may not be possible due to execution outside of the row cache 118.

[0062] At operation 564, processing logic (e.g., manual function exchange engine 700) may evict any data from the multiple lines of the always-on region 112 of the self-cache. This data eviction is optional in the sense that eviction occurs when enough cache lines need to be freed up to import the critical function into the line cache 118.

[0063] At operation 566, processing logic (e.g., manual function exchange engine 700) may read a first number of bytes of each row partition of the critical function from a memory device (e.g., one of memory devices 140) into a corresponding row of the plurality of rows of row cache 118. Figure 7As shown, in different embodiments, this number of bytes may be a smaller number such as two bytes, four bytes, or six bytes. Reading in this smaller number of bytes may not take much time, but advantageously, the hardware of the controller 115 may be triggered to automatically read in the remainder of each row partition of the critical function. The hardware of the controller 115 performs these automatic writes or reads of larger data chunks in bursts, such as 64 bytes (although different numbers of bytes such as 32 bytes or 128 bytes are contemplated).

[0064] At operation 568, processing logic may allow the critical function to be executed out of the row cache after the plurality of rows of the row cache have been completely loaded by the row cache hardware. That is, the execution stage of the critical function is separated from the loading stage, and thus the execution of the critical function is temporarily delayed long enough to ensure that the code of the critical function is first completely loaded into the row cache 118. In this way, row cache misses are effectively avoided because the execution of the critical function is guaranteed to hit at the row cache.

[0065] Figure 8 An example machine of a computer system 800 is shown in which a set of instructions may be executed to cause the machine to perform any one or more of the methodologies discussed herein. In some embodiments, the computer system 800 may correspond to a host system (e.g., Figures 1A to 1B 1) a host system 120 that includes, is coupled to, or utilizes a memory subsystem (e.g., Figures 1A to 1B 110) or can be used to perform operations of the controller 115 (e.g., execute an operating system to execute operations corresponding to Figure 1B In some embodiments, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or in the capacity of a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0066] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. Further, while a single machine is shown, the term "machine" should also be construed to include any collection of machines that individually or collectively execute (one or more) sets of instructions to perform any one or more of the methodologies discussed herein.

[0067] The example computer system 800 includes a processing device 802, a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 818 that communicate with each other via a bus 830.

[0068] The processing device 802 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. The processing device 802 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. The processing device 802 is configured to execute instructions 826 for performing the operations and steps discussed herein. The computer system 800 may further include a network interface device 808 to communicate on a network 820.

[0069] The data storage system 818 may include a machine-readable storage medium 824 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 826 or software embodying any one or more of the methodologies or functions described herein. The instructions 826 may also reside, completely or at least partially, within the main memory 804 and / or within the processing device 802 during execution thereof by the computer system 800, the main memory 804 and the processing device 802 also constituting machine-readable storage media. The machine-readable storage medium 824, the data storage system 818, and / or the main memory 804 may correspond to Figures 1A to 1B Memory subsystem 110.

[0070] In one embodiment, instructions 826 include implementing a command corresponding to an error determination component (e.g., Figure 1B The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions executed by a machine and causing the machine to perform any one or more of the methods of the present disclosure. Thus, the term "machine-readable storage medium" should be considered to include, but not be limited to, solid-state memory, optical media, and magnetic media.

[0071] Some portions of the previous detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively convey the substance of their work to others skilled in the art. An algorithm is herein and generally considered to be a self-consistent sequence of operations that produce a desired result. Operations are those that require physical manipulation of physical quantities. These quantities are typically, but not necessarily, in the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Primarily for reasons of common usage, it has proven convenient at times to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0072] It should be borne in mind, however, that all of these and similar terms should be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may be directed to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0073] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0074] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with the program according to the teachings herein, or it may prove convenient to construct more specialized equipment to perform the method. The structures for various of these systems will be presented as set forth in the description below. In addition, the embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages ​​may be used to implement the teachings of the present disclosure as described herein.

[0075] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a machine (e.g., computer) readable form. In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, etc.

[0076] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments of the present disclosure. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A system comprising: row cache; Memory device; as well as A processing device operatively coupled to the line cache and the memory device, the processing device including a buffer manager and a high-speed mode driver, the operations performed by the processing device including: detecting that one or more received events are in an event list, wherein events stored in the event list are associated with a set of functions known to cause a clock domain crossing between the buffer manager and a host system; enabling access to the line cache; determining one or more functions of the set of functions corresponding to the one or more received events; and Using the overspeed mode driver, operating in overspeed mode to execute the one or more functions from the line cache on behalf of the host system.

2. The system of claim 1, wherein the operations further comprise: setting one or more registers of the processing device to store an indication of a range of code and data stored in the memory device that is available for cache line access; as well as Wherein operating in said high speed mode further comprises: accessing the one or more registers; as well as Code and data identified by the values ​​stored in the one or more registers are extracted from the line cache to be used in the execution of the one or more functions.

3. The system of claim 2, wherein extracting the code and data comprises reading the code and data from the row cache in bursts at a granularity of a cache row partition of the row cache.

4. The system of claim 1, wherein the high-speed mode driver comprises firmware executable by the processing device to operate from the line cache instead of the memory device.

5. The system of claim 1 , wherein the operations further comprise, in response to determining that a total size of the one or more functions is less than or equal to a size of an always-on region of the line cache: preloading the one or more functions into an always-on region of a line cache; and The one or more functions are executed from the always-on region of the line cache. 6 . The system of claim 5 , wherein the operations further comprise disabling access to the line cache in response to detecting an end of execution of the one or more functions.

7. The system of claim 1 , wherein the operations further comprise, in response to determining that a total size of the one or more functions is greater than a size of the always-on region of the line cache: verifying that a function of the one or more functions is not larger than the size of the always-on region of the line cache; evicting any data from a plurality of rows of the always-on region of the row cache to free up enough cache lines to store the function; reading a first number of bytes of each row partition of the function from the memory device into a corresponding row of the plurality of rows; as well as The function is allowed to execute from the line cache after the plurality of lines have been completely loaded by hardware of the line cache.

8. The system of claim 7, wherein the operations further comprise disabling access to the line cache in response to detecting an end of execution of the one or more functions.

9. The system of claim 1, wherein the event list includes two or more of: a plurality of logging events, a clear command, a smart command transfer command, a write uncorrectable command, a download firmware command, and a trim command.

10. The system of claim 1, wherein the one or more functions each comprise one of a drive boot sequence related function, a clear handle function, a smart command transmission function, a write uncorrectable handle function, a firmware image download function, or a trim handle function.

11. A method comprising: detecting that one or more events received by a processing device coupled to a memory device are in an event list, wherein the events stored in the event list are associated with a set of functions known to cause a clock domain crossing between a buffer manager and a host system, the processing device including the buffer manager and a high-speed mode driver; Enable access to the row cache; determining one or more functions of the set of functions corresponding to the one or more received events; as well as Using the overspeed mode driver, operating in overspeed mode to execute the one or more functions from the line cache on behalf of the host system.

12. The method according to claim 11, further comprising: setting one or more registers of the processing device to store an indication of a range of code and data stored in the memory device that is available for cache line access; as well as Wherein operating in said high speed mode further comprises: accessing the one or more registers; as well as Code and data identified by the values ​​stored in the one or more registers are extracted from the line cache to be used in the execution of the one or more functions.

13. The method of claim 12, wherein extracting the code and data comprises reading the code and data from the row cache in bursts at a granularity of a cache row partition of the row cache.

14. The method of claim 11, wherein the high speed mode driver comprises firmware executable by the processing device to operate from the line cache instead of the memory device.

15. The method of claim 11, wherein in response to determining that a total size of the one or more functions is less than or equal to a size of an always-on region of the line cache, the method further comprises: preloading the one or more functions into an always-on region of a line cache; as well as The one or more functions are executed from the always-on region of the line cache.

16. The method of claim 15, wherein in response to detecting an end of execution of the one or more functions, the method further comprises disabling access to the line cache.

17. The method of claim 11, wherein in response to determining that a total size of the one or more functions is greater than a size of the always-on region of the line cache, the method further comprises: verifying that a function of the one or more functions is not larger than the size of the always-on region of the line cache; evicting any data from a plurality of rows of the always-on region of the row cache to free up enough cache lines to store the function; reading a first number of bytes of each row partition of the function from the memory device into a corresponding row of the plurality of rows; as well as The function is allowed to execute from the line cache after the plurality of lines have been completely loaded by hardware of the line cache.

18. The method of claim 17, wherein in response to detecting an end of execution of the one or more functions, the method further comprises disabling access to the line cache.

19. The method of claim 17, wherein the one or more functions each comprise one of a drive boot sequence related function, a clear handle function, a smart command transmission function, a write uncorrectable handle function, a firmware image download function, or a trim handle function.

20. A non-transitory computer-readable storage medium storing instructions that, when executed by a processing device coupled to a memory device and comprising a buffer manager and a high-speed mode driver, cause the processing device to perform operations comprising: detecting that one or more received events are in an event list, wherein events stored in the event list are associated with a set of functions known to cause a clock domain crossing between the buffer manager and a host system; Enable access to the row cache; determining one or more functions of the set of functions corresponding to the one or more received events; as well as Using the overspeed mode driver, operating in overspeed mode to execute the one or more functions from the line cache on behalf of the host system.

Images