CA2029199A1 - Bus master command protocol - Google Patents

Abstract

Abstract A bus master interface command protocol for use with a computer system having an intelligent mass storage disk array subsystem, including a bus master and microprocessor controller. The command protocol permits the computer system to issue disk array commands to the controller at a logical level without having to issue disk specific commands. The disk array subsystem microprocessor controller reads the logical commands, translates the commands into smaller disk specific commands, and queues the disk specific commands for processing. Upon completion of the logical command, the bus master controller asserts control over the computer system bus and manages the transfer of data to or from the computer system memory. The management of the disk array subsystem and the transfer of data is effectively off-loaded from the system processor permitting more efficient use of the processor.

Description

P~

BUS MASTER COMMAND PROTOCOL

The present invention relates to the control of -~
multiple disk drives within computer systems, and more particularly to command protocol and definition used to facilitate high speed dat~ transfers for personal computer systems.

Microprocessors and the personal computers which utilize them have become more pow2r over the recent years.
Currently availabl~ personal computers have capabilities .:
easily exceeding ~he main~rame computers of 20 to 30 years ago a~d approach the capabiliti~s of many computers currently manu~actured. Microprocessors having word sizes of 32 bits wide are now widely available, whereas in the past 8 bits was conventional and 1~ bits was common.
Personal computer systems have developed over the years a~d new US2S are being discovered daily. The uses are varied and, as a result, have different requirements fsr variou~ subsystems forming a complete computer system.
Because of productio~ volume requirements and ~he reduced costs as volumes increase, it is desirable that as ~any common features as possible are combined into high volume units. This has happened in the per~onal computer area by developing a basic system unit which generally contains a power supply, provisions or physically mounting the various mass storage devices and a system board, which in turn incorporates a microprocessor, microprocessor related circuitry, connecto~s for receiving circuit boards containing other subsystems, circuitry r~lated to interfacing the circuit boards to the microprocessor, and memory. The use of connectors and interchangeable circuit boards allows subsystems o~ the desired capability for each computer system to be easily inco~porated into the computer system. The use of interchang~able circuit boards n~cessitated the developement of an interface or bus standard so that the subsystems could be easily designed and problems would not result from incompatible decisions by the system unit designers and the interchangeable circuit board desi~ners.
The u~e of interchangeable circuit boards and an interface standard, commonly called a bus specification because the various signals are provided to all the connectors ove~ a bus, was incorporated into the original International Business Machines Corporations (IBM) personal computer, the IBM PC. The IBM PC utilized in Intel Corporation 8088 as the microprocessor. The 8088 has an 8 bit, or 1 byte, external data interface but operates on a 16 bit word internally. The 8088 has 20 address lines, which means that it can directly address a maximum of 1 Mbyte of memory. In addition, the memory components available for incorporation in the original IBM
PC were relatively clow and expensive as compared to curr~nt components. The various subsystems such as video output units or mass storage units, were not complex and also had relatively low performance levels because of the relative simplicity of the devices available at a reasonabl~ costs at ~hat time.
With ~hese various factors and the component choices made in mind, an interface standard was developed and used in the ~BM PC. The standard utilized 20 addxess lines and 8 data lin~s, had individual lines to indicate input or ",.",. '', ;~ "~

,, ~
! '` ' ~ ~ ' ' 2 ~ L? ~

