Storage device and operating method of storage device
By incorporating a built-in debugging and profiling unit into the memory device, combined with the CXL protocol, the problems of data inconsistency and increased hardware costs in memory devices are solved, achieving efficient data consistency verification and performance optimization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SAMSUNG ELECTRONICS CO LTD
- Filing Date
- 2025-06-06
- Publication Date
- 2026-04-17
AI Technical Summary
In the prior art, memory devices are prone to data inconsistency issues during data storage and retrieval, and existing debugging tools may increase hardware costs and require additional drivers at the host computing device, making data consistency verification a challenge.
By employing the built-in debug and profiling unit of the memory device, debug data is collected at multiple points in the data path, and the debug and profiling engine of the host computing device is used for data consistency verification and performance analysis, avoiding additional hardware costs. The CXL protocol is used to achieve data consistency verification and performance optimization.
It achieves efficient data consistency verification and performance optimization, reduces hardware costs, improves data consistency and performance of storage devices, and simplifies the debugging process.
Smart Images

Figure CN121879664A_ABST
Abstract
Description
[0001] This application claims priority and benefit to U.S. Provisional Application No. 63 / 708,673, filed October 17, 2024, entitled "Compute Express Link (CXL) High Density Memory (HDM) Based Debug / Profiling Mechanism for CXL Memory Device," and U.S. Application No. 19 / 035,124, filed January 23, 2025, the entire contents of which are incorporated herein by reference. Technical Field
[0002] One or more aspects of embodiments of this disclosure relate to storage devices, and more specifically, to debugging and profiling storage devices. Background Technology
[0003] Memory devices can be used to store and retrieve data by one or more applications. Errors can occur during the storage and / or retrieval of data. It is desirable to perform data verification to ensure, for example, that data written to the memory device is the same data read from the memory device.
[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of this disclosure, and therefore may contain information that does not form prior art. Summary of the Invention
[0005] One or more embodiments of this disclosure relate to a storage device comprising: a first memory medium including a first region and a second region; and a processor coupled to the first memory medium, the processor being configured to: receive a first command from an application of a computing device, wherein the first command is associated with first data; identify the occurrence of a trigger condition; identify second data associated with the first data based on the identification of the occurrence of the trigger condition; and store the second data in the first region, wherein the computing device is configured to retrieve the second data from the first region to determine a state associated with the first data.
[0006] According to one embodiment, the first memory medium includes volatile memory.
[0007] According to one embodiment, the second region is configured as a cache memory, and the processor is configured to store the first data in the second region based on a first command.
[0008] According to one embodiment, the triggering condition includes detecting a second command from a computing device, the second command being used to set the storage device to a mode for collecting second data.
[0009] According to one embodiment, the second data is output based on sending the first data to or from the first memory medium.
[0010] According to one embodiment, during the transmission of the first data, the first data is stored in a buffer and retrieved from the buffer, wherein the second data includes the output from the buffer.
[0011] According to one embodiment, the second data includes the output of a second region of the first memory medium.
[0012] According to one embodiment, the process of determining the state of the first data includes: comparing the first data with second data; and identifying the differences between the first data and the second data.
[0013] According to one embodiment, the processor is configured to: identify information about operations performed by the storage device; and store the information in a first region, wherein the computing device is configured to acquire the information to evaluate the performance of the storage device.
[0014] According to one embodiment, the information includes a value indicating the number of times the operation is performed.
[0015] One or more embodiments of this disclosure also relate to a method comprising: receiving a first command from an application of a computing device by a storage device, wherein the first command is associated with first data; identifying the occurrence of a trigger condition by the storage device; identifying second data associated with the first data based on the identification of the occurrence of the trigger condition; and storing the second data in a first region of a first memory medium by the storage device, wherein the computing device is configured to retrieve the second data from the first region to determine a state associated with the first data.
[0016] These and other features, aspects, and advantages of the embodiments of this disclosure will be more fully understood when considered with respect to the following detailed description, the appended claims, and the accompanying drawings. Of course, the actual scope of the invention is defined by the appended claims. Attached Figure Description
[0017] Non-limiting and non-exhaustive embodiments of this example are described with reference to the following figures, wherein, unless otherwise specified, the same reference numerals denote the same parts throughout the figures.
[0018] Figure 1 A block diagram depicts a debugging and profiling system according to one or more embodiments.
[0019] Figure 2 A block diagram depicting a storage controller according to one or more embodiments.
[0020] Figure 3 A conceptual layout diagram depicting a memory node exposed to a host according to one or more embodiments.
[0021] Figure 4 A block diagram depicting various checkpoints that can be inserted into the data flow path through which data can be traversed, according to one or more embodiments.
[0022] Figure 5 A flowchart depicting the debugging process according to one or more embodiments is provided.
[0023] Figure 6 A flowchart is drawn based on one or more embodiments of the analysis process.
[0024] Figure 7 A flowchart depicts the processes performed by the Debug and Profiling (D&P) engine according to one or more embodiments. Detailed Implementation
[0025] In the following description, exemplary embodiments will be illustrated in more detail with reference to the accompanying drawings, in which the same reference numerals consistently denote the same elements. However, this disclosure may be implemented in a variety of different forms and should not be construed as being limited to the embodiments shown herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey to those skilled in the art the aspects and features of this disclosure; therefore, unnecessary treatments, elements, and techniques for a full understanding of the aspects and features of this disclosure by those of ordinary skill in the art are not described. Unless otherwise stated, the same reference numerals denote the same elements throughout the drawings and written description, and therefore their descriptions are not repeated. Furthermore, in the drawings, the relative dimensions of elements, layers, and regions may be enlarged and / or simplified for clarity.
[0026] Embodiments of this disclosure are described below with reference to block diagrams and flowcharts. Therefore, it should be understood that each block of the block diagrams and flowcharts can be implemented as a computer program product, a complete hardware embodiment, a combination of hardware and computer program products, and / or an apparatus, system, computing device, computing entity, etc., that executes instructions, operations, steps, and interchangeable similar terms (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium. For example, code fetching, loading, and execution can be performed sequentially, such that one instruction is fetched, loaded, and executed at a time. In some example embodiments, fetching, loading, and / or execution can be performed in parallel, such that multiple instructions are fetched, loaded, and / or executed together. Therefore, such embodiments can produce machines specifically configured to perform the steps or operations specified in the block diagrams and flowcharts. Thus, the block diagrams and flowcharts support various combinations of embodiments for performing specified instructions, operations, or steps.
[0027] Furthermore, the features of the embodiments of this disclosure may be combined in part or in whole with one or more other features, and may be operated in various ways, and the embodiments may be implemented independently of one or more other embodiments, or in combination with one or more other embodiments.
[0028] Applications can access memory devices to store data to and read data from those devices. Due to errors that can occur during data storage and / or retrieval (e.g., data corruption), stored data may sometimes be inconsistent with the data read (a phenomenon known as data mismatch). For example, a data stream used to store data to a memory device may begin with an application, flow to the kernel level, and from the kernel level to the driver (e.g., firmware) level. The driver may send data to the memory device via a memory interface. Within the memory device, data may be stored in one or more buffers before being finally stored in a memory medium (e.g., flash memory). Similarly, when data is retrieved from a memory medium, it may be stored in one or more buffers, sent via a memory interface, flow from the driver level to the kernel level, and from the kernel level to the application that requested the data. Errors can occur at one or more points along the data path. For example, bit-flipping may occur when data is stored in and / or retrieved from a buffer and / or memory medium. Such errors can lead to a mismatch between the data written by the application and the data retrieved by the application.
[0029] Debugging tools can be used to perform end-to-end data verification (e.g., verification of data from the point when it is generated and sent via the data path to the point when it is read and returned to the application) to check for data consistency issues. Data consistency verification can be a challenging task. For example, data inconsistency can occur as an extreme case (e.g., outside of normal operating parameters). Errors in the storage device can take a significant amount of time before being triggered by an extreme case. It may be necessary to collect a large amount of data using debugging tools until the data associated with the extreme case is captured.
[0030] Furthermore, debugging tools can use custom ports and / or protocols to capture and store data for analysis and / or debugging. The use of custom ports and / or protocols can increase hardware costs. The use of custom ports and / or protocols may also require the addition of a host driver on the host computing device to support the debug port.
[0031] Generally, embodiments of this disclosure relate to systems and methods for debugging and profiling a memory device using a region of a memory medium to collect debug data and profiling data (collectively, debug data). In some embodiments, the memory medium is a host-managed device memory (HDM) mapped to an address space accessible to the host device. A portion of the HDM may be reserved for storing debug data. The remainder of the HDM may be used to store data generated and used by applications on the host device.
[0032] In some embodiments, the memory device includes a debugging or tracing unit (collectively referred to as a debugging unit) and a profiling or performance unit (collectively referred to as a profiling unit). The debugging unit may be configured to collect data at one or more points along a data path that the data can traverse as data is written to / read from the memory medium. The collected data may be stored in a debugging area of the memory device. One or more data path points may be associated with buffers, queues, or other memory devices that may cause errors (e.g., bit flips) in the data when it is stored in or retrieved from the memory device. In some embodiments, the host device uses the debugging data to determine the points in the data stream that cause errors. The host device or developer may take corrective actions based on the determination. Corrective actions may include, for example, optimizing the scheduler or data path based on the profiling results to avoid device performance bottlenecks, modifying / optimizing relevant device modules to address these errors caused by extreme cases, modifying the use of error correction codes, marking a storage area as faulty, allocating a new storage area to a storage pool, etc.
[0033] In some embodiments, the profiling unit is configured to monitor one or more data transactions and increment one or more counters associated with the monitored data transactions. The profiling unit may increment the corresponding counter when a transaction is detected (e.g., the number of times data is written to the memory medium, the number of times data is evicted from the memory medium, the number of times data is merged before being stored in the memory medium, etc.). The counter values may be stored in a debug area. The host device may use the counter values to evaluate the performance of the storage device (e.g., internal hardware stack profiling). Optimization actions may be taken based on the evaluation. Optimization actions may include, for example, optimizing the scheduler or data path based on the profiling results to avoid device performance bottlenecks, identifying device failures, migrating to a new device, etc.
[0034] Figure 1 A block diagram depicts a debugging and profiling system according to one or more embodiments. The system may include a host computing device (“host”) 100, which is coupled to an attached storage memory device (referred to as storage device) 102 via one or more data communication links 104. In some embodiments, the data communication link 104 may include various general-purpose interfaces such as, for example, PCIe, Ethernet, Universal Serial Bus (USB), and / or any wired or wireless data communication link.
[0035] Host 100 may include processor 106, main memory 108, and host interface controller 110. Processor 106 may include one or more central processing unit (CPU) cores configured to run one or more applications (Apps) 114 based on computer program instructions stored in main memory 108. Main memory 108 may include volatile memory (e.g., random access memory (RAM)) and / or non-volatile memory (e.g., read-only memory (ROM)). For example, main memory 108 may include dynamic random access memory (DRAM) for storing computer program instructions and / or data generated by processor 106.
[0036] Application 114 can be any application configured to send commands (e.g., load commands and store commands) to storage device 102. For example, application 114 could be a big data analytics application, an e-commerce application, a database application, a machine learning application, etc. The results of the data commands can be used to generate output.
[0037] In some embodiments, processor 106 further includes a debug and profiling engine (or debug / profiling engine) 116, configured to send commands to put storage device 102 into debug mode. Debug and profiling engine 116 may also be configured to acquire debug data collected by storage device 102. Debug data can be collected via data communication link 104 using the same type of commands used to acquire non-debug data from storage device. In this respect, no additional hardware (e.g., debug port) or software (e.g., driver software) is required to acquire debug data.
[0038] The debugging and profiling engine 116 can evaluate the acquired data for data consistency verification, performance analysis, and / or other debugging and profiling analyses. Debugging and profiling analyses can be used to perform corrective and / or optimization actions. Such actions may include, for example, optimizing the scheduler or data path based on profiling results to avoid device performance bottlenecks, modifying / optimizing relevant device modules to address errors caused by extreme conditions, modifying error correction code usage, marking storage areas as faulty, allocating new storage areas to storage pools, etc.
[0039] The host interface controller 110 may include physical connections and software instructions executable by the processor 106. In some embodiments, the host interface controller 110 allows the host 100 and the storage device 102 to send and receive data using protocols such as NVMe, CXL, Cache Coherent Interconnect for Accelerators (CCIX), Dual In-line Memory Module (DIMM) interface, Small Computer System Interface (SCSI), Non-Volatile Memory Fast (NVMe), Peripheral Component Interconnect Fast (PCIe), Remote Direct Memory Access over Ethernet (RDMA), Serial Advanced Technology Attachment (SATA), Fibre Channel, Serial Attached SCSI (SAS), NVMe over Fabric (NVMe-oF), iWARP protocol, InfiniBand protocol, 5G wireless protocol, Wi-Fi protocol, Bluetooth protocol, etc.
[0040] In some embodiments, the host interface controller 110 is configured to receive data commands from the debugging and profiling engine 116 and forward the commands to the storage device 102. Commands may include commands for loading / reading data from the storage device 102, and commands for storing / writing data to the storage device. Commands may be generated in response to instructions executed by the application 114 that uses the data.
[0041] In some embodiments, the host interface controller 110 is configured to receive a load command from the debug and profiling engine 116. The load command may be sent to the storage device 102 to retrieve debug data collected by the storage device.
[0042] Storage device 102 may take the form of a solid-state drive (SSD), persistent storage, etc. In some embodiments, storage device 102 includes (or is implemented as) an SSD with cache coherency and / or computing power.
[0043] In some embodiments, storage device 102 includes storage controller 120, storage memory 122, and non-volatile memory (NVM) 124. Storage memory 122 and NVM 124 may be configured as host-managed device memory (HDM). In this respect, at least a portion of NVM 124 and storage memory 122 may be mapped to a coherent address space and be accessible to host 100 via load and store commands.
[0044] Storage memory 122 may be a high-performance memory of storage device 102 and may include (or may be) volatile memory (e.g., such as DRAM), but this disclosure is not limited thereto, and storage memory 122 may be any suitable type of high-performance volatile memory or non-volatile memory. Although a single storage memory 122 is depicted for the sake of brevity, those skilled in the art will recognize that storage device 102 may include additional local memory for temporarily storing other data for storage device use.
[0045] In some embodiments, the storage memory 122 is configured to have two or more memory regions. In some embodiments, the storage memory 122 includes a debug region 122a and a data cache region 122b. The debug region 122a may have a first capacity and a first base address, the first base address being exposed to the host 100 to retrieve debug data from the region. The host 100 may access the debug region 122a using, for example, a load command conforming to the CXL protocol. In some embodiments, although the host 100 can access the debug region 122a to retrieve debug data from the region, the host may not store or write the data to the region.
[0046] Data cache region 122b may have a second capacity and a second base address. In some embodiments, data cache region 122b is not exposed to the host. Data cache region 122b is internally used as a cache memory by storage device 102. In this respect, cache region 122b may store a copy of the data stored in NVM 124. For example, data requested by application 114 via a load command may be copied from NVM 124 to cache region 122b (if it does not already exist) to allow data to be retrieved from cache region 122b (instead of NVM 124).
[0047] although Figure 1 The embodiments described herein depict storage memory 122 as having two regions; however, those skilled in the art will recognize that storage memory 122 may be constructed to have more than two regions. For example, storage memory 122 may have a region for storing debug data, a separate region for storing profiling data, and another region for storing cached data. Configuration information for each region may be provided to host 100 via one or more registers. Registers may store the size and base address of the corresponding region. Regions may be mapped to the system address space and accessed by the host via interface controller 110.
[0048] NVM 124 may store, for example, data received from host 100. NVM 124 may include, for example, NAND flash memory, but this disclosure is not limited thereto, and NVM 124 may include any suitable type of memory (e.g., disk, magnetic tape, optical disc, etc.) for storing data (persistently or non-persistently) depending on the implementation of storage device 102. In some embodiments, the capacity of NVM 124 is greater than the capacity of storage memory 122. In this respect, (e.g., because of the use of NVM 124 to expand the size of memory) storage device 102 may be referred to as a "memory expander" or "memory expansion device".
[0049] Storage controller 120 can be connected to NVM 124 and storage memory 122 via one or more storage interfaces. Storage controller 120 can receive data commands from host 100 and send commands to NVM 124 and / or storage memory 122, and receive commands from NVM 124 and / or storage memory 122 to complete the commands. In this regard, storage controller 120 may include at least one processing component embedded thereon for interfacing with host 100, storage memory 122 and NVM 124. The processing component may include, for example, digital circuitry (e.g., microcontroller, microprocessor, digital signal processor or logic device (e.g., field-programmable gate array (FPGA), application-specific integrated circuit (ASIC) etc.)) capable of executing data access instructions to provide access to data (debug data and non-debug data) stored in storage memory 122 or NVM 124 according to the data access instructions.
[0050] In some embodiments, the storage controller 120 receives a command to set the storage device 102 to debug mode. Debug mode allows the storage controller 120 to collect debug data into debug region 122a while executing data access instructions sent by the host 100. Debug data may be collected at one or more checkpoints. Checkpoints may be located at one or more locations along a data flow path traversed by data loaded or stored by the storage device based on data access instructions. Checkpoints may be selected as points in the data flow where errors may occur in the data.
[0051] Figure 2 A block diagram depicts a storage controller 120 according to one or more embodiments. In some embodiments, the storage controller 120 includes a device interface controller (or interface controller) 200 configured to receive commands from a host 100, for example, via a host interface controller 110. In this regard, the device interface controller 200 may include physical connections for sending data to and receiving data from the host 100 using protocols such as, for example, CXL, as well as software instructions, but embodiments are not limited thereto.
[0052] In some embodiments, interface controller 200 receives a data command for loading data from / storing data to a specified memory address. The command may be received by cache controller 202. Cache controller 202 may be configured to examine the address in the received command to determine if the requested memory address is located in debug region 122a. In some embodiments, debug region 122a is configured and exposed to the host as HDM 208 (e.g., HDM 1) having a first address space. Host 100 may be configured to load data from first HDM 208, but may not be configured to write data to first HDM 208.
[0053] If the received memory address (or range of memory addresses) is in debug region 122a, cache controller 202 sends a request to volatile memory (VM) manager 204 (referred to as memory manager or VM manager). Memory manager 204 then retrieves the requested debug data from debug region 122a and returns the data to debug and profiling engine 116.
[0054] If the cache controller 202 determines that the address in the received command is not in debug region 122a, the command is processed as a data access command sent based on the execution of application 114. In this regard, the cache controller 202 may determine whether the requested memory address is found in data cache region 122b (e.g., cache hit), and based on the determination, initiate an appropriate request to memory manager 204 or NVM manager 206. The requested memory address may be obtained from data cache region 122b or NVM 124 via memory manager 204 or NVM manager 206, respectively, and returned to the requesting application 114. In some embodiments, NVM 124 is configured and exposed to host 100 as a second HDM 210 (e.g., HDM 0) having a second address space. Host 100 may be configured to write data to and read data from the second HDM 210 during the execution of application 114.
[0055] In some embodiments, the storage controller 120 includes a debugging unit 212, a profiling unit 214, and a data pattern generator 216. The debugging unit 212 can be configured to receive a command from the debugging / profiling engine 116 to set the storage device 120 to debug mode. In response to the command, the debugging unit 212 can monitor the data flow as a load command or store command for data is processed.
[0056] For example, for a data storage command, the debug unit 212 can monitor the data received by the interface controller 200 from the host 100, and monitor the data as it flows through the cache controller 202, the VM manager 204, and into the data cache area 122b and the NVM 124. For a data load command, the debug unit 212 can monitor the data acquired from the data cache area 122b or the NVM 124, and monitor the data as it flows through the VM manager 204 or the NVM manager 206, to the cache controller 202, and to the interface controller 200.
[0057] In some embodiments, as data flows through a data path, data may be written to and read from one or more buffers. Buffers may be included in the storage controller 120 and may provide temporary storage for different types of data as load or store commands are processed. Errors may occur when different data is written to / read from buffers. Debugging unit 212 may be configured to capture data written to / read from buffers, written to / read from data cache area 122b, and / or written to / read from NVM 124 into debugging area 122a. In some embodiments, debugging unit 212 uses a sliding window to store data in debugging area 122a. In this respect, when the debugging area becomes full, the sliding window pushes out older data in debugging area 122a to make room for new debugging data.
[0058] In some embodiments, the profiling unit 214 is configured to collect profiling data for the storage device 102. In this regard, the profiling unit 214 may monitor transactions and / or resources of the storage device 102 and increment one or more counters associated with the monitored transactions or resources. For example, the profiling unit 214 may maintain one or more performance counters for monitoring the number of times data is written to a storage medium (e.g., memory 122 and / or NVM 124), the number of times data is evicted from the data cache area 122b, the number of times data is merged before being stored in the data cache area 122b, and / or other types of transactions configured to be monitored by the profiling unit 214.
[0059] In some embodiments, the profiling unit 214 also monitors incomplete items in queues (e.g., DRAM cache write / read request queues, NAND read / write request queues, CXL read / write queues, etc.) via associated counters. In some embodiments, the profiling unit collects other types of profiling data (e.g., latency of incomplete items (e.g., using one or more timers), round-trip latency of a single request in the queue, and average latency of a request in the queue, etc.).
[0060] The profiling unit 214 may store profiling data in the debug area 122a. In some embodiments, the profiling unit 214 tracks and collects profiling data when a monitored transaction is detected, and stores the profiling data in the debug area 122a periodically (regularly or irregularly). In some embodiments, the debug and profiling engine 116 obtains profiling data from the debug area 122a to evaluate storage device performance. For example, the level and timing of usage of different resources of the storage device 102 (e.g., buffers, caches, memory, etc.) may be determined, and optimization actions may be taken to help improve the performance of the storage device (e.g., bandwidth, throughput, etc.).
[0061] In some embodiments, the data pattern generator 216 may generate a data pattern (e.g., data matching the data address of a data subject to a load command or store command) and provide the data pattern to the debugging unit 212. In some embodiments, the debugging unit 212 is configured to compare data captured at checkpoints along the data flow path with the data pattern provided by the data pattern generator 216 to perform a data consistency assessment (e.g., determine if a data mismatch exists). The debugging unit 212 may be configured to store the captured data in the debugging area 122a based on the detected mismatch.
[0062] In embodiments that do not include the data pattern generator 216, the debugging unit 212 stores data when data is captured at one or more checkpoints, and may not perform a data consistency assessment before the data is stored.
[0063] Although the hypothesis Figure 2 One or more components are individual components, but those skilled in the art will recognize that, without departing from the spirit and scope of the inventive concept, the functions of the components may be combined or integrated into a single component, or further divided into further sub-components.
[0064] Figure 3 A conceptual layout diagram depicts memory nodes exposed to host 100 according to one or more embodiments. In some embodiments, the host's main memory 108 includes two DRAM nodes identified as node 0 300 and node 1 302, which are mapped to a first address space and a second address space, respectively. The capabilities of the host's main memory 108 may be extended via node 2 304, which may be implemented via NVM 124. Node 2 304 may be configured and exposed to host 100 as an HDM (e.g., HDM 210) mapped to a third address space. Node 2 304 may be accessible via, for example, the cxl.mem protocol for storing and loading data.
[0065] In some embodiments, debug region 122a is configured as a soft-reserved memory region and exposed to host 100 as a second HDM (e.g., HDM 208) mapped to a fourth address space. In some embodiments, the host is configured to read debug data from debug region 122a. However, debug region 122a may not be used by host 100 to write data.
[0066] Figure 4 A block diagram depicts various checkpoints that can be inserted into the data flow path through which data can be traversed, according to one or more embodiments. For example, a data storage command for storing host data may be received by interface controller 200 and provided to cache controller 202 to determine whether the host data is located in data cache area 122b (e.g., cache hit). The address associated with the host data may be stored in address buffer 400 until the host data is ready to be processed for storage (e.g., stored in data cache area 122b).
[0067] In the event of a cache miss, the content of the requested data address can be retrieved from NVM 124 and stored in the first temporary buffer. The host data to be stored can be identified based on the address in address buffer 400 and stored in the second temporary buffer. Before storing the merged data in data cache area 122b, the contents of the first and second temporary buffers can be merged and stored in a third temporary buffer.
[0068] Errors can occur when data is stored in and retrieved from the first, second, and / or third temporary buffers. For example, when data is retrieved from the second temporary buffer and merged with the contents of the first temporary buffer, the host data to be stored may experience bit flips or other data corruption. In other examples, data errors can occur when host data is merged with data in the second temporary buffer, and / or when the merged data is retrieved from the third temporary buffer. Errors can also occur when data is written to temporary buffers, but (e.g., when the write operation is faster than the read operation) new data is written before the old data can be read, causing a data mismatch. In other examples, (e.g., due to data corruption and other types of errors) data written to data cache area 122b or NVM 124 may differ from data retrieved from these memory media, causing a data mismatch.
[0069] In some embodiments, checkpoints (such as write-to merged data mismatch detector 404) are inserted in the data path traversing the first temporary buffer, the second temporary buffer, and / or the third temporary buffer to determine whether a data mismatch has occurred and / or to collect data from one or more corresponding buffer outputs for debugging by host 100. In this regard, patterns of host data, data obtained from NVM 124, and / or merged data to be stored can be generated by data pattern generator 216 and compared with the outputs of the first temporary buffer, the second temporary buffer, and / or the third temporary buffer to determine a data mismatch. The outputs of the first temporary buffer, the second temporary buffer, and / or the third temporary buffer can be provided to the tracker module 406 of debug unit 212 and stored in debug area 122a when a data mismatch is determined.
[0070] In some embodiments, the write merge mismatch detector 404 provides write merge mismatch flags and location information to the tracker module 406 for storage in the debug region 122a (e.g., in the address space associated with the first HDM 208). The location information may identify where data is collected in the data path (e.g., checkpoint or buffer location).
[0071] In one embodiment where storage device 102 does not include data pattern generator 216, write-merge data mismatch detector 404 may simply collect data output from the first temporary buffer, second temporary buffer, and / or third temporary buffer, and provide the collected data to tracker module 406 without performing mismatch determination. Alternatively, mismatch determination may be performed by debugging and profiling engine 116.
[0072] If a cache hit occurs and the address of the host data to be stored is found in the data cache area, the VM manager 204 can write the host data to the identified cache address. However, in some cases, the cache address provided by the VM manager 204 may be incorrect. Therefore, in some embodiments, checkpoints (such as write hit mismatch detector 408) can be inserted during the traversal of the VM manager 204's data path to determine whether the identified cache address is correct and / or to write the cache address identified by the VM manager 204 to the debug area 122a. In the case of a mismatch determination (e.g., by comparing the generated data pattern with the cache address generated by the VM manager 204), a write hit mismatch flag and location information can be provided to the tracker module 406 for storage in the debug area 122a.
[0073] In some embodiments, the interface controller 200 receives a data load command for loading data from data cache region 122b (e.g., for a cache hit) or NVM 124 (e.g., for a cache miss). The storage controller 120's data response module 410 can be configured to provide the requested data to the host 100. However, in some cases, the data retrieved based on the identified address may differ from data previously written to that address, resulting in a data mismatch.
[0074] In some embodiments, checkpoints (such as read data mismatch detector 412) are inserted into the data path of the traversing data response module 410 to determine whether a data mismatch has occurred, and / or to write the acquired data and its address to the debug area 122a. In the event of a mismatch determination (e.g., by comparing the acquired data with previously written data), a read mismatch flag and location information may be provided to the tracker module 406 for storage in the debug area 122a. In some embodiments (e.g., in embodiments excluding a data pattern generator), debug data is stored in the debug area 122a without first performing a mismatch determination.
[0075] In some embodiments, cache controller 202 may send signals to performance counter module 402 (e.g., within profiling unit 214) to increment one or more counters based on received commands. For example, performance counter module 402 may increment a write counter based on a store command, increment a read counter based on a load command, and so on. Counter information may be provided to tracker module 406 for storage in debug area 122a. Debugging and profiling engine 116 may be configured to analyze counter values to evaluate the performance of storage device 102.
[0076] Figure 5 A flowchart depicts a debugging process according to one or more embodiments. The process begins, and in action 500, the storage controller 120 receives a first command associated with first data. The first command may be a data load command or a storage command sent by a computing device (e.g., host 100) based on running an application.
[0077] In action 502, the storage controller 120 determines whether a trigger condition has been identified. The trigger condition may be identified, for example, based on (e.g., by the debug and profiling engine 116) a command from the host 100 to set the storage device 102 to debug mode. In some embodiments, the trigger condition is identified based on a checkpoint detected in the data path of the first data when data is sent to or from the first memory medium (e.g., data cache area 122b or NVM 124).
[0078] If a trigger condition has been identified, in action 504, the storage controller 120 (e.g., debug unit 212) identifies second data (e.g., debug data) associated with the first data. The second data may be data captured at a checkpoint. For example, the second data may be the output of one or more buffers in the data path as the first data enters and exits the buffer while traversing the data path. In another example, the second data may be the output of a second region of the first memory medium (e.g., data cache region 122b).
[0079] In action 506, the storage controller 120 stores the second data in a first region of the first memory medium (e.g., debug region 122a). A computing device (e.g., debug and profiling engine 116) can retrieve the second data from the first region to determine attributes or states associated with the first data (e.g., data consistency). In some embodiments, determining the attribute or state includes comparing the first data with the second data and identifying differences (e.g., mismatches) between the first data and the second data.
[0080] Figure 6 A flowchart depicts a profiling process according to one or more embodiments. The process begins, and in action 600, the storage controller 120 (e.g., profiling unit 214) identifies the transaction or operation that profiling unit 214 is configured to monitor. In this regard, commands received by the interface controller 200 (such as, for example, data storage and load commands) are sent to profiling unit 214. Information on other operations (such as, for example, operations performed by cache controller 202) may also be sent to profiling unit 214. Such operations may include, for example, data eviction operations, data merging operations, data caching operations, etc.
[0081] In action 602, the profiling unit 214 determines whether a counter or other measurement tool (e.g., a timer) is configured for the identified transaction or operation.
[0082] If the answer is yes, then in action 604, the profiling unit 214 updates the associated counter or measurement tool. For example, the write counter may be incremented when a write command is detected, and the eviction counter may be incremented when an eviction command is detected, etc.
[0083] In action 606, it is determined whether the collected counter value should be stored in debug area 122a. In this regard, the storage of the counter value can occur periodically at regular or irregular intervals.
[0084] If the answer is yes, then in action 608, one or more counter values are stored in debug area 122a.
[0085] Figure 7 A flowchart depicts a process performed by a debug and profiling (D&P) engine 116 according to one or more embodiments. The process begins, and in action 700, the D&P engine 116 sends a debug command to storage device 102 to put storage device 102 into debug mode. The debug command may be sent based on detected triggering conditions, such as, for example, based on the detection of a threshold number of data consistency errors, the detection of reduced performance of the storage device (e.g., access time exceeding a maximum threshold), etc.
[0086] In action 702, the D&P engine 116 acquires debug and profiling data stored in debug region 122a. In this respect, the D&P engine 116 accesses one or more memory addresses mapped to debug region 122a. Access can be made via a data load command. In this respect, no additional hardware or software drivers are required to acquire debug data. The same type of command used to acquire non-debug data from NVM 124 (e.g., the CXL load command) can be used to acquire debug data from debug region 122a.
[0087] In action 704, the D&P engine analyzes the acquired debug data to perform debug or profiling operations. Debugging operations may include comparing expected data with data recorded in debug area 122a to determine if there is a data mismatch. Profiling operations may include evaluating storage device performance based on acquired counter values. Performance evaluation may include, for example, determining storage device latency, throughput, cache hit rate, etc.
[0088] In action 706, corrective actions are taken based on the detected data mismatch during the debugging operation. For example, the location where the mismatched data was generated (e.g., a buffer or checkpoint on the data path) can be identified, and the faulty module can be identified and modified / corrected. For the profiling operation, actions that can be taken may include optimization actions to improve the performance of the storage device 102.
[0089] As those skilled in the art will understand, embodiments of this disclosure allow for the collection and analysis of debug data without dedicated hardware (e.g., debug ports) or associated software (e.g., driver software) or protocols. Host 100 can access data collected by the storage device in the HDM debug address region as it would access any other data. In some embodiments, for further analysis and debugging, the host can access debug data via a CXL load command. For performance analysis and optimization, profiling data can similarly be stored in the debug address region and accessed by host 100.
[0090] One or more embodiments of this disclosure may be implemented in one or more processors. The term processor may refer to one or more processors and / or one or more processing cores. One or more processors may reside in a single device or be distributed across multiple devices (e.g., on a cloud system). Processors may include, for example, application-specific integrated circuits (ASICs), general-purpose or special-purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices (such as field-programmable gate arrays (FPGAs)). In a processor, as used herein, each function is performed by hardware configured (i.e., hardwired) to perform that function, or by more general-purpose hardware (e.g., a CPU) configured to execute instructions stored in a non-transitory storage medium (e.g., memory). Processors may be fabricated on a single printed circuit board (PCB) or distributed across several interconnected PCBs. Processors may include other processing circuitry; for example, the processing circuitry may include two processing circuits (FPGA and CPU) interconnected on the PCB.
[0091] It will be understood that although the terms “first,” “second,” “third,” etc., may be used herein to describe various elements, components, regions, layers, and / or portions, these elements, components, regions, layers, and / or portions should not be limited by these terms. These terms are used only to distinguish one element, one component, one region, one layer, or one portion from another element, another component, another region, another layer, or another portion. Therefore, without departing from the spirit and scope of the inventive concept, the first element, first component, first region, first layer, or first portion discussed herein may be referred to as a second element, second component, second region, second layer, or second portion.
[0092] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. Furthermore, unless explicitly stated otherwise, the embodiments described herein are not mutually exclusive. In some implementations, aspects of the embodiments described herein may be combined.
[0093] As used herein, the terms “basic,” “approximately,” and similar terms are used as approximate terms rather than terms of degree, and are intended to take into account the inherent biases of measurements or calculations that will be recognized by one of ordinary skill in the art.
[0094] As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. It will also be understood that, when used herein, the terms “comprising” and / or “including” specify the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items. When a statement such as “at least one of…” follows a list of elements, it modifies the entire list without modifying individual elements within the list. Furthermore, when describing embodiments of the inventive concept, the use of “may” indicates “one or more embodiments of this disclosure.” Additionally, the term “exemplary” is intended to mean an example or illustration. As used herein, the term “use” may be considered synonymous with the term “utilize.”
[0095] Although exemplary embodiments of systems and methods for debugging and profiling memory devices have been specifically described and illustrated herein, many modifications and variations will be apparent to those skilled in the art. Therefore, it will be understood that systems and methods for debugging and profiling memory devices constructed in accordance with the principles of this disclosure may be implemented in ways different from those specifically described herein. The disclosure is further defined in the appended claims and their equivalents.
[0096] Systems and methods for debugging and profiling storage devices may include one or more combinations of the features set forth in the following statements.
[0097] Statement 1. A storage device comprising: a first memory medium including a first region and a second region; and a processor coupled to the first memory medium, the processor being configured to: receive a first command from an application of a computing device, wherein the first command is associated with the first data; identify the occurrence of the trigger condition; identify the second data associated with the first data based on the identification of the occurrence of the trigger condition; and store the second data in the first region, wherein the computing device is configured to retrieve the second data from the first region to determine a state associated with the first data.
[0098] Statement 2. The storage device according to Statement 1, wherein the first memory medium includes volatile memory.
[0099] Statement 3. The storage device according to Statement 2, wherein the second region is configured as a cache memory, and the processor is configured to store the first data in the second region based on a first command.
[0100] Statement 4. The storage device according to Statement 1, wherein the triggering condition includes detecting a second command from a computing device, the second command being used to set the storage device to a mode for collecting second data.
[0101] Statement 5. The storage device according to Statement 1, wherein the second data is output based on sending the first data to or from the first memory medium.
[0102] Statement 6. The storage device according to Statement 5, wherein during the transmission of the first data, the first data is stored in a buffer and retrieved from the buffer, wherein the second data includes the output from the buffer.
[0103] Statement 7. The storage device according to Statement 5, wherein the second data includes the output of a second region of the first memory medium.
[0104] Statement 8. The storage device according to Statement 1, wherein the process of determining the state of the first data includes: comparing the first data with second data; and identifying the difference between the first data and the second data.
[0105] Statement 9. The storage device according to Statement 1, wherein the processor is configured to: identify information about operations performed by the storage device; and store the information in a first region, wherein the computing device is configured to acquire the information to evaluate the performance of the storage device.
[0106] Statement 10. The storage device according to Statement 9, wherein the information includes a value indicating the number of times the operation is performed.
[0107] Statement 11. A method comprising: receiving a first command from an application of a computing device by a storage device, wherein the first command is associated with first data; identifying the occurrence of the trigger condition by the storage device; identifying second data associated with the first data based on the identification of the occurrence of the trigger condition; and storing the second data by the storage device in a first region of a first memory medium, wherein the computing device is configured to retrieve the second data from the first region to determine a state associated with the first data.
[0108] Statement 12: The method according to Statement 11, wherein the first memory medium includes volatile memory.
[0109] Statement 13. The method according to Statement 12, wherein a second region of the first memory medium is configured as a cache memory, and the method further includes: storing the first data in the second region based on a first command.
[0110] Statement 14. The method according to Statement 11, wherein the triggering condition includes detecting a second command from a computing device, the second command being used to set the mode of the storage device to collect second data.
[0111] Statement 15, according to the method of statement 11, wherein the second data is output based on sending the first data to or from the first memory medium.
[0112] Statement 16, the method according to Statement 15, wherein during the transmission of the first data, the first data is stored in a buffer and retrieved from the buffer, wherein the second data includes output from the buffer.
[0113] Statement 17. The method according to Statement 15, wherein the second data includes the output of a second region of the first memory medium.
[0114] Statement 18. According to the method of Statement 11, the step of determining the state associated with the first data includes: comparing the first data with the second data; and identifying the difference between the first data and the second data.
[0115] Statement 19. The method according to Statement 11 further includes: identifying information about operations performed by the storage device; and storing the information in a first region, wherein the computing device is configured to acquire the information to evaluate the performance of the storage device.
[0116] Statement 20: The method according to Statement 19, wherein the information includes a value indicating the number of times the operation is performed.
Claims
1. A storage device, comprising: The first memory medium includes a first region and a second region; as well as The processor, combined with the first memory medium, is configured as follows: Receive a first command from an application of a computing device, wherein the first command is associated with first data; Identify the occurrence of triggering conditions; Based on the detection of the triggering condition, second data associated with the first data is identified; and The second data is stored in the first area, wherein the computing device is configured to retrieve the second data from the first area to determine the state associated with the first data.
2. The storage device according to claim 1, wherein, The first memory medium includes volatile memory.
3. The storage device according to claim 2, wherein, The second region is configured as a cache memory, and the processor is configured to store the first data in the second region based on the first command.
4. The storage device according to claim 1, wherein, The triggering condition includes detecting a second command from the computing device, which sets the storage device to a mode for collecting second data.
5. The storage device according to claim 1, wherein, The second data is output based on sending the first data to or from the first memory medium.
6. The storage device according to claim 5, wherein, During the transmission of the first data, the first data is stored in a buffer and retrieved from the buffer, wherein the second data includes the output from the buffer.
7. The storage device according to claim 5, wherein, The second data includes the output of the second region of the first memory medium.
8. The storage device according to claim 1, wherein, The process of determining the state of the first data includes: Compare the first data with the second data; and Identify the differences between the first and second data.
9. The storage device according to any one of claims 1 to 8, wherein, The processor is configured as follows: Identify information about the operations performed by the storage device; and The information is stored in a first region, wherein a computing device is configured to acquire the information to evaluate the performance of the storage device.
10. The storage device according to claim 9, wherein, The information includes a value indicating the number of times the operation was performed.
11. A method of operating a storage device, comprising: The storage device receives a first command from an application of the computing device, wherein the first command is associated with first data; The occurrence of the triggering condition is identified by the storage device; Based on the detection of the trigger condition, the storage device identifies second data associated with the first data; and The second data is stored by a storage device in a first area of a first memory medium, wherein a computing device is configured to retrieve the second data from the first area to determine a state associated with the first data.
12. The operating method according to claim 11, wherein, The first memory medium includes volatile memory.
13. The operating method according to claim 12, wherein, The second region of the first memory medium is configured as a cache memory, and the method further includes: The first data is stored in the second area based on the first command.
14. The operating method according to claim 11, wherein, The triggering conditions include detecting a second command from the computing device, which sets the storage device to a mode for collecting second data.
15. The operating method according to claim 11, wherein, The second data is output based on sending the first data to or from the first memory medium.
16. The operating method according to claim 15, wherein, During the transmission of the first data, the first data is stored in a buffer and retrieved from the buffer, wherein the second data includes the output from the buffer.
17. The operating method according to claim 15, wherein, The second data includes the output of the second region of the first memory medium.
18. The operating method according to claim 11, wherein, The steps for determining the state associated with the first data include: Compare the first data with the second data; and Identify the differences between the first and second data.
19. The operating method according to any one of claims 11 to 18, further comprising: Identify information about operations performed by the storage device; as well as The information is stored in a first region, wherein a computing device is configured to acquire the information to evaluate the performance of the storage device.
20. The operating method according to claim 19, wherein, The information includes a value indicating the number of times the operation is performed.