CN105453062A - Implementing hardware auto device operations initiator - Google Patents

Abstract

A method and controller for implementing hardware auto device operation initiator in a data storage system, and a design structure on which a subject controller circuit resides are provided. The controller includes an inline hardware engine receiving host commands, and assessing a received command for starting without firmware involvement. The inline hardware engine builds one or more chains of hardware command blocks to perform the received command and starts executing the chain or chains for the received command.

Description

Implement hardware automatic device operation launcher

technical field

The present invention relates generally to the field of data processing, and more particularly to methods and controllers for implementing hardware automatic device operation enablers and design structures on which the subject controller circuitry resides.

Background technique

Storage adapters are used to connect a host computer system to peripheral storage I/O devices such as hard disk drives, solid state drives, tape drives, compact disk drives, and the like. Various high-speed system interconnects such as Peripheral Component Interconnect Express (PCIe), Serial Attached SCSI (SAS), Fiber Channel, and InfiniBand (InfiniBand).

For many years, hard disk drives (HDDs) or spinning drives have been the dominant storage I/O device for persistent storage of computer data that requires online access. Recently, solid-state drives (SSDs) have become more popular because SSDs are generally capable of performing more I/Os per second (IOPS) than HDDs, even though SSDs do not always have a higher maximum data rate than HDDs.

With the advent of faster and higher performance solid-state devices (SSDs), the performance requirements for storage subsystems have increased by more than an order of magnitude. This is especially true for command throughput or small operations. An increasing number of applications are emerging that take advantage of the extremely low latency and extremely high command throughput offered by SSDs, and in many cases the storage subsystem can become a bottleneck.

In a traditional storage subsystem or RAID controller, requests come in from the host, and in many cases the fetching of such requests is automated by hardware. The firmware interrogates the request and determines the course of action to take. This process often involves the first operation in a sequence of beginning asynchronous hardware operations. When the first operation is complete, the firmware re-evaluates the operation and determines the next course of action. This continues until the requested host operation is completed and a response is sent to the host.

In more recent high-performance memory subsystems, many of these asynchronous hardware operations can be chained together, allowing firmware to setup all hardware operations, start the sequence, and only handle completion of the entire chain on success Completion or an error somewhere along the way.

However, both traditional implementations and even more recent high-performance implementations still fall short of the increasing performance demands placed on storage subsystems. Even high-performance designs require that the firmware decide the course of the operation at least twice, at the beginning of the chain and at the completion of the chain, and still require the firmware to query the host for requests and establish hardware control blocks to perform the operation. Typically, up to 30% of a controller's processor time can be consumed just waking up firmware.

A need exists for an efficient method and controller for implementing a hardware automatic device operation enabler.

As used in the following description and claims, the terms "controller" and "controller circuitry" should be construed broadly to include input/output (IO) adapters (IOAs) and to include various components connected to a host computer system. An IORAID adapter for arranging and peripheral storage I/O devices including hard disk drives, solid state drives, tape drives, compact disk drives, and the like.

Contents of the invention

The main aspect of the present invention is to provide a method and controller for implementing a hardware automatic device operation enabler and a design structure on which the subject controller circuit resides. Other important aspects of the present invention are to provide such methods, controllers and designs which are substantially free of adverse effects and which overcome many of the disadvantages of prior art arrangements.

In brief, a method and controller for implementing a hardware automatic device operation enabler and a design structure on which the subject controller circuitry resides are provided. The controller includes an inline hardware engine that receives host commands and evaluates the received commands for initiation without involving firmware. The inline hardware engine builds one or more chains of hardware command blocks that execute the received command and begins execution of the one or more chains for the received command.

According to a feature of the invention, the number of interactions between hardware and firmware is reduced to the point that firmware is only involved once for a host operation, thereby providing significantly better performance by the storage subsystem than conventional arrangements.

According to a feature of the invention, the inline hardware engine includes a register for each logical host resource that allows automatically executed commands to be enabled and disabled for that host resource. In cases where the configuration for a host resource does not allow autoexecution, the enable setting allows firmware to disable or partially disable autoexecute functionality per resource, such as a resource that is caching or is doing error handling, that requires a logical block address ( LBA) translated resources.

According to a feature of the invention, the inline hardware engine includes a register for each logical host resource that links each host resource directly to the physical device and provides engine routing information to the physical device. Generated device operations are directed to the physical device described within these registers.

