Memory system background operations can also include updating or maintaining a logical-to-physical tracking database. For example, the memory system 110 also tracks physical memory locations of logical addresses (e.g., using a tracking database). The tracking database relates physical memory locations at the memory device 112 to logical addresses, for example, referenced by the host device. Background operations can also include updating and/or maintaining this tracking database.

As described herein, at least some portion of the background operations for the memory system 110 may be deferred until a time when the electronic device is not dependent on battery power. In some implementations this can be achieved without modifying an industry standard physical interface, such as a UFS or eMMC-compliant physical interface. For example, a memory device 112 of the memory system 110 (e.g., a UFS device) can further include a unidirectional reset interface (RST) 116, such as a hardware reset signal interface from the host device 105 to the memory system 110. The memory controller 111 can receive instructions from the host device 105, and can communicate with the non-volatile memory device 112, such as to transfer data to (e.g., write or erase) or from (e.g., read) one or more of the memory cells of the non-volatile memory device 112. The memory controller 111 can include, among other things, circuitry or firmware, such as a number of components or integrated circuits. The memory controller 111 can include a processor 120 responsive to instructions retained in the memory system 110 which, when executed by the processor 120, cause the processor 120 to perform operations correlated to the instructions. The operations can include operations of a pulse pattern detector 118 described below.

FIG. 2 shows an example electronic device 200 including a host 205 and a memory system 210 and showing signals between the host 205 and the memory system 210. The host 205 and memory system 210 can be implemented similarly to a host device 105 and memory system 110, respectively, of FIG. 1. The signals shown are a reset signal, RST (which can be similar to RST 116 (FIG. 1)), a reference clock, REF_CLK, a data-in signal, DIN_t/c, and a data-out signal, DOUT_t/c, though other signals are conveyed between the host 205 and the memory system 210 in operation of a system comprising such apparatus. The RST signal can be an active low signal, designated RST_n, with activation on a negative. RST_n can be defined as active based on UFS standards. For example, in the UFS specification, RST_n is defined as active by keeping the reset signal pulled down greater than 1 μS and then holding the reset signal pulled high for a length greater than 1 μS. A pulse width for a reset signal can also be defined by specification. The D_INand D_OUTsignals can be true/complement signals meaning that they are differential signals. Due to a user board layout limitation, it may be difficult to define a new hardware pin dedicated for the battery charging notification. Therefore, in some embodiments, an existing pin of the memory system 210 (e.g., the reset pin 119 (FIG. 1)) can be shared by a battery charging notification and a function (e.g., a reset function) assigned to the existing pin.

Referring again to FIG. 1, the memory controller 111 can include a pulse pattern detector 118 coupled to a pin (e.g., the reset pin 119). Some operations of the pulse pattern detector 118 can be implemented in software, hardware, firmware, or a combination thereof. While embodiments are described herein with respect to signals at reset pin 119, embodiments are not limited thereto, and the signal can occur at other pins already part of the memory system 110 or at a new pin added to the memory system 110 for implementation of operations described herein.

The pulse pattern detector 118 can include filtering circuitry and timing circuitry to aid in detection of parameters of a pulse (e.g., timing parameters, pulse width, rising and falling edges, etc.). These and other parameters can help the pulse pattern detector 118 distinguish the received pulse signal from, for example, a standard reset signal, which can have timing parameters set by UFS specifications. For example, a reset signal according to UFS specifications may have a defined pulse width. The pulse pattern detector 118 can determine whether a pulse signal received by a designated pin or pins, in the present example the UFS-specified reset pin 119, conforms to a predetermined pulse pattern (e.g., a first pulse pattern).

The predetermined pulse pattern can contain, for example, eight (8) pulses, although embodiments are not limited thereto. Herein, a pulse has an amplitude greater than a preset value, so as to be distinguishable from noise at the reset pin 119. If the pulse signal conforms to a predetermined pulse pattern, this can indicate that the electronic device 100 is in a battery charging state and that background operations can be performed. Other pulse patterns can be used to signify different states; for example, a second pulse pattern can indicate a timeout error (e.g., indication that the electronic device 100 is in an unknown or “stuck” state).

