United States Patent (19)
`Barrett et al.
`
`54 APPARATUS AND METHOD FOR BURST
`DATA TRANSFEREMPLOYNG A PAUSEAT
`FIXED DATA INTERVALS
`
`(75) Inventors: Wayne M. Barrett, Rochester; Bruce
`L. Beukema, Hayfield; William E.
`Hammer; Daniel F. Moertl, both of
`Rochester, all of Minn.
`73 Assignee: International Business Machines
`Corporation, Armonk, N.Y.
`
`(21) Appl. No. 335,228
`22 Filed:
`Nov. 7, 1994
`Related U.S. Application Data
`63 Continuation of Ser. No. 760,426, Sep. 16, 1991, abandoned.
`(51) Int. Cl." ............................................. G06F 13/28
`52 U.S. C. ....................... 395/800; 364/260; 364/271.5;
`364/260.1; 364/DIG. 1; 395/868
`58) Field of Search ...................................... 395/800, 868
`56)
`References Cited
`U.S. PATENT DOCUMENTS
`
`Re.34,282 6/1993 Suzuki .................................... 395/425
`4,275,440
`6/1981 Adans .
`... 395/868
`4,558,429 12/1985 Barlow .................................... 395/425
`4,644,463 2/1987 Hotchkin ................................. 395/250
`4,703,478 10/1987 Haselton ................................... 370/94.
`4,712,176 12/1987 Fredericks et al. ...
`... 364/200
`4,799,199
`1/1989 Scales, III et al. ...
`... 365/230
`4,807,109 2/1989 Farrell et al. .....
`... 364/200
`4,816,947 3/1989 Scales ..........
`... 395/325
`5,029,124 7/1991 Leahy et al. ..
`370/85
`355/307
`5,073.969 12/1991 Shoemaker ...
`5,140,680
`8/1992 Best ........................................ 395/325
`
`|||||||||
`USOO55.84033A
`5,584,033
`11
`Patent Number:
`45) Date of Patent:
`Dec. 10, 1996
`
`5,159,672 10/1992 Salmon ................................... 395/325
`5,276,818
`1/1994 Okazawa ................................. 395/325
`OTHER PUBLICATIONS
`IBM Technical Disclosure Bulletin vol. 30 No. 4 Sep. 1987
`pp. 1432–1434 “Swinging Buffer With Programmable
`Size'.
`Primary Examiner-Eric Coleman
`Attorney, Agent, or Firm-Roy W. Truelson; Owen J.
`Gamon, Karuna Ojanen
`57)
`ABSTRACT
`A plurality of devices attached to a communications bus
`observe a burst transfer protocol which allows pausing only
`at pre-determined, fixed intervals of n data words, where a
`word is the width of the bus. In accordance with this
`protocol, once burst transfer is initialized the sending device
`transmits an uninterrupted stream of n data words over the
`communications bus, after which either the sender or
`receiver may cause transmission to pause. The sender may
`need to wait for more data, or the receiver may need to finish
`processing the data just received. The pause lasts as long as
`needed until both devices are ready to proceed. This cycle is
`repeated until the data transmission is complete. The sending
`and receiving devices do not relinquish control of the bus
`during a pause, and therefore are not required to re-initialize
`communications. In the preferred embodiment, after n data
`words have been transmitted, the sender and receiver toggle
`interlocking signals that accomplish a handshaking between
`the two devices. The sender de-activates its signal when it is
`ready to send more, and the receiver de-activates its signal
`when it is ready to receive more. Both devices are equipped
`with buffers large enough to hold in data words, but the
`buffers need not be as large as the longest possible burst
`communication.
`
`30 Claims, 5 Drawing Sheets
`
`10l.
`
`05
`
`100 /
`
`
`
`
`
`
`
`
`
`
`
`BUS Interface
`Unit
`
`Systell I/O BUS
`
`BUS Interface
`
`BuS Interface
`
`I/O PrOCeSSO?
`
`I/O Processor
`
`
`
`112
`
`BUS Interface
`Unit
`
`70 POceSSOr
`Unit
`
`13
`
`14
`
`15
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 1
`
`

`