According to a feature of the invention, the inline hardware engine checks incoming commands to ensure that they meet the conditions of an automatically performed operation, such as a simple read or write with no ordering requirements.

According to a feature of the invention, the error and event handling code captures the completion of these automatically performed operations. This code handles successful completion and simply initiates sending a good response to the host.

Description of drawings

The present invention, together with the above and other objects and advantages, can be best understood from the following detailed description of preferred embodiments of the invention illustrated in the accompanying drawings, in which:

FIG. 1 is a schematic block diagram illustrating an exemplary system for implementing a hardware automatic device operation initiator according to a preferred embodiment;

Figure 2 illustrates example hardware operations for implementing a hardware automatic device operation enabler, according to a preferred embodiment;

Figure 3 illustrates an example automatically created chain implemented by a hardware automatic device operation enabler, according to a preferred embodiment;

Figure 4 shows an example error path for an example string of hardware command blocks implemented in accordance with a preferred embodiment;

Figures 5A and 5B illustrate an example of the handling of direct index errors according to a preferred embodiment;

Figures 6A and 6B illustrate examples of firmware (FW) events and controls according to a preferred embodiment;

7A and 7B show further examples of firmware (FW) events and controls according to a preferred embodiment;

Figure 8 illustrates an example normal flow implemented by a hardware automatic device operation enabler in accordance with a preferred embodiment;

Figure 9 shows an example for enabling and disabling event queue operations implemented by a hardware automatic device operation enabler in accordance with a preferred embodiment; and

10 is a flowchart of a design process used in semiconductor design, manufacturing and/or testing.

detailed description

In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings, which illustrate example embodiments by which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that when used in this specification, the term "comprising" specifies the presence of stated features, integers, steps, operations, elements and/or components, but does not exclude one or more other features, integers, steps, The presence or addition of operations, elements, components and/or groups of the foregoing.

According to features of the present invention, there is provided a method and controller for implementing a hardware automatic device operation enabler and a design structure on which the subject controller circuitry resides. The number of interactions between hardware and firmware is reduced to the point that firmware is only involved once for a host operation. The firmware does not need to see host requests, and does not need to build or even see any hardware control blocks. This removes at least 50% of the number of times the firmware needs to be touched and removes the entire burden of the build operation compared to conventional implementations. This yields significantly better performance through the storage subsystem and enables many emerging workloads that fit well with SSDs.

Referring now to the drawings, in FIG. 1 there is shown an input/output adapter (IOA) or controller, generally indicated by the numeral 100, in accordance with a preferred embodiment. Controller 100 includes a semiconductor chip 102 coupled to at least one processor complex 104 , where processor complex 104 includes one or more processors or central processing units (CPUs) 106 . Controller 100 includes control storage (CS) 108 , such as dynamic random access memory (DRAM) that provides command block, work queue, and event queue storage near CPU 106 . The controller 100 may include a non-volatile (NV) backup memory 110 and a data store (DS) 112 that provide data and temporary buffers for, for example, command block setup and processing performed by hardware. Controller 100 may include non-volatile random access memory (NVRAM) 114 and flash memory 116 .

According to a feature of the invention, controller 100 includes inline hardware engine 118 that receives host commands from host system 134 and evaluates the received commands for booting without involving firmware. The inline hardware engine 118 builds one or more strings or chains of hardware command blocks that execute the received command and begins execution of the one or more strings for the received command. The inline hardware engine 118 contains or is connected to a register 119 for each logical host resource that allows automatically executed commands to be enabled and disabled for that host resource. The inline hardware engine 118 contains or is connected to a register 119 for each logical host resource, which directly links each host resource to a physical device and provides engine routing information to that physical device. Device operations generated by the inline hardware engine 118 are directed to the physical device described within these registers 119 .

According to a feature of the invention, a register 119 is associated with each logical host resource. These registers 119 contain the ability to enable and disable auto-read and auto-write. These registers 119 may also contain the ability to enable and disable other hardware offload operations. When the auto-execute function is enabled, no action needs to be taken other than to turn on the enable register 119 . When the auto-execute feature is disabled, no action is required other than turning off the enable register. This is because any quiescent or synchronization that must be performed can also be performed regardless of the automatic execution function. When the auto-execute function is changed, for example, from auto-read and auto-write to only auto-read, the auto-execute function can be disabled entirely, and then only the desired function can be enabled. This ensures that there are no problems caused by atomicity issues. The physical routing information is all held in a single atomically modifiable register 119 . Thus, if the path to the drive changes or must fail over to another path, the routing information can be updated without interrupting the auto-execute function.