FIG. 3 is a flowchart showing one example of a process flow 300 for performing memory system 110 background operations. Systems, apparatuses and methods according to these and other embodiments can reduce negative effects on electronic device 100 performance and battery levels by executing background operations while the electronic device 100 battery is being charged. Example process flow 300 can be performed by elements of a memory system 110 (FIG. 1), such as memory controller 111, pulse pattern detector 118, processor 120, etc.

At operation 302, the memory system 110 receives (e.g., from a host device 105 over, e.g., interface 116) a pulse signal at a pin (e.g., reset pin 119). As discussed above, in many examples, the pulse signals will be provided through one or more pins and associated paths between the host and memory system that are used for other command/control signals (in the present example the reset pin for signal RST_n, in the current UFS standard, as identified earlier herein). The host device 105 may be configured to automatically generate the pulse signal, when the host device 105 is receiving power from an external source (as opposed to from the system battery).

At operation 304, the pulse pattern detector 118 of the memory controller 111, coupled to the reset pin 119, determines whether the pulse signal conforms to a first pulse pattern corresponding to a “battery charging” pulse pattern. Predetermined pulse patterns can include not only a “battery charging” pulse pattern, but other indications useful for regulating memory operations, such as second pattern to indicate a low battery state, etc. In some examples, the pulse pattern may indicate a time period during which the memory system 110 is permitted to perform background operations. As described earlier herein, the pulse pattern detector 118 can use filtering circuitry and timing circuitry to aid in detection of pulse parameters (such as amplitude, to filter noise; and timing parameters such as pulse width, rising and falling edges, etc.). Detection of such pulse parameters can help the pulse pattern detector 118 distinguish the received pulse signal from a reset signal, for example, or from another of multiple pulse patterns representative of selected states. At operation 306, the memory controller 111 initiates execution of a memory system 110 background operation responsive to determining that the pulse signal conforms to a first pulse pattern. In examples, the first pulse pattern can indicate “battery charging.”

If the pulse signal does not conform to the first pulse pattern (or any other predetermined pulse pattern), the pulse signal may be a standard reset signal or other signal. In such cases, the example process flow 300 can include performing a reset or waiting for a next pulse signal, among other possible operations.

In some examples, the memory system 110 executes background operations upon receiving permission data 122 from the host device 105 via the interface 115. For example, the permission data 122 can take the form of a command, message, or other UFS-compliant communication. FIG. 4 is a flowchart showing one example of a process flow 400 that may be executed by a memory system, such as the memory system 110, to perform background operations. The process flow 400 may be based, for example, on a permission message received by the memory system 110 from the host device 105.

At operation 402, the memory system 110 determines background operations to be performed. The background operations may include, for example, GC operation, SLC cache management, cell refresh operations, updating a tracking database, and so on. For example, the memory controller 111 may track the state of the various memory devices 112 at the memory system 110 to determine when various background operations are needed. For example, the memory controller 111 may determine that GC operations are to be performed when the percentage of stale data at a page exceeds a threshold and/or when the percentage of pages including stale data exceeds a threshold. The memory controller 111 may determine that SLC cache management is to be performed, for example, if the SLC cache of the memory system 110 (and/or any memory devices 112 thereof) is filled or nearly filled.

At operation 404, the memory system 110 sends an indication of background operations to be performed to the host device 105, for example, via the interface 115. In some examples, described herein, the indication of the background operations is provided via a device descriptor stored at the memory system 110, such as the Device Health descriptor described in more detail herein. The host device 105 may periodically query the descriptor, as described herein. At operation 406, the memory system 110 waits for permission data 122. For example, the host device 105 can be programmed to provide the permission data 122 at a time when the electronic device 100 is charging its battery and/or when the host device 105 has otherwise determined that it is a suitable for the memory system 110 to perform background operations. If permission data 122 is not received, the memory system 110 may continue to wait. The host device 105 may notice that the memory system 110 has a need or preference to perform background operations, for example, based on the indication provided at operation 404.

