`
`INTERFACING
`
`Harold S. Stone
`
`Page 1 of 41
`
`Samsung Exhibit 1020
`
`
`
`Microcomputer
`Interfacing
`
`HAROLD S. STONE
`lNVB&TYG .MME§T
`
`fi AWISON-WESLEY PUBLISHING OOMPANY
`READIN3. HTS
`|£M.O PAR‘. CALJFGRMA
`LWJGJ
`AWTEHJAM
`
`DUN MLLS. (NTARIO
`SYEIEY
`
`Page 2 of 41
`
`
`
`This book is in the ADDISON-WESLEY SERIES IN ELECTRICAL ENGINEERING
`
`SPONSORING EDITOR: Tom Robbins
`PRODUCTION EDHOR: Marilee Sorouldn
`
`TEXT DESIGNEK: Herb Caswell
`
`IU..USTRA'IOR' Jay’: Publishers Service Inc.
`(DVER DBIGN AND IILUSTRATOR: T. A. Pllilbrook
`
`ART COORDINATOR: Joseph Vetere
`PRODUCTION MANAGER: Sue Zorn
`
`PRODUCTION CXXIIDINATOR: Helen Wytlle
`
`finmxtofdfismokwmamposedmfincskmrulmahdagemflulnbykfunnnim
`SciencesCorpotutionnndwsprimedbyR.R.DonnelleyandSons.
`
`Lllnry ol‘Congm Cnuloglngln Pnbflafloulhu
`
`Slom, Hamid S., 1938-
`
`Bibli°snphy=p-
`I. lnnfacecixcuits.
`l.Tn|e. TK7868.lS8S76
`ISBN 0-201-07403-6
`
`2. u.
`62l.38l9’5835
`
`81-17619
`
`AACRZ
`
`Reprinted with corrections, February 1983
`
`Copyright © 1982 by Addison-Wesley Publishing Company, Inc.
`
`Allrightsneserved.Nopanofmisbooknnybe!qmdwed,stmedmateu'ievdsystan.mmmnined,mmy
`fumorbyanynrans,e|ectmnic,nnd1anical,pIxxooopyh1g,nouding,mod1etwisc,wiIIn1mepri<xwfincn
`pe:~missionofthepuhlisher.Ptinledintl1eUninedStatcsofAm:1ica. Printedsin1ultaneouslyinCanada.
`Isnuozm-07403-6
`ncnatnmxoonnssas
`
`Page 3 of 41
`
`
`
`3 / BUS INTEFICONNECTIONS
`
`Now that we have covered both the high-level functional description of microcomputers
`and have looked as well at the lowest-level of implementation details, we will work our
`way quickly into practical interfacing techniques. This chapter treats the data paths that
`tie together the processor, memory. and I/O modules of a microcomputer. The strategy
`followed for these intercomiections is similar across all microcomputers; they make use of
`a general structure that we call a bus. A bus is a collection of signal lines that carry
`module-to-module communications in a microcomputer. In almost all cases bus lines are
`unbroken, and modules simply tap onto a bus by connecting their respective inputs and
`outputs directly to corresponding bus signal lines. (The only exception to this rule is for
`signal lines used for priority resolution, as described later in this chapter.)
`For high-performance applications, buses must be restricted in length, thus limiting
`their use to the short module-to-module connections within a computer chassis. Although
`these buses can be extended from one chassis to another, performance and reliability
`suffer as bus length increases. For the longer and lower-performance interconnections,
`most microcomputer systems rely on special buses, quite separate from their high-speed
`internal buses, or on other point-to—point connections in order to isolate the high-speed
`buses from the long physical buses, thereby reducing the degradation caused by excessive
`bus length. Exceptions to this practice occur in low-speed applications where the internal
`bus runs slow enough to be extended to a second chassis with little or no performance
`penalty. With just one type of bus, the system avoids an additional burden of integrating
`two distinct bus systems and protocols.
`
`3.1 BUS FUNCTIONS
`
`The signal lines that collectively form a bus break naturally into three groups as shown in
`Fig. 3.1. One group of signals carries the basic information to be communicated on the
`bus; the other two signal groups guarantee that the infomiation is delivered during a bus
`transaction. From the earlier discussion of the functional behavior of a microprocessor,
`we know that the first group of signals carries such infomiation as
`
`1. memory address (or port ID).
`2. data. and
`
`3. command type (READ, WRITE, DATA, STATUS).
`
`Since there are a vast number of different buses in use, there is a wide variation in just
`what information is carried on the first group of lines. Generally speaking, this group car-
`ries infonnation that one module needs to convey to another in order to invoke a remote
`
`Page 4 of 41
`
`
`
`3.1
`
`Bus Functions
`
`89
`
`Address, data. commands
`
`Data transfer control
`
`FIGURE 3.1 Bus signal and control lines.
`
`function, response, or change of state in the remote module. ln order to pass the informa-
`tion, the bus itself has to be controlled and operated correctly. The other two groups are
`dedicated to different aspects of the latter function.
`.
`The second group of signal lines controls the timing of the data transfer. This group is
`often called the data handshake lines, and contains the signals that dictate when each indi-
`vidual data transfer begins and ends. The handshake lines have a role analogous to traffic
`lights on a roadway. The handshakes start and stop transactions, and they exert the same
`functional control on all transactions regardless of transaction type.
`The type of transaction comes into play on the third group of lines, the arbitration
`lines, which give critical transactions priority over less critical ones when deciding what
`transactions shall access the bus. This third group of lines arbitrates which module gains
`access to the bus. The necessity for arbitration is due to the inherent problem that occurs
`when two or more modules attempt to transmit information simultaneously. lf module A
`spews forth a logic 0 while module B attempts to transmit a logic 1 at the same instant of
`time, we say that there is a bus conflict. The signal actually delivered depends on the logic
`family that drives the bus. A line driven by open-collector drivers moves to the 0 state
`during any conflict, so that in the given example, the logic 1 output by module B is lost.
`Then one or both modules lose data at the point of conflict, and what data are lost is
`unpredictable. Hence, conflicts almost certainly result in a communications failure on the
`bus. To ensure reliable communication, as a general rule only one module at a time can
`transmit on the bus, although potentially all other modules can accept the transmission
`andchange state in response to it.
`A bus conflict can be more disastrous than portrayed here. For example, what hap-
`pens when tri-state drivers engage in a bus conflict? In this case, there is a possibility of
`damaging the bus drivers because the conflict creates a low impedance path from Vcc to
`pound through the output stages of the conflicting gates. The high current through this
`
`Page 5 of 41
`
`
`
`90
`
`Buslntoreonnoctlons
`
`path can bum out both driving gates. If either gate fails in a shorted condition, the failure
`could be in conflict with other driving gates on the same signal line, and burn them out as
`well. If bus conflicts occur during an instruction-fetch cycle, the instruction received by
`the processor is a corrupted version of its original form, and the incorrect version almost
`inevitably wreaks havoc in the program.
`The role of the arbitration lines is then very clearly defined. They guarantee that, at
`most, one module at a time transmits on the bus. The first two groups of signals, the infor-
`mation and handshake groups, are thus protected from conflict by the arbitration group.
`The arbitration group has inherent conflicts because all potential transmitting devices use
`these lines concurrently as part of the arbitration process. Therefore, in many buses the ar-
`bitration lines are driven with open-collector devices. and the arbitration protocol depends
`on the OR-function logic of the open—collector gate.
`Later sections of this chapter treat various methods for implementing both the
`handshake and arbitration protocols. Even though the context of the discussion is buses,
`the protocols have a use that extends into other areas of microcomputers as well. For ex-
`ample, an arbitration protocol for selecting one of several potential bus transmitters is also
`suitable for selecting one of several I/O ports in an interrupt-priority resolver.
`
`3.2 THE BUS HANDSHAKE
`
`Handshake protocols fall generally into three broad classes:
`
`I . synchronous (clocked transfer, one clock period per transfer),
`2. asynchronous (unclocked), and
`3. semisynchronous (clocked transfer, one or more clock periods per transfer).
`
`Since the specific function of the handshake lines is to indicate the beginning and end of a
`data transfer, the handshake lines must somehow mark these points through voltage
`changes in the handshake signals. Some buses have very complex, sequential timing for
`each data transfer, perhaps requiring a number of different data to pass along the bus dur-
`ing a single transaction. For these buses, the handshake lines signal the beginning and end
`of each subcycle within the full cycle, as well as identifying the start and end of the full
`cycle.
`The three generic handshake techniques span a spectrum of different approaches from
`complete control by a clock to no clock control whatsoever. Synchronous protocols are
`among the easiest to implement because the only control signal is a clock oscillator. The
`rising and falling edges of the clock signify, respectively, the beginning and end of a bus
`cycle. All memories, peripherals, and processors on the bus are controlled by the same
`clock oscillator so that modules operate in “lock-step," advancing cycle by cycle as the
`clock line ticks away. Not only are synchronous protocols the least complex of the three
`protocols, but they also.
`in general, lead to the fastest transactions (provided that the
`responding devices are fast enough to operate at the bus—clock speed).
`
`Page 6 of 41
`
`
`
`3.2
`
`Thoausflandslruko
`
`91
`
`synchronous Buses
`
`The timing of a typical synchronous protocol is illustrated in Fig. 3.2. The top waveform
`isthe bus clock, which synchronizes all modules to a common time base. (It is shown here
`with a 50% duty cycle, but the actual duty cycle differs for various synchronous buses.)
`Address and data lines are shown on the next two wavefonns. The addresses and data
`
`each their stable values at the beginning of the shaded area, retain their values through
`the high half-cycle of the clock, and fall at the end of the trailing shaded area. Although
`the address and data lines are shown in the high-state during the active portion of the
`clock. they actually can be in either a high or a low state. depending on the information
`they convey. The figure actually shows the period during which the address and data lines
`are stable, and does not show their logic values.
`
`Clock
`
`Address
`
`Data
`
`§\\\\\\V-! t\\\\\VI!
`
`.\\\\\\§
`
`WRITE
`
`READ
`
`WRITE
`
`\\}‘
`/.
`
`Setup decode and skew delay W Hold-and-skew delay
`’
`’
`\
`
`FIGURE 3.2 Timing for a synchronous bus.
`
`There are several different reasons for the shaded area of the waveforms. Fig. 3.3
`shows one source of logic delay in the address decoder of a receiving module on the bus.
`The figure shows a bus transmitter, hereafter called a bus master, transmitting to a re-
`ceiver labeled bus slave. There are potentially many slaves on the bus, and the purpose of
`the address lines is to select a single slave to respond to the bus transaction. Therefore, the
`figure shows the address lines entering a decoder that detects the slave's address, which
`then selects this specific slave by producing a signal that forces the slave to load data from
`llre bus when the clock reaches the active phase of its cycle. The decoder has to produce
`itssignal in advance of the rising of the edge of the clock, so that the address lines must be
`stable for at least the duration of the logic delay through the decoder.
`
`Page 7 of 41
`
`
`
`
`
`FIGURE 3.3 Typical slave internal structure.
`
`Another related effect that cannot be ignored is the setup time and hold time of logic
`in the buffer. Setup time is the minimum amount of time that a control signal has to be
`present on an input of a memory device before the clock triggers a transfer into the device.
`Hold time is the minimum time that data has to be held stable on the inputs of a memory
`device after a clock change triggers a transfer into that device. The setup time for the
`diagram in Fig. 3.3 for a WRITE into the slave is the time required for the address lines to
`be stable after they reach the buffer, but before applying a clock to the buffer. The hold
`time in Fig. 3.2 depends on whether the bus operation is READ or WRITE. For a
`WRITE, the hold time is the hold time of the buffer in the slave. For a READ, the hold
`
`time is the hold time of the equivalent buffer in the master. In both cases, the addresses
`and data must be stable for at least the duration of the hold time after the clock changes
`state. Address and data lines need to have identical setup and hold times. If they are not
`identical, the bus protocol must incorporate setup and hold times that are long enough to
`satisfy the maximum of the address and data requirements.
`In the light of the infomiation on setup and hold times, let us return to Fig. 3.2 to con-
`sider how these times are represented in the figure. For a WRITE operation, the master
`transmits both addresses and data in advance of the rising edge of the clock. During this
`time the slave decodes the address, and the data lines stabilize at the buffer. When the
`
`clock rises, the selected slave initiates an internal WRITE operation, during which it
`copies the data on its data lines into an address or register identified by the address lines.
`If the slave is a memory chip, the subsequent delay accounts for the write-access time to
`memory, usually on the order of 100 to 200 ns for moderate-speed rnetal-oxide silicon
`(MOS) devices. Other devices can be bus slaves as well, including I/O ports and discrete
`registers. Some devices respond faster than the moderate-speed memory, but the fixed-
`cycle time of the synchronous bus cannot take advantage of the faster response. The fall-
`ing edge of the clock signifies the end of the bus cycle. At this time, the WRITE operation
`is complete, and the slave can disconnect logically from the data lines.
`
`Page 8 of 41
`
`
`
`
`
`The READ operation is similar to WRITE for the address lines, but data lines behave
`differently. In this case the rising edge of the clock initiates a memory READ in the slave.
`Some time after the clock rises, the data reaches the output buffer of the slave, which in
`turn places the data on the bus. The data has to be on the bus at least one setup time before
`the falling edge of the clock, where the setup time in question is the setup time of the
`master’s data buffer. The slave holds the data on the bus at least one hold time after the
`
`falling edge of the clock in order to satisfy the hold-tirne requirements of the master.
`Reexamination of Fig. 3.2 shows we have accounted for the general form of the
`shaded area, although we have not accounted for exact lengths of time. Note that the setup
`time is shown much longer than the hold time because the setup time includes the decod-
`ing delay in the slave, as well as other factors we now examine.
`Among the other sources of timing delay accounted in the shaded area is signal skew,
`which is explained more fully in Fig. 3.4. The top two waveforms show the signals on two
`address lines as they appear at the bus master. Both signals are assumed to change at
`exactly the same instant for the purposes of this discussion although. in reality, the master
`itself may produce these signals displaced slightly with respect to each other. The master
`transmits the signals over the bus to the slave, which sees the signals as shown in the
`lower two waveforms of the figure. Note that the signals no longer change at the same
`instant of time, but now one changes D time units later than the other. This change in rela-
`tive timing produced somewhere in the bus system is what we mean by skew.
`
`Address line waveforms at bus master.
`
`
`
`Address line waveforms at bus slave.
`
`FIGURE 3.4 Skew in signal
`transmission. The delay D is the
`skew in the signals.
`
`Page 9 of 41
`
`
`
`Several different sources of skew account for the delay. One source is a difference in
`the propagation delays of the two signals because the signals follow slightly different
`paths in going from master to slave. Propagation delays usually influence skew less than
`the varying logic delays through gates on the path from master to slave. Gate delays may
`vary from chip to chip by 10 to 20 ns, depending on the chip family. Since each of the bus
`signals travels through a different set of gates, the end—to-end propagation time is rarely
`the same for all bus signals. The rise time and fall time of a signal also affect skewing
`delays. A gate recognizes a change in a signal when the signal voltage passes the gate
`threshold. If capacitive effects stretch out the rise or fall time, there is an apparent
`increase in the delay between the start of a signal transition and the time when the transi-
`tion is recognized. Since this time also depends on the gate threshold, differences in gate
`thresholds contribute to differences in skew in much the same way that rise and fall times
`impact skew.
`To compensate for skew, addresses must stabilize at least one maximum skew time
`earlier than in the absence of skew, just in case some address line is delayed by skew rela-
`tive to the rising edge of the clock. Hence the shaded area said to be setup time in Fig. 3.2
`includes this skew time plus the decoding time and address setup time. Note also that the
`hold time for data written includes skew to protect against problems caused by clock
`skew. If the clock were delayed relative to the data during the propagation of the signals
`from master to slave, then the apparent hold time of data at the slave is diminished by the
`amount of the skew. Hence, for a WRITE cycle the master has to assert data for at least
`one hold time plus one skew time after the clock edge falls.
`It is interesting to consider the effects of propagation delays on hold time. For the
`READ operation, propagation delays actually reduce the hold time somewhat, whereas
`for WRITE operations they have no effect unless increases in propagation delay tend to
`increase clock skew also. Consider the READ in Fig. 3.2, for example, and observe what
`happens if there are significant propagation delays between master and slave. When the
`master drops the clock signal at the end of the cycle, the output data at the slave remains
`stable at the master's input buffer for at least one round-trip propagation time between
`master and slave. This is true because the clock edge change has to propagate from master
`to slave, and the resulting changes on the data lines then propagate back to the master.
`Technically speaking, a slave can reduce hold time by the amount of a propagation delay,
`but in practice it is very difficult to do so. The propagation time delay depends on the rel-
`ative positions of the master and slave on the bus, and this varies from configuration to
`configuration. Yet the slave module has to be engineered to work in every configuration,
`so that at best the slave can take advantage of the shortest propagation delay that can occur
`in any configuration. This delay is so unpredictable, and likely to be very small in any
`event, that it is rarely worthwhile to consider.
`This brings us to the end of our discussion of the details of Fig. 3.2. To summarize the
`effects that limit the bus bandwidth, we have
`
`I. setup time of data and control signals before clocking data into a buffer,
`2. address decode delay,
`.
`
`Page 10 of41
`
`
`
`3.2
`
`‘lheaucflandahalo
`
`95
`
`3. skew time of address and data signals relative to a rising and to a falling clock edge,
`4. hold time of data at a buffer input, after clocking data into the buffer, and
`5. one round-trip propagation delay (for the READ operation).
`
`The bus cycle time cannot be smaller than
`
`Tsrrrur ‘l’ TDECODE. + 2TsKr-;w 4' MAX(THoLn. TRT-mop),
`
`where the MAX operation recognizes that propagation delay can be overlapped with hold
`time. If the cycle time of a bus is shorter than the time given here, the signaling rate fails
`to meet the signal specifications for modules that connect to that bus, so that incorrect or
`unreliable computations may result. Even this upper limit on bandwidth is overly optimis-
`tic. In practical situations, the master itself has an internal delay between transactions,
`and the slave has a nonzero access time, both of which increase the minimum cycle time
`and decrease realizable bandwidth.
`
`The primary advantage of the synchronous system is simplicity. Data transfers are
`controlled through a single signal, and the data transfers run with minimal overhead in
`terms of skew, setup, hold, and propagation delays. However, the synchronous bus has a
`serious problem in dealing with slow slaves connected to the bus. The synchronous bus
`described thus far cannot accormnodate devices whose access time is greater than the time
`available during a clock period. With the given bus protocol, the clock rate has to be set
`slow enough to satisfy the slowest device on the bus where the device’s response time in-
`cludes the effect of propagation delays due to physical separation. But this reduces the
`bandwidth for all transactions, and the slow device has thereby decreased the potential
`system performance even though the slow device is rarely accessed.
`
`Asynchronous Buses
`
`For the computer that drives a mix of devices with widely varying access times, the syn-
`chronous protocol may be inappropriate because the bus mns at the speed of the slowest
`device. Intuitively speaking, it is advantageous to have fast tramactions for fast devices
`and slow transactions for slow or distant devices, so that transaction time varies with the
`device rather than being fixed for all time by a system clock. The timing and control sig-
`nals for a typical asynchronous bus that has these characteristics appear in Fig. 3.5.
`This bus is said to be afully interlocked asynchronous bus, and is by far the most pop-
`ular asynchronous protocol in use today. The DEC Unibus for the PDP-ll family is one
`notable implementation of this protocol (Digital Equipment, 1979). The termfidly inter-
`locked stems from the way the two control signals work together during a bus transaction.
`The control signals in the figure are called MASTER and SLAVE, and take the name of
`the module that produces their respective signals. The interlocked protocol requires
`changes to alternate between the control signals and to occur sequentially, with a change
`in one signal anning the other for its subsequent change. By interlocking in this manner,
`the infomtation on address and data lines is guaranteed to be transmitted without conflict
`and without loss or duplication by the bus.
`
`Page 11 of 41
`
`
`
`96
`
`Bus Interconnection:
`
`MASTER
`
`SLAVE
`
`
`
`WRITE
`
`READ
`
`% Skew and decode Skew only
`
`FIGURE 3.5 Timing for a fully interlocked asynchronous bus.
`
`For the WRITE transaction. the bus master places address and data on the bus. After
`a delay to allow for skew, decoding. and setup time, the bus master raises MASTER,
`which signifies to the slave that the data can be accepted. Raising MASTER thus triggers
`a slave memory to initiate a WRITE cycle, and latches data into a slave buffer register. In
`any case, action at the slave takes place only after MASTER is asserted.
`While the slave is busy copying data in response to MASTER. the SLAVE signal
`remains low. When copying is completed, the slave module raises SLAVE to signify,
`“I’ve got it." The handshake continues with MASTER going low ("I see you've got it").
`and SLAVE going low (‘‘I see you see I've got it"). The last two transitions are part of a
`sequence to guarantee that neither MASTER nor SLAVE changes too quickly. SLAVE
`stays high as shown in the figure until the MASTER signal goes low. thus ensuring that
`the high SLAVE signal has been observed and acted upon. Only then does SLAVE go
`low. Similarly, a new transaction catmot be initiated until SLAVE goes low signifying the
`end of the present transaction. Hence the rising edge of MASTER (and the transitions on
`the address and data lines) are interlocked to the fall of SLAVE.
`A READ transaction is very similar to a WRITE, with the high value of MASTER in-
`itiating the operation at the slave after the bus master places an address on the bus.
`SLAVE goes high after the slave module accesses the datum requested and places it on
`the bus. In this context, a high value on SLAVE signifies, “The READ is complete."
`
`Page 12 of41
`
`
`
`
`
`3.2
`
`A
`
`The Bus Handchdto
`
`97
`
`This triggers the master to load its buffer from the bus. During this period SLAVE must
`remain high, and the data lines must be stable. If the slave were to change these signals
`premattuely, the master could read incorrect information. When the master has completed
`its acceptance ofdata, it drops MASTER (“I've got it"), and then SLAVEdrops (“I see
`you've got it").
`The reasons for the interlocking become clear when we consider how a partially inter-
`locked protocol can fail. Consider the two situations shown in Fig. 3.6. In Fig. 3.6(a), we
`permit SLAVE to drop a fixed time after it rises, without waiting for MASTER to drop.
`Likewise, we also remove the interlock between the falling edge of SLAVE and the lead-
`ing edge of MASTER. Also in Fig 3.6(a), SLAVE goes down well before MASTER
`does. and we see that the transfer is done safely. The dotted lines show SLAVE delayed
`somewhat with respect to MASTER. possibly because of long propagation delays or sig-
`nal skew. In this case, if MASTER drops and rises again while SLAVE is high, it may
`mistake the high value of SLAVE for a response to the next transfer. This situation is
`shown in Fig. 3.6(b). Now the master may remove data and addresses too quickly from
`thebus for the slave to accept the new data. As a result, one transaction is lost.
`
`
`
`FIGURE 3.6 Examples of signaling with a partially
`interlocked asynchronous protocol.
`
`Although partial interlocking as shown in Fig. 3.6 lacks the safety of full interlock-
`ing, it can be made safe provided that master and slaves adhere to a strict set of timing
`constraints on the noninterlocked transitions. The advantage of eliminating part of the in-
`terlocking is that the bus transaction can be made a little faster so that the bus bandwidth
`can be greater than it would be in a fully interlocked protocol. But tight constraints usu-
`ally result in higher manufacturing cost, making the partially interlocked protocols less
`desirable in general, although useful in specific applications where the extra expense is
`justified.
`Returning to Fig. 3.5, we note in this protocol shaded areas that represent roles simi-
`lar to those represented by the shaded areas of the synchronous protocol. Addresses have
`to be raised before MASTER at least early enough to permit address decoding and buffer
`setup, and to protect against skew on the address lines relative to MASTER. Hold times
`are not shown specifically, but exist nevertheless. Hold time is usually incorporated into
`
`Page 13 of 41
`
`
`
`the slave by delaying the SLAVE signal one hold time after a WRITE is completed, or
`after presenting data on the bus for a READ. Obviously, the hold time can equally well
`be incorporated into the master, with the SLAVE signal being presented concurrently
`with an event while the master delays its actions one hold time after receiving a transition
`on SLAVE. Whichever of these techniques is used in a protocol, that technique has to be
`used consistently for all slave and master modules, for otherwise the protocol will not
`work correctly. Deskewing data and address signals relative to MASTER and SLAVE can
`nomially be combined with hold time, since skew effects are treated by inserting delays in
`the protocol, in much the way that delays for hold time are inserted into a protocol.
`The wide acceptance of the fully interlocked asynchronous protocol is largely due to
`its reliability and its general efficiency in dealing with devices that have a broad range of
`response times over long buses. But the protocol is inherently slower than the synchro-
`nous protocol because of extra propagation delays. The minimum cycle time for a READ
`operation must account for
`
`l. deskew (and setup time) of addresses to slave,
`2. address decode at slave,
`
`3. deskew (and hold time) of data returned by slave, and
`4.
`two round-trip propagation delays of MASTER and SLAVE signals.
`
`The first three items in this list are comparable to those for synchronous buses, but the
`propagation delay for the fully interlocked handshake is double that of a clocked bus. In-
`fomiation is passed up and down the bus twice per transaction for asynchronous buses, but
`only once for synchronous buses. The second round trip is omitted for synchronous proto-
`cols because the devices are known in advance to respond within a fixed maximum time.
`The purpose of the second round trip for an asynchronous bus is to convey completion in-
`formation that is not bounded in advance.
`
`semisynchronous Buses
`
`Because the propagation delays of the asynchronous bus severely limit maximum
`bandwidth, many bus designers have turned to “hybrid” buses that combine the advan-
`tages of synchronous and asynchronous buses. One such bus is the semisynchronous bus
`that appears in Fig. 3.7. This bus has two control signals, CLOCK (from the master) and
`WAIT (from the slave). In some sense the signals play the role of MASTER and SLAVE
`for the asynchronous bus, but the propagation delays are half those of the asynchronous
`bus because a single round trip is all that is necessary for a successful handshake. For fast
`devices, the bus is essentially a synchronous bus controlled by the clock alone. If a slave
`is fast enough to respond in one clock cycle, it does not raise WAIT, and the sen1isynchro-
`nous bus behaves like a synchronous bus. If the slave cannot respond in one cycle, it
`raises the WAIT signal, and the master halts. Subsequent clock cycles find the master
`idle as long as WAIT is asserted. When the slave can respond, it drops WAIT, and the
`master accepts the slave response using the timing of the standard synchronous protocol.
`The semisynchronous bus thus has the speed of the synchronous bus and versatility of the
`
`Page 14 of41
`
`
`
`
`
`32
`
`‘|'hoBuu|-Iundelndto
`
`so
`
`cuocx I
`
`ADDRESS
`
`MtoS
`
`DATA
`
`I
`
`N
`
`StoM
`I
`
`MtoS
`
`I
`
`StoM
`I
`l
`
`FIGURE 3.7 A semisynchronous bus with cycle times increased by a WAIT signal.
`
`asynchronous bus. However, the length of the semisynchronous bus is limited by the re-
`quirement that WAIT must be asserted within a fixed period of time. So these buses can-
`not have an indefinitely long length, but there is no equivalent timing constraint for asyn-
`chronous buses.
`
`Another way to retain the advantage of the fast synchronous protocol while accom-
`modating slow devices is with the use of a “split-cycle” protocol as shown in Fig. 3.8. In
`this case a READ is split into two separate transactions. During the first transaction, the
`bus master transmits an address to a slave, and then disconnects from the bus. Other mas-
`
`ters then use the bus until the slave is able to return the requested data. At this point, the
`slave initiates the second part of the split cycle by accessing the bus as a master and
`transmitting the data to the requesting module, which responds as a slave. The split cycle
`places a greater burden on the master and slave modules because each type of module
`must have the logic to assume both master and slave roles. Moreover, the bus protocol as-
`sumes that many different bus masters access the bus at different times, so tint every
`module must also contain the logic for bus arbitration protocol in order to gain access to
`the bus as a master.
`
`The split-cycle protocol differs slightly in the information passed on the bus from the
`protocols studied above. For a READ transaction the master supplies a unique identifier
`for itself together with the address of the requested data so that the slave can return the re-
`quested data to the master. In fact, the master identifier is the address used during the
`second part of the split cycle, and both halves of a READ follow the protocol of a WRITE
`cycle.
`
`Page 15 of 41
`
`
`
`100
`
`Bus Interconnection:
`
`ADDRESS
`
`|
`
`I
`
`I
`
`MASTER
`
`SLAVE
`
`DATA
`
`Master transmits
`address to slave
`
`Bus idle
`(Available for other
`transactions)
`
`|
`
`‘
`
`Slave transmits
`Data to master
`
`FIGURE 3.8 A split-cycle protocol READ transaction.
`
`Clearly the perfonnance of a split-cycle protocol depends on being able to use the bus
`time between the cycle halves for other transactions. Thus the protocol is most suitable
`for systems with multiple processors or multiple DMA devices on the bus; it makes little
`sense for low-performance systems. This type of protocol is used in high-perforrnance
`rninicomputers such as DEC's VAX-l l/780, but has rarely been used in microcomputers
`until the introduction of the Intel iAPX- 432 in 1981.
`
`3.3 ARBITRATION PROTOCOLS
`
`The purpose of arbitration has been discussed earlier, namely to guarantee conflict-free
`acces