Abstract:
A method is provided for asynchronous notifications from a device to a host in systems without requiring hardware provision for asynchronous operations. In an embodiment of the invention, a system supports command queuing and a command is sent from a host to a device. The device receives the command and an associated tag, and accepts the command as valid. After accepting the command, the device begins monitoring for asynchronous events. If an asynchronous event is detected, the device provides notification of the event by sending a response and the associated tag to the host. In another embodiment of the invention, a method of asynchronous notification enables use of invalid tags. In a further embodiment of the invention, asynchronous notifications may be enabled by a host and operate without additional host commands.

Description:
BACKGROUND 
       [0001]    Computers and computer systems have become ubiquitous. With the great range of computer hardware and software available, it has become important to set a number of standards for connecting various computer devices and communicating among them. 
         [0002]    The computer industry has formed organizations of member companies to provide standards that permit compatibility and interoperability. Standards are now available for hardware and software connection between computers and peripherals, for example. Internal computer devices such as disk drives and input/output devices, and external products such as portable devices are attached to computers with standard interface cables and use standard communication protocols. Some widely adopted examples include USB, ATA, and Serial ATA (SATA or eSATA) interfaces. 
         [0003]    In each of these systems, the host initiates operations and sends commands to the device, and the device responds to host commands following pre-defined protocols. There is no provision in these interfaces for a device to initiate a command or operation to a host. A device can only send information to a host that has been requested by a host-sent command or otherwise directly caused by a host action. 
         [0004]    Such protocols use asymmetric interfaces where host and devices have defined roles of command and response (e.g., the host commands and the device responds) and are unlike peer-to-peer communication protocols where a unit can operate as both an initiator and as a target. SCSI is one standard interface that provides this peer-to-peer support. 
         [0005]    Some system interfaces may allow for hardware notification between units via the host to device cable, however new interfaces favor serial communication that cannot provide a dedicated signal on the cable, and are not provided in systems such as Serial ATA or USB. 
         [0006]    In a system with a host and a device where there is no provision for a device to notify a host of an important event at any time, the device has only unfavorable options. For example, upon failure conditions or events from which a device cannot recover, some devices may resort to self resetting or aborting outstanding commands in order to force a host to take notice and hopefully recover. This may cause catastrophic loss of data or result in an inoperable system. System timeouts or resets are a last resort to attempt recovery. Additionally, device to host notifications may be desirable before a situation becomes critical, such as environmental conditions or recoverable errors. 
         [0007]      FIG. 1  illustrates a system  10  employing a host computer  11 , a device  13 , and an optional interconnect cable  12 , allowing communication between the host computer  11  and device  13 . The communication of  FIG. 1  may comprise, for example, a Universal Serial Bus, AT Attachment, Serial Attached SCSI, or Serial ATA communication interface. Alternatively, some devices  13  plug directly into a host  11  without the need for a cable  12  and operate in the same manner. The host computer  11  may be any system that can send commands to the device  13 . The host computer may be, for example, a desktop computer, notebook computer, or an application specific controller. 
         [0008]    The interface between the host computer  11  and the device  13  may be a Universal Serial Bus interface, commonly referred to as a USB interface. The USB interface is also referred to as USB- 1 , USB- 2  or USB- 3 , and future revisions are expected. Devices may support command queuing, and incorporate a command queue  14 . The device  13  may be, for example, an I/O device such as keyboard, printer or mouse; storage device such as a disk drive, solid state drive, CD or DVD player; a communication device such as modems; or a personal entertainment device such as a music or video player. 
         [0009]      FIG. 2  illustrates a system  20  employing a host computer  11  connected with a cable  12  to a host side of a hub  15 , and devices  13  connected to a device side of the hub  15  with optional cables  12 . The hub provides expansion ports so that multiple devices can connect to a single host port. In the system shown in  FIG. 2 , the host computer is the communication host; however, the devices are physically connected to the hub  15 . The hub provides the physical interface to the devices and will appear to a device as a host. Hubs as shown in  FIG. 2  are well known in the art and are widely available. References to hosts or host computers hereinafter may comprise a directly connected host as shown in  FIG. 1 , or a host connected through a hub as shown in  FIG. 2 . 
         [0010]      FIG. 3  illustrates a flow chart of a device receiving a queued command. Beginning in step  300 , a device is operating in a system with a host. In block  305 , the device checks for a command reception from the host. If no new commands have been received (block  310 ) the device advances to block  315  to determine if there are any outstanding commands in the command queue. If the queue is empty, the device returns to  305  to continue checking for new commands. 
         [0011]    If a new command was received in block  310 , the device checks the command and its associated queue command tag validity in block  325 . If the command is invalid or the tag is invalid, the device responds to the host by sending an error status in block  320 . If the command and tag are valid, the device accepts the command (block  330 ) for execution. The device will add the command into the device command queue with any other outstanding commands waiting for completion. In block  340 , the device will make a determination which command should be executed next and may reorder the queue for optimal performance as needed, although reordering is not required. The device then executes a command from the command queue in  345 . 
         [0012]    The flow chart shown in  FIG. 3  is one example of a queued command process. Alternative embodiments might, for example, perform command reception, queue ordering, and/or command execution as simultaneous operations to provide improved performance. 
       BRIEF SUMMARY 
       [0013]    Methods for providing asynchronous notifications from a device to a host in systems without requiring hardware provision for asynchronous operations are disclosed herein. 
         [0014]    In an embodiment of the invention, a method is provided for asynchronous event notification from a device in a system that supports command queuing. The method includes receiving a queued command and queue tag from a host; accepting the queued command from the host without scheduling the command for completion; monitoring device operation for asynchronous events; detecting an asynchronous event; and providing notification of the asynchronous event by scheduling and sending a response comprising the tag to the host. 
         [0015]    In another embodiment of the invention, a method is provided for asynchronous event notification from a device in a system that supports command queuing and a command is sent from a host to a device. The device receives the command and an associated queue tag, and determines that the tag is not a valid tag. The device then determines if the command is an asynchronous event notification request type command, and if so, accepts the command as valid. After accepting the command, the device begins monitoring for asynchronous events. If an asynchronous event is detected, the device provides notification of the event by sending a response and the associated tag to the host. 
         [0016]    In another embodiment of the invention, a method is provided for asynchronous event notification from a device in a system that supports command queuing and a command is sent from a host to a device to enable unsolicited queue command responses. The device receives the command and assigns or associates a queue tag to the command and enables unsolicited queue command responses. The device begins monitoring for asynchronous events. If an asynchronous event is detected, the device provides notification of the event by sending a response and the associated tag to the host. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]      FIG. 1  illustrates a block diagram of a host and a device system. 
           [0018]      FIG. 2  illustrates a block diagram of a host and a device system with a hub. 
           [0019]      FIG. 3  is a flow chart illustrating a device receiving a queued command. 
           [0020]      FIG. 4  is a flow chart illustrating an embodiment of the invention with an Asynchronous Event Command. 
           [0021]      FIG. 5  is a flow chart illustrating an embodiment of the invention with a valid queue command tag or with an invalid queue command tag. 
           [0022]      FIG. 6  is a flow chart illustrating an embodiment of the invention with host enabled operation. 
           [0023]      FIG. 7  illustrates a block diagram of a device according to an embodiment of the invention. 
           [0024]      FIG. 8  illustrates separated queue storage according to an embodiment of the invention. 
           [0025]      FIG. 9  illustrates partitioned queue storage according to an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0026]      FIG. 4  illustrates an embodiment of the invention with an Asynchronous Event Command. 
         [0027]    Beginning in block  400 , a device is operating in a system with a host. In block  405 , the device checks for a command reception from the host. If no new commands have been received (block  410 ) the device advances to block  415  to determine if there are any outstanding commands in the command queue. If the queue is empty, the device returns to  405  to continue checking for new commands. If the queue is not empty, the device continues to execute outstanding commands in block  445 . 
         [0028]    If a new command was received in block  410 , the device checks the command and its associated queue command tag validity in block  412 . If the command is invalid or the tag is invalid, the device responds to the host by sending an error status in block  420 . If the command and tag are valid, the device accepts the command (block  425 ). The device checks to determine if the command is an Asynchronous Event Notification command (AEN Command) in block  430 . If the command is not an AEN command, the device will add the command into the device command queue (block  435 ) with any other outstanding commands waiting for completion. In block  440 , the device will make a determination which command should be executed next and may reorder the queue for optimal performance as needed. The device then executes a command from the command queue in  445 . 
         [0029]    Returning to block  430 , if the command was an AEN command, the device starts a new process (path  432 ) comprising blocks  455  through  465 . The process beginning in block  455  starts by the device initiating monitoring for asynchronous events. If no event is detected in block  460 , the device continues monitoring. If an event is detected in  460 , the device will prepare an ending status and transmit the asynchronous event status to the host. Returning again to block  430 , if the command was an AEN command, in addition to the new process started in block  455 , the process continues processing queue commands by returning to block  405  by path  450 . 
         [0030]    The embodiment shown in  FIG. 4  is one embodiment of a queued command process. Alternative embodiments might, for example, perform command reception, queue ordering, and/or command execution as simultaneous operations to provide improved performance. 
         [0031]      FIG. 5  illustrates an embodiment of the inventive process dealing with a valid or invalid queue command tag. Beginning in block  500 , a device is operating in a system with a host. In block  505 , the device checks for a command reception from the host. If a new command has been received (block  510 ) the process advances to block  515  to check the command and its associated queue command tag validity. If the command and tag are valid, the process advances to block  550  and checks the new command received in block  510  to determine if the command is an Asynchronous Event Notification command (AEN Command). If the command is not an AEN command, the device will add the command into the device command queue (block  555 ) with any other outstanding commands waiting for completion. In block  560 , the device will make a determination which command should be executed next and reorders the queue for optimal performance as needed. The device then executes a command from the command queue in  565  and returns to  505  to resume operation. 
         [0032]    Returning to block  550 , if the command was an AEN command, the device starts a new process (path  551 ) comprising blocks  530  through  540 . The process beginning in block  530  starts by the device accepting the AEN command for processing. The device will initiate monitoring for asynchronous events in block  530 . If no event is detected in block  535 , the device continues monitoring. If an event is detected in  535 , the device will prepare an ending status and transmit the asynchronous event status to the host in block  540  and then return to  505  to continue operation. 
         [0033]    Returning again to block  550 , if the command was an AEN command, in addition to the new process started in block  530  through path  551 , the process continues processing queue commands by returning to block  505  by path  552 . 
         [0034]    Returning to block  515 , if the command and tag are invalid, the process advances to block  520 . If the command was an AEN type command the device will initiate monitoring for asynchronous events in block  530 . If no event is detected in block  535 , the device continues monitoring. If an event is detected in block  535 , the device will prepare an ending status and transmit the asynchronous event status to the host in  540  and then return to  505  to continue queue command operation. 
         [0035]    Returning again to block  520 , in addition to the process started by transitioning to block  530  the device also continues to process queue commands by returning to block  505  through path  522 . In block  520 , if the command was not an AEN command, the device sends error status to the host and returns to  505  to continue queue command operation. 
         [0036]    In the embodiment illustrated in  FIG. 5 , invalid tags are processed if the command is an AEN command. Invalid tags may be, for example, duplicate tag assignments, out of range values, reserved tags, or any tag that is not normally accepted and will result in an error status to the host. The method of  FIG. 5  resolves the problem, wherein if a command with an invalid tag is received, the device may abort all outstanding commands and possibly cause catastrophic failure to the system. In the embodiment illustrated in  FIG. 5 , invalid tags will be accepted if the command is an AEN command. 
         [0037]    In another embodiment of the invention, a device may be enabled by a command or by default operation to begin asynchronous event monitoring and reporting. If a host is aware of the feature by device inquiry, the host may enable the device to initiate asynchronous event notification using an agreed upon command tag. The tag may be a valid or an invalid tag value. The host can provide a preferred tag at the same time the feature is enabled. The device may also provide a default tag. 
         [0038]    In another embodiment of the invention, any queued command may include an option bit that enables asynchronous event notification. By using this embodiment of the invention, the host does not need to send any commands to the drive, simplifying operation and overhead. Features enabled in a device may be persistent or not persistent across resets and loss of power. This reduces configuration time after startup and reset operations. 
         [0039]    In an embodiment of the invention, the enabling of asynchronous event notification may be selected to persist if a device reset occurs. 
         [0040]    In an embodiment of the invention, the enabling of asynchronous event notification may be selected to persist after a device has been powered off. 
         [0041]      FIG. 6  illustrates an embodiment of the invention with host enabled operation. 
         [0042]    Beginning in block  610 , a power or device reset is applied to the device. After the reset is ended, the device will check its configuration information to determine if the asynchronous event notification feature is enabled in block  615 . If the feature is not enabled the process ends in  620 . If the feature is enabled, the device will assign a tag (block  625 ) for AEN command status reporting. The assigned tag may be a tag previously provided by a host, or a tag assigned by the device. 
         [0043]    The device will initiate monitoring for asynchronous events in block  630 . If no event is detected in block  635 , the device continues monitoring. If an event is detected in  635 , the device will prepare an ending status and transmit the asynchronous event status to the host in  640  and then optionally return to  630  to continue monitoring. 
         [0044]    In the embodiments of  FIG. 4 ,  FIG. 5  and  FIG. 6 , the AEN commands are not scheduled for completion and may continue to be outstanding indefinitely without affecting the ongoing queue command operation or queue order. After an asynchronous event occurs, the AEN command will be scheduled for completion. The device may elect for immediate completion or may defer notification depending on the event severity. 
         [0045]      FIG. 7  illustrates a block diagram of a device  700  according to an embodiment of the invention. Device  700  comprised a processor  710  and a command queue  14 . The command queue may be a portion of memory allocated by the processor  710 , or dedicated hardware such as registers or data storage accessible to the processor  710 . The queue contains the information related to each outstanding tag queued command. The tags may be a number, illustrated in the queue as separate entries 1, 2, 3, and so on. 
         [0046]    An asynchronous monitoring unit  720  may be software operating on the processor  710  or a distinct hardware unit. 
         [0047]    In an embodiment, the asynchronous monitoring unit  720  will monitor the asynchronous events through hardware functions or by polling. 
         [0048]    In an embodiment, the asynchronous monitoring unit  720  may provide information to the processor  710  by interrupting the processor, or by a processor executing a polling routine. 
         [0049]    The asynchronous storage  730  may be any typical memory/data storage distinct from the command queue either thorough separate units, partitions, distinct memory locations, or the like. 
         [0050]      FIG. 8  illustrates queue storage  14  and asynchronous queue storage  730  according to an embodiment of the invention. In this embodiment the command queue  14  is distinct from the asynchronous storage  730 . The queue storage  14  may operate independently from asynchronous storage  730  and separately scheduled and ordered for command execution and completion by the processor  710 . In an embodiment, operations in asynchronous monitoring unit  720  and asynchronous storage  730  will not affect operations in command queue  14 . 
         [0051]      FIG. 9  illustrates partitioned queue storage  740  according to an embodiment of the invention. In an embodiment, the portioned queue storage  740  is a common memory or data storage that is allocated by the processor  740 . The partitioned storage  740  comprises two partitions, a command queue partition  14  and asynchronous storage partition  730 . According to embodiments of the invention, although both partitions may reside in a common memory or data location, they are treated separately. 
         [0052]    In an embodiment of the invention, asynchronous events monitored comprises exceeding at least one threshold related to one or more of the following parameters: 
         [0053]    temperature; 
         [0054]    shock; 
         [0055]    vibration; 
         [0056]    power; 
         [0057]    humidity; 
         [0058]    altitude; 
         [0059]    gas pressure; 
         [0060]    error rate; 
         [0061]    wear out, and 
         [0062]    delayed completion thresholds. 
         [0063]    In another embodiment of the invention the asynchronous events comprise encryption, license, or right-to-use conditions. 
         [0064]    Although the foregoing has been described in terms of certain embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. For example, in an alternative embodiment, operations may be performed concurrently, rather than sequentially, thereby improving performance. In another embodiment, the asynchronous event monitoring may be performed in a hardware implementation and reported automatically without processor involvement. Alternatives to embody the invention in combinations of hardware and/or software running on a processor, or as a hardware implementation that is reconfigurable to operate in multiple modes would be design choices apparent to those of ordinary skill in the art. As a consequence, the system and method of the present invention may be embodied as software which provides such programming, such as a set of instructions and/or metadata embodied within a computer readable medium. The described embodiments have been presented by way of example only and are not intended to limit the scope of the disclosure. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms without departing from the spirit thereof. Thus, the invention is not limited by any preferred embodiments, but is defined by reference to the appended claims.