If permission data is not received at operation 406, the memory system 110 may continue to wait for permission data. If permission data is received at operation 406, the memory system 110 may execute background operations at operation 408. In some examples, the permission data 122 is received by a flag, such as a UFS flag, that can be set by the host device 105 as described herein. The permission data 122 may also include and/or refer to parameter data describing parameters of the permission granted to the memory system 110 to execute background operations. In some examples, the parameter data includes time data describing a time period during which the memory system 110 is permitted to execute background operations. Accordingly, the memory system 110 may execute background operations during the indicated time period.

FIG. 5 is a flowchart showing one example of a process flow 500 that may be executed by the host device 105 and the memory system 110 to execute background operations at the memory system 110. The flowchart of FIG. 5 includes two columns. A first column 501 shows operations that are performed by the memory system 110. A second column 503 shows operations that are performed by the host device 105.

At operation 502, the memory system 110 sends an indication 505 of background operations to be performed to the host device 105, for example, via the interface 115. The host device reads the indication 505 at operation 504. In some examples, described herein, the memory system 110 sends the indication 505 by writing the indication to a Device Health descriptor or other device descriptor, as described herein. The host device 105 may read the indication 505 by querying the appropriate device descriptor.

At operation 506, the host device 105 determines if it is permissible for the memory system 110 to execute background operations. The host device 105 may consider various factors. For example, the host device 105 may utilize the charge detection and signaling circuit 103 to determine whether the electronic device 100 is currently charging its battery, indicating that an external source of power is available. If the electronic device 100 is charging its battery, the host device 105 may determine that it is appropriate for the memory system 110 to execute background operations. In other examples, the host device 105 considers other factors in addition to or instead of whether the battery of the electronic device is charging. For example, the host device 105 may consider whether the electronic device 100 is idle. For example, if the electronic device 100 is charging, but not idle, it may not be desirable for the memory system 110 to execute background operations. Also, in some examples, the electronic device 100 includes more than one memory system, where the host device 105 may be configured to manage the memory system 110 and one or more other memory systems (not shown in FIG. 1). It may not be desirable for more than one memory system to perform background operations at the same time. Accordingly, the host device 105 may manage the time period when the memory system 110 performs background operations to limit the number of memory systems executing background operations at any given time.

If the host device 105, at operation 506, determines that it is not permissible for the memory system 110 to execute background operations, the host device may continue to check, for example, periodically, whether it is permissible for the memory system 110 to execute background operations. If the host device 105 determines that it is permissible for the memory system 110 to execute background operations at operation 506, the host device 105 sends background operation permission data 507 at operation 508. The background operation permission data 507 may be sent via the interface 115. In some examples, the host device 105 sends the permission data 507 by setting a flag stored at a location of the memory system 110. The memory system 110 may determine that the flag has been sent and begin executing background operations at operation 510.

While executing background operations, the memory system 110 may determine, at optional operation 512, whether to stop executing background operations. If the memory system 110 determines not to stop executing background operations, it may continue executing background operations. If the memory system 110 determines to stop executing background operations, it stops executing background operations at operation 518. The memory system 110 may determine that it should stop executing background operations, for example, if the background operations are complete. The memory system 110 may also determine that it should stop executing background operations if a time period for executing the background operations (e.g., provided by the host device 105) has expired.

In some examples, the memory system 110 determines to stop background operations if it receives a stop background operations interrupt signal. For example, the host device 105, at optional operation 514, may continue to determine if background operations are permissible for the memory system 110. For example, the host device 105 may determine whether the battery of the electronic device 100 is still being charged (e.g., whether an external source of power is available). If the battery of the electronic device 100 is no longer being charged, the host device 105 may determine that the memory system 110 should no longer execute background operations and, therefore, generate the stop background operations interrupt signal. In another example, the host device 105 may monitor requests to execute background operations from other memory systems or other devices of the electronic device 100. If another device has requested to execute background operations (or execute any other kind of operation that would make it disadvantageous for the memory system 110 to continue), then the host device 105 may determine that it is no longer permissible for the memory system 110 to continue executing background operations. In another example, the host device 105 may determine that it is no longer permissible for the memory system 110 to execute background operations when a time period for executing the background operations has expired.

