Patent Application
20080077727
In the embodiments below, the; task of coordinating the execution of simultaneous read and write requests made by a computing device is moved from management software residing on the computing device but external to its memory device, to the memory device itself. In at least some embodiments, this is accomplished by including a multi-threaded state machine in the command logic of the memory device. As will be appreciated by one skilled in the art and in view of the discussion below, this can ultimately result in improved performance and lower software maintenance costs.
Although computing device 102 is depicted as a mobile phone, it is to be appreciated and understood that any suitable computing device can be utilized without departing from the spirit and scope of the claimed subject matter. Other suitable computing devices can include, by way of example and not limitation, desktop or portable computers, digital cameras, pagers, handheld computers such as personal digital assistants (PDAs) and the like.
Continuing, process requests from computing device 102 are received by non-volatile memory device 120, typically via a bus (not shown). Computing device 102 can be communicatively coupled with non-volatile memory device 120 in any suitable way. Further, non-volatile memory device 120 can either be permanently affixed or removably attached to computing device 102.
As illustrated, non-volatile memory device 120 includes memory array module 122 and its supporting logic, depicted here as control logic 124. Typically, memory array modules, like memory array module 122, include a plurality of transistors, such as floating gate transistors and the like, that implement the storage elements of the non-volatile memory device. In this particular embodiment, control logic 124 includes a multi-threaded state machine, as will be described in greater detail below. In at least some embodiments, the multi-threaded state machine is fabricated on the same substrate, such as a silicon substrate, as the memory array module. Hence, the multi-threaded state machine is integrated with the memory array module.
In operation, computing device 102 makes process requests to non-volatile memory device 120 and the multi-threaded state machine facilitates processing those requests. These process requests are often made to non-volatile memory device 120 when it is already busy performing an operation associated with a previous request.
In these instances, the multi-threaded state machine can process the requests by, for example, queuing up the requests, prioritizing the requests, performing arbitration relative to the requests: and associating available resources and the like, in a multi-threaded fashion as will be appreciated by the skilled artisan. For example, consider a user who is reading, editing and creating email messages on a mobile phone device. If the user receives an incoming phone call during this time, the mobile phone device may attempt to identify the incoming caller by searching the user's address book—held in memory on the flash device. To accomplish this, a caller identification process on the phone device will make a “read” operation request to the flash memory device—which may already be engaged in either a “read”, “write” or “erase” operation with respect to the user's email messaging activities. Here, these incoming requests can be handled by the multi-threaded state machine in a multi-threaded fashion to improve the efficiency of the phone device's overall handling of the requests.
This constitutes a dramatic improvement over past single-threaded approaches which could not handle and efficiently or effectively process multiple requests, but rather utilized software to process these requests.
Here, the multi-threaded state machine of control logic 124 allows non-volatile memory device 102 to accommodate multiple process requests at the same time. This, in turn, allows the task of managing multiple requests to be handled by the non-volatile memory device itself, and relieves the burden of this processing from external device software
To provide some tangible context for the reader to appreciate the role of multi-threaded state machines in the particular context described herein, consider the following. The control logic of a memory device includes a state machine to handle the transitions of the memory device from one state to the next. For instance, if the current state of the memory device is that it is being engaged in a read process, the state machine can define conditions that cause transitions from that state—as by defining the conditions that suspend the read process. Likewise, that state machine can define conditions that transition to and from, as well as suspend, other processes such as write processes, erase processes, and the like. Any number of such operations or processes can be so executed as a “thread” by the state machine in response to process requests made to the memory device. Unlike single-threaded state machines, multi-treaded state machines can initiate two or more of these operations simultaneously or pseudo-simultaneously, as will be appreciated and understood by those skilled in the art. This means that operations associated with multiple process requests can be received and managed and multiple threads can be allocated and performed by a memory device that includes a multi-threading state machine, such as non-volatile memory device 120 depicted here.
Here, a memory bus 220 operably connects flash memory device 210 with other components, such as a processor (not specifically shown), on an associated computing device such as computing device 102 depicted in
As illustrated, flash memory device 210 includes, among other things, a memory array module 212 and its supporting logic, here depicted as control logic 214. Control logic 214 includes a multi-threaded state machine which, as discussed above, allows flash memory device 210 to accommodate and manage multiple processes requests at the same time. By way of example, and not limitation, this management can include discerning different process requests and their priorities, arbitrating various operations associated with these process requests (for example, reading, writing or erasing data in the memory array module), caching retrieved data, and ensuring that these operations are completed. 100181 Also included on flash memory device 210 is a command queue 216 where various commands, associated with various process requests received by flash memory device 210, can be held until they are serviced. Control logic 214 can poll this queue and service each command therein under the influence of the multi-threaded state machine. Commands can be placed or otherwise ordered in the command queue and/or serviced based upon any suitable criteria. By way of example, and not limitation, this order can be based on the designated priority of the process requests corresponding to the commands and/or on the identity of the requesting processes themselves.
Again, note that process request management functions, traditionally performed by software external to the memory device, are performed here by flash memory device 210 in a multi-threaded fashion. This is beneficial because, as discussed above, flash memory device 210 can manage process requests in a more efficient and timely manner than external software can. On reason for this is the overhead consumed by the external software. For instance, mutual exclusion algorithms, abstract data types and other related processing means typically employed by such software require significant computational resources. Furthermore, maintaining and upgrading this software can be time consuming and expensive.
Consider again the example above involving a user using a mobile phone device to read, edit, and create email messages. By utilizing a flash memory device that includes a multi-threaded state machine, the mobile phone device's performance is no longer negatively impacted by various software drivers handling the various process requests associated with features such as email messaging and caller identification. As such, the user enjoys a faster, more efficient mobile phone device. Furthermore, less software maintenance and upgrading are necessary.
Act 300 receives multiple process requests on a non-volatile memory device. The non-volatile memory device can accommodate any suitable number of process requests at any particular time. In at least some embodiments, the non-volatile memory device has control logic that includes a multi-threaded state machine. In addition, as noted, above,: these process requests can be made by an associated computing device and are typically received via a bus.
Act 302 queues commands associated with the received process requests on the non-volatile memory device. As noted above, commands can be queued according to any suitable criteria. Commands can designate operations such as “reading”, “writing” or “erasing” data. In at least some embodiments, such as those described above, this act is performed by control logic on the non-volatile memory device.
Act 304 determines a next command or commands to be serviced. This includes, but is not necessarily limited to, polling a command queue (containing the queued commands) and ascertaining which command(s) in the queue have the highest designated priority. In at least some embodiments, such as those described above, this act is performed by control logic on the non-volatile memory device.
Act 306 services the command(s). Servicing typically entails performing one or more operations associated with the command(s). For instance, if a command is to “read” from a memory array module on the non-volatile memory device, the operation is the performance of reading from the memory array module. In at least some embodiments, such as those described above, this act is performed by control logic on the non-volatile memory device.
Act 308 determines whether the service is complete. This typically entails ascertaining whether the performance of the operation associated with the command being serviced has successfully finished. Here, if the service of the command is not complete (i.e. “no” branch), act 308 loops back to complete the command. Note that this act can be repeated any number of times until it is determined that the service is complete (i.e. “yes” branch). When this happens (“yes”), acts 304-308 are repeated for any subsequent commands. Hence, the next command(s) to be serviced will be determined.
Some or all of the acts described in this example can be performed under the influence of the multi-threaded state machine. Specifically, processing of the multiple requests, as exemplified in acts 300-308, can be handled in a multi-threaded fashion to provide for fast and efficient execution of the commands.
Conclusion
The various principles and methods described above allow a non-volatile memory device with a suitable multi-threaded state machine, rather than management software external to the device, to manage process requests from an associated computing device. Accordingly, the overhead and performance penalty associated with relying on external management software, along with the cost and effort of creating and maintaining this software, can be mitigated.
Although the embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed subject matter.