output (I/O~ space or memory space read/write operations, :~
and had limited availability of interrupts and direct memory access (D~A~ channels. The complexity of the available components did not require greater flexibility or capabilities of the interface standard to allow the necessary operations to occur. This interface standard wa~ satisfactory for a number of years.
As i~ inevitable in the computer and electronics industry, cap~bilities of the various components available increased dramatically. Memory component prices dropped in capacities and speeds increased. Performance rate and capacitles of the mass storage subsystems increased, generally by the incorporation of hard disk units for previous floppy disk units. The video processor technology improved so that high resolution color systems were reasonably affordable. These developments all pushed the capabilities of the existing IBM PC interface standard so that the numerous limitations in the interface standard became a problem. With the introduction by Intel Corporation of the 80286, IBM developed a new, more powerful personal computer called the AT. The 80286 has a 16 bit data path and 24 addre!3s lines so that it can directly address lS Mbytes of memory. In addition, the 80286 has an increased speed of operation and can easily perform many operations which taxed 8088 performance limits.
It was desired that the existing subsystem circuit boards be capable of being used in the new ~T, so the interface standard ~sed in the PC was utilized and extended~ A new interface standard was developed, which has become known as the industry standard architecture (ISA). A second connector for each location was added to contain additional lines fox the signals used in the extension. These lines included additional address and 3S data lines to allow tAe use of the 24 bit addressing capability and 16 bit data transfers, additional interrupt and direct memory access lines and lines to indicate , :;

~,, , ,: i, ::, i,, ' :'i : "
.. . . .
.: : .. .. .

whether the subsystems circuit board was capable of using the extended features. While the addxess values are presented by the 80286 micxoprocessor relatively early in the operation cycle, the PC interface standard could not S utilize ~h~ initial portions of the address availability because of different timing standards for the 8088 around which the PC int~rface was designed. This limited the speed at which operations could occur because they were now limited to the interface standard memory timing specifications and could not operate at the rates available with the 80~86. Therefore, the newly added addr~ss lines included address signals previous available, but ~he newly added signals were available at an early time in the cycle. This change in the address single timing allowed operations which utilized the extended portions of the architecture to operate aster.
With a higher performance components availabl~, it became possible to have a master unit other than the system microprocessor or direct memory access controller operating the bus. However, because of the need to cooperate with circuit boards which operated under the new 16 bit standard or the old 8 bit standard, each master unit was reguired to understand and operate wi~h all the possible combinations o~ circuit boards. This increased the complexity of the master unit and resulted in a duplication of components, because ~he master unit had to incorporate many of the functions and eatures already performed by the logic and circuitry on ~he system board and other master units. Additionally, the master unit was required to utilize the dixect memory access controller to gain control of tbe bus, limiting prioritizing and the number of master units possible in a given computer syste~.
The capability of components continued to increase.
Memory speeds and ~izes increased, mass storage units and size increased~ video unit resolutions increased and Intel introduced ~he 80386. The increased capabilities of the .
; , .. .

" : . ,: ,;~ . . .

components created a desire for the use of bus master unit~, but the performance of a bus master unit was limited by the ISA specification and capabilities. The 80386 could not be fully utilized because it offered the capability to directly address 4 Gbytes o memory using 32 bits of address and could perform 32 bit wide data transfers, while the ISA s~andard allowed only 16 bits of data and 24 bits of address. The local area network (LAN) concept, where information and file stored on one computer called server and distributad to local work stations having li~ited or no mass storage capabilities, started becoming practical with the relatively low cost of high capability of components needed for adequate servers and the low costs of the components for work stations. An ext~nsion similar to that performed in developing the ISA
could be implemented to utilize the 80386's capabilities.
However, this type of extension would have certain disadvantages. With the advent of the LAN concept and the high performan~e reguirements of the server and of video graphics work stations used in computer-added design and animation work, the need for a very high data transfer rates became critical. An extension similar to that perfo~med in developing the ISA would not provide this capability, even if slightly shorter standards cycle was provid~d, because this would still leave the per~ormance below desired levels.
With the increased p rformance of computer systems, it became apparent ~hat mass storage subsystems~ ~uch as fixed disk drives, played an increasingly important role in the transfer data to a~d from the computer system. In the past few years, a new trend in this storage subsystems has emerged for improving data trans~er performance, capacity and reliability. This is generally known as a disk array subsystem. One key reason for wanting to build a disk array subsyst~m is to crea e a logical device that has very high data tra~sfer rate. This may be accomplished by "ganging" multiple st~ndard disk drives together and trans f erring data to or from these ~rives to the sy~tem memory. If n drives are ganged together, then the effective data transfexred rate is increased n times.
This technique, called "striping" originated in the super computing environment where the transfer of large amounts of data to a~d from secondary storage is a frequent requirement. With ~his approach, the end physical drives would become a single logical device and may be implemented either through software or hardware.
A number of refer~nce articles on the design and management of disk arrays have been published in recent years. These include "Some Design Issues of Disk Arrays"
by Spencer Ng, April 198~ IEEE; "Disk Array Systems" by Wes E. Meador, April 1989 IEEE; and "A Case for Redundant Arrays of Inexpensive Disk~ (RAID)" by ~. Patterson, G.
Gibson and R. Catts report No. UCB/CSD 87/391, December 1~87, Computer Science Division, University of California, .
Burkley, California.

The present invention is directed towards a method for an intelligent disk array controller system, permitting the controller to manage the operation of an array of up to 8 standaxd integrated disk drives connected in drive pairs without significant supervision by the computer system host. Further, the present invention is directed toward a communications protocol between the disk array controller and a computer system host. The controller of the present invention provides for two communica~ions paths for commands and data through which the host may issue disk requests such as a read, write or diagnostic commands to the disk array. These communication path~ are known as the compatibility interface and the bus master interface. The compatibility interface and th~ bu~ master interface operate in parallel, and may be u~ed alternatively or concurrently to pass commands and data between th~ host and the disk drive array controllex. The controller of the present invention _7_ 72159-37 2~2~
i~ d~signed to further allow th~ host proc~ssor to be independ~t of the physiGal configuration o the a~ray and ~ive which make the disk array; the data distribution technigue used to ~pread tho data a~nong the drive~ in the S array; drive parity oper~tion; and IDost orror r~covery and fault tolerance activitie~.
The! communication mechanism betwee~ the disk array arid exi~ting llo~t driver ~o~tware within the pr~sent inven~ion is via ~e compatibility int~rfac~. This i~at~rfal:e ~llow~ operation o~ ~oftwar~ t~at expects a hardware int~rface co~p tible with e~cisting ~tandard ISA
hard disk regi~ter s~t .
The! eo~unication ~echanis~ between the disk ~rray and n~w ho t d~iv~r softwaro i~ through the bus mast~r inter3~ac~ controll~r (BM~C). Th~ controller i~ capable of dat~ transfer rate~ ~cro~s th~ EI5A l:~u~ ~t a rate o 32 M~ytes per ~e~cond usir~g 32 bit ~u3 ~a~'cer burst DMA ( type C) cycle~ a~ de~ined i~ EI';A ~p~cification ~:hrough the bu~ mast~r int~rf~ce ~ontrolls~
The pre~ent inv~rltion i~ direct~d toward a colo~and protocol for tho imple~ent~tion of 'chi~ high ~p~ed disk arr~y dat~ er. ~n 1~ pra~ent invention, th~ host ~ U~5 logic~l coD~aand~ to t~ di~X ~rr~y ~on~croller, a~
oppo~e~ to d~t~iled di~k iA~ormatio~, ~uch a~ disk driv~
nu~ber, h~, cylinder and s~ctor ir~formation. Th~se log~c~l r~au2~s ar~ proce~s~d by thl~ di~k ~rray cor~oll~r ~hic~ lop~ det~ d leval information or p~rfon~ g fwlc~ion~ w~ di~k array without placing thi- oYerh~d o~ th~ ~y~t~ ho~.
A ~e~ex under~tanding th~ of t~e invention can b~
had whon th~ ollo~ing d~tail~ de~crip~io~ of the pr~ r~d e~bodi~nt i~ con~id~d i~ conjunction with the ollowin~ dr~wing~ which:
Fig. 1 and 2 A and s are a schematic block diagram of a computer system incorporating the present invention;

, .

2 ~
Fig. 3 i~ ~ ~che~nai:ic block diagra~ of a disk array controller inco~orating ~che pre~ent invention;
Fig. 4 i~ ~ ~chematic block diagram of a bus master interface coaltroller incorporating ths~ preser~t invention;
S Figure 5 i~ a s~h~matic diagra~ depicting a cosunand list, including com~nand li~t head~!r and reguest blocks;
Figure 6 i~ a flow diagram depicting th~ manner in which I/O request3 ar~ ~ubmitted to ~ di~l~ array controll~r o~ the pres~nt invention;
Figurc 7 ifi i9. ~lo~ diagra~ showing the ~anner in which the di~k array controller notifie~ ~ ho~t processor or devic~ drivar tll~t th~ r~guest ha~ ~e~n co~pl~ted;
Figur~ 8 i~ ~ ~low ~iagr~m of the ~ann~r in which the m~thod o~ reser2t~ ventio~ i~ initiali2~d;
Figure 9 is a detailed flow diagram showing the mann~r ial which logical co~m~nd~ ~r~ ~rocessed;
Figure lOA and lOES aE~ flow diagram~ of th~ sp~cific mann~r in which th~ disk con~roll~r notifi~s the ho~t processor or dovic~ driver that ~he co~unand has comple~ed;
Figure 11 i8 1~, flow âiag.ram of th~ manner in which the present inY~n~ion proce~es intesrupt~ from oith~r the EISA bu~ ox di3k arr~y co~t~oller;
Figur* 12 i~ a ~low ~iagr~ o~ e rJ~anner in ~hich the preYe~nt i~av~n~io~ proc:e~l~e~ a RE~D co~m~nd;
Figlar~ 13 i~ ~ flow di~grazl of ~ ner in which t~ pre~nt i~v~tion proce~e~ l$~ co~and;
Figur~s 14~ ~nd 14B ~r~ flow diagrull~ o 'che manner i~ which th~ ~ros~n~ in~ tion ~t~ eonfiguration fox th~ d~k arr~y;
Figur~ 15 i$ ~ 10w ~ ra~ o~ thl! ~er in which the pr~s~nt inv@neion d~erDli~e~ configur~tion for dislc ~rr~y;
Figur2 16 i~ ~ ~lo~ di~gra~ o~ m~nner in whi~h th~ pr~ent i~von~io~l p~oce~ com1sand ~o identi y individu~1 di~k or di~ ar~ay eox~ollerl-;

,; , . . . . .

_9_ 72159-37 2 ~3 2 g '~
~ iguro~ 17A and 17~ are flow diagrams of tho manner in whieh ~h~ curr~nt invention ma~ag~s transf~r~ acro~s the ~IS~ bu~;
Figures 18A and 18~ aro flow diagra~s o~ the ~anner S in which the curren~ inventlon manag~ logic~l regues~
h~ving multipl~ locations or data;
Figure lg i8 ~ flow diagram o~ the m~nner in which ~h~ prosen~ inv~ntion m~nages a transfer gueue;
~ igure 20 i5 ~ flow di~gra~ of the mann~r in which the ~re~ent inv~ntion h~ndl~ a P~EK d~ta tran~er;
Figur~ 21 i~ ~ flow diagra~ of ~h~ manner in which tho pres-nt invention ~ana~c~ a POÆ dat~ t~an~fer;
Figure~ 22A and 22~ ar~ ~low dia~rams o~ the manner in which ~h~ pre~en~ inv~ntion will r~ad a reguest list to det~rmin~ initial validity;
Figure 23 is a flow diag.ram of the manner in which the ~r~s~nt inventlon determi~e~ whether a disk array configur~tior~ i~ v?~lid;
Figur~ 24 i~ a flow diagra~ of th~ ~anner in which ~o pre~ent in~ention mAn~ges notiication o comple~ion or ~rror~ in thc ~xecution of a r~quost;
Figur~ 25 i~ ~ flow diagrz~ o~ tho ~ann~r in which ~h~ pre~t i~v~tio~ ~y alt~rnately U8~ ~O notify the completion o ~ co~and;
Figur~ 25 i~ ~ flow ~i~gru~ of th~ ~anner in which ~h~ ~re~c~t i~v~ntion r~iew~ and d~te~ines ~h~ initial validi~y of ~ r~gu~t; ~nd Flgur~ 27 i~ 10~ di~gr~ o the ~anner in wh~ch the p~2~t invorltiorl d~r~ e~ ci~ic u~it i~fonm~io~ ~or 30 a unit within ~@~ k t~iYe~.

. .
. . . : ` :
:, `: :.; `", `.

.

Table of Contents . . " ., . , _ I. Computer System Overview II. Disk Array Controller III. Bus Master Int~rface Controller IV. Command Protocol and Definition V. System Operation A. Overview of Command Submission B. Overview of Command Completion Notification C. Command Protocol System 1. Initialization 2. Local Processor Interrupt Service Procedure 3. Logical Command Submission 4. Command List Parse/Review 1~ 5. Next Disk Request Review 6. Sca~ter/Gather Block Transer 7. BMIC Data Transfex 8. BMIC Data Transfer Queue 9. BMIC Data Read 10. BMIC Data Write 11. Peek Mode Data Tralns~er 12. Poke Mode Data Tr~nsfer 13. Command Completion Notification 14. Command Notification 15. Command Completion Post Notification 16. Configure Logical Unit 17. Sense Logical Unit Configuration 18. Sense Unit Status lg. Identify Controller or Disk 20. Logical Unit Configuration Check VI. Conclusio~
I. Com~uter System Overview:
Referring now to Figures 1 and 2, the letter C
designates generally a computer system incorporating the present invention. For clarity, system C is shown in two portions, with ~he interconnections hetween Figures 1 and 2 designated by reference to the circled numbers one to , , , . " : : . . ~ , ., " - .,.,~; " ., , ", ,, , : : ~

2 ~ f ~ 9 eight. System C is comprised of a number of block elements interconnected via four buses. Throughout this specification, signal mnemonics with an asterisk following the signal descriptors indicates the signal is active at a S logic low level. Signal mnemonics having numbers or ranges between angled brackets refer to those particular bits or positions in a bus.
In Figure 1, a computer syst~m is depicted. A
central process.ing unit CPU comprises a processor 20, a numerical coprocessor 22 and a cache memory controller 24 and associated logic circuits connected to a local processor bus 26. Associated with cache controller 24 is high speed cache data random access memory 28, noncacheable memory address map progrc~mming logic circuitry 30, noncacheable address memory 32, address exchange latch circuitry 34 and data e~change transceiver 36. Associated with the CPU also are local bus ready logic circuit 38, next address enable logic circuit 40 and bus request logic circuit 42.
The processor 20 is pre~erably an Intel 80386 microprocessor. The processor 20 has its control, address and data lines interfaced to the local processor bus 26.
The coprocessor 22 is pre~erably an Intel 80387 and/or Weitek WTL 3167 numeric coprocessor interfacing with the local processor bus 26 and the processor 20 in the conventional manner. The cach~a ram 28 is preferably suitable high-speed static random access memory which interfaces with t:he address and data elements of bus 26 under control of the cache controller 24 to carry out reguired cache memory operations. The cache controller 24 is preferably an Intel 82385 cache controller configured to operate in two-way set associative master mode. In the preferred embodimen~ ~he components are the 33 MHz versisns of the respective units. Address latch circuitry 34 and data transceiver 36 interface the cache controller 24 with the processor 20 and provid~ a local ~us interface between the local processor bus 26 and a host bus 44.

~ : . " ~ . .. . . .

-12~

Circuit 3~ is a logic circuit which provides a bus ready signal to control aceess to the local bus 26 and indicate when the next cycle can begin. The enable circuit 40 is utiliz~d to indicate that ~he next address of data or code to be utilized by subsystem elements in pipelined address mode can be placed on the local bus 26.
Noncacheabl~ memory ~ddress map programmer 30 cooperates with the processor 20 and the noncacheable address memory 32 to map noncacheable memory locations.
The noncacheable address memory 32 is utilized to designate areas of system memory that are noncacheable to avoid many types o~ cache memory incoherency. The bus request logic circuit 4~ is utilized by tha processor 20 and associated elements to request access to the host bus 44 in situations such as when requested data is not located in the cache memory 28 and access to system memory is required.
In the drawings, system C is configured having the processor bus 26, the host bus 44, an extended industry standard architecture (EISA) bus 46 (Fig. 2~ and an X bus 90. The details of the portion of th~ system illustrated in Figure 2 and not discusRed in detail below are not significant to the present invention other than to illustrate an example of a fully configured computer system. The EISA specification Version 3.1 is included as App~ndix 1 to ~ully explain requirements of an EISA
system. The portion of ystem C illustrated in Fig. 2 is e~sentially a configured EISA system which includes the necessary EISA bus 46, and EISA bus controller 48, data latches and transceivers 50 and address latches and buffers 52 to interface between the EISA bus 46 and the host bus 44. Also illustrated in Figure 2 i an integrated syst~m peripheral 54, which incorporates a number of the element~ used in an EISA-based computer system.
The integrated system peripheral (ISP) 54 includes a direct memory access controller 56 for controlling access .: ~ . ':' :' : :, : : : ::
,, .. : . :

to main memory 58 (Fig. 1~ or memory contained in EISA
slots and input/output (I/0) locatio~s without the need for access to the processor 20. The main memory array 58 i5 considered to b* local memory and comprises a memory circuit array of size suitable to accommodate the particular requirements of the system. Th~ ISP 54 also ineludes interrupt controllers 70, nonmaskable interrupt logic 72 and system timers 74 which allow control of interrupt signals and generate necessary timing signals and wait states in a manner according to the EISA
specification and conv~ntio~al practice. In the preferred embodiment, processor generated interrupt request are controlled via dual interrupt control circuits emulating and extending conventional Intel 8259 interrupt controllers. The ISP 54 also includes bus arbitration logic 75 which, in cooperation with the bus controller 48, controls and arbitrates among the various requests for the EISA bus 46 by the cache contro.Ller 24, the DMA controller 56 and bus master devices located on the EISA bus 46.
The main memory array 58 iS preferably dynamic random access memory. Memory 58 interfaces with the host bus 44 via a data buffer circuit 60, a memory controller circuit 62 and a memory m~pper 68. The bufer 60 performs data transceiving and parity generating and checking functions.
The m~mory controller 62 and memory ~apper 68 interface with the ~emory 58 via address multiplexer and column addres~ strobe buffers 66 and row address enable lo~ic - circuit 64.
The EISA bus 46 includes ISA and EISA control buses 76 and 78, ISA and EIS~ control buses 80 and 82 and address buses 84, 86 and 8A. System peripherals are interfaced via the X bus 90 in combination with the ISA
control bus 76 fro~ the EISA bus 46. Control and data/address transfer for the X bus 90 are facilitated by X bus control logic 92, data transceivers 94 and address latches 96.

- .. , ~ :
; , ,:, :', ' ' ' ':' ': :. , :

Attached to the X bus 90 are various peripheral devices such as keyboard/mouse controller 98 which interfaces the X bus 90 with a suitable keyboard and mouse via connectors 100 and 102, resp~ctively. Also attached to the X bus 90 are read only memory circuits 106 which contain basic operations software for the system C and for system videa operations. A serial communications port 108 is also connected to the system C via the X bus 90.
Floppy and fixed disk support, a parallel port, a second serial port, and video support circuits are provided in block circuit 110.
II. Disk Axray Controller:
The disk array controller 112 is connected to the EISA bus 46 to provide for the communication ~f data and address information through the EISA bus. Fixed disk connectors 11~ are connected to the fixed disk support system and are in turn connected to a fixed disk array 116. Figure 3 is a schematic block diagram o the disk array controller 112 incorporating the present invention.
The disX array controller 112 .incorporating the present invention includes a hus master interface controller 118 tBMIC), preferably an Intel Co~oration 82355, which is designed for use in a 32 bit EISA bus master expansion board and provides all EISA control, address, and data signals necessary for transfers across the EISA bus. The BMIC 118 supports 16 and 32 bit burst transfers between the disk array system and system memory. Further, the BMIC is capable of converting a tr~ns~er to two 32 bit transfers if the memory to be transferred is nonburstable.
Additionally, BMIC 118 provides for the transfers of varying data sizes betwean an expansion board and EISA and ISA devices.
The disk array controller 112 o~ the present invention also includes a compatibility port controller 120 (CPC). ~he CPC 120 is designed as a communication mechanism between the EISA bus 46 and existing host driver :; ,, - , , . .,: ~ ~ .. . .. . .. .

-15~

software not designed to take advantage o EISA
capabilities .
Also includ d in the disk array controll~r 112 which incorporates the presen~ invention is a microprocessor 122, preferably an Intel Corporation 80186 microprocessor.
The local processor 122 has its control, address and data lines interfaced to the BMIC 118, CPC 120, and transfer channel cohtroller 124. Further, the local processor 122 is also interfaced to local read only memory (ROM) 126 and d~n~mic random access memory (RAM) 128 located within the disk array controller 112.
The transfer channel controller 124 (TCC) controls the operation of four major DMA channels that access a static RAM transfer buffer 130. The TCC 124 assigns DMA
channels to the 3MIC 118, the CPC 120 the local processor 122 and to the disk array DMA channel 114. The TCC 124 receives regueæts from the four channels and assigns each channel a priority level. The local processor 122 has the highest priority level. The CPC 120 channel has the second highest priority level. The BMIC 118 channel has the third highest priority level and the disk array DMA
channel 114 has ~he lowest prioriLty level.
The disk array DMA channel 114 is shared by four disk ~rives subchannels. The four disk drive subchannels may be assigned to any one of eight different disk drives residing in the disk array. The four drive subchann~ls have equal priority within the disk array DMA channel.
- The subchannels are rotated ~ually to become the source for the disk array D~A channel. One of the subchannels is inserted in rotation only if it has an active DMA request.
The remaining thr~e subchannels ar~ always active in the rotation.
I~ the present invention a request is submitted to the disk array controller 112 through the BMIC 118. The local processor 122 on receiving this request through the BMIC 118 builds a data structure in local processor RAM
memory 128. This data ~txucture is also known as a , .. . . ..

, , ., , . . .

~` ' ` , ~

command list and may be a simple read or write request directed to the disk array, or it may be a more elaborate set of request containing multiple read/write or diagnostic and configuration reguests. The co~mand list is then submitted to the local processor 122 for processing accordlng to the method of the present invention.
The local process 122 first translates the co~mand list or "logical command" into a series of smaller command reguests, described hereinafter in Fig. 5. These command requests may include disk I/O operations or other diagnostic functions. Where the command requests are non-I/O operations, the local processor places them in a queue for execution. Where the command requests are diracted toward I/O functions, the local processor performs a second set of translations to generate drive regue~ts which include specific disk parameters such as head, cylinder and sector information related to the souxce or target address for any transfer.
The drive requests are al~so placed in queue for execution. The local processor 122 will select the first command in queue for execution. The local processor 12~
will process the command in conjunction with the TCC 124 to manage transfer of data into or out of the disk array into a transfer buffer. The local procesæor 122 will then load the BMIC 118 registers wi~h transfer information and the BMIC 118 will manage the transfer between the host and di~k array.
Once the execution of the command list is complete, the local processor 122 notifies the operating system device driver. The submission of the command list and the notification of a command list completion are achieved by a protocol which uses the BMIC 118 I/O registers. To allow multiple outstanding reguests to ~he disk array controller 112, these I/O registers are divided into two channels: a command list submit channel and a command list complete channel.

,:

$ ~

III. Bus Master Interface Controller:
Fig. 4 is a schematic block diagram of BMIC 11~.
What follows is a brief discussion of the functions and features of the BMIC 118.
In EISA slave mode, ~he BMIC 118 monitors the EISA
bus 46 address lines ~or general I/O addre~s decoding, slot-specific address decoding, and shared register 144 accessing. During slave mode operations, all BMIC 118 internal registers are accessible through the local processor interface 1~2, and all shared registers 144 are accessible to the EISA bus 46 or local processor 122 through ~he EISA interface 1~0 or the local processor interfac~ 142 respectively.
In EISA master ~ode, the BMIC 118 becomes the master o~ the EISA bus 46. It may perform bursts, nonburst, mism~tched or peek/poke data transfers. During master mode operations, all internal registers of the BMIC 118 are accessible to the local processor 1?2 (Fig. 33 through the local processor interace 142 of the BMI~ 118. The arbiter portion of the EISA interface 140 determines which mode the BMIC 118 is in; perfol~s EISA arbitration; and provides the contxol signal necessary to regulate the slave and mastex activities int~ernal to t~e BMIC 118. In slave mode, the arbiter portion of the EISA interfac* 140 also mediatec between ~he EISA side ~nd thP local side during shar~d regis~er 144 acce-~ses.
Local CPU EISA 1/0 Shared Reg. Only Reg. Addres~ Da'ca Accessin~_ Accessing Decodin~ Transfer~
EISA Slsve Mode YES YESYES NO
EISA Master Mode YES YESNO YES
The EISA interface and arbitex 140 contains two identical independent trans~er channels which are co~figurable to run either burst or nonburst cycles to and from syst~m memory 58 (Fig. 1~. The BMIC 118 will automatically run nonburst or mismatched cycles if the memory addressed ~y ~he BMIC 118 cannot run burst cycles.

.: : ~ i: : ' :: ' ' :
: ~ . , . , :: : . .,: .. ,.. : : , :
... .: . , .: . : :,: . -:
: : :., : , :
... . :.

Mismatched cycles will be run if data size translation is required from 32 bit to 16 bit or 8 bit.
Each transfer channel has three sets of reglsters to regulate data transfers. These are the base register group, the current register group, and the data ~tatus/control register group. This implementation of a triple register set allows the local processor 122 to program the next transfer on th~ channel while the current transfer is being executed.
The base register contains seven 8 bit registers.
These regist~rs are programmed by the local processor 122 when a trans fer is reguired across one of the channels.
Four transfer channel base address registers are combined to form the starting 32-bit EISA address to be used during the transfer. The remaining three registers are the transfer channel base count registers. The base count registers are utilized to det~rmine the number of transfers to be performed. The nu~ber of bits which can be transferred ranges from l bi1: to 4 Gbytes. The most significant bit of the transfer channel base count register is used to control ~he start of the transfer and the second most significant bit is used to control the direction o~ the transfer.
The current register set contains seven registers, each o which corre~pond to a bAse register. These registers are loaded from the base registers. The tran~er channel current address registers contain the 32 bit real~time EISA memory addres~es. The transfer channel current coun~ registers contain the number of bits remaining to be transferred on the channel. The current register set may be read by the local proce~sor 122 ( Fig.
3) through the local processor interface 142. The status/control register fiet contains three registers: th~
transer chan~el strobe xegister, the transfer channel con~iguration register and ~he transfer channel status register. rhe transfer channel strobe re~ister is used to initiate the transfer o~ data from the base register set :: :. ... .. : ,............. . ; .

-19- ~s~

associated current register. A transfer reguest for the channel will b~ gener~ted following the current register load. Th~ transfer channel configuration register is used to program the mode of the transfer. The transfer channel status register provides current FIFO 146 and transfer channel status.
In initializing a transfer over either o the two transfer channels, the present invention first determines whether the base registers for the desired transfer channel are available. The local processor 122 programs or loads the transfer channel's base register set with the desired transfer information. The local processor 122 then loads the current register set from the base register and schedules a regue~t by writing to th~ channel's transfer strobe register. If a transfer is in progress on the reguested channel, the b~se to current register load will take place immediately after the data transfer on the requested channel has been completed.
The BMIC 118 may be progr~lmed for burst or nonburst, data transfers to and from EISA memory. This is determined by a write to the channel configuration register. I~ a burst mode is e;nabled, BMIC 118 will look for a slave buxst signal at the beginning of the transfer to determine if the slave device that is being addressed is capable of running burst cycles. If the slave d~vice does not respond with an active slave burst signal, BMIC
118 will not attempt to make a burst transfer and will proceed with either a nonburst or mismatched data transfer.
In order to allow the local processor 122 (Fig. 3) to communicat~ with other devices in ~he computer system C
(Figs. 1, 2), the method of th~ present invention permits the local processor 122 to e~ecute individu~l I/O or memory cycles over ~he EISA bus 46. These cycles can be thought of as beinq similar to "peek" and "poke"
statements in tbe BASIC programming language. Th2se cycles may be reads, writes or loc~ed exchanges in 8, 16, 24 or 32 bit value~. PEEK/POKE transfer cycles must be contained within a single double word. The peek/poke operation requires four 8 bit peek/poke address registers which are combined to provide the 32 bit peek/poke address; an 8 b.it peek/poke control re~ister which contains the bits defining whether the cycle is I/O or memory, peek ~read)/poke (write~ or locked exchange, and which bit enabl~s are to be active during the cycle; and four 8-bit peek/poke data registers which are used to hold the data for the peek/poke cycle. To do an individual write cycle (poke ), the local processor 122 loads the peek/poke address register to specify the 32 bit memory address or the 16 bit I/0 address. The local processor 122 then loads the data to be transferred into ~he 15 peek/poke data register set in ~he appropriate bit positions in ~he data register sets such that the data is transferred on the correct bit lanes during a 3~ bit bus mast~r txansfer. The local processor 122 then loads the peek~poke control registers to specify the cycle type and to initiate the data transfer cycle. Bit 2 in the local status/control register will be set to a 1 by the BMIC 118 to indicate that a peek/poke request is pending and that the peek/poke registers are busy. When the poke cycle has finished executing on the EISA bus 46 the peek/poke status bit in local status/control register will return to normal (O). To perform an individual read cycle (peek), the local processor 122 loads the the 32 bit memory address into the peek/poke address register. Th~ local processor 122 then loads the peek/poke control register to initiate the read cycle. The peek/poke cycle bit 2 in the local status/control register will be set high by the BMIC 118 and remain active until the peek cycle finishes on the EISA bus 46. The local processor 122 can then read the data from the peek/poke data regist~r. When a locked exchange cycle is requested by the local processor 122, a peek cycle is scheduled first and then immediately ollowing by a poke cycle. A "LOCK" signal is asserted , , :, , ~ ::: i :;

. ,:

during the locked exchange ~ycle to indicate that no other access tv the addressed location may be made.
The disk controller 112 will begin master mode operation any time a transfer request is pending. If more than one transfer request is pending, the disk controll~r 112 will service them in the following order: Peek/poke cycle~ have ~he highest priority access to the EIS~ bus 46, followed by the two data channels. Once the disk controller 112 has gained control of the EISA bus 46, the controller will fir~t perform any peek, poke, or locked exchange transfers that may be pending. If there are no peek, poke or locked exchange transfers pending, the disk controller 112 will run data transfers initiate by either of the two transfer channels. The two transfer channels haYe equal priority with respect to each other and are serviced in an alternating fashion. The disk controller will continue to assert ownership of the EISA hus 46 until it has serviced all outstanding data transfer request or it is preempted from the EISA bus 46. The disk controller 112 may be configured to relinquish the EISA bus 46 immediately or for set time periods after a pr~empt signal is received acxoss the EIS~ bus.
The transfer buffer interface 148 portion of the BMIC
118 provides for signals essent:ial ~or interfacing to the disk array controller 112 to the physical disk array. The transfer buffer interace 148 is connected to ~ high speed data transfer controller and utilizes simple logic similar to that used in traditional DMA designs. This interface includes a 16 bit data bus, one clock input and seven control signals. Th~ 16 data lines are used by the BMIC
118 to transfer ~he data to and from the transfer controller 124 (Fig. 3) in the disk array controller 112.
The BMIC 118 automatically assembles the data received from the transfer controller 124 into 32 bit double words 35 for 32 bit transfers over the EISA blls ~S. The data lines are also used by th~ BMIC 118 to transport int~rnally generated transfer staxt and real time addresses to the . ~
~ -.
.. , . : : .. . :. :, ... . , , ~ .. ~ . , .
: . :, ~ ~ . , . . :
' , .' .. ' .. ,. : . :: , .
~ , -22~

local processor 122 for use during data transfers. The transfer data buffer interface 148 includes four 8 bit transfer buffer interface registers: two base registers and two current registers all of which may be programmed with 16 bit start addresses by the local processor lZ2.
Each transfer channel has an associated base and current register pair. The base registers contain the start addr~ss and the c~lrrent reglst~rs provide the real^time addresses used to track the current to transf~r. The current registers automatically adva~ce address 1 each time a 16 bit word is transferred across the transfer buffer interface 148. The 16 bit start address is transferred from ~he transfer buffer interface 148 to the transfer channel controller 12~ (Fig. 3) at the beginning of all new data transfers. The contents of the transfer buffer interface 14~ base re~isters are transferred to the transfar buffer interface 148 current registers. The BMIC
118 provides a load signal which may be used to latch the start addre~s into an extexnal address counter for use by ~0 th~ transfer channel controller 124.
The BMIC 118 may also be programmed by ~he local processor 122 (Fig. 3) to generate the transfer address each tim~ an associated channel regains control of the EISA bus 46, in which instance, the address in the base register set i~ also the address in the real time register set. By programming bit 7 in ~he channel configuration register to a "1", a start addre~s will be transferred to the trans~er channel conkroller 124 at ~he begi~ning of all new tr~nsfers and the real time addresses will be transferr~d Pach time the associated channel reyains co~trol of the EISA bus 46. If bit 7 in the channel configuration register is set to a "O", the transfer start addres~ will be transferred at the beginning of all new transfers and the real-time address need not be tran~ferred to the current channel configuration register.
The BMIC 118 also include~ two identical first in first out buffers ( FIFOs ), one per a transfer channel and ; ~ . .
...

:, ~

-23~

a common data aligner for data transfers between computer system memory 58 and the disk array controller. The primary function of the FIFO/data aligner unit 146 is to isolat~ and simplify timing relationships between the EISA
bus ~6 and the d~vices in the disk array controller 112.
The FIFO 146 allow the timing on the disk array controller 112 side of the BMIC 118 to be basPd on locally generated clock signals. This local clock may be independ~nt o~ the EISA bus clock ~ignal that governs EISA bus 46 timing.
The FIFO also provides latency protection for wait states generated on ei~her the EISA bus 46 or the disk array controller. Each FIFO 146 withi~ the BMIC 118 is 24 bytes in size. The transfer data is loaded into the FIFOs from either the disk array controller 112 or the EISA bu~ 46 side, given the direction of the data transfer. The data is written into the FIFO as a d~uble word during the data transfer, However, if the data is not a double word aligned, partial FIFO loads w.ill be formed at th~
beginning or end o a transfer depending on th~ bit count, address program and the direction of the transfer. The condition o the FIFOs 146 may be determined by from the transfer channel status register set which will indicate whether ~he FIFOs 146 are ~talled or active. A FIFO stall is defined as a FIFO that is full during an EISA read or empty during an EISA write. In either instance, the transfer channel contrQller 124 will be unable to maintain data transfer reguested by the EISA device. If a FIFO
stall occurs, the data transfer will be halted and the BMIC 118 will ei~h~r service the transfer reguest with the highest priority or relinquish the EISA bus 46 to the comput~r cystem.
The data aligner function arrang~s the 16-bit data ..
from the transfer channel controller 124 into an arbitrary bit alignment into ~ystem memory 58. The dat~ aligner also performs the assembly and disassembly of the EISA
dat~ during the txansfer. The data aligner 146 is also used to arrange ~it alignment or the EISA bus 46 in the -24~

event of a ~isaligned double word bsundary. The data aligner 146 will penmit the BMIC 118 to do partial double word transfers as required at the beginning and the ~nd of all such transfers.
The local processor interface 142 portion of the BMIC
118 contains two 8-bit reglsters through which the local pro~essor 122 (Fig. 3~ may access all the BMICs 118 internal registers. The registers are mapped into the local processor interface 142 and include a local data registers and a local inde~ r~gister. These registers are s~lected by the local processor 122 through the local processor interface 142 address lines. The local status/control register is also directly mapped into the local processor interface 142 and is used to provide the local processor 122 with interrupt peek/poke and base register status.
The local processor 122 (Fig. 3) and the EISA bus 46 communicate with each other through a set of command/status registers known as the shared I/0 registers ~0 144. The shared registers 144 include a set of mailbox registers, semaphore ports and doorbell registers. The mailbox registers are used to pass instructions and data to between th~ local processor and the EISA bus 46 and are controlled by ~he semaphore ports. The doorbell regi~ter set is utilized ~o in~orm the local processor 122 or EISA
bus 46 side of ~he app~arance of new messages. Also ;.
included as part o~ ~he shared I/0 register et 144 are identification registers which are used to support EISA
identification functions.
The two semaphore ports withi~ ~he shared I~0 register 144 are used for set and test functions in the I/O space. The ports are used to lock access to mailbox registexs. Each of the two semaphore ports consist of a ~emaphore flag bit and a semapbore test bit. When a write occur~ to the semaphore flag bit to either the EISA
interface 140 or ~he local processor interface 142, the old value o~ the fie~aphore flag bit is copied to ~he ,:
~ ' ', ', !

appropriate semaphore test bit. The old value of the semaphore flag bit is then available and the test bit to be read bacX by either the local processor 122 or a device on the EISA bus 46. If the value read back from the S semaphore test bit is a "1", the requested resource is unavailable for use. Conversely, if the value read back is a "0", the requested resource is available for use and will be locked by the requesting processor or bus master.
The mailbox register set comprises a set of sixteen 8-bit general-purpose registers utilized to pass information between the disk array controller and the EISA
system C. The sixteen registers are mapped continuously into EISA slot-specific I/O space and may be accessed as bits, words or double words. The registers may be used directly to pass command and status information or may be used as pointers to larger command blocks in memory. The mailbox register~ may be read or written at either time from either the EISA bus 46 or the local processor interface 142. The mailbox register s~t also includes an internal arbitration scheme which will prevent the existence of indeterminate bits in the event there is a simultaneous read and write fro~ both sides o the mailbox register.
The shared I/O register 144 set also includes ~wo 8-bit doorbell interrupt/status registers; one assigned to the EISA side and one assigned to the disk array controller side. The EISA system doorbell register set is utilized by the local processor 122 to request service from ~he EISA ~ide of th~ BMIC and the local doorbell register is utilized by a devlce on the EISA side of the BMIC 118 to send an intexrupt request to the local pro~essor 122 on the disk array controller. The 8-bits in each doorbell register permit up to eight separate devices or events in each direction ts have interrupt request simultaneously pending. Each doorbell register has an associated 8-bit interrupt enable register which may be used to enable or disable the interrupts for the doorbell ., :- ,..: ,.,, , ,. , , , :

- " . .... ... . .

--2 6-- r~

register on an individual basis. The BMIC lla also includ2s a system interrupt enable/control register and a local status/control register used to disable the system and local interrupts and to verify the status of the system and local interrupts on a global basis. Each device or event that may interrupt the disk array controller 112 may be assigned a bit position within the BMIC's 118 local interrupt/status doorbell register. When the device on the EISA bus 46 attempts to send an interrupt reguest to the disk array controller, it writes to the local interrupt/status doorbell register from the EISA side with the devices assigned bit position set active. This will set ~hat bit in the local interrupt/status doorbell register but leave other bits in the register unaffected. If that bit position has not been disabled by the system interrupt enable/control register, the interrupt signal will be passed on through .
the local processor interface 142 to the local processor 122. When the local processor 122 services the interrupt, it will read the local statu~/control register to determine the source of the int:errupt~ If the control register indicates that the local doorbell register is one ;.
of the enabled interrupt sources, the local processor 122 will read the local doorbell register to determine which bits are active and the requesting interrupts. The local processor services one of ~he request from the local doorbell register, it will write to the local doorbell regis~er with th~ bit position set. This will cause that bit in the local doorbell register to reset but the other bits will remain unaffected.
The method of the present invention is implemented as a number of applicatio~ tasks ruDning on the local processor 122 (Fig. 3). Because of the nature of interactive input/output operations, it is impractical for the present invention to operate as a single batch task on a local processor 122. Accordingly, th~ local processor 122 utilizes a real time multitasking system which permits -27~

multiple tasks to be addressed by the local processor 122, including the present invention. Prefer~ly, the operating system on the local processor 122 is the AMX86 Multitasking Executive by Kadak Products Limited. The AMX
operating system kernel provides a number of system services i~ addition to the applica~.ions set forth the method present invention.
IV. Command Protocol Definition:
Referring now to Fiy. 5, the method of the present invention includes the development of a data structure for the disk array controller 112 known as a command list 200.
The command list 200 consists of a command list header 202, followed by a variable number of request block~ 204.
The request blocks are variable in length and may be any :L5 combination of I/0 requests which will be d~scribed further below. A command list 200 typically contains a number of related request blocks 204; from 1 to any number that take up less than 16 Kbytes o memory. The command list header 202 contains data that applies to all reguest blocks 204 in a given command list 200: logical drive number, priority and control flags. The request blocks 204 consist of a re~uest block header 206 and other requested parameters, given the nature of the request.
The request block header 206 has a fixed length, whereas other reguest parameters are variable in length.
The individual reguest blocks 204 each represent an individual I/0 request. By forming a command list 200 out of sevesal individual re~uest blocks, and submitting the comma~d list 200 to the disk array controller 112 (Fig.
2), the computer system C microprocessor 20 overhead is reduced.
Still referring to Fig. 5, a command list header 202 contains informatio~ that applie~ to each of the regues~
blocks 204 contained in th~ command li~t 200. The command list header 202 is a total of 4 bytes in length. The logical drive number specifie6 to which logical drive that all reguest blocks 204 wi~hin the command list 200 apply.

., -28~

The method of the present invention permits a total of 256 logical drives to be specified. The priority bit is used to provide control over the processing of a command list.
The disk axray controller 112 is cap~ble of operating upon many command list concurrently. In specifying priority ~he method of the present invention permits a command list to be processed prior to those already scheduled for processing by the disk array controller. The control flag bytes under the method of ~he present invention are used for error processing and ordering of request o~ the same priority. Ordered reguests are scheduled according to priority, however, they are placed after all previous request of the s~me priority. If all requests are of the same priority and the order flag is set, the request are :*
perform~d on a first come, first-serve basis.
Error condition reporting options are specified by error flags in the control flag bytes. In the avent of an error, the disk array controller 112 can either: notify the reguesting device and cont:inue processing reguest block~ 204 in ~he list; notify ~he reguesting device and stop processing of all other rlequest blocks 204 in the list; or not notify the reguest:ing device of the error.
In all instances, an error cod~ will be returned in the command list status register at the time the next command list comple~e noti~ication and in the error code field in ~he reguest block 204 where the error occurred. Further, notification of completion may be set for each individual request block 204 or for the entire command list 200. In the event th~ EISA bus 46 is to be notified each time a reguest block has been completed a "notify on completion of every reguest" flag may be set in the control flags field.
A request block 204 is comprised of two parts, a fixed length reguest header 206 and variable length parameter list 208. The parameters are created as data structures known as scatter/gather (S/G) descriptor counters which define data transfer addresses. The ;;

': ' i ". , : ' request header 206 fields contain a link to the next request block 204, the I/0 command, space for a return status, a block addres and a block count, and a count o ~he scatter~gather descriptor structure elements for two S/G descriptor counters. The request header is a total of 12 bytes in leng~h.
The scatter/gather descriptor counters are used to designat~ the number of scatter/gather descriptors 208 which utilized in the particular request. The number of scatter/gather descriptors 208 associated wi~h the request block 204 will vary. Further, if the command is a read co~mand, the reguest may contain up to two different sets of scatter/g~ther descriptors. Thus, the present invention is capable of reading data from two different areas in system memory. Each scatter/gather descriptor 208 contains a 32 bit buffer length and a 32 bit address.
This information is used to determine the system memory data transfer address which will be the source or destination of the data transfer. Unlike the requests blocks 204 in the command li~;t, the scatter/gather descriptors must be contiguous and, if there exists a second scatter/gather descriptor set ~or a request, it must directly follow tha first set of scatter/gather descriptors.
A command list 200 has a variable number of request blocks 204. In order to guickly and efficiently traverse the list of variable reguest blocks 204 the reguest header includes a point~r or n~xt request offset which specifies an offset of "n" bytes from ~he current reques~ block address to the next request block. This field makes the command list 200 a s~t of li~ked list request bloc~s 204.
The last request block 204 has a value of OOOh in the next reque~t offset to signify the end of the command list 200.
Thus ~ the method in the present invention permits memory space between res[uest blocks 204 wit~in a command list 200 which may be used by an operating sy~tem device driver.
Elowever, it should be noted that the yreater ~he e~tra :,: -:: . :. .:.. ~.... . . : , - ~--30~ 3'~

space between the reguest blocks 204 longer it will require ~he disk array controller 112 to tra~sfer ~he command lis~ 200 into its local memory.
The command specifies the functlon of the particular reguest blocX and implies the format of the parameter list. The commands supported by the disk array controller 112 of the preferred embodiment include:
CO~AND
_ IDENTIFY LOGICAL DRIVE
IDENTIFY CONTROLLER
IDENTIFY LOGICAL DRIVE STATUS
STA~T RECOVERY
READ
WRITE
DIAGNOSTIC MODE
SENSE CONFIFURATION
SET CONFIGURATION
Identify logical drive is u~ed to identify the defined logical drives within the di~k array. Processing of the command returns information related to ~he logical drive in a 28 byte buffer. Information included is block length; number of blocks; logic:al drive parameter table entry; and f~ult tolerance type. If a logical drive is not defined, the leng~h and nu~ber of blocks for that logical drive will be returned a~ 0 values. In ~he current implementation of the pxesent invention only logical drives 0 and 1 may be defined.
Identify controller is used to identify the configuration of the disk array controller 112. It returns information in a 256 byte buffer and is used primarily to return the number of logical drives that are defined. In the present implementation of the current invention, infor~ation returned includes the number of logi~al drives, the configuration signature for the disk array controller; and the firmware revisio~ for the disk array controller.

, . ,, . ~

~' . # ~ ' :
.
: : .

-31- ~f!~.'',ji;~

Identify logical drive status is used to indicate the status of a particular logical drive. Information is return~d after processing of this command in a 256 byte buffer. Information includes the logical drive status and drive failure assi~nment information. Possible values that may be returned regarding the logical drive status include: the logical drive failure; logical drive needs to be configured; logical drive is operating in the regenerate mode; Iogical drive is ready to start recover;
and logical drive will resume recover after a power off.
The start recover command is a command used exclusively by the computer system C ROM memory during a post. This ..
command gives the disk array controller permission to start the recovery process.
The I/O commands instruct the disk array controller to perform scatter/gather operation~ on sec~ential blocks of data. This scatter/gather descriptor structure is used by ~he disk array control].er to locate data within the array for transfer. The clescriptor structure may specify buffer addresses and buifer lengths for data to be tranæferred to or from system memory 58. The total buffer length must equal the number by~es to be transferred for any I/O operation.
The read command transfers seguential blocks of data 25 from the disk into ~uffers in the system memory 5~. Two - .
~catter/gather descriptors are available to specify dual destinations for the data. The present invention also includes a method for specifying partial block transfers.
If an initial buffer address is OFFFFFFFh (NULL), the present invention will skip to the offset of the requested ~ytes and the data for the specified interval is effectively ignoxed. The present invention will then xead the remainder of the data within the particular block and tran~fer it to the address as requested. A null address will generate ~n error during a write operation.
The wxit~ command transfers data from the syst~m memory 58 and writes it to sequential blocks on the disk -32~

drive array. The scatter/gather descriptox count number 2 is ignored by a write com~and.
The diagnostic command is a special command in the present invention that allows the direct manipulation of 5 hardware. This command is generally iesued as the only ..
re~u~st in a command list. The only valid field in a diagnostic command is the command field. If there exist any outstanding request when the diagnostic command is submitted, an abort error will be returned. once the dis~
array controller has be~n placed in a diagnostic mode ~he disk array controll~r is ready to except diagnostic commands upon receipt of the command complete notifica-~ion. The disk array controller will remain in diagnostic mode until otherwise notified and will not proc~ss nondia~nostic command list.
The sense configuration command is used to determine ~he configuration of a disk ar.ray controller and returns the information to a 56 byte buffer. Information returned includes a configuration signa~ure which is supplied by the EISA ~onfiguration utility and is written on the reserved sectors on each of the physical drives. The configuration signature is use~d by the disk array co~troller 112 firmware to reliably identify that a physical driv~ is a member of the configured drive array.
The sense configuration buffer also includes information relating to whether a compatibility port has been configured to be the primary or s~condary means of entry into ~he disk array. The sense configuration buffer also includes a value which indicates the type of operating system ~hat has been sp~ci~ied during EISA configuration.
This command also returns information regarding the total number of physical drives detected by ~he configuration utility through the diagnostic mode; the number of physical drives as~igned to ~he logical drive during th~
co~figuration utility; the typ~ of fault tolerance mode (parity versus mirror~ assigned to ~he logical dxive by the configuration utility. The sense configuration buffer .. . ..
: , , -: . . ., : -~ ~ ~ t~

also include infonmation relating to the specific drive parameter such as sectors per cylinder, numb~r of cylinders, numbex of heads, and number of platters. The buffer returned upon completion of the sense configuration command also includes logical drive parameters supplied by the configuration utility and a bit map indicating which physical drives axe assigned to the particular logical drive.
The msthod of the present invention relies upon a communlcation protocol utilizing unidirectional channels to communicate between the system processor 20 and the disk array controller local processor 122. The channel that is used to submit a new command list 200 to the disk array controller 11~ is also us~d to send the length of the command list 200 in bytes and a tag I.D. used to identify the command list 200. The length is required so that the disk array controller 112 may allocate the proper amount of memory in its local memory to process the command list. The tag I.D. is used exclusively by thP
operating system device driver and does not effect ~he processing of ~he command list 200 by the disk array controller 112. The channel that returns the command list 200 completion and error noti~ications uses the addresses of the command list 200 and offset pointer to the request block 204 that generated ~h~ notification, the command list 200, the status.at the time of notification, and ~he tag I.D. give~ when the com~and list 200 was ~ubmitted.
V. Syste~ ~exation:
A. Overview of Command Submission:
When a new command list 200 is submitted to ~he disk array controller 112~ the ~y~tem processor 20 determine~
if the transer channel is clear. If the channel is busy, the system processor 20 may poll, waiting for the channel to cle r, or it may unmask the channel clear interrupt so that it will be notlfied when the dis~ array controller clears the channel. Fig. 6 i5 a flowchart of the method used to submit a new command list 200 to ~he di~k array ' , '' , ,',"''' '' ;,,'''',:,`.'.':':;:,'"'' :' '' . ': : !
'.:

controller 112. Operation of sub~ission begins at step 300. The local processor 122 receives notification of ;~
submission a command list from the doorbell register in step 302 via BMIC 118. Control transfers to step 304 where ~he local processor 122 determines whether the channel 0 (command submission channel) is clear. If the channel is clear, control transfers to step 306 which resets th~ channel clear bit. Control transfers to step 308 in which ~he BMIC 188 loads the command list address, length and tag I.D. into a ring queue. When the queue is serviced by the local processor 122, the command list is transferred to the mailbox registers to be read by the local processor 122. Control transfers to step 310 in which the local processor 122 sets the channel clear bit to busy. Control transfers to step 332 which terminates the submission of the command. If in step 304 the local processor 122 determines that ~le command submit channel is not clear, the local proces~or 122 continues to poll ~or channel clear. If th~ channel is clear, control transfers to step 304. If the! local processor 122 determines in step 312 that the command list submission is a priority submission, con~rol t:ransfers to step 31S which queues ~he command list to be trans~erred. Control transfers to step 318 in which the local pro~essor 122 unmasks the channel clear interrupt bit. On ~ervice of the interrupt by the local processor, control transfers to step 320 which resets the channel clear. Control trans~ers to ~tep 3~2 the local processor dequeues the command list. Con~rol ~ransfers to step 324 which loads the command li t address, length and tag I.D. into the channel xegisters. Control transfers to step 326 which determines whether the command list submission gueue i~
empty. If the command li~t ~ubmis~ion list gueue is empty, control transfers to step 328 in which the local processor 122 masks the channel cl~ar interrupt bit.
Control transf~r~ to step 332 which terminat~s ~he command list ~ubmission. ~f the local processor determines in ,:
,. ., ~.

step 326 ~hat the queue is not empty, control transfers to step 330 which sets the channel busy bit. Control i~ then transferred to st~p 332 which terminates the submission of ~he command list.
B. Ovexview of Command _o~e~ on Notification:
Fig. 7 is a flow diagram overview of the manner in which ~he present invention notifies the device issuing the command that the command has be~n completed by the disk array controller 112. Processing begins in step 350.
In step 352 the local proc~ssor 122 loads the ~ommand list address, block offset, ~tatus and tag I.D. are loaded into transfer registers. Control transfers to step 354 in which tho local processor 122 r~sets the channel 1 bit as busy. Control transfers to step 356 in which the channel 1 clear bit is set. Control transfers to step 358 where the local processor 122 determines whether ~here exists a non 0 block offset. If this is a 0 bloc~ offset, control transfers to step 360 which processes the command list as complete. Control transfers to step 374 which terminates operation of the notification procedure.
If the local processor 12;2 determines in step 358 there to be a non 0 block offs~t, control transfers to step 352 which adds the o~fset: to the bzse addres~.
Control transfers to step 364 in which the local processor 122 determines whether the command list reguest status has an ~rror codes set. If there is an error code set, control tran~fers to step 368. If there is no error code s~t, control transfers to step 366 in which the local processor 1~2 proc~ ses the reguest block to completion.
Control transfers to step 370. If in step 364 the local processor 122 determine~ ~here has been an ~rror code set, and the 6yst~m has been notified in step 358, control transfers to step 370. In ~tep 370 the local processor 122 determines if more reguest blocks exist in the co~mand list. If yes, control transfers to step 362 and the local processor 122 continues to loop until all r~quest blocks have been processed as completed. I ~here are n4 more , . : : :::
: . . . -~ . .
.: ,. : . ~. .: . , :, .. .

-36 ~ 2~

regue~t blocks, control transfers to gtep 372 in which ~he local proc ssor 122 processes ~he command list as completed. Control transfers to step 374 which terminates notification procedure.
S C. Command Protocol SYstem The first o the modules within the method of the present invention addresses initialization of the disk array to carry out the method. In this module, the local processor 122 initializes all the BMIC 118 hardware and variables utilized in the method. Further, the module installs the BMIC Interrupt Service ProcPdure.
The BMIC Interrupt Service Procedure sets forkh ~he manner in which the BMIC 118 services requests and/or interrupts between the system processor 20 and the local proce~sor 122.
1. Initialization:
Fig. 8 is a flow diagram of a program tas~ designed to install the command passing and protocol used wikhin the pres~nt invention. Operations commence with step 400.
Control transfers to step 402 where ~he local processor 122 inst~lls the BMIC 118 interrupt service procedure described in more detail below. Control transfers to step 40~ in which ~he local proces~or 122 installs the transfer channel controller 148 and disk drive interrupts. Conkrol transfers to step 406 wherein ~he local processor 122 initialize~ the shared register~ and semaphore ports.
Control tran~fer6 to step 408 in which the local processor initializes the local doorb~ll registers, doorbell interrupts and ~asks. Con~rol trans fer~ to step 410 in which the local processor 1~2 initializes the EIS~
doorbell regi~ters, interrupts and ~ask. Control transfers to step 412 wherei~ th~ local proces or disables the local procecsor int~rrupts and sets the BMIC 118 local proces~or interface interrupt~. Control transfer~ to step 414 where the local proce~sor 122 re-enables ~he local procee~or interrupts. Control transfers to tep ~16 which terminate~ ~he initiali2ation procedure.

:: , - ~. . ;,., :, -. , .. : .:, : .. .... .
~, -:, . . ;,, .:
:, ::::,, ~, :,; ,: , -: ;.~

-37~

2~ Local Processor ~ ~r~edure:
_ _ _ Figure 11 is a flow diagram of the method used to monitor interrupt x~quests received by the BMIC lla ~nd local processor 122. Operation begins at step 550. The loc~l proc~ssor 122 transfers control to step 552 in which the local processor 122 saves the current BMIC inde~
value. Control transfers to step 554 wherein the local processor reads ~he local doorbell register mask to determine which bits are activ~. Control transfers to step 556 in which the local processor sets the local doorbell bits. Control transfers to step 558 in which the local processor detenmines whether the address for the command list which has arrived at the mailbox corresponding to the active doorbell bits i5 available and unmasked. If it is determined that it is not available or it is not unmasked, control transfers to step 560 in which the local processor 122 determines whether other doorbell .
bits have been set as active during ~his interrupt ~ervice. If other bits are ~et active, control transfers to step 562 in which the local processor 122 indexes to the next active bit ~ld control transfers to step 556. If in step 560 it is de~ermined there ar~ no other active bits, control transfers to ~tep 582. If in step 558 it is determin~d that th~ current doorbell bit and its as~ociated mailbox register are unmasked and the local processor 122 has the address for the command list, control transfers to step 564, in which the local processor 122 reads the command list address and size from the mailbo~ register corresponding to the doorbell bit.
Control transfers to step 566 where the local processor sends a system doorbell interrupt and clears the EISA
command submit bit. Control transfers to step 568 in which the local proc~ssor 122 calls the function BMIC IN
which transfers the command list to the BMTC command loader. Control transfers to step 570 wher~ the local processor 122 clears the local doorbell mask bit interrupt bit and the command submit state. Control transfers to ,.. . .. ~ . .

. .

-3~

step 572 in which the local processor clears the command list bit. Contxol transfers to step 574 in which th~
local processor determines whether the command competition channel is clear and unmasked. If not clear and unmasked, control transfers to step 582. If clear and unmasked, control transfers to step 576 where ~he local processor 122 calls function NOTIFICATION CLEAR to indicate that the interrupt has been serviced. Control transfers to step 578 which clears the local doorbell command notiication bit in the ~ask and the mask channel clear interrupt bit.
Control transfers to step 580 where the local pxocessor 122 clear~ the local command notify clear bit in the local doorbell interrupt register. Further, the local processor 122 clears ~he channel clear bit. Control transfers to step 582 in which the local processor 122 restores the saved BMIC IN~EX value to the current BMIC inde~ register.
Control transfers to step 58~ which completes operation of this function and control is to the local processor operating system~
The next set of modules are used in logical command receipt by the BMIC 118 and local processor 122. These routines include servicing a system processor interrupt and obtaining the command list. In the following module, the local processor parses the command list to determine if the commands contained therein are valid co~mands. The thixd module also performs a parse function, but on an individual reguest basis as opposed to the entire command list.
3. Logical Command Submission:
Figures 9A and 9B are flow diagrams of the processing of commands sent using the protocol co~mand structure at ~he present invention. The submission of commands to ~he local processor was described previously in Fig. 6. Fig~.
9A and 9B de cribe the ma~ner in which the local processor 122 and ~he BMIC 118 and transfer channel controller 1~6 .. ... ..
.: ,. ~ , . :, ,: , :. ,: . .
::. : ., ~ ~ :., ~ . , -39~

operate within the method of the present invention.
Operation begins in step 450 following the submission of a command ~s described in Fig. 6. Xn step 452 the local processor 122 determines whether the command list exceeds S the maximum 16Kbyte size permitted by the present invention. If the command list exceeds the maximum size, control transfers to step 454 in which an error message is set and control transfers to step 456 which returns to ~he local processor operati~g system with an error message.
If the local processor determine~ in step 452 that the command list does not exceed the maximum 16Kbyte size, control transfers to step 458. In step 458, the local processor allocates local ~emory for the command list header, transfer addr~ss and tag I.D. Control transfers to step 460 wherein the local processor 122 reads the first lK byt~ of the command list. Control transfers to step 462 which loads the comm~md list header, transfer address and tag I.D. into the! BMIC command buffer.
Control transfers to step 464 in which the local processor 122 calls routine get transfex- buffer which loads the command list into the local processor through the local processor interface 124. Control transfers to step 466 in which the local processor 122 determine~ whether additional elements of the command list exist. If there are additional parts to the command list, control transfers back to step 460 which continues to read in the command list in a maximum lK byte incre~ents until the command list has been totally transferred into the local processor memory. If the local processor 122 determines 30 in step 466 ~hat there are no additional elements to the command list, control transfers to step 468 where the local processor 122 calls the function PARSE NEW LIST to review the command list to d termine if all the command~
and requests therein are v~lid. Control transf~rs to step 470 in which the local procecsox 1~2 reviews the code set by PARSE NEW LIST to determine if the command list is valid. If the command list is not valid in its entirety, . ;. ,, . ,. , ~ :

. .. : :

, ,: . : .~
. : - : :: ::

-40~

control transf~rs to step 454 which sets an error message indicating that the command list is not valid. Control transfers to step 456 which returns to the local processor 122 operatiny system. If in step 470 the local processor lX2 deter~ines that the command list is valid, control transf~rs to step 472 through 484 which reads the particular command request and calls the correct command set. I~ the command is a read command step 472 calls BMIC READ function. If the command is a write command step 474 also calls BMIC_READ. If the command is an identi~y controller co~mand, step 476 calls the id~ntify function. If the command is an identify unit, step 478 also calls the identify function. If the command is a set configuration, step 480 calls the set configuration 15 functlon. If ~he co~mand is a sense unit status command step 482 calls the sense unit status function. In the event that the command is not one of the above cases, control transfers to step 484, which is the default command and i.s reported as a bad command or error command.
If the command was one of ~he commands listed in step 472 through 482, co~trol transf~rs to step 492 in which the local processor 122 determines if there are additional command requests in the command list. If ~here are more commands in the command list, control transfers to step 472 in which th~ local processor 122 again e~amines the ~o~mand and calls the proper unction. If there are no urther com~ands in the command list, control transfers to step 492 .
If irl ~tep 484 it is determined that the command is a bad request, control transfers to step 486 which sets an error ~essage that the command was not one of the commands recognized by BMIC IN. Control transfers to step 488 which releases the local memory allocated to the co~mand li6t. Control transfers to step 490 in which the local processor 122 sets a b~d command list error message.
Control transfers to step 492 in which the local processor 122 unmask~ the local doorbell interrupîs, indicating that -:
- . : ;: :. .~, . :,, .
... ~ . .

-41~

it has either completed processing of th~ command list or that ~he command lists an error. Control transfers to step 494 which returns to the local processor 122 to operating system task.
4. Command List Parse/Review:
Figures 22A and 22B are flow diagrams for the PARSE NFW LIST function which is utilized by the present inventisn to verify the validity of the command list 200 submitted to the disk array controller 112.
PARSE NEW LIST is called in step 1100. Control transfers to step 1102 wherein the local processor 122 finds the first byte past the current buffer. Control transfers to step 1104 where the local processor sets data structure poi~ters to correspond to command list header fields.
Control transfers to step 1106 in which the local processor 122 reads the request block counter. Control transfers to step 1108 in which the local processor reads scatter/gather count number 1 fields in the command list header. Control transfers to step 1110 i~ which the local processor determines the command request size from the reguest header infonmation. Control transfers to step 1112 in which the local process:or determines whether the scatter/gather count number 1 is equal to the size in bytes specified for that particular scatter/gather descriptor. If ~he scatter/gather count is not equal, control transfers to step 1114 which sets an error code and control is transferred to step 1116 which returns to the calling program with the error code. If the local processor 122 determines in step 1112 that the scatter/gather count number 1 is equal to the size specified, control transfers to step 1118 where the local processor 122 determines whe~her the second ccatter/gather count is non-null. If the second scatter/ga~her count is null, control transfers to step 1130. If the second scatter/ga~her count is not ~ull, control transfers to step 1120 where the local processor 122 reads the second scatter~gath~r count in the request header. Control ..: . ~

-42~

transfers to step 1122 where the local processor 122 determines ~he size of the reguest from the request header. Control transfers to stap 1124 where the local processor 122 determines whether the second scatter/gather count i equal to the size of the data. If the second scatter/ga~her count i not egual, control transfers to step 1126 which set~ compl~tion code to false and control is transferred to step 1128 which returns to the calling program. If the second scatter/gather count is equal to the proper size, control transfers to step 1130 where the local procsssor 122 determines whether the total size of the command list exceeds the maximum 16Kbyte buffer for each command list and that the size of the command list specified in the command header matches actual si~e. If the total size of the command list 200 exceeds the allotted buffer size, control transfers to step 1132 in which the local processor 1~2 sets a completion code equal to FALSE and control transfers to step 1134 which returns to the calling program. If the total size of the command list is equal to or less than the maximum 16Kbyte buffer, control transfers to step 1136 where the local processor 122 determines if there i~ a next reguest following the current command list request. If there is no next request, control transfers to step 1138 wherein the local processor 122 sets the next request to null. Control then transfers to step 1148. If thare is a next request, control tra~sfers to step 1140 in which the local processor 122 adds the reguest offset for the next request to the current request ~tart header. Control transfers to step 1142 where the local processor 1~2 determines wheth~r the end of the cuxrent request overlaps the calculated address for the next request. If an overlap does occur, control transfers to ~tep 1144 where the local processor 122 sets a completion code egual to FAL~E and control transfexs to step 1146 which r~turns co~trol to ~he calling program. If there is no overlap, control transfers to step 1148 wherein the local processor 122 ,: , :.
- - . . , j , .
:: , , .

-43~ ~s~

determines whether ~here ~re additional request in the rommand list 200. If there are additional request in the command list 200, control is transferred to step 1106 and the function continues to PARSE the list until th~ list has been fully PARSED. If there are no additional regue~ts, control transfers to step 1150 which sets a P~RSE completion code equal to TRUE. Control transfers to step 1152 which returns contxol to the calling program.
5. Next Dlsk Request Review:
Figure 26 is a flow diagram for the PARSE NEXT_REQUEST function which parse~ the next request from the command list and builds a data structure for the particular request. The P~RSE NEXT REQUEST function is called in step 1300. Control tra~sfers to step 1302 where the local processor 122 determines if th~re i~ a next request block relative to the current request. If there is no next reque~t block, control transfers to step 13~4 .
which returns control to the calling program. If there is a next request block, control transfers to step 1304 where the local processor 122 sets the pointers in the r~quest header to the corresponding next reguest offset. Control transfers to step 1306 where the local processor 122 allocates local memory for the S/G count l. Control transfers to step 1308 where the local processor 122 copies the size of th~ S/G count 1 and count to the local memory. Control transfers to step 1310 where the local processor 122 d~termines if the request h~ader includes a second S/G count. If ther~ is no second S/G count, control transfers to step 1312 where ~he local processor 122 sets the S/G count number 2 to null and the re~uest header to null. Control transfers to step 1318. If step 1310 determines ~hat there i8 a second S/G count field, control transfers to step 131~ where ~he local processor 122 allocates local memory for ~he S/G count number 2.
Control trænsfers to step 1316 where ~he local pro~essor 122 copies the S/G count nu~ber 2 and the size of the S~G
count to local memory. Control transf~rs to ~tep 1318.

- . ~ r ? ~

In step 1318, ~he local processor 1~2 determines if there i8 another request in the command list. If there are no other reques~ in ~he command list, control transfers to step 1320, in which ~he local processor sets the next reguest point~r to null. Control transfers to step 1324 which returns control to the calling program. If there are additional requests in th~ list, control transfers to step 1322 wherein the local processor 122 sets the next request block pointer to offset in the regue~t list header. Control transfers to step 1324 which returns control to the calling program.
The n~xt set of modules address the manner in which the method of the present invention transfers data to and from the host and th2 disk array. The SG BLOCK module is used to scatter or gather one block of data into or out of the transfer buffers managed by computer system memory.
The BMIC XFER module is used to transfer mutiple blocks of data to or from the computer system C utilizing multiple scatter/~ather descriptors 208 which are defined in the logical request 204. The BMIC XFER QUEUE module merely queues an incoming transfer request. The BMIC READ module is used by the local processor 122 to read transfer buffers in the disk controller 112 and transfer the data to the host system. Similarly, the BMIC WRITE module is used by the BMIC to write data from the host memory to transfer buffers in ~he disk array controller 1~2. The PEEK module sets forth the method by which the present invention reads one byte o~ data in system ~emory.
Similarly, the PQKE module set~ forth the method for writing one byte of data to ~ystem memory.

6. Scatter~Gather Block Transfer:
Figures l~A and 18B represent a flow diagram for the SG BLOC~ m~thod of tran~ferring data to and from the disk array controller. This method of transferring the data is used in those incidences wherein ~h~ command list may contain more than one ~catter/gather descriptor block per command request. Operatio~ of the SG BLOCX ~unction .. . . .

: : . : ~ : .

-45~ ~

begins at step 960. Control tran5fers to step 962 in which the local processor 122 scans the scatter/gather array for count and determines the address of the start descriptor block. Control ~ransfers to step 96~ wherein the local processor 122 deter~ines the host address and ~he size of the transfer to be made. It should be noted ~hat the host address may include the address of da~a to be transferred to the host or, the address of data which will be transferred from the host to the disk array controller. Control transfers to step 966 wherein the local processor 122 determines whether calculated address for ~he beginning of the block is a null address or OFFFFFFFH. If the calculated addre~s is equal to null, co~trol transfers to step 968 which sets S~ TRANSFER flag to FALSE. Control transfers to step 972. If the calculated address is not equal to null, the local processor 122 transfers con~rol to step 970 which sets the SG TRANSFER flag to TRUE. Control transfers to step 972 wherein the local processor 122 determines whether additional data is contained within a current block. It should be noted that an initial null address may be used to indicate a block wherein ~he data does not occupy the entire block and is offset by a given number o~ bytes from the beginning of ~he block.
If the local pxoc ssor 122 determines in ~tep 972 th~t a~ditional data is within the command block, control transers to step 974 where the local processor 122 sets the address offset from the beginning of ~he block data and ~he new data size and sets SG TR~NSFER egual to TRUE.
Control ~ransfers ~o step 978. If ~he local processor 122 determines in step 972 that there is no additional data in the block, control transfers to step 976 which sets the point~r to ~he next descriptor block. Control transfers to s~ep 978 wherein th~ local proces or determines if the SG TR~NSFER flag i~ equal to TRUE. If egyal to TRUE, control transfers to step 980 in which the local processor 122 determines whether the operation is to be an ~ISA read .. , ; . , :.

.. ~, - .. ,, :; , , .:

:

-46~

or write. It should be noted that an EISA read is viewed by ~he disk array controller as a write operation, whereas an EISA write is viewed by the disk array controller as a read operation. If the command is an EISA read, control S transfers to step 9~2 which calls function BMIC READ to transfer the information required and sets the directional bit as outgoing.
If the 1OCA1 processor determines in step 980 that the command is an ESIA wxite, control transfers to step 984 which calls BMIC READ to transfer the information to the host and sets the dixectional bit as incoming.
Following step 982 control transfers to step 986.
Following step 984, control transfers to step 986. In gtep 986 th~ local proce~sor 122 updates the number of blocks which have been transferred to ~he host and the number of remaining blocks to be transferred. Control transfers to step 988 which updates the transfer buffer address by on~ block size (512 bytes). Control transfers to step 990 in which the local processor 122 determines whether more descriptor blocks are to be transferred to or from the host. If more descriptor blocks are to be transferred, control is transfer.red to step 964 and the local processor 122 loops unti]. the transfer is complete.
I~ no more blocks are to be transferred, control transfers to step 992 which terminates operation of SG BLOCK and control i~ transferred back to the local processor 122 operating system.

7. BMIC Data Transfer:
Figur~s 17A and 17B are flow diagrams of the BMIC T~ANSFER function which is utilized to transfer data from the dis~ array controller ~hrough ~he ~MIC to the c lling device whether host or some othex bus master device. The function is called at step 900. Control tran~fer~ to step 902 wherein the local processor determines where the logical blocks for the reguest start using the parent logical pointer. Control transfers to step 904, wherein the local proces~or 12~ determines `: : ::~

~47-whe~her the logical blocks to be transferred are in a contiguous group. If the logical block~ are not in a contiguous group, control transfers to step 906 which sets the block 5i2e to ~he sector count for that particular contiguous block. Control transfers to step 910. If the local processor 122 determines in step 904 tha~ the block~
to be transferred are in a contiguous group, control tr.~nsfers to step 908. In step 908, the local processor 122 sets the block size equal to the rntire 6ector count for the transfer. Control transfers to step 910 wherein the local processor 122 obtains the starting block address and pointer to the logical request. Control transfers to step 912 wherein the local processor 122 determines whether the logical reguest ha~ only one scatter/gather axray. If the logical request has more tha~ one scatter/gather array control transfers to step 938. If the logical request has only one scatter/gather array, a high speed data transfer as follows is effected. Control .
transfers to step 914 in which the local processor 122 calculates the host start address. Control transfers to step 916 wherein the local processor determines whether the base xegisters are availabl~. If the base registers are not available, control transfers to step 918 wherein the local processor goes into a wait or poll state and loops back ~hrough step 916 until the base registers are available. I~ the base registers are available, control transfers to step 920, whçrein the local processor 122 clears the transfer complete bit And loads th@ transfer buffer interface data into BMIC 188 channel 0. Control txansfers to step 922 wherein the local processor 122 sets BMIC 118 channel 0 buffer address equal to the logical block address for the transfer. Control transfer~ to step 924 in which ~he local processor 122 loads the host address and count into BMIC 118 chaDnel 0 base registers.
Control transfers to step 926 wherein the local processor 122 loads the output block size of the transfer into the buffer. Control tran~ers to step 928 in which the local .
, ., , " . ~

' ~ . ''' ~ ' ,' .

-48~

processor 122 determines if ~le transfer is to be a read or write. If the transfer is a read transfer, control transfer-~ to step 930 which sets the directional bit to transfer data to the EISA master (seen as a write from the disk array controller 112). Control transfers to step 934. If the local processor 122 determines in step 928 that ~he operation is to be a write, control transers to step 932 which ~ets ~he directional bit to receive data from the EISA master (effectively a read ~or the disk array controller 112~. Control transfers to step 934, wherein the local processor initiates transfer of the 32 bit data, outputs ~he current channel ~onfiguration, channel strobe and increments the host address. ~ontrol transfers to step 936 in which ~he local processor 122 determines if there are more blocks to transfer in the command list. If there are more request blocks to be process~d, control transfers to step 916 wherein the local processor 122 continues to procless all blocks until the command list 200 is completed. If there are no more request blocks 204 to be processed, control transfers to step 950.
If the local processor 122 determin~s in step 912 that ~he logical re~uest has more than one scatter/gather descriptor set 20~, control transfers to step 938 which calls the SG BLOCR function which upon sending the block address, block size to the SG BLOCK function, the present invention sends the 32 bit data, the output current channel configuration, channel strobe and increments host address. Control transfer~ to step 940 in which the local processor 122 determines if there is a second scatter/gather descriptor set 208 for ~he current request.
This would indicate that addre s information for the read command may be found in two different areas of system m~mory. If ~here is no second ecatter/gather de~criptor set, control transfers to ~tep 944. If there iB a second scatter/gather descriptor set, control trans~ers to step 942 wherein the block addres~, block size are se~t to ' ' ,, .. . " ~ i ,: . ," ,,, , .
: . . ,: , , , ,: .,: ;

2 ~

function SG_BLOCK and a transfer of 32 bit data, channel configuration, channel strobe are sent to the host device and the host address is incremented. Control transfers to step 944 wherein the local processor 122 determines if there are additional request blocXs to be processedO If there are additional request blocks 204 to be processed control is transferred back to step 938 and the function continues to loop until all request blocks 204 have been processed. If the local processor 122 determines in step 944 that there are no further request blocks 204 to be processecl control is transferred to step 946 wherein the local processor 122 advances the BMIC reguest queue pointer to the nPxt co~mand list 200. Control transfers to step 950 in which the local processor 122 notifies the drive task that the transfer has been completed. Control transfers to step 952 which terminates ~he operation of this fu~ction and returns control to the local processor 122 operating system.

8. BMIC Data Transfer Q~eue:
Figure 19 is a flow diagram of the BMIC XFER QUE
function. This function is u1:ilized by the present invention to queue BMIC transfers when there are multiple BMIC transfers being operated upon by the local processor.
BMIC XFER_QUE is called by ~he calliny program in step 1000. Control transfers to step 1002 wherein the local processor 122 determines whether the BMIC XFER QUE is empty. If the BMIC XFER QUE i~ not empty, control transfers to step lQ04 which adds the request to the end of the BMIC XFER QUE. Contxol transfers to step 1008. If the local processor 122 de~ermines in step 1002 that the BMIC XFER QUE is empty, control transfers to step 1006.
In step 1006, the local processor 122 initializes th2 queue, sets the head of the queue and the end oE the queue pointers to the current request. Control transfers to step 1008, wherein ~he local processor 122 sets the next request pointer egual to null. Control transfers to step 1010 which returns control to the calling program.

', " '. .
' . ~ , ' :
, . . :

9. BMIC Data Read:
Figure 12 is a flow diagram of the BMIC_READ function which is used by the present invention to xead (effectively, a write from the system or device driver) S information sent to the disk array controller 112. The BMIC_READ function is called at step 600. Control transfers to step 602 wherei~ th~ local processor 122 waits until BMIC chann21 0 base registers are all available. Control transfers to step 6Q4 in which the local processor 122 determines whether the host buffer address for the data to be sent to th~ disk array controller 112 is odd byte aligned. If it is determined that the host buffer address is odd byte aligned, control transfers to step 606 in which the local processor 122 obtains the address and the data contained within the first byte and loads into the txansfer buffer. Control transfers to step 608 in which ~he local processor 122 calls the PEEK function, effectively transferring the first byte from the host to ~he transfer buffer. Control transfers to 610 in which the local processor 122 increments the start address of the data from the host to ~he next byte, effectively even aligning the bytes and decrements the numb~r of bytes to b~ transferred. Control is then transferred to st@p 612. If in step 604 the local processor 122 determines that the host buffer address is not odd byte aligned, control transfers to ~tep 612. In Step 612 the local processor 122 sets th~ directlon of the transfer and loads the transfer buffer address into BMIC
channel 0. Control transfers to step 614 in which the ~-local processor 122 transfers the data size and 32 bit data from the host to the transf~r buffex. In step 616 th~ local processor 122 transfer6 ~h~ cha~n~l configuration ~nd channel stxobe into the transfer channel buffer. Control transfers to step 618 which completes the loading of the transfer channel interface information in the BMIC 118. The BMIC 118 ~hen initiate~ the transfer of the sector data with the transfer channel controller 124, .
. i, :., ,.~ .. ,:
., ~ ,, . . :, . .: . . ;: : . .:

which results in the data being automatically transferred from host memory to the transfer buffer memory 130 for later transfer to the disk array. Control returns to the local processor 122 operating system.

10. BMIC Data Write:
Figure 13 is a flow diagram of the function BMIC WRITE which is used by ~he present invention to load the transfer bufer interface write commands from the disk array controller 112 (effectively a READ for the system 10 processor). BMIC WRITE is called in step 650. Control -~
txansfers to step 652 in which the local processor 122 waits until BMIC channel 0 base registers are available.
Control transfers to step 654 wherein the local processor 122 determines whether the transfer buffer address is odd byte aligned. If it is determin~d that the transfer buffer address from the disk array is odd byte aligned, control transfers to step 656 in which the local processor 122 retrieves the first byt~ and address of the data from the disk array. Control transfers to step 658 in which the local processor 122 calls function POKE to transfer the first unaligned byte to the host. Control tran~fers to step 660 where the local processor 122 increments the start address and decrements the nu~ber of bytes to be transferred. Control transfers to step 662. If in step 654 it is determined that the transfer buffer address is not odd~byte ali~ne~, control transfers to step 662. In step 662, the local processor 122 sets the direction of ~he transfer and loads the transfer buffer interface address into BMIC channel 0. Control transfers to step 664 in which the local processor 122 transfers the data size and 32 bit data to the host. Control transfers to 666 in which the local processor 122 sends the transfer channel configuration and channel strobe to the transfer channel buffer. Data transfer from the transfer buffer memory 130 is performed in a similar fashion to the transfer of BMIC Data Read. Control transfers to step 668 which ~e tenninates the BMIC WRITÆ function and returns ,, ~, .
- .
, ~, . .. , :
. , , -52~

control of the system to the local proce~sor 122 operating system.

11. Peek Mode_Data Transfer:
Figure 20 is a flow diagram of the PEEK function S wherein the local processor 1~2 reads a single byte of memory from the host processor or other device driver.
The PEEK function is called at step 1020. Control transfers to step 1022 wherein the local processor 122 determine~ if another P EK/POKE cycle is active. If the local processor 122 determines ~hat another PEEK/POKE
cycle is active, contxol transfers to step 1024 wherein the local processor 122 waits until the PEEK/POKE
operation currently active is complete. Control transfers back to step 1022 which again interrogates whether another PEEK/POKE cycle is active. If no other PEEK/POKE cycle is active, control transfers to step 1026 wherein the local processor 122 loads the PEEK/PO'.KE register with the local address into which the data is to be read. Control transfers to step 1028 wherein the local processor 122 loads the host addres~ into the PEEK/POÆ register. The host address represents the address in system memory 58 or device driver memory wherein thle data is to be obtained from. Control transfer~ to step 1030 wherein the local processor 122 sends the PEEK address to the BMIC 118 which performs the PEEK cycle to read the data from the host or device driver memory. Control transfers ~o step 1032 wherein the data read from host or device driver memory is aligned for the local processor 122. Control transfers to step lQ34 which returns control of the local processor 122 to the operating system.

12. POKE Mode_Data Transfer:
Figure 21 is a flow diagram of the POKE function which is used by the local processor 122 to send a byte of inormation to the host or device driver memoxy. The poke function i~ called from step ~050. Control transfers to step 1052 in which the local processor 122 determines whether another PEEK/POKE cycle is active. If another : ~' ,j, .. , ' , ~ ' .:

-53 - ,~ $ ~? ~

PEEK~POKE cycle is active, control transfers to step 1054 wherein the local processor 122 waits until ~he current PEEK/POKE operation cycle is complete. Control transfers to step 1052 wherein the local proces~or 122 again i~terrogat~s whether another PEEK/POKE cycle is active.
If no other PEEK/PORE cycle is active, control trancfers ;~
to step 1056 wherein the local processor 122 loads the PEEK/POKE register with the local addre~s of the information to be sent to the host or device driver memory. Control transfers to step 1058 wher~ the local processor 122 loads the host address into the ~EEK/POKE
r~gister. The host address represents the target address to which the data is to b~ sent from the local proce sor.
Control transfers to stap 1060 where in the BMIC 118 aligns the byte data the proper byte lanes and loads into the PEEK/POKE register. Control transfers to step 1062 and the local processor 122 sends the POKE request to the BMIC which acts upon the POKE request sending the data to the host or device driver memory. Control transfers to step 1064 which terminates the operation o the POKE
function and returns control to t~e local processor 122 to the operating system.
The next set of modules are directed toward the method by which the present invention notifies the computer system C of command completion or error. The BMIC OUR module i~ the main module by which the disk controller 112 notifies ~he computer syste~ of command completion state. The POST NOTIFICATION module is utilized to progra~ the BMIC to carry out notification called for in BMIC OUT. Th~ NOTIFICATION ChEAR module is utilized when the host system ha~ been unable to keep up with the completio~ noti~ications. The notifications are queued until the notification channel is cleared by the host ~ystem.

13. Command C o otification:
Figures 10A and 10B are flow diagram~ of the function BMIC OUT, which i~ used by the present invention to notify ' ' ' ' . '"

' -54~

the system processor that ~he command list has been completed or an error has occurred. The process of notifying ~he system proce~sor 20 that a command has completed is generally described in Fig. 7. Figs. lOA and lOB specify th~ method followed by the present invention.
Operation of BMIC OUT besin~ with a system called by the local processor 122 in step 500. Control transfers to step 502 in which the local processor 122 sets a completed list pointer to the list header. Control tran~fers to step 504 where the local processor 122 determines whether the command list indicates a command list error or abort.
If list status indicates errox or abort, control transfers to step 506 in which the local processor 122 sets the list error in the list status register. Control transfers to step ~08 where the local processor calls subroutine POXE
to send the error to the master device which sent the command. Control transfers to step 510 in which the local processor 122 det~rmines whether the control flag set in the command list header calls for an abort on error. If an abort on error is called for~ control is transferred to step 512 which sets the comm~nd status to abort and saves the last completed command. Control is then transferred to step 536. If in step 510 it is detenmined that the contxol flag has not been set on abort on error, control 2S transfers to step 522 in which the local processor 122 de~ermin~s whether the control flag is set to a notify on error. If not set to notify on error, control transfers to step 536. If set to notify on error, control transfers to step 524 in which the local processor 122 determi~es if the command which caused the error was the last command reguest in th~ list. If true, control transfers to step 526 where the local processor saves the last completed command request. Control transfers to step 526. If the command request causing the erxox was not the last request in the list, control transfers to step 528 which calls fun~tion POST NOTIFICATION, which sends the address of the .. , . . ., ,, .: . . : ~

, , :.~ : : :. , : :

.

-55~

command request cau~ing the error. Control transfers to step 536.
If in step 504, the list header does not have an error or an abort, control transfers to step 514 in which the local processor 122 determines whether the control flag in the command list header is set to notify upon completion. If set to notify upon completion, control transfers to step 516 in which the local processox 122 determines whether the completed request is the last command request in the command list 200. If the command request 204 is the la~t request in the command list 200, control trans~ers to ~tep 518 in which the local proces or 122 saves the last request as a completed command request ~.
address. Control transfers to step 530. If in step 516 it is determined that the request is not the last command request in the command list, control transfers to step 520 and the local processor 122 calls function POST NOTIFICATION to indicate that the particular request in the list has b~en completed. Control transfers to step 536. If in step 514 it is determined from the command list header control flags that the reques~ is not to notify upon completion, control transfers to step 530. In step 530, the local processor 122 determines whether the command list is compl~te. If the command list 200 is complete, control transfers to step 532 and the local processor 122 sets the list status in the command list header to list complete. Control transfers to step 534 where the local processor 122 calls function POST NOTIFICATION to send the list complete status to the requesting device. Control transfers to step 536 which frees local m~mory allocated to the command list headers, com~and list reque~t ~nd the command list scatter/gather d~scriptor~ arrays. Co~trol ~xansfers to step 538 which return~ control of the the local processor 122 to the real-time system.

.

14. o ~ d Notification:
Figur~ 25 is a flow diagram for the function NOTIFICATION CLEAR. NOTIFICATION CLEAR is called in step 1250. Control transfers to step 1252 where the local proc~ssor 122 loads ~he notification information into the channel 1 registers. Control transfers to step 1254 wherein the local processor 122 sets the system doorbell bit. Control transfers to step 1256 where ~he local processor 122 loads the address, offs~t, status and tag I.D. into the transfer registers. Control transfers to step 1258 in which the local processor 122 resets the channel clear bit. Control transfers to step 1260, where the local processor 122 sets the system doorbell bit.
Control transfers to step 1262 where ~he local processor 122 determines whe~her the notification queue is empty.
If not empty, contrvl transfers to step 1264 which unmasks the local channel 1 clear in~errupt bit. Control transfers to step 1266. If it .is determined in step 1262 that the notification gueue is empty, control transfers to step 1266. In step 1266, the local processor 122 determines whether the BMIC_OUT function is stalled. If Rtalled, control transfers to step 1268 in which the local processor 122 determines whether the BMIC OUT is stalled on notifications. If stalled on notifications, control is transferred to step 1270 in which the local processor 122 calls function~ POST NOTIFICATION to queue notifications to the syst~m. Fur~her, a NOTIFY OUT ~tall flag is set.
Control transers to step 1274 which returns control to the calling program. If ~he BMIC_OUT is not stalled on notifications, control is transferred to step 1272 which calls function POST NOTIFICATION and sets ~ NOTIErY IN
stall flag. Control transfer~ to step 1274. If step 1266 determines that tha BMIC OUT has not ~talled, control is transferxed to step 1274 which returni~ to the calling program.

.. ~: ~ : :

15. Co~mand Completlon Post Notiflcation:
Figure 24 is a flow diagram of the POST NOTIFICATION
functlon which is used to notify as to completion of a command list. P05T_NOTIFICATION is called in step 1200.
Control transfers to step 1202 where the local processor 122 determines whether there is a notification ring queue.
Control transfers to step 1204 if there is a queue. The local processor allocates memory for the notification data structure in step 1204. Control transfers to step 1206 where the local processor 122 load~ the address, offset, tag I.D. and status into ~he notification data structure.
Control transfers to step 1208 which places the notification data structure at the end of the POSTIT QUEUE. Control transfers to step 1228. If it is determined that there is ~o queue in step 1202, control transfers to step 1210 in which ~he local processox 122 unma~ks the local doorbell interrupt. Control transfers to step 1212 where the local processor 122 determines if the local command notify bit is clear. If the local command notify clear bit is not: clear, control transfers to step 1214 where ~he local processor 12~ allocates memory for the notification POSTIT. Control transfers to step 1216 where the local proce~;sor 122 loads the address, offset, status and tag I.D. into the data structure.
Control transfers to step 1218 which create~ a ring queue and places the notification structure at the head of the queue. Control transfers to s~ep 1~20 where the local processor unmasks th~ local doorbell interrupt. Control transfers to step 122R~ If in step 1212 the local 30 processor 122 determine~s that the local command notify clear bit is set, control transfers to step 1222 where the local proc~sor 122 loads notification information into registers and ~ets the system dooxbell. Control transfers to ~tep 1224 where the local processor 122 loads the address, offset, statu~ and tag I.D. information in~o th~
transfer buffers. Control transfers to tep 122~ in which the local processor 122 unmask~ the system doorbell - :. , . , ............................. .. -, . ~ , ,. . , . ; , ,'~ '.', ." .-. :,, ~., ;
: . .: , -58~

interrupt. Control then transfers to step 1228 where control is returned as a calling program.
The next set of modules are utilized by the present invention to carry out non-I/O disk co~mands, such as setting and checking the configuration o the disk array.
The SET CONFIGURATION module is utiliæed to create a configuration for the entire array. The SENSE CONFI~URATION module is utilized to determina what the existing configuration is within the array. The SET CONFIGURATION command is issued by the EISA CMOS upon completion of a losical unit by the ISA conflguration routine. The BMIC SENSE ~NIT module is used to determine ~he status of a specified logical unit to ~he host system.
The IDENTIFY module is used to identify either the controller of the particular type of disk wi~hin the array based upon the logical command issued. The CONFIGURATION VALID module is used to determine whether the existing configuration for the disk array is valid for the controller and overall system configuration.

16. Config~re Logical Unit:
Figures 14A and 14B are flow diagrams of the SET CONFIGURATION function. The set configuration ~unction is used to initialize a logical unit by the local processor 122 and is generally r~m when ~he disk array is first initialized or when additional and/or replacement disks ara added to the disk array drive system.
SET CONFIGURATION is called in step 700 by the local processor 122. Control transfers to step 702 in which the local processor 122 determi~es wheth~r the number o~
logical drives called for in the co~mand exceed the maximum number logical drives for the system. If ~he logical drives exceed ~he maximum nu~ber, control transfers to step 704 in which the local processor 122 setR a completion code as FALSE and returns control of the system to the local processor 122 in step 706. If in step 702 it is determined that ~he number of logical drives does not exceed the maximum nu~ber of drives permitted, ;. :, , , . j. , :,-59~

control transfers to step 708 wherein the local processor determines the configuration buffer size. Control transfers to step 710 where the local processor 122 allocates local memory for the configuration buffer.
Control transfers to step 712 in which the local processor 122 transfers the configuration data from the host to the transfer buffer interface. Control transfers to step 714 in which the local processor 122 transfers the configuration data from the transfer buffer into local memory. Control transfers to step 716 in which the local processor 122 calls function CONFIGURATION VALID which will return a valid or a nonvalid return code. Control transfers to step 715 where the local processor 122 determines whether the return code is valid. If not valid, control transfers to step 758. If the xeturn code is valid, control transfers to step 720 in which the local processor 122 determines whether the global reserved information (RIS) sectors are egual to a null value. If not null, the disk array global RIS information indicates that a prior configuration existed and the FIRST_CONFIG
flag is set equal to FALSE in step 722. Control transfers to step 728. If the GLOBAL RIS value is equal to null, this indicates that there has bee~ no prior configuration of the disk array. Control is then transferred to st2p 724 which allocat~s local memory for a GLOBAL RIS
struc1;ure and sets the FIRST CONFIG flag equal to TRUE.
Control transfers to step 72S which copies ~he RIS
signature from the host to ~he local data structure.
Control transf~rs to step 728. In step 728 th~ local processor copies the configuration signature and physical driv~ data to the local data structur2 ~or ~he global RIS.
Control transfer to step 730. If the FIRST CONFIG flag is set to TRUE, control transfers to step 732, wherein the local processor 122 reads all logical drives. Control transfers to step 734 which sets the drive status for all drives to o.k. and available. Control trans~ers to step 738. If in step 738 it is determined that the , :. . . :

, .
:
, . ~ ,. . .. .

~o.. 2 ~

FIRST CONFIG flag is FALSE, control transfers to step 736, in which the local processor 122 sets th~ logical drive to start at ~he next available or u~used volume. Control transfers to step 738. In step 738 the local processor 122 loads the transfer volume, CPC port address, operating system, interleave scheme, drive count, fault tolerance and u~er drive count all of which comprises information relating to the physical coniguration of the logical unit. Control transfers to stap 740 and 742 wherein the local processor 122 raads ~he fault tolerance flag to determine how to set the number of drives available. In step 740, if parity drive tolerance has been set, the local processor 122 will indicate that dri~es 3 and 7 are set for parity drive tolerance and the drives are no longer available for use. If fault tolerance has been set to mirror fault tolerance, step 742 the local processor 122 decreases the number of user drives available indicating that there are total of four user drives available as opposed to eight, or one half the available number of drives. Control transfers to step 744, in which the local processor 122 calculates the block offset to reserve ~he first cylinder for all disk in the array for the eventual writing of all RIS information to this ~irst cylinder. Control transfers to step 7~6 in which the local processor transfers all disk logical param~ters to the transer interface buffer. Control transfers to step 748 where the local processor 122 builds a logical map for each drive and for all drives in the array. Control is transerred to step 750 in which the local processor 122 determines if FIRST CO~FIG fla~ is egual to TRUE. If not equal to TRUE control transfers to step 754.
If step 750 determines that ~he FIRST CONFI~ flag is equal to TRUE control transfers to step 752 in which the local proc~ssor 122 sets RIS sectors to n~ll for all drives in ~he disk array, pending writing of the RIS
structure to the cylinder reserved in step 744. Control transfers to step 754 in which the local processor writes :: - ~. :, , :, ; :

the configuratio~ sectors to the RIS sectors on disk.
Control transfers to step 756 where the local processor 122 sets a set confi~ratio~ complete flag equal to TR~E.
Control transfers to step 768.
S If in step 718 it is determined that the configuration is not valid, control transfers to step 758.
If the physical drive count is equal to 0, control transfers to St8p 764, in which the local processor 122 sets the SET CONFIG ~ TION complete flag equal to false.
Control transfers to step 768. If in step 758 it is determined that the physical drive count is not equal to 0, contxol transfers to step 760 which sets the drives egual to unused and disabled. Control transfers to step 762 which sets the set configuration compl~ e flag equal to true. Control transers to step 768. If the SET CONFIGUR~TION complete flag is equal to TRUE, control transfers to step 770 in which the local processor 122 saves the entire configuration into the RIS sectors on all disks. Control transfers to st.ep 772 which returns control of this local processor back to the operating system. If it is determined that the SET CONFIGURATION
complete flag is not equal to TRUE, control transfers to step 774 in which the local processor sets an error code and returns contrQl of the local processor in step 776.

17. Sense Loqical Unit Confi~uration:
Figure 15 is a flow diagram of the SENSE CONFIGURATION_UNIT functio~ wherein ~he disk array controller 112 identifie~ the type of lo~ical unit to the calling device in response to comma~d issu~d by the calling d~vice. Operation of the SENSE_CONFIGURATION
function begins at ~tep 800 wherein it is called. Control transfers to step 80~ wherei~ signature address, compatibility port address, operating system, interleave factor, drive count, physical drive count, tolerance mode and other physical logi~al para~eters are loaded into a data 6tructure in the local memory by ~he local processor 122. Control transfer to step B04 wherein the local .. : : : . . ..

-62~

processor 122 roads the RIS data structures for all drives speclfied in the drive man into local memory. Control transfers to step 806 in which the local processor 122 transfers the data structure frvm local memory into the tranefer buffer. Control transfers to step 808 where the local processor 122 transers drive array information to the host memoryO Control transfers to step 810, where the local processor determines whe~her there e~ists a second scatter/gather count field for the particular configuxation. If there is no second scatter/gather count, control txansfers to step 814 wherein control returns to the loc~l processor 122 operating ~ystem. 1 there is a second scatter/gather count, control transfers to step 812 in which ~he local processor 122 transfers the second scatter/gather count from the transfer buffer to the host or calling device memory.

18. BMIC Sense Scatter/Gather Structure:
Figure 27 is a flow diagre~m of the BMIC SENSE UNIT
function which is used to read parameters dealing with a specific drive within the disk array. BMIC SENSE UNIT is called in step 1350. Control tr.ansfers to step 1352 where the local processor 122 allocates local memory and reads the specified logical drive data into the local memory.
Control transfers to step 1354 where the local processor 122 transfers the data struc ure into the transfer buffer.
Control transfers to step 1356 where the local proces~or 122 transfers the unit data to the host using SG BLOCK.
Control transfers to step 1358 in which the local processor 122 determines i~ there is a second S/G count field in the request header. 1 there is no second S/&
count header, control transfers to step 1362. If there is an additional S/G count header, control transfers to step 1360 where the local processor 122 calls the SG BLOCK
function to transfçr the data from the transf~r buffer to the host. Control transfers to step 1362 which terminates operation of ~he BMIC SENSE UNIT function and returns control to the local processor operating system.

- :: . . ". . , .. "~
: ,, ., ~ .::
~ ;:

, . . .. .

-63~

19. ~r~ L__ntroller or Disk:
Figure 16 is a flow diagxam of the BMIC IDENTIE'Y
-function of the present invention. Th~ function is called at step 830 and control transfers to step 832 in which the c local processor 122 determin~s whether the command was an identify controller or identify drive command. If it is identify controller, control transfers to step 834. In step 834, the local processor 122 allocates local memory for a data structure for the RIS sectors of the disks, and reads the RIS sector inormation into the structure.
Control txansfers to step 836 in which the local processor 122 determines the siz~ of the identification information to be sent to the calling device. Control transfers to step 838 in which the local processor 122 loads the controller information in the transfer buffer. Control transfers 840. If in step 832 it is determined that the identify command is re~uesting identification information .for a particular drive, control transfers to step 842, wherein the local processor 122 allocates local memory for the data structure and reads the disk drive parameters including head, cylinder and number of sectors per cylinder. Control transfers to step a44 in which the local processor 122 determines ~le type of fault tolerance for the particular drives. Control transfers to step 846 where the local processor 122 determines the size o the transfer in~ormation to be sent to the calling device.
This transfer size information i~ then added to the command header. Control transfer~ to step 848 wherein the local processor 122 loads the unit information for tha disks is to the transfer buffer. Control transfers to step 840, wherein ~he local processor 122 sends the identification information to ~he calling device. Control transfers to ~tep 850, wherein operation of ~he BMIC IDENTIFY function terminates and control is returned to ~he local processor operating system.

,........ .. ,., , , ~ .. . . :
. ; : . .: .. . . ...
: :
:, . .
- . . . .
:. :. ::: : . .

-64~ 2 ~ r~

20. Loqical U~it confiquration Check:
Figure 23 is a flow diagram of the CONFIGURATION VALID function which may be called by other tasks in the present invention. CONFIGURATION VALID is called in step 1160. Control transfers to step 1162 where the local processor 122 determines whether the number of drives in the configuration buffer i~ egual to the physical number of drives i~ the logical unit. If the physical number of drives iA the array are not equal to the number drives in the configuration buffer, control tr ~sfers to step 1164 in which the local processor 122 sets a return code of FALSE and transfers control to step 1166 which retur~s to the calling program. If the number of driv~s in ~he configuration buffer is equal to ~he physical number of drives in the logical unit, control traslsfers to step 1168 where the local processor 122 counts ~he number of drives through the map of the logical unit. Control transfers to step 1170 where the local processor 122 determines whether the count as obtained through ~he map of the logical ~lit is equal to the number of disk specified in the confi~lration buffer count. If they are not equal control trans~ers to step 1164 in which the local processor 122 sets a xeturn code o~ FALSE and returns to the calling program i~l step 1166. If the count is egual to the configuration buffer count, control transfers to steps 1172 - 1178 which comprise a switch, based on fault toleran~e modes in the logic~l unit. In step 1172 if th~ disk array is set for PARITY_FAULT PROTECTION, control is then transferred to step 1180 in which the local processor 122 determines whether drives 3 and 7 are set for parity. If drives 3 and 7 are no~ set for parity, control transfers to step 1164 in which the local proce~sor 122 sets a r~turn code sf FALSE and r~turns to the calling program in step 1166.
If drives 3 and 7 axe set ~vr parity, control transfers to step 1186 in which the local processor 122 sets a return code of TRUE. If step 1174 deter~ines that the . . " .. ... .. .

,: , . . : :
,. :. ~. :; ' ; .; ~ "
. .
,: :, . .

-65 ~ S``~

configuration calls for MIRROR FAULT protection, control is transferred to step 1182 in which the local processor 122 dete.rmines whethex the user drive count has been set for mirror, i.e., drives 0-3 are the only active user drives. If the drive count has been set to reflect MIRROR FA~LT protection, control txansfers to step 1186 in which the local processor 122 sets a return code of TRUE.
If ~he dxive count has not been set to reflect ~IRROR FAULT protection, control transfers to step 1164 in which the local processor 122 sets a return code of FALSE
and returns to the calling program in step 1166. If step 1176 determines ther~ i5 no fault prot~ction in the disk array, control transfers to step 1186 in which ~he local processor 122 sets a return code sf TRUE. If step 1178 determin~s that a field is bla~k or default, control transfers to step 1184 in which the local processor 122 sets a return code of FALSE. Control transfers to step 1188 which returns to the calling program. In step 1186 the local processor 122 sets a return code of TRUE and control transfers to step 1188 which returns to the calling program.
VI. Conclusion:
It will be appreciated that the protocol defined in the present invention will result in improved host processor efficiency. The host processor need not issue disX s~ecific co~mands to the drive array. The buildlng of the disk specific commands has been off-loaded to the local processor within the disk array controller.
Further, the system processor need only issue logical level commands to the disk array controller.
Further, ~he use of a bus master int~rface controller relieves ~he system processor rom data transfer management tasks as the I/O operations are carried out.
The transfer of these tasks to th~ disk array controller will result in improved overall p~rformance for the computer system.

.:: . : . .:
. .~. . : . .. - , -, -66- ~ ~ 2 ~

The foregoing disclosure and descrip~ion of the invention are illustrative and explanatory thereof, and various changes in the size, shape, materials, components, circuitry, wiring connections and contacts, as well as in the details of the illustrated circuitry, construction and method of operation may be made without departing from the spirit of the invention.

- . : ... :: . . .
,. .... , : : . ~ . .:
.

, : , . :

Claims (19)

1. For use with a computer system having a bus, an intelligent mass storage disk array subsystem, the disk subsystem having a microprocessor controller, and other device drivers, a method for managing the transfer of data and system management information between the disk array subsystem and the computer system comprising:
sending a plurality of disk requests from the computer system to the disk array subsystem controller;
translating the plurality of disk requests into disk specific commands used to manage the operations of the disk storage devices within the disk array independent of the computer system processor;
processing of the plurality of disk specific commands by the disk array controller;
managing control of the transfer of data to or from the computer system memory by the microprocessor controller; and notifying the computer system when the plurality disk requests have been fully processed.

2. The method of claim 1, wherein the sending of a plurality of disk requests further includes building a plurality of information control packets specifying a plurality of functions to be performed by the disk array subsystem.

3. The method of claim 2, wherein the building of an information control packet further includes specifying command completion information, command priority information and data address and size.

4. The method of claim 3, wherein translating the plurality of disk requests into disk specific commands includes:
reading the disk request and information control packets associated with the disk request;
calculating disk drive specific parameters for disks within the array according to the information contained in the control packets; and building a plurality of disk specific command packets, including command function and disk specific parameters, for each disk request.

5. The method of claim 3, wherein the processing of disk specific command packets includes:
queuing the disk specific commands according to the priority information specified in the information control packet; and transferring the disk specific commands to the individual disk drives in the array.

6. The method of claim 1., wherein the method of managing control of the transfer of data by the microprocessor controller includes:
asserting control over the computer system bus by means of a bus master;
determining the method of transfer information;
transferring data to or from the computer system according to the method determined by the bus master; and relinquishing control of the computer system bus.

7. The method of claim 6, wherein the transferring of data to or from the computer system includes transferring of 32 bit data.

8. The method of claim 7, wherein the transferring of data to or from the computer system includes transferring of 32 bit data at the rate of 33 Mbytes per second.

9. The method of claim 6, wherein the transferring of data to or from the computer system includes transferring of 32 bit data to a computer system device capable of receiving 8 bit or 16 bit data.

10. The method of claim 6, wherein the transferring of data to or from the computer system includes transferring a single byte of memory to or from the computer system or a device attached to the computer system.

11. The method of claim 2, wherein notifying the computer system when the plurality of disk requests have been fully processed includes notifying the computer system of the completion of processing of an information control packet.

12. An information control packet for use with a computer system having an intelligent mass storage disk array subsystem, including a microprocessor controller, comprising:
a command list header; and a plurality of disk command requests.

13. The information control packet of claim 12, wherein the command list header includes information common to all disk command requests.

14. The information control packet of claim 13, wherein the information common to all disk command requests includes:
a logical drive description;
a priority for the command list; and control information applicable to each disk command requests.

15. The information control packet of claim 14, wherein the control information within the command header includes:
additional priority information; and command completion information relating to the entire command list.

16. The information control packet of claim 15, wherein each disk command requests includes:
a request header; and a plurality of descriptor packets.

17. The information control packet of claim 16, wherein the request header includes:
a disk command which specifies the junction of the command;
a return code specifying the manner in which the disk array controller is to notify the computer system upon completion of the specific command;
an address specifying a location in the logical drive specified in the command list header;
the volume of data to be transferred to or from the logical drive specified in the command list header;
the memory address of the next request header in the command list; and the number of descriptor packets within a set associated with the disk command requests.

18. The information control packet of claim 17, wherein the request header further includes a second number specifying a second set of descriptor packets associated with the disk command request.

19. The information control packet of claim 18, wherein a descriptor packet includes:
a buffer address specifying a location in system memory to be used in the disk command; and a buffer length specifying a volume of data beginning at the buffer address.