If, at operation 514, the host device 105 determines that it is no longer permissible for the memory system 110 to execute background operations, then the host device may trigger a stop background operations interrupt signal 509 at operation 516. The memory system 110 may receive the interrupt signal 509 at operation 512 and proceed to stop executing background operations at operation 518. In some examples, the memory system 110 may also provide background operations stopped data to the host device 105 indicating that the execution of background operations has stopped. For example, the memory system 110 may set a flag indicating that background operations are stopped, where the flag is accessible to the host device 105. In some examples, the flag set by the memory system 110 to indicate that it has stopped executing background operations is the same flag set by the host device 105 to trigger a stop background operation interrupt, as described herein.

In some examples, an electronic device includes one or more UFS devices and utilizes UFS-compliant communications, or similar communications, to communicate to a memory system including a UFS device that the memory system may execute background operations at the UFS device. For example, the electronic device may utilize attributes, flags, and/or descriptors of UFS or a similar protocol to conduct communications regarding background operations at a memory system. For example, FIG. 6 shows one example of an electronic device 600 including a host device 605 and a memory system 610, where the memory system 610 includes a UFS device 640. The host device 605 is an entity or a device with the characteristics of a computing device (e.g., as shown in FIGS. 10 and 11) that includes one or more Small Computer System Interface (SCSI) initiator devices. In some examples, the host device 605 may be an application processor of the electronic device 600 (e.g., processor 1102 of FIG. 11). Initiator devices (initiators) are devices or processes which initiate a UFS transaction to a target device and are identified by an Initiator ID (IID). For example, different processes (e.g., operating systems) may each have a unique IID, a radio portion of a phone might have a unique IID, and the like. In some examples, the host device 105 of FIG. 1 may be arranged as a host device 605.

The host device 605 may execute one or more applications 615 that read or write data to the UFS device 640. Applications 615 interface with a UFS driver 620 which manages the UFS host controller 625 through a UFS Host Controller Interface using a set of registers. Registers may be volatile memory, non-volatile memory, or any combination and may be a temporary storage location that is used by the UFS host controller 625. The UFS host controller 625 utilizes the UFS interconnect 630 to communicate with the UFS interconnect 645 of the UFS device 640. The UFS device 640 is a target device (e.g., receives UFS commands). The electronic device 600 may include both the host and the UFS device. The UFS interconnect comprises the physical layer and provides basic transfer capabilities to the upper layers. The UFS interconnect 645 communicates with the components of the UFS device 640. In some examples, the host device 605 may be an application specific integrated circuit (ASIC) or one or more other microprocessors designed to act as an interface to the UFS device 640. In some examples, applications 615, driver 620, UFS host controller 625, and UFS interconnect 630 may be implemented in hardware or software (e.g., be implemented as computer-readable instructions that are performed by a hardware processor such as processor 1102 of FIG. 11).

UFS device 640 features a device level manager 650 that provides for device level features such as power management and the like (which may be executed by memory controller 111 of FIG. 1). Storage 670 may be one or more NAND storage cells or storage devices segmented into a plurality of Logical Unit (LU)s 0-N (655, 660, 665) that handle read/write and other storage related commands. For example, a 16 GB UFS device might be configured as 4 LUs of 4 GB each. In some examples, each die on a memory device may be a LUN. Storage 670 may be an example organization of memory cells. In some examples, the device level manager 650, device descriptors 657, attributes 659, flags 661, and UFS interconnect 645 may be implemented by one or more hardware processors.

Device descriptors 657 are one or more memory locations (e.g., blocks or pages) accessible to the host device 605 that include parameters describing something about a device. Device descriptors 657 may be stored at locations of the UFS device 640 that are accessible to queries from the device level manager 650 and/or the host device 605. Flags also describe something about the UFS device 640. Flags 661 comprise one or more bits that can be modified by the host device 605 and/or the UFS device 640 to perform communications between the devices 605, 640. Attributes 659 also describe something about the UFS device 640. For example, attributes 659 may comprise one or more bytes, where each of the one or more bytes corresponds to an attribute of the UFS device 640. Device descriptors 657, attributes 659, and flags 661 may be stored at memory locations outside of logical units 655, 660, 665 at storage 670 as shown in FIG. 6. In some examples, however, device descriptors 657, attributes 659, and/or flags 661 may be stored at storage 670.