Controller semiconductor chip 102 includes multiple hardware engines for executing chains of hardware command blocks established by inline hardware engine 118, such as allocation engine 120A, host direct memory access (HDMA) engine 120H, serial attached SCSI (SAS ) engine 120S and deallocation engine 120D.

In accordance with features of the present invention, a large amount of conventional firmware functionality is moved to HW operations performed by the inline hardware engine 118 .

As shown, the controller semiconductor chip 102 includes a respective PCIe interface 128 with a Peripheral Component Interconnect Express (PCIe) high-speed system interconnect between the controller semiconductor chip 102 and the processor complex 104, and SAS controller 130 having a serial attached SCSI (SAS) high speed system interconnect between 102 and a plurality of storage devices 132 such as hard disk drives (HDD) or spin drives 132 and solid state drives ( SSD) 132. Host system 134 is connected to controller 100 using a PCIe express system interconnect. It should be understood that the external processor complex 104 is not required and may be embedded in the controller semiconductor chip 102 .

For example, the DS112 includes 8GB of DRAM that stores volatile and/or nonvolatile 4KB pages of data, a 32-byte cache line (CL), and a 32-byte Parity Update Footprint (PUFP), where one CL is used for each non-volatile page of the write cache in the contiguous region of the DS.

Controller semiconductor chip 102 and control store (CS) 108 store chains of hardware command blocks and other structures and command blocks built by inline hardware engine 118 , such as illustrated and described with respect to FIG. 3 .

Referring to FIG. 2, example hardware operations for implementing a hardware automatic device operation enabler, generally indicated by the numeral 200, are shown in accordance with a preferred embodiment. As indicated in block 202, processing of a received command or received operation begins.

An evaluation command is executed to determine whether the command can be started without involving firmware, as indicated in decision block 204 . When an operation is initiated from the host, the hardware fetches the control block describing the request, as it does for any request. When the control block arrives and is placed in memory, at decision block 204, the hardware interrogates the request. At decision block 204, the hardware then checks whether the operation points to a logical resource that allows the automatically executed operation. At decision block 204, the hardware checks whether the operation is a read or a write. At decision block 204, the hardware checks to see if the operation has only simple or untagged queue tags. At decision block 204, the hardware checks to see if there are no other complex requirements for the operation.

For example, at decision block 204, inline hardware engine 118 checks the logical host resource in register 119 to determine whether to allow auto-execution commands to be enabled and disabled for that host resource. The enable setting provided by register 119 allows firmware to disable or partially disable the auto-execute feature per resource where the configuration for a host resource, such as a host resource that is caching or is doing error handling, requires Resources for LBA translations. At decision block 204, the inline hardware engine 118 checks incoming commands to ensure that they meet the conditions for automatically performed operations, such as simple reads or writes with no ordering requirements, and the like. If at decision block 204 it is determined that the current configuration is not capable of using the HW auto-execute function, then as indicated in block 206 the received command is placed on the HW event queue.

If it is determined at decision block 204 that the current configuration is capable of using the HW auto-execute function, then as indicated at block 208, the inline hardware engine 118 builds one or more strings of hardware command blocks that execute read or write requests, and then begins the string implement. If the operation is a read and the above checks are met, the inline hardware engine 118 builds one or more strings of hardware command blocks that execute the request. For example, the hardware creates control blocks associated with incoming host operations in a 2K hardware buffer, such as illustrated and described with respect to FIG. 3 .

Direct indexing mode consists of a special set of pre-allocated resources that can be used on small operations to reduce overhead at block 208 through the resource allocator. If an incoming operation uses only one 4K page, the page is implicitly bound to each control block associated with the host operation. This single page can be used directly without going through the normal page allocation engine.

The error and event handling code captures the completion of these automatically performed operations, as indicated in decision block 210 . This code process completes successfully and simply initiates sending a good response to the host, as indicated in block 212 . Successful completion is only handled when the control block at the end of the string of hardware command blocks completes successfully. Successful completion causes the firmware to work on the operation only once per host request. Also, the firmware never needs to look at host requests and never needs to construct or even look at hardware control blocks.