`U.S. Patent
`
`Dec. 10, 1996
`
`Sheet 1 of 5
`
`5,584,033
`
`100
`
`
`
`
`
`
`
`
`
`
`
`
`
`Bus Interface
`Unit
`
`
`
`System I 10 BUS
`
`lill
`Bus Interface
`Unit
`
`112
`
`BUS Interface
`Unit
`
`I/O PrOCeSSOr
`Unit
`
`I/O PrOCeSSOr
`Unit
`
`
`
`114
`
`115
`
`BUS Interface
`
`I/O PrOCeSSOr
`
`
`
`13
`
`FG.
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 2
`
`

`

`U
`
`3
`
`
`
`__mom2E5:2:EBmm2222:352anBEBEm\E2:2:HE:2:532:2825m2:NewP.95.:Q:”WEESEEEmEE
`;
`‘
`
`
`3:2é3:22.11..mg_____:a_____:
`
`a._______me______xD:__3N____a”::2:
`
`QMSNNS
`
`fi,BEE?maBEBE8m:8
`
`
`
`m,.H:a:MNGE:2::2:CNN
`
`_______________:2.m::3:3:
`s::_:___:__:um“
`
`
`Petitioner STMicroelectronics, Inc., EX. 1010
`
`IPR2021-00355, Page 3
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 3
`
`
`

`

`U.S. Patent
`
`Dec. 10, 1996
`
`Sheet 3 of 5
`
`5,584,033
`
`as
`
`3Ol
`
`
`
`
`
`a
`
`305 ----
`Arbitration
`Logic
`- - - - -
`
`----
`Buffer
`
`-- -
`so
`
`BUS INTERFACE UNIT
`
`FG. 3
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 4
`
`

`

`U.S. Patent
`
`Dec. 10, 1996
`
`Sheet 4 of 5
`
`5,584,033
`
`STAR
`
`l4O1
`
`Master BUS Unit arbitrates for
`the bus, takeS COntrol Of buS
`
`Master BUS Unit SelectS Slave
`Unit, iSSueS COMmand
`
`l,02
`
`lO3
`
`Initial StatuS CyCle, Slave
`Sends Status, pauSe all OWed
`by Sender Or RCVr,
`
`l,04
`BurSt Data Transfer: 31 CyCleS
`Uninterrupted data transfer
`
`lO5
`32nd Cy Cle: RCV acknoW ledgeS,
`Slave Sends Status, pause
`all OWed by Sender Or RCVr,
`
`
`
`407
`Master releaseS COntrol of buS
`
`END
`
`FIG. 4
`
`D
`A
`T
`A
`T
`R
`
`R
`s
`E
`R
`P
`H
`A
`S
`E
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 5
`
`

`

`US. Patent
`
`Dec. 10, 1996
`
`Sheet 5 of 5
`
`5,584,033
`
`
`
`\mwmzan<
`
`<h<a
`
`hm<mmam
`
`mom
`
`.momFEES”.
`
`.1I...mizmazé
`
`IIIIIIIIIIIIm2:
`
`.
`
`w.mmnzmw
`
`...mx<=mnz<=
`
`mzwg
`
`mmh>mmNH‘
`
`z<mzhw
`
`mmw>mwNH1‘
`z<mmkwMNH4<HHHZH
`
`z<mmhw
`
`z<mmhm
`
`.
`
`mwh>mwNHs,
`wm~>mwNH‘
`
`
`
`
`
`VII?“3::VA..."YK’I‘;\mfifiwu
`
`Hz<¢m=m
`
`PefifionerSTBAkmoechonkx,hnl,EX.1010
`
`IPR2021-00355,Pag66
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 6
`
`
`
`
`
`

`