Device descriptors 657, attributes 559, and flags 661 of a storage device are queried by the host device 605 through a Query Request UFS Protocol Information Unit (UPIU) and corresponding replies are provided through a Query Response UPIU. FIG. 7 is a flowchart showing one example of a process flow 700 that may be executed by a memory system, such as the memory system 610 or the memory system 110, to provide a device descriptor, attribute, and/or flag in response to a request. The process flow 700 applies generally to all requests for device descriptors, attributes, and/or flags, but will be described in reference to the background operations case described herein. At operation 702, the memory device receives a host query for a device descriptor, e.g., through a UPIU request message. In some examples, the message may request a device descriptor including background operation data written by the UFS Device 640, such as the UFS DEVICE_HEALTH descriptor. Accordingly, the host device may read an indication of background operations to be performed by a memory system by querying the DEVICE_HEALTH descriptor. In other examples, the message may be for one or more flags. In this way, the host device 605 may determine whether the memory system 610 has set or cleared any flags indicating that it is performing background operations.

At operation 704, the host device searches for the requested device descriptor, attribute, or flag. If the requested device descriptor, attribute, or flag is found at operation 706, then a query response with the requested device descriptor, attribute, or flag (e.g., the DEVICE_HEALTH descriptor) is sent at operation 710 (e.g., as part of a Query Response UPIU). If the requested device descriptor, attribute, or flag is not located at operation 704, then at operation 710, a response is sent with an error indicator, such as an error code that is part of the Query Response UPIU).

Turning now to FIG. 8, a flowchart showing one example of a process flow 800 that may be executed by a host device, such as the host device 605 or the host device 105, to read a device descriptor, attribute, and/or flag of a memory device, such as a memory device of the memory system 610. The process flow 800 applies generally to requests for device descriptors, attributes, and flags but will also be described in reference to the background operations case described herein. At operation 802, the host device 605 sends a host query for values of a device descriptor, attribute, or flag (for example, the DEVICE_HEALTH descriptor, or other descriptor, attribute, and/or flag including data regarding memory system background operations). The host device 605 may set a timer to ensure that a response is received. If the response is not received within a timeout period, at operation 804, the host device 605 may retry to send the message at operation 802. If, at operation 804, a response is received within the timeout period, then at operation 806, the response may be parsed and a determination may be made if the response includes the requested descriptor, attribute, and/or flag. If not, then various error handling procedures may be adopted at operation 808. If the response contains the descriptor, attribute, or flag, then at operation 810, the descriptor, attribute, or flag may be read and/or saved to a memory of the host device 605 (e.g., in a RAM of the host device). Optionally, at operation 812, the host device may utilize the descriptor, attribute, or flag. For example, if the descriptor includes an indication of background operations to be performed at the memory system 610, then the host device 605 may use the indication to determine whether to send the memory system 610 permission to execute background operations and, in some examples, background operation parameters such as, for example, a time period for performing the background operations, temperature conditions under which the background operations may be performed, as described herein.

FIG. 9 is a flowchart showing one example of a process flow 900 that may be executed by a memory system, such as the memory system 110 or 610, to execute background operations utilizing UFS-compliant communications with a host device, such as the host device 105 or 605. At operation 902, the memory system writes background operation data to a device descriptor, attribute, and/or flag, such as the UFS DEVICE_HEALTH descriptor. The background operation data provides information about background operations to be executed at the memory system such as, for example, volume data indicating a volume of background operations to be performed at the memory system. The volume of background operations describes the number of, length of, or other measure of the quantity of background operations to be performed. Example units for describing the volume of background operations may describe an amount of memory to be garbage collected, a number of cells to be refreshed, an amount of data to be moved from SLC cache to MLC cells, etc.

In some examples, the device descriptor, such as the DEVICE_HEALTH descriptor, comprises a background operations byte or other set of bits. Example configurations for a background operations byte are shown by TABLE 1 below:

TABLE 1

Value
Background Operation Volume

00h
No background operations

01h
First level of background operations

02h
Second level of background operations greater than

the first level

03h
Third level of background operations greater than

the second level

04-FFh
Reserved