The error and event handling code at decision block 210 handles the error completion of any hardware control blocks within the automatically executed string of hardware command blocks, as indicated in block 214 . The error handling code firmware evaluates the failed string and establishes the necessary controls to look like the code started the string of hardware command blocks. At block 214, the error handling code will then initiate error handling as if the automatic execution had not been initiated without firmware intervention. Essentially, this code converts an automated action into a normal non-automated action. At block 214, the error and event handling code handles the external synchronization and merge operations as if the automatic execution operations had been established and executed with the knowledge of the firmware. A sync or merge request goes through all possible control blocks to see if they are being executed, and if so, potentially flag the operation as requiring sync or merge work. In good completion, all external requests for synchronization or merging will be considered with a single if (if) check that checks a single variable for each operation. On error completion, after the operation is converted, all processing is done within the error-handling routine that handles normal non-automatic operation errors.

Referring now to FIG. 3 , there is shown an example automatically created chain, generally indicated by reference numeral 300 , implemented by a hardware automatic device operation enabler, in accordance with a preferred embodiment. The hardware HW interrogates incoming host requests and establishes the appropriate chain of operations. The automatically created chains 300 shown include a host write chain greater than 4K 302 , a host read chain greater than 4K 304 , a host write chain less than or equal to 4K 306 , and a host read chain less than or equal to 4K 308 . Host write chains 302 greater than 4K include operations that allocate pages or buffers to be used in transfers of data, transfer data from host memory across the PCIe bus into allocated buffers for writing Or transfer data from a buffer across the PCIe bus into host memory for a host direct memory access (HDMA) H operation that reads, writes data from a buffer to a drive, or reads data from a drive into an allocated buffer Serial Attached SCSI (SAS) S operations in an area and deallocation D operations that free pages or buffers.

The host read chain 304 greater than 4K includes the operations of allocate A, SASS, HDMAH, and deallocate D. The host write chain 306 less than or equal to 4K includes host direct memory access (HDMA) H and serial attached SCSI (SAS) S operations. Host read chain 302 less than or equal to 4K includes SASS and HDMAH operations.

In accordance with a feature of the invention, for operation of host write chain 306 and host read chain 308 less than or equal to 4K, pre-allocated pages associated with the 2K hardware control block being used are used. This avoids building and using allocation and deallocation control blocks in host write chain 306 and host read chain 308, and has performance impacts in two ways. First, this reduces latency by removing the requirement for the allocation engine to run before SAS or HDMA operations can begin. Second, it reduces the number of control-store interactions performed by the hardware. First, the two 16 or 32 byte control block writes to the control store are removed by avoiding the setup of allocating and deallocating control blocks. Next, by not chaining in the allocation/deallocation engine, fetching those mentioned control blocks is removed, saving even more control store operations. Finally, by not running the allocation and deallocation engine, neither the page table nor the page free list is read/written, saving another two to four accesses to the control store.

For operations that only touch a single 4K page, direct indexing mode is used, and direct indexing has one page pinned to each 2K hardware-controlled (HwCb) buffer. The use of preallocated pages or direct indexing mode is not a requirement for hardware autoexecution, but a performance enhancement that can be used by autoexecution. Each control block chain built has an event ID from the appropriate register set. Upon the successful completion of the last control block in the chain 302, 304, 306, 308 or the erroneous completion of any control block in the chain, this event ID is used to notify the firmware of the completion.

All data needed to create the allocation operation A and deallocation operation D is included in the host request. Based on the requested LBA and length, the span of the 4K aligned pages can be determined. If this number is greater than one, an allocation and deallocation control block is generated. If the number is less than one, preallocated implied pages are used. Both the allocation and deallocation control blocks will be generated with the page table destination/source in the unused portion of the 2K hardware control block associated with the incoming host operation.

In order to set up HDMA operation H, all data needed are included in the host request. The type of transfer, presence or absence of headers, required data checks, etc. are included in the host request. The destination or source host memory address is also in the host request.