`5,584,033
`
`1.
`APPARATUS AND METHOD FOR BURST
`DATA TRANSFEREMPLOYING A PAUSEAT
`FIXED DATA INTERVALS
`
`This application is a continuation of application Ser. No.
`07/760,426 filed Sep. 16, 1991, now abandoned.
`
`5
`
`FIELD OF THE INVENTION
`The present invention relates to computer communica
`tions, and in particular to improving the speed and reducing
`the cost of burst communications between different devices
`in a computer system.
`
`10
`
`2
`desirable that both devices operate as fast as the physical
`limitations of the devices will permit. On the other hand, the
`devices must be able to-keep up with each other or com
`munication errors will result. A typical system communica
`tions bus may have a variety of devices of different types
`attached. Because these devices perform different functions,
`they will not all be able to produce or consume data at the
`same rate. If each device is allowed to produce or consume
`data at the fastest rate possible for that device, the slower
`devices will not be able to keep up with the faster devices.
`If all devices are slowed to the rate of the slowest device on
`the system, the performance of the system will become
`unacceptably slow.
`The problem of differing speed devices is sometimes
`addressed by including large buffers in each device to avoid
`overflow or underflow of data. To guarantee that the device
`can keep up, the buffer must be large enough to hold the
`largest possible burst data transfer. This requires a design
`trade-off between buffer size and maximum packet size of
`the burst data transfer. From a performance standpoint, it is
`desirable to have the largest possible maximum packet size
`to reduce the overhead of transferring large data blocks.
`From a cost standpoint, it is desirable to have a small packet
`size so that only a small buffer is required. Moreover, even
`buffers are not a complete solution to the problem. It is still
`necessary to have bus interface circuitry operating at the
`same speed on each card, sufficiently fast to empty or fill the
`buffer at the speed of the data transfer, so that design of I/O
`devices is still constrained.
`Another approach to the problem of differing speed
`devices is to allow either device to trigger a pause at any
`point during the transmission. This requires that the devices
`be prepared to accept a pause indication after each word of
`data is transferred on the bus, which is typically accom
`plished with some form of handshaking exchange between
`the devices. Unfortunately, this reduces the speed of the data
`transfer (even where no pause indication is present), and
`adds complexity to the logic that must be present in the
`devices to handle the pauses. In effect, allowing a pause at
`any point defeats the purpose of burst transmission, which is
`to send data a rapidly as possible in an uninterrupted stream.
`In the design of a communications bus, it is desirable to
`permit a variety of different types of devices operating at
`varying speeds to be attached to the bus, and to utilize the
`high speed characteristics of high speed devices, while still
`permitting low speed devices to be attached to the system.
`It is also desirable to avoid transmission overflows in the
`receiver's buffer, or underflows in the sender's buffer, with
`out the need for large buffers. A variety of different com
`munications protocols exist. However, these either require
`more hardware than minimally necessary or otherwise
`unduly constrain the performance or characteristics of the
`system.
`
`SUMMARY OF THE INVENTION
`It is therefore an object of the present invention to provide
`an enhanced method and apparatus for communicating
`among a plurality of devices attached to a communications
`bus.
`Another object of this invention is to increase the perfor
`mance of a system having a communications bus and a
`plurality of devices attached thereto.
`Another object of this invention is to reduce the design
`constraints of devices attached to a communications bus.
`Another object of this invention is to reduce the design
`complexity of devices attached to a communications bus.
`
`15
`
`20
`
`25
`
`BACKGROUND OF THE INVENTION
`Modern computer systems support communications at
`many different levels. An individual computer comprises a
`variety of different processors communicating with each
`other. A single central processing unit (CPU) is typically the
`basic workhorse of the computer, but other processors
`control disk storage devices, printers, terminals, communi
`cations with other computers, etc. Even more remote and
`primitive processors may control other functions, such as
`monitoring sensors, input keypads, etc. In addition, multiple
`computer systems may be connected to s network, whereby
`they may communicate with each other. Each of these
`processors or systems must have some defined path for
`communications.
`Design requirements for communications paths vary. A
`30
`typical computer system will have several paths which must
`support high speed mass data transfer. For example, when a
`block of code is loaded from a magnetic disk storage device
`into main memory, the volume of data being transferred
`requires a very fast, efficient mechanism.
`To support mass data transfer operations, most computer
`systems employ some form of burst data transfer protocol.
`A burst protocol typically comprises an initialization part, a
`data transfer part, and a concluding part. In the initialization
`part, the sender informs the receiver of the pending trans
`mission, providing information necessary for the receiver to
`prepare itself. For example, the sender may tell the receiver
`the number of bytes to be transferred, a forwarding desti
`nation for the data, etc. The receiver may be required to
`acknowledge receipt of initialization information before the
`sender can start transmitting the main body of data. In some
`protocols, initialization will involve several exchanges
`between sender and receiver. After initialization is complete,
`the sender sends the data, without further intervening
`exchanges. When all data has been transmitted, the conclud
`ing part of the transmission occurs. The receiver will typi
`cally perform some error checking of the transmission, as for
`example, by verifying parity bits, or that the correct number
`of bytes were received. The receiver will then send an
`acknowledgment message to the sender, indicating either
`that the data was received without error or that some error
`was detected. As in the case of initialization, the concluding
`part may involve more than a single exchange between
`sender and receiver. Although there is some overhead asso
`ciated with the initialization and concluding phases, in the
`case of a large data transfer this overhead is offset by the fact
`that the data transfer phase is large in comparison to the
`other two phases.
`The essential feature of burst communication is that the
`data transfer takes place at high speed and without interrup
`tion. This feature places certain constraints on the design of
`the sender and receiver devices. On the one hand, it is
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 7
`
`

`