At operation 904, the memory system determines whether a background operations trigger has been set. The background operations trigger may be, for example, a bit at a flag. The host device may set the trigger, for example, to provide permission for the memory system to begin executing background operations. The memory system may periodically poll the relevant descriptor, attribute, or flag containing the operations trigger. If the background operations trigger is not set, the memory system may wait at operation 906 and then determine again, at operation 904, whether the background operations trigger is set. In some examples, the memory system continues to perform non-background operations, such as reads and writes, while waiting for the background operations trigger to be set.

If, at operation 904, the memory system determines that the background operations trigger is set, it begins to execute background operations at operation 908. In some examples, before initiating execution of background operations, the memory system obtains parameter data describing background operation parameters. For example, the host device may write background operation parameters to various device descriptors. In some examples, the host device writes minimum and maximum temperature data describing minimum and maximum temperatures for performing background operations to one or more attributes. Upon detecting the background operations trigger, the memory system may read the appropriate attribute or attributes to determine minimum and/or maximum temperatures for executing background operations. Also, in some examples, the host device writes a time period for executing the operations to a device descriptor, attribute, or flag such as the UFS CONFIG descriptor. For example, the host device may write the time period to one or more predetermined bytes at the CONFIG descriptor. In some examples, two bytes are used and the corresponding time period measured in seconds, such that the memory system may be given between 0 to FFFF FFFFh seconds to complete background operations (e.g., 0-4,294,967,295 seconds). Any other suitable number of bytes, unit of time, or range of time periods may be used, however.

While background operations are executing, the memory system may monitor conditions and stop executing background operations if the monitored conditions so indicate. For example, at operation 910, the memory system may determine if the background operations are complete. If the background operations are complete, the memory system may stop background operations at operation 920. At operation 912, the memory system may determine whether the time period for executing the background operations has elapsed. If the time period has elapsed, the memory system stops executing background operations at operation 920.

At operation 914, the memory system determines whether the host device has set a stop background operations interrupt signal. For example, the host device may send the stop background operations interrupt signal by setting a flag (e.g., a UFS flag such as at flags 661). The memory system may periodically poll to determine whether the stop background operations interrupt is set. In another example, the flag, when set by the host device, may automatically trigger a hardware interrupt at the memory system. Upon detecting the stop background operations interrupt signal, the memory system may stop background operations at operation 920. At operation 916, the memory system may determine if it is operating outside any background operation parameters, such as, for example, a minimum or maximum temperature. If the memory system is outside of any background operation parameters, it may stop background operations at operation 920.

If none of the conditions tested at operations 910, 912, 914, 916 are present, then the memory system may continue to execute background operations at operation 918. The memory system may continue to periodically test the conditions of operations 910, 912, 914, 916 while background operations are performed. While various portions of the disclosure herein may be described with respect to UFS, one of ordinary skill in the art with the benefit of the present disclosure will recognize that the disclosed improvements may also be applied to eMMC and other interfaces between a storage device and a host.

FIG. 10 shows an environment 1000 including an example electronic device 1001 having a host device 1010 and a memory system 1020 (e.g., memory system 110) as part of one or more apparatuses 1030-1050. Apparatuses include any device that may include an electronic device, such as electronic device 1001. The electronic device 1001 may be any device capable of executing instructions (sequential or otherwise). Example apparatuses include a vehicle 1030 (e.g., as part of an infotainment system, a control system, or the like), a drone 1050 (e.g., as part of a control system), furniture or appliances 1040 (e.g., as part of a sensor system, an entertainment or infotainment system), or the like. In other examples, although not shown, apparatuses may include aeronautical, marine, Internet of Things (IOT), and other devices.

FIG. 11 shows a block diagram of an example machine 1100 upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform. In alternative embodiments, the machine 1100 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 1100 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 1100 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 1100 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, an IoT device, automotive system, or any other electronic device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that electronic device. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (Saas), other computer cluster configurations.