To establish a SAS operation S, information from the host request and information on how to route to the physical drives are used. With the inline HW engine 118 of Figure 1, information from host requests is held in registers 119 for a given logical host resource. This information includes the chip or SAS engine number for the SAS engine that will handle the operation. This information also includes port numbers and device numbers. port number is the SAS port number attached to a given SAS engine. The device number is an index into the array maintained by the SAS engine, allowing the SAS engine to look up the SAS address for a given device 132 . Essentially, all the routing information needed by the hardware to reach the physical device 132 is stored in the registers 119 in the chip 102, and the hardware can reach it without firmware intervention. These registers 119 are set by firmware before enabling the auto-execute function.

Once the hardware control block is established as shown at block 208 in Figure 2, the hardware will start the operation in the same way that the firmware would start the operation. The entire chain of operations will be executed, and upon successful completion, the hardware will generate an event informing the firmware of the successful completion of the chain, as shown at block 212 in FIG. 2 . In this case, the firmware will catch the event, make sure nothing happened to track the event, and initiate a response to the host.

If the firmware needs to merge or synchronize all pending operations, as shown at block 214 in FIG. 2, an indication is placed in the control block associated with the host operation. Upon successful completion, if this indication is on, the firmware control block will be adjusted to mimic operations initiated by firmware. Completion will then be processed as if the firmware had initiated the operation, as shown at block 214 in FIG. 2 .

In case any part of the chain fails, e.g. as illustrated and described with respect to Figure 4, as if the chain was started by firmware, the hardware will stop the chain and generate a fault event for the failed control block in the chain to handle the HW Error completion of the command block, as shown by block 214 in FIG. 2 . The event ID routes the firmware to the correct event handler. The event handler will then change or populate the firmware control block associated or to be associated with the operation, if the operation was initiated by firmware. Once everything in the firmware is set up to mimic the control blocks that would have existed if the operation was initiated by the firmware, the firmware initiates handling of the failure event as if it were a failure of normal firmware initiated operation. From this point on, all error handling is the same as for normal firmware startup.

Referring now to FIG. 4 , there is shown an example error path, generally indicated by reference numeral 400 , for an example string of hardware command blocks implemented in accordance with a preferred embodiment. Error path 400 shows a host write chain 402 greater than 4K, including operations A, H, S, D, where the error is indicated in a Serial Attached SCSI (SAS) S block. When there is an error, an error event is generated for the failed HwCb. The firmware will convert the auto-started chain 402 into what looks like a FW-started chain, or a FW capability path operation/construction 404 . Most of the time, this just needs to turn on a bit, saying that the FW knows it's executing. Additionally, the constructor is run to build a table of virtual function pointers. Where everything looks like the FW has started this operation as a FW performance path operation/construct 404, all existing error handling code is used unchanged, as indicated in the existing error path 406 .

Referring now to Figures 5A and 5B, there is shown an example of the handling of direct indexing errors, indicated generally by reference numerals 500 and 510, respectively, in accordance with a preferred embodiment.

In FIG. 5A , an example 500 of handling of direct index errors includes a host write 502 of less than or equal to 4K, including operations H and S, where the error is indicated in a Serial Attached SCSI (SAS) S block. The firmware is unaware of the use of direct indexing. When writing the trace, allocation control block A and HDMA control block H are rebuilt to follow allocation A. This new chain is executed as indicated by chain A, H504. FW capability path operations/constructs 506 with errors in S-blocks are used for normal error handling.

In FIG. 5B, an example 510 of handling of direct index errors includes a host write 512 of less than or equal to 4K, including operations S and H, where the error is indicated in a Serial Attached SCSI (SAS) S block. On read failures, automatic reads using direct indexes are converted to performance-path reads that appear to be performed by the FW. Lost allocations A and deallocations D are not used during error handling. Once error handling has cleared the error, the entire operation is re-issued as a normal read operation. The difference between this and what was done before is that the existence of the allocation or deallocation control block is checked before the page is deallocated before restarting the operation.

Referring now to FIGS. 6A and 6B , there are shown examples of firmware (FW) events and controls, generally indicated by reference numerals 600 and 610 , respectively, in accordance with a preferred embodiment.

Referring also to Figures 7A and 7B, further examples of firmware (FW) events and controls, indicated generally by reference numerals 700 and 710, respectively, are shown in accordance with a preferred embodiment.