`5,584,033
`
`3
`Another object of this invention is to increase the speed of
`information transmission between devices attached to a
`communications bus.
`Another object of this invention is to reduce the cost of a
`system having a communications bus add a plurality of
`devices attached thereto.
`A plurality of devices attached to a communications bus
`observe a burst transfer protocol which allows pausing only
`at pre-determined, fixed intervals of n data transfer cycles,
`where, in the preferred embodiment, one word, being the
`width of the bus, can be transferred in one data transfer
`cycle. In accordance with this protocol, a sending device and
`a receiving device obtain control of the bus to establish a
`burst transfer communication. Once burst transfer is initial
`ized, the sending device transmits an uninterrupted stream of
`in data transfer cycles over the communications bus. After a
`predetermined number of n data transfer cycles, where n is
`greater than one, either the sender or receiver may cause
`transmission to pause. The sender may need to wait for more
`data, or the receiver may need to finish processing the data
`just received. The pause lasts as long as needed until both
`devices are ready to proceed. The sender then transmits
`another n data transfer cycles, and the devices pause as
`required until they are both ready. This cycle is repeated
`until the data transmission is complete.
`The sending and receiving devices do not relinquish
`control of the bus during a pause, and therefore are not
`required to re-initialize communications. In the preferred
`embodiment, after n data words have been transmitted, the
`sender and receiver toggle interlocking signals that accom
`plish a handshaking between the two devices. The sender
`de-activates its signal when it is ready to send more, and the
`receiver de-activates its signal when it is ready to receive
`more. Generally, the pause will be of a relatively short
`duration, and the overhead associated with terminating the
`data transfer and re-initializing would considerably out
`weigh the effects of the pause.
`Bus devices must be equipped with buffers large enough
`to hold the data within n data transfer cycles, but the buffer
`need not be any larger than this. The choice of optimum size
`of n involves a trade-off between buffer size and the over
`head associated with handshaking and pausing as necessary.
`Because the overhead associated with handshaking is far
`less than the overhead of terminating and re-establishing a
`burst communication, the buffer can be made much smaller
`than is normally required to support burst communication
`without pausing. Furthermore, the total length of a burst
`communication is not limited by buffer size, making much
`longer burst communications possible. In the preferred
`embodiment, n is 32 data transfer cycles.
`Because the sending device transmits an uninterrupted
`stream of n data transfer cycles, it can guarantee that
`sufficient space will be available in its buffer for the next
`data transfer cycles stream within a specific time period. As
`a result, it can overlap the action of obtaining more data
`(refilling the buffer) with the action of transmitting the
`current data (emptying the buffer). Furthermore, allowing
`pauses only at specific intervals simplifies the bus interface
`circuitry because the number of potential cases (or sce
`narios) involving pauses is drastically reduced.
`
`45
`
`50
`
`55
`
`60
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows the major components of a computer system
`employing a burst transfer protocol according to the pre
`ferred embodiment of this invention;
`
`65
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`4.
`FIG.2 shows in greater detail the structure of a system I/O
`bus employing a burst transfer protocol according to the
`preferred embodiment of this invention;
`FIG. 3 sows the major components of a typical bus
`interface unit according to the preferred embodiment;
`FIG. 4 shows the steps required to transfer data in a burst
`protocol according to the preferred embodiment;
`FIG. 5 shows the actions of key portions of the bus during
`data transfer phase according to the preferred embodiment.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`A diagram of the major components of a computer system
`employing a burst transfer protocol according to the pre
`ferred embodiment of the present invention is shown in FIG.
`1. Computer system 100 comprises system I/O bus 101, to
`which are attached a plurality of bus interface units 102,
`110-2. Bus interface unit 102 couples a system processorbus
`103 to system I/O bus 101. System central processing unit
`(CPU) 104 and system random access memory 105 are
`connected to system processor bus 103. Bus interface units
`110-2 couple respective I/O processor units 113-5 to system
`I/O bus 101. Buses 101 and 103, together with bus interface
`units 102, 110-2, establish a communications path between
`any two I/O processor units, or between CPU 104 or
`memory 105 and any I/O processor unit.
`Each I/O processor unit 113-5 handles communications
`with one or more I/O devices (not shown). These I/O devices
`may, for example, be magnetic disk drive units, magnetic
`tape drive units, interactive workstations, printers, etc.,
`which are attached to system 100. In the alternative, an I/O
`processor unit may handle communications with other com
`puter systems via a local area network or remote commu
`nications lines. I/O processor unit 113-5 is shown separately
`from their respective bus interface units 110-2 in FIG. 1 to
`illustrate the division of function. In the preferred embodi
`ment, the I/O processor unit and its bus interface unit may
`be contained in a single circuit card assembly, a portion of
`the circuitry on said assembly comprising the bus interface
`unit, and another portion comprising the I/O processor unit.
`While I/O processor units 113-5 are shown generically in
`FIG. 1, it should be understood that different types of I/O
`processor units may exist with system 100, and that the
`number of such units may vary. In addition, system 100 may
`comprise multiple CPUs and memory units communicating
`with other units via system I/O bus 101. In the preferred
`embodiment, system 100 is an IBM Application System/400
`computer system, it being understood that other systems
`could be used.
`The structure of system I/O bus 101 of the preferred
`embodiment is shown in greater detail in FIG. 2. System I/O
`bus 101 is a bi-directional bus comprising address/data bus
`portion 201, command/status bus portion 202, origin/desti
`nation bus portion 203, MSEL line 204, RDY line 205,
`ACKB line 206, REQB line 207, MST line 208, BUSG line
`209, and REQP portion 210. Address/data bus portion 201
`carries the actual data bits being transmitted by bus 101; it
`comprises 32 data lines (4 bytes) and four parity lines.
`Command/status bus portion 202 carries command and
`status information with respect to a data transfer, it com
`prises 8 command/status lines and one parity line. Origin/
`destination bus portion 203 carries information identifying a
`bus unit, and is used to identify the originator of an operation
`or destination of a command. It comprises 5 bus unit
`identifier lines and one parity line. MSEL ("Master Select”)
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 8
`
`

`

`S
`204 and RDY ("Ready) 205 are bi-directional lines used in
`handshaking between the sending and receiving devices.
`ACKB ("Acknowledge Bus") 206, REQB ("Request Bus")
`207, and BUSG (“Bus Grant') 209 are uni-directional lines
`used to arbitrate control of the bus. MST ("Master Steering")
`208 is a uni-directional line used by the master to hold
`control of the bus. REQP (“Request Priority') portion 210
`comprises three bi-directional lines used for communicating
`a priority level with a request for control of the bus. Poll 220
`is serially propagated to the individual bus units; this line is
`used for bus arbitration. Bus 101 comprises additional lines
`(not shown) which are used for error recovery or other
`functions not part of the invention described herein. Because
`bus 101 supports the transfer of 4 bytes in parallel, a data
`word is defined as 4 bytes (32 bits) of information and this
`is the amount of data that can be transferred in one data
`transfer cycle.
`FIG. 3 shows the major components of a bus interface
`unit, such as any of units 102,110-112 shown in FIG.1. Bus
`101, comprising a plurality of individual bidirectional lines,
`is physically connected to the bus interface unit. Each line
`of bus 101 is connected to a separate high impedance driver
`circuit 301. A buffer 303 contains a plurality of memory
`cells, sufficient to hold in data words, where n is the number
`of data words transmitted between each potential pause
`point. In the preferred embodiment, n is 32. Bus interface
`unit may optionally contain additional buffers 304. One of
`the bus interface units contains bus arbitration logic 305.
`Bus arbitration logic 305 manages the bus by granting
`control for a limited time to a requesting bus interface unit,
`following a predefined bus arbitration protocol. In the pre
`ferred embodiment, arbitration logic 305 is located in bus
`unit 102 coupling the system I/O bus 101 with system
`processor bus 103. However, arbitration logic could alter
`natively be in any bus unit, or in a dedicated arbitration unit
`which does not itself transmit data on the bus.
`A variable number of bus interface units can be attached
`to bus 101. When receiving data or when idle, high imped
`ance driver circuits 301 of each bus interface unit are in a
`high impedance state. This high impedance state allows
`another bus unit to send signals on the bus without inter
`ference, and at the same time permits the bus unit (not
`sending signals) to receive bus signals. When active, high
`impedance driver circuit 301 can act in driver mode to send
`a signal on the bus line. The design of such high impedance
`driver circuits is known in the art.
`The protocol for transferring data according to the pre
`ferred embodiment will now be described. FIG. 4 shows the
`steps required to transfer data on bus 101. For purposes of
`the data transfer operation, the bus unit requesting a data
`transfer is referred to as the "master'. The bus unit to which
`a request is directed is the 'slave'. The master may be either
`a sender or a receiver of data, depending on whether the
`requested operation is a write or a read. The designations
`"master”, “slave', "sender' and "receiver' are applicable
`only to a specific data transfer operation. Each bus interface
`unit is capable of acting either as master or slave, sender or
`receiver of data.
`A data transfer operation contains an initialization phase,
`a data. transfer phase, and a conclusion phase. The initial
`ization phase commences when a bus interface unit requests
`control of the bus for purposes of initiating the transfer. The
`first step is for the requesting unit to gain control of the bus
`(becoming "master' for purposes of the operation), at 401.
`Bus arbitration logic 305 recognizes the request and,
`through an established protocol, described more fully below,
`grants control of bus 101 to the requesting unit, which then
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,584,033
`
`10
`
`5
`
`20
`
`30
`
`6
`becomes the master. The master unit then issues the appro
`priate data transfer command to the slave at 402. The slave
`to which the command is directed responds by sending its
`status to the master at 403. At this point the receiving unit
`may elicit a pause by holding a defined signal line active.
`When the line is de-activated, the data transfer phase is
`ready to begin.
`In the data transfer phase, the sender transmits 32 words
`of data in successive cycles, without interruption, at step
`404. Each word is the amount of data the bus can support in
`a single cycle, i.e. the number of parallel data lines in the
`bus. In the preferred embodiment, address/data portion
`comprises 32 lines (4 bytes) of data. Since 4 bytes are
`transmitted with each cycle, a total of 128 bytes are trans
`mitted by the sender in 32 cycles.
`On the 32nd data transfer cycle, the slave sends its status
`to the master at step 405. The receiver may then elicit a
`pause by holding a defined signal line active. The pause
`continues as long as the signal line is active. The deactiva
`tion of the line is the receiver's indication that it is ready to
`continue. The sender may also pause if necessary until it is
`ready to continue. If more data remains to be transferred
`(step 406), the sender resumes by transmitting another 32
`words in uninterrupted cycles at step 404. Steps 404–406 are
`repeated until all data has been transferred. When the data
`transfer phase is complete, the master relinquishes control of
`the bus at 407 (the conclusion phase).
`In the preferred embodiment, the bus unit desiring to
`initiate a transfer requests control of the bus by activating
`REQB line 207. Arbitration logic 305 detects the activation
`of REQB line 207 and responds by activating ACKB line
`206 and BUSG line 209. At the same time, poll 220 is
`activated. Each bus interface unit in turn propagates a signal
`on poll line 220 until a bus unit requesting the bus is
`encountered. This bus unit (at which the poll is halted) then
`activates MST line 208 and MSEL line 204, and deactivates
`REQB line 207, effectively assuming the role of master.
`Arbitration logic 305 responds by deactivating ACKB line
`206, and later deactivates BUSG line 209, completing
`arbitration step 401.
`The arbitration sequence described above is designed to
`ensure that only one bus unit can become master at any one
`time. If more than one bus unit activate REQB line 207 more
`or less simultaneously, the first bus unit to receive the poll
`will become master. This order can be modified by use of
`REQP portion 210. A bus unit can activate a line in REQP
`portion to indicate a priority associated with its bus request.
`Any unit receiving the poll must then have a bus request of
`as high a priority as the highest priority request made via
`REQP bus portion 210 to become master; otherwise, it must
`propagate the poll to the bus unit with the higher priority
`request.
`It should be understood that the description above is only
`an overview of the arbitration protocol of the preferred
`embodiment, the actual protocol containing additional
`defined sequences for recovery from errors and other con
`flict resolution, as is known in the art. The essential feature
`of the arbitration sequence is that only one bus unit can
`become master at any one time; the implementation details
`are not critical to the invention claimed herein. It would, be
`possible to practice this invention with other arbitration
`protocols.
`In the preferred embodiment, when the master bus unit
`activates MST line 208 during the arbitration sequence, it
`also drives command/status bus portion 202 and origin/
`destination bus portion 203 with identifier data correspond
`
`Petitioner STMicroelectronics, Inc., Ex. 1010
`IPR2021-00355, Page 9
`
`

`

`5,584,033
`
`10
`
`15
`
`20
`
`25
`
`7
`ing to the desired command and slave unit, respectively, All
`bus units are listening to the sequence of bus signals, and
`will know that this is the signal for the slave unit to respond.
`The slave unit identified by the data on origin/destination
`bus portion 203 responds by activating RDY line 205. The
`master unit acknowledges this response by deactivating
`MSEL line 204. The slave unit then deactivates RDY line
`205, completing slave selection step 402.
`With arbitration and selection complete, the master and
`slave units then perform an initial status cycle prior to data
`transfer. The master unit activates MSEL line 204, request
`ing status from the slave. The slave unit responds by driving
`command/status bus portion 202 with status data, and acti
`vates RDY line 205 after a predefined delay. The master unit
`reads status and deactivates MSEL line 204 when it is ready
`for the data transfer phase to begin. The slave unit deacti
`vates RDY line 205 when it is ready. Either the master or
`slave unit may force a pause at this point by holding MSEL
`or RDY line active, respectively. When the master deacti
`vates MSEL and the slave deactivates RDY line 205, initial
`status cycle 403 is completed and the data transfer phase is
`ready to begin.
`Except for minor details unrelated to the substance of the
`invention claimed herein, the protocol during the initializa
`tion phase is the same whether the command calls for
`transfer of data from master to slave (WRITE command) or
`for transfer of data from slave to master (READ command).
`During data transfer phase, each bus unit controls a separate
`line for the purpose of timing and acknowledgment, desig
`nated the handshake line. The master unit controls MSEL
`line 204 which is its handshake line. The slave unit controls
`30
`RDY line 205, which is its handshake line. The protocol for
`WRITE commands and READ commands is similar, but the
`role of MSEL and RDY lines are reversed due to the
`reversed roles of their respective controlling bus units.
`The operation of the handshake lines in conjunction with
`address/data bus part 201 and command/status bus part 202
`during the data transfer phase is illustrated in FIG. 5. After
`initialization is complete, data transfer proceeds in 128-byte
`bursts as follows. The sender bus unit (which may be either
`the master or slave) activates its handshake line (501), which
`40
`would be MSEL line 204 in the case or a WRITE, and RDY
`line 205 in the case of a READ. The sender must drive
`address/data bus portion 201 with the first four bytes of data
`to be transferred (502) a predefined setup time period before
`activating its handshake line to ensure data is valid at the
`time the line is activated. The receiver must accept the data
`on address/data bus portion 201 within a predefined hold
`time period after the activation of the sender's handshake
`line. The sender deactivates its handshake line after a
`predefined stability period (503). The sender's handshake
`line remains inactive for the predefined stability period, after
`which it repeats the cycle to transfer another four bytes of
`data. Sometime after the predefined hold period following
`activation of the sender's handshake line on the first cycle,
`and before a predefined setup period before activating the
`handshake line on the second cycle, the sender drives
`address/data bus portion 201 with four more bytes of data for
`the second cycle. The gap in time when the first four bytes
`of data is valid and the second four bytes is valid on
`address/data bus part 201 is shown in FIG.5 as crossed area
`504, indicating that the receiver should not attempt to read
`the bus during this period. The cycle repeats 31 times,
`effecting the transfer of 124 bytes. During this period, the
`receiver's handshake line is inactive. The receiver plays a
`completely passive role, simply receiving data on address/
`data bus portion 201 at the cycle intervals indicated by the
`rise and fall of the sender's handshake line.
`
`50
`
`8
`After the sender deactivates its handshake line to end the
`31st cycle (510), the receiver activates its handshake line
`(505). The master activates its handshake line on the 32nd
`cycle before the slave. Thus, where a READ operation is in
`progress (slave is sender), the receiver activates its hand
`shake line (505) first, then the sender activates its line (506)
`for the 32nd cycle. Where a WRITE operation is in progress
`(master is sender), the sender activates its line (506) before
`the receiver activates its line (505). The sender drives
`address/data bus portion 201 with 4