Examples, as described herein, may include, or may operate by, logic, components, devices, packages, or mechanisms. Circuitry is a collection (e.g., set) of circuits implemented in tangible entities that include hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership may be flexible over time and underlying hardware variability. Circuitries include members that may, alone or in combination, perform specific tasks when operating. In an example, hardware of the circuitry may be immutably designed to carry out a specific operation (e.g., hardwired). In an example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a non-transitory computer-readable medium physically modified (e.g., magnetically, electrically, moveable placement of invariant massed particles, etc.) to encode instructions of the specific operation. In connecting the physical components, the underlying electrical properties of a hardware constituent are changed, for example, from an insulator to a conductor or vice versa. The instructions enable participating hardware (e.g., the execution units or a loading mechanism) to create members of the circuitry in hardware via the variable connections to carry out portions of the specific tasks when in operation. Accordingly, the computer-readable medium is communicatively coupled to the other components of the circuitry when the device is operating. In an example, any of the physical components may be used in more than one member of more than one circuitry. For example, under operation, execution units may be used in a first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry, or by a third circuit in a second circuitry at a different time.

The machine (e.g., computer system) 1100 (e.g., host device 105, the memory system 110, memory devices 112, etc.) may include a hardware processor 1102 (e.g., a CPU, a graphics processing unit (GPU), a hardware processor core, or any combination thereof, such as the memory controller 111, 114, etc.), a main memory 1104, and a static memory 1106, some or all of which may communicate with each other via an interlink (e.g., bus) 1108. The machine 1100 may further include a display unit 1110, an alphanumeric input device 1112 (e.g., a keyboard), and a user interface (UI) navigation device 1114 (e.g., a mouse). In an example, the display unit 1110, input device 1112 and UI navigation device 1114 may be a touch screen display. The machine 1100 may additionally include a storage device (e.g., drive unit) 1122, a signal generation device 1118 (e.g., a speaker), a network interface device 1120, and one or more sensors 1117, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 1100 may include an output controller 1128, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage device 1122 may include one or more machine readable media on which is stored one or more sets of data structures or instructions 1124 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 1124 may also reside, completely or at least partially, within the main memory 1104, within static memory 1106, or within the hardware processor 1102 during execution thereof by the machine 1100. In an example, one or any combination of the hardware processor 1102, the main memory 1104, the static memory 1106, or the storage device 1122 may constitute the machine readable medium.

The term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store the one or more instructions 1124.

The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 1100 and that cause the machine 1100 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. In an example, a massed machine readable medium comprises a machine-readable medium with a plurality of particles having invariant (e.g., rest) mass. Accordingly, massed machine-readable media are not transitory propagating signals. Specific examples of massed machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., EPROM, EEPROM) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

The instructions 1124 (e.g., software, programs, an operating system (OS), etc.) or other data are stored on the storage device 1121 and can be accessed by the memory 1104 for use by the processor 1102. The memory 1104 (e.g., DRAM) is typically fast, but volatile, and thus a different type of storage than the storage device 1121 (e.g., an SSD), which is suitable for long-term storage, including while in an “off” condition. The instructions 1124 or data in use by a user or the machine 1100 are typically loaded in the memory 1104 for use by the processor 1102. When the memory 1104 is full, virtual space from the storage device 1121 can be allocated to supplement the memory 1104; however, because the storage 1121 device is typically slower than the memory 1104, and write speeds are typically at least twice as slow as read speeds, use of virtual memory can greatly reduce user experience due to storage device latency (in contrast to the memory 1104, e.g., DRAM). Further, use of the storage device 1121 for virtual memory can greatly reduce the usable lifespan of the storage device 1121.

In contrast to virtual memory, virtual memory compression (e.g., the Linux kernel feature “ZRAM”) uses part of the memory as compressed block storage to avoid paging to the storage device 1121. Paging takes place in the compressed block until it is necessary to write such data to the storage device 1121. Virtual memory compression increases the usable size of memory 1104, while reducing wear on the storage device 1121.

Storage devices optimized for mobile electronic devices, or mobile storage, traditionally include MMC solid-state storage devices (e.g., micro Secure Digital (microSD™) cards, etc.). MMC devices include a number of parallel interfaces (e.g., an 8-bit parallel interface) with a host device and are often removable and separate components from the host device. In contrast, eMMC™ devices are attached to a circuit board and considered a component of the host device, with read speeds that rival serial ATA™ (Serial AT (Advanced Technology) Attachment, or SATA) based SSD devices. However, demand for mobile device performance continues to increase, such as to fully enable virtual or augmented-reality devices, utilize increasing networks speeds, etc. In response to this demand, storage devices have shifted from parallel to serial communication interfaces. UFS devices, including controllers and firmware, communicate with a host device using a low-voltage differential signaling (LVDS) serial interface with dedicated read/write paths, further advancing greater read/write speeds.