According to a feature of the invention, the examples of Figures 6A and 6B and Figures 7A and 7B generally deal with three different paths in the code that handle converting automatic SAS writes. First, freeze everything provided so that no new operations will be scheduled in the various engines. Next, checks are provided for three places where an action might be located. First, it may have gone through the HDMA engine. In this case, the operation is converted to a performance path write operation as if the FW had started it. Second, the operation may not have entered the HDMA engine. In this case, the HDMA control block is changed to be last in the chain so that when it does go to the HDMA engine, the chain does not continue past the HDMA engine (and thus looks like an automatic allocation and DMA operation). Finally, if the operation is in the HDMA engine, the operation is aborted. But this proves difficult because it is an asynchronous operation. An abort may miss an operation in the HDMA engine and the HDMA may complete quickly, in which case it is handled as if the operation had progressed beyond the HDMA engine. Alternatively, an abort would actually stop HDMA. In this case, sometimes this can be detected synchronously, and sometimes it can't. Where possible, normal error handling is used to get things right. If this is not possible to tell, then the assumption may have already been made HDMA, and thus the operation is handled as if the operation had progressed beyond the HDMA engine. Finally, in this case, the process receives an abort event for the HDMA control block for the chain that has been converted.

In FIG. 6A, an example 600 of FW events and controls includes a host write chain 602 greater than 4K, including operations A, H, S, D, with events indicated in host direct memory access (HDMA) H blocks. The FW translates operations into FW performance path operations/constructs 604, including performance path operations A, H, S, D.

In FIG. 6B, an example 610 of FW events and controls includes a host write chain 602 larger than 4K, including operations A, H, S, D, with events indicated in host direct memory access (HDMA) H blocks. FW converts operations to FW performance path operations/constructs 612, including performance path operations A, H.

In FIGS. 6A and 6B , the FW does not really know about these operations of the host write chain 602 . When FW wants to do some operation where operation needs to be stopped or stalled, as indicated in operation H, FW needs to know all operations, FW utilizes FW search through all possible HW automatic operations to convert operation and put operation Translates to performance path operations that look like FW-initiated, as illustrated by FW performance path operation/construct 604 in FIG. 6A and FW performance path operation/construct 612 in FIG. 6B. On write, operations may need to be converted to auto-allocate and DMA operations due to existing auto-allocate and DMA operations, which involves changing HwCb after HDMA operation H to end the chain.

In FIG. 7A, an example 700 of FW events and controls includes a host write chain 702 greater than 4K, including operations A, H, S, D, with events and aborts indicated in host direct memory access (HDMA) H blocks . FW converts operations to FW performance path operations/construction 704, including performance path operations A, H, S, D.

In FIG. 7B, an example 610 of FW events and controls includes a host write chain 702 greater than 4K, including operations A, H, S, D, with events and aborts indicated in host direct memory access (HDMA) H blocks . The FW converts operations to look like auto-allocate and DMA operations/constructs 712, including operations A, H.

In Figures 7A and 7B, if the HDMA engine is performing operation H when the switch is to be started, as indicated in host write chain 702, then HwCbH cannot be changed because it is already in process and cannot be allowed to continue Proceed as it may start the next HwCb. Thus, suspension of the HDMA operation is required. When the operation starts the next Cb in the chain, we assume that the abort missed this HDMA operation, and in this case, the operation is switched. If the chain is stopped, an abort event is generated and the chain is not switched. In some cases, the operation is switched when the abort may have missed the HDMA operation or not, and there is a need to deal with whether the operation was switched without actually completing the HDMA. An abort event on the HDMA indicates that the HDMA is aborted when the abort event arrives asynchronously. If the operation was switched, but then found to be HDMA aborted, the FW pointer is cleared, the HDMA operation is rebuilt to the end of the chain and reissued.

Referring now to FIG. 8 , there is shown an example normal flow or good path with events generated by a hardware automatic device operation enabler, generally indicated by reference numeral 800 , in accordance with a preferred embodiment. As indicated at block 802, a query to the Input/Output Adapter Request Control Block (IOARCB) is performed. The current configuration is capable of using the HW autoexecution function for the IOARCB queried at block 802, then the inline hardware engine 118 builds a chain of hardware command blocks that execute the IOARCB, as indicated at block 804, and then begins chain execution, as indicated in Indicated in blocks 806 , 808 , 810 , 812 of respective operations A, H, S, D 808 . As indicated in block 814, an event is generated. As indicated in block 816, FW processing completion is provided. The FW then initiates sending a response to the host as indicated in block 818 .

Referring now to FIG. 9 , there is shown an example for enabling and disabling event queue operations implemented by a hardware automatic device operation enabler, generally indicated by reference numeral 900 , in accordance with a preferred embodiment. Enabling is generally simple, the FW writes some bits into some per-resource processing hardware registers 119 of Figure 1, and after the bits are written, the HW automatically builds the chain for any new operations. Disabling is more complicated because there are some asynchronous issues to consider.

In FIG. 9 , the example enable and disable event queue process 1000 includes an event queue 902 with an unknown zone 904 shown between the last event 906 processed by the FW and the point 908 at which assistance is disabled and firmware events are received. The window of the unknown region 904 is reduced by switching all possible pending auxiliary operations. Once the firmware atomically disables the HW, no more automatic actions are generated. All subsequent operations after point 908 in event queue 902 where assistance is disabled and firmware events are received are not automatic operations. At the last event 906 handled by the FW, the transition is performed on all possible SAS auxiliary operations, so that there are no accidental automatic operation completions and the firmware sends itself an event on the event queue. By the FW sending an event to itself at 906 and receiving it at 908, the window of the unknown zone 904 is defined. Before the FW event, the HW can send an event saying it started automatic operation. The FW must filter these out and take into account the transitions it performs during disabling. After a FW event, the FW can stop filtering the event queue and return to normal processing of the event queue.

FIG. 10 shows a block diagram of an example design flow 1000 . Design flow 1000 may vary depending on the type of IC being designed. For example, the design flow 1000 for building an application specific IC (ASIC) may be different than the design flow 1000 for designing a standard component. Design structure 1002 is preferably an input to design process 1004 and may come from an IP provider, core developer, or other design firm, or may be generated by the operator of the design flow, or from other sources. Design structure 1002 includes controller 100 and chip 102 in the form of a schematic or HDL hardware description language, such as Verilog, VHDL, C, or the like. Design structure 1002 may be embodied on one or more machine-readable media. For example, design structure 1002 may be a text file or a graphical representation of controller 100 and chip 102 . Design process 1004 preferably synthesizes or converts controller 100 and chip 102 into netlist 1006, where netlist 1006 is, for example, wires, transistors, logic gates, control circuits, list of I/O, models, etc., and is recorded on at least one machine-readable medium. This may be an iterative process where netlist 1006 is resynthesized one or more times depending on the design specifications and parameters for controller 100 and chip 102 .

The design process 1004 can include using various inputs; for example, input from library elements 1008, design specifications 1010, characterization data 1012, verification data 1014, design rules 1016, and test data files 1018, where library elements 1008 can accommodate applications such as different A common set of components, circuits, and devices, including models, layouts, and symbolic representations, for a given fabrication technology of technology nodes 32nm, 45nm, 90nm, etc., and where test data files 1018 may include test patterns and other test information. Design process 1004 may also include, for example, standard circuit design processes such as timing analysis, verification, design rule checking, place and route operations, and the like. Those of ordinary skill in the art of integrated circuit design can recognize the extent to which electronic design automation tools and applications are possible for use in the design process 1004 without departing from the scope and spirit of the invention. The design structure of the present invention is not limited to any particular design flow.

The design process 1004 preferably converts the embodiment of the invention as shown in FIG. 1 into a second design structure 1020, along with any additional integrated circuit design or data, if applicable. Design structure 1020 resides on a storage medium in a data format for layout data exchange of integrated circuits, eg, information stored in GDSII (GDS2), GL1, OASIS, or any other suitable format for storing such design structures. Design structure 1020 may include information such as, for example, test data files, design content files, fabrication data, layout parameters, wires, metal levels, vias, shapes, data for routing through the manufacturing line, and semiconductor manufacturer generated Any other data required for the embodiment of the invention shown. Design structure 1020 may then proceed to stage 1022 where, for example, design structure 1020 is advanced to tape-out, issued to manufacturing, issued to a mask house, sent to another design house , is sent back to the consumer, etc.

While the invention has been described with reference to details of embodiments of the invention shown in the drawings, these details are not intended to limit the scope of the invention as claimed in the appended claims.