The instructions 1124 may further be transmitted or received over a communications network 1126 using a transmission medium via the network interface device 1120 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 1120 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 1126. In an example, the network interface device 1120 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 1100, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” may include “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein”. Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc., are used merely as labels, and are not intended to impose numerical requirements on their objects.

In various examples, the components, controllers, processors, units, engines, or tables described herein can include, among other things, physical circuitry or firmware stored on a physical device. As used herein, “processor” means any type of computational circuit such as, but not limited to, a microprocessor, a microcontroller, a graphics processor, a digital signal processor (DSP), or any other type of processor or processing circuit, including a group of processors or multi-core devices.

Various embodiments according to the present disclosure and described herein include memory utilizing a vertical structure of memory cells (e.g., NAND strings of memory cells). As used herein, directional adjectives will be taken relative a surface of a substrate upon which the memory cells are formed (i.e., a vertical structure will be taken as extending away from the substrate surface, a bottom end of the vertical structure will be taken as the end nearest the substrate surface and a top end of the vertical structure will be taken as the end farthest from the substrate surface).

As used herein, directional adjectives, such as horizontal, vertical, normal, parallel, perpendicular, etc., can refer to relative orientations, and are not intended to require strict adherence to specific geometric properties, unless otherwise noted. For example, as used herein, a vertical structure need not be strictly perpendicular to a surface of a substrate but may instead be generally perpendicular to the surface of the substrate and may form an acute angle with the surface of the substrate (e.g., between 60 and 120 degrees, etc.).

Operating a memory cell, as used herein, includes reading from, writing to, or erasing the memory cell. The operation of placing a memory cell in an intended state is referred to herein as “programming,” and can include both writing to or erasing from the memory cell (e.g., the memory cell may be programmed to an erased state).

According to one or more embodiments of the present disclosure, a memory controller (e.g., a processor, controller, firmware, etc.) located internal or external to a memory device, is capable of determining (e.g., selecting, setting, adjusting, computing, changing, clearing, communicating, adapting, deriving, defining, utilizing, modifying, applying, etc.) a quantity of wear cycles or a wear state (e.g., recording wear cycles, counting operations of the memory device as they occur, tracking the operations of the memory device it initiates, evaluating the memory device characteristics corresponding to a wear state, etc.)

According to one or more embodiments of the present disclosure, a memory access device may be configured to provide wear cycle information to the memory device with each memory operation. The memory device control circuitry (e.g., control logic) may be programmed to compensate for memory device performance changes corresponding to the wear cycle information. The memory device may receive the wear cycle information and determine one or more operating parameters (e.g., a value, characteristic) in response to the wear cycle information.

It will be understood that when an element is referred to as being “on,” “connected to,” or “coupled with” another element, it can be directly on, connected, or coupled with the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly on,” “directly connected to,” or “directly coupled with” another element, there are no intervening elements or layers present. If two elements are shown in the drawings with a line connecting them, the two elements can be either be coupled, or directly coupled, unless otherwise indicated.

Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer-readable instructions for performing various methods. The code may form portions of computer program products. Further, the code can be tangibly stored on one or more volatile or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media can include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact discs and digital video disks), magnetic cassettes, memory cards or sticks, RAMs, ROMs, SSDs, UFS devices, eMMC devices, and the like.

In order to further describe the current subject matter, a non-exhaustive set of numbered examples is provided.

Example 1 is an electronic device, comprising: a memory system comprising a memory controller and a plurality of memory locations, the memory controller being programmed to perform operations comprising: communicating, to a host device, a first message describing background operations to be performed at the memory system; receiving, from the host device, a second message indicating permission to execute the background operations; and initiating execution of at least one background operation.

In Example 2, the subject matter of Example 1 optionally includes wherein the first message comprises volume data describing a volume of background operations to be performed at the memory system.

In Example 3, the subject matter of any one or more of Examples 1-2 optionally includes wherein communicating the first message comprises writing background operations data to a memory location of the plurality of memory locations that is accessible to the host device.