Claims (20)

1., for realizing a controller for hardware automatic equipment operation start device in computer systems, which, comprising:

Inline hardware engine, for Receiving Host order;

Order received by described inline hardware engine assessment starts for when not relating to firmware;

Described inline hardware engine sets up one or more chains of the hardware command block of the order received by performing; And

Described inline hardware engine starts to perform the described one or more chain for received order.

2. controller as claimed in claim 1, wherein said inline hardware engine completes the described one or more chain performed for received order, sends to start firmware the response be successfully completed to host computer system.

3. controller as claimed in claim 2, comprises described inline hardware engine and generates the event of notice firmware about the hardware command block completed for received order.

4. controller as claimed in claim 1, wherein said inline hardware engine comprises the predefined register for each Logical HEA resource, is activated to allow the order automatically performed and forbids each host resource.

5. controller as claimed in claim 1, wherein said inline hardware engine comprises the predefined register for each Logical HEA resource, so that each host resource is directly linked to physical equipment.

6. controller as claimed in claim 5, comprises the equipment operating that described inline hardware engine generates the interior described physical equipment described of the information pointed in a register.

7. controller as claimed in claim 1, the order received by wherein said inline hardware engine assessment checks for starting to comprise described inline hardware engine when not relating to firmware, to identify the read request or write request that do not have ordering requirements.

8. controller as claimed in claim 1, comprises mistake and event handling code, and described mistake and event handling code complete for the treatment of the mistake of the hardware command block in the chain of the hardware command block for received order.

9. controller as claimed in claim 8, wherein said mistake and event handling code process is synchronous and union operation.

10. controller as claimed in claim 1, one or more chains that wherein said inline hardware engine sets up the hardware command block of the order received by performing comprise described inline hardware engine and have direct index pattern for utilizing the predefined one group of pre-allocation resource being less than or equal to the order of one page for receiving to set up the chain of hardware command block.

11. controllers as claimed in claim 1, one or more chains that wherein said inline hardware engine sets up the hardware command block of the order received by performing comprise the chain that described inline hardware engine sets up the hardware command block performing read command, and described inline hardware engine sets up the chain of the hardware command block performing write order.

12. controllers as claimed in claim 1, the buffer zone page that the chain wherein performing the described hardware command block of read command comprises the distribution controll block of allocation buffer page, data read in Serial Attached SCSI (SAS) (SAS) the equipment operating controll block of distributed buffer zone page, host direct memory access (HDMA) controll block that transmits for data and release distribute deallocate controll block.

13. 1 kinds, for realizing the method for hardware automatic equipment operation start device in computer systems, which, comprising:

There is provided inline hardware engine for Receiving Host order;

Described inline hardware engine performs following steps:

Order received by assessment starts for when not relating to firmware;

Set up one or more strings of the hardware command block of the order received by performing; And

Start to perform the described one or more string for received order.

14. methods as claimed in claim 13, comprise described inline hardware engine and complete the described one or more chain performed for received order, send to start firmware the response be successfully completed to host computer system.

15. methods as claimed in claim 13, wherein provide described inline hardware engine to comprise the predefined register being provided for each Logical HEA resource, are activated to allow the order automatically performed and forbid each host resource.

16. methods as claimed in claim 13, wherein provide described inline hardware engine to comprise the predefined register being provided for each Logical HEA resource, so that each host resource is directly linked to physical equipment.

17. methods as claimed in claim 13, comprise and provide mistake and event handling code, and the mistake being used for the hardware command block in the chain of the hardware command block of received order for process completes.

18. methods as claimed in claim 13, comprise and provide mistake and event handling code, the synchronous and union operation for process.

19. 1 kinds, for realizing the controller of hardware automatic equipment operation start device in computer systems, which, comprising:

Inline hardware engine, for Receiving Host order;

Described inline hardware engine comprises the predefined register for each Logical HEA resource, is activated to allow the order automatically performed and forbids each host resource;

Order received by described inline hardware engine assessment starts for when not relating to firmware;

Described inline hardware engine sets up one or more chains of the hardware command block of the order received by performing; And

Described inline hardware engine starts to perform the one or more chains for received order.

20. controllers as claimed in claim 19, wherein said inline hardware engine also comprises the predefined register for each Logical HEA resource, so that each host resource is directly linked to physical equipment.