Page 1 of 41
`
` ZTE EXHIBIT 1020
`
`

`
`Microcomputer·
`Interfacing!
`HAROLD S. STONE
`
`UNIVERSITY OF MASSACHUSETTS, MtiERS1r
`
`IT ADDISON-WESLEY PUBLISHING COMPANV
`
`READING, MASSACHUSETTS
`
`LONDON
`
`AMSTERDM~
`DON MIUS, ONTARIO
`SYDNEV
`
`Page 2 of 41
`
`

`
`This book is in the ADDISON· WESLEY SERIES IN ELECTRICAL ENGINEERING
`
`SPONSORING EDITOR: Tom Robbin:r
`PRODUcnON EDITOR: Marilee Sorotsldn
`
`TEXT DESIGNER: Herb Caswell
`ILLUSlRA TOR: Jay's Publishers Service Inc.
`COVER DESIGN AND ll.LUSTRA TOR: T. A. Philbrook
`ART COORD INA TOR: Joseph Vetere
`PROOUCITON MANAGER: Sue Zorn
`PRODUCTION COORDINATOR: Helen Wythe
`
`The !ext of this book was composed in Tunes Roman on a Mergenthaler 202 by Infoomtion
`Sciences Corporation and was prinred by R. R. Donne! ley and Sons.
`
`Ubrary of C~ Catalogj.ng ID Publialtion Data
`
`Stone, Harold S., 1938-
`Microcomputing interlacing.
`
`Bibliography: p.
`I. lntelface circuits. 2. Microcomputers--Circuits.
`t nde. TK7868.l5SS76
`621.3819'5835
`ISBN0-201.07403-6
`
`SI-176)9
`MCRZ
`
`Repriilted with corrections, FebTUilry 1983
`
`())pyright © 1982 by A~on· Wesley Publishing Company, Inc.
`
`All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or ttansmitted, in any
`form or by any means, elecronic, mechanical, pho!OCOpying, recocding. or otlerwise, wilhout the prior wrinen
`permission of the publisher. Printed in the United States of America. Printed simultaneously in Canada.
`
`ISBNI).:20J.W40J.6
`IICilER:;HIJK.00.89876543
`
`.
`
`Page 3 of 41
`
`

`
`3 I BUS INTERCONNECTIONS
`
`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 1!0 modules of a microcomputer. The strategy
`followed for these interconnections 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 tQ be communicated on the
`bus; the other two signal groups guarantee that the information 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 information as
`
`1. memory address (or port lD),
`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(cid:173)
`ries information that one module needs to convey to another in order to invoke a remote
`
`88
`
`Page 4 of 41
`
`

`
`Bus Functions
`
`89
`
`Adrlress, data, commmds
`
`D-J ta 1111nsrer con tTol
`
`Arbi r:rarion
`
`FIGURE J.l Bus ~ignal and control lines.
`
`function, response. or change of slate in the remote:: mooule. In order to p<i!is Lhe informa(cid:173)
`tion, the bus itself has to be co11tmlled and operated correctly. The other two groups are
`dedicated to different aspect~ of the latter function.
`The second group of signal lines controls the timing of the data transfer. This group js
`often called the data handshake lin~s. and contains the signals that djctate when each indi(cid:173)
`vidual data transfer begins and ends. The handshake lines have a role analogous to traffic
`lights on a roadway. The h:llldshakes 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 transaction!> priority over less critical ones when deci&ng 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 mt"ldule A
`spews forth a logic 0 while module B attempts to transmit a Logic I at Lhe 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-cnllector drivers moves to the 0 state
`during any conflict, so that in the given example, tre 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 lhe
`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
`and change state in response to it.
`A bus conflict can be more disastrous than portrayed here. For example. what hap(cid:173)
`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 V cc to
`ground through the output stages of t.he conflicting gates. The rugh current through this
`
`Page 5 of 41
`
`

`
`90
`
`Bus lnteroonnectlons
`
`path can burn 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 bum 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 ftrst two groups of signals, the infor·
`mation and handshake groups, are t hus protected from conflict by the arbitration group.
`The arbitration group has inherent conflicts because all potential transmitting devices use
`these lines concurrentJy as pan of the arbitration process. Therefore, in many buses the ar(cid:173)
`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 mjcrocomputcrs as well. For ex(cid:173)
`ample. an arbitration protocol for selecti ng one of several potential bus transmitters is also
`suitable for selecting one of several I/0 ports in an interrupt-priority resolver.
`
`3.2 THE BUS HANDSHAKE
`
`Handshake protocols falJ generally into three broad classes:
`
`I. synchronous (clocked transfer, one clock period per transfer).
`2. asynchronous (unclocked), and
`3. semisynchronous (clocked transfer, one or mo!'C clock periods pertransfcr).
`
`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(cid:173)
`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 t~e least complex of the three
`protocols, but they alsq, 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
`
`

`
`32
`
`The Bus HandahakB
`
`91
`
`Synchronous Buses
`The timing of a typical synchronous protocol is illustrated in Fig. 3.2. The top wavefonn
`is the bus clock. which syrx:hronizes a.ll modules to a common time base. (lt is shown here
`with a 50% duty cycJe, bli the actuaJ duty cycle differs for various synchronous buses.)
`Address and data lines are shown on the next two wavefonns. The addresses and data
`reach 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 tr.Uliog shaded area. Although
`the address and datl! 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 infonnation
`they convey. The figure acrually shows the period during whtich the address and data lines
`are stable, and does not show their logic values.
`
`Clock
`
`I I I [J
`
`D~l
`
`WRITE
`
`READ
`
`WRITE
`
`~ Selup. decode, .and skew delay ~ Hold-and-slcew delay
`
`FIGURE 3.2 Timing for a synchronou!; bus.
`
`There are several different reasons for the shaded area of the waveforms. Fig. 3.3
`snows 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(cid:173)
`ceiver labeled bus slave. There are potentially many sJaves on the bus, and the purpose of
`Ire address lines is ro select a single slave to resJX>nd to the bus transaction. Therefore, lhe
`figun: shows the address lines entering a decoder that detects lhe slave's address, which
`then selects this specific slave by producing a signal that fom~s the slave to load data from
`the bus when the clock rea:hes the active phase of its cycle. Tite decoder bas to produce
`its signaJ in advance of the rising of the edge of the dock. so l~hat the address lines must be
`stable for at least the duration of the logic delay through the d::codcr.
`
`Page 7 of 41
`
`

`
`92
`
`Bus Interconnections
`
`Clock
`Data
`Address
`
`I
`
`Bus master
`
`r--
`I Decode!
`~ Buffer j
`Bus slave
`
`FIGURE 3.3 TypiCill slave internal structu.re.
`
`Another related effect that cannot be ignored is the setup time and hold time of logic
`in the buffer. Setup cime is the minimum amount of time that a control signal has to be
`prese,nt on an input of a memory device before the clock triggers a transfer into the device.
`Hold time is the mirumum time that data has to be held stable on the inputs of a memory
`devic:e 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. Tbe hold
`time in Fig. 3.2 depends on whether the bus operation is READ or WRJTE. 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. ln 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 Jines 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 infonnation on setup and hold times, let us return to Fig. 3.2 to con(cid:173)
`sider how these times are represented in the figure. For a WRJTE operation, the master
`transi!Tlits 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. tises, the selected slave initiates an internal WRITE operation, during which it
`copie:S the data on its data Jines 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
`mem•ory, usually on the order of 100 to 200 os for moderate-speed metal-oxide silicon
`(MOS) devices. Other devices can be bus slaves as well. inclucling UO ports and discrete
`registers. Some devices respond faster than the moderate-speed memory, but the fLxed(cid:173)
`cycle time of the synchronous bus cannot take advantage of the faster response. The fall(cid:173)
`ing edge of the clock signifies the end of the bus cycle. At this time. the WRITE operation
`is complete, and the slave can clisconnect logically from the data lines.
`
`Page 8 of 41
`
`

`
`The Bua Hand&hake
`
`93
`
`The READ operation is similar to WRITE for the address lines. but data lines behave
`differently. ln this case the rising edge of the clock initiates a memory READ in the slave .
`Some time after the clod: rise5. the data reaches the output buffer of the ~lave. which in
`rum places the data on the bus. The data has to be on the bus at least one setup time before
`lhe fal ling edge of the dock, where d1e setup time in question is the setup time of the
`master's data buffer. The slave holds rhc data on the bus at least one hold time after the
`falling edge of the clock in order to satisfy the bold-time requirements of the master.
`Reexamination of Fig. 3.2 shows we bave accounted for the general form of the
`shaded area, although WI:! have not accounted for exact lengths of rjme, Note that the setup
`time is shown much longer than the hold time because the setup time includes the decod(cid:173)
`ing delay in the slave, tlS well as other factors we now examine.
`Among the other soiUrces of timjng 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 Jines as they appear at the bus master. Both s.ignals ate 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 sl ightly with respect to each other. The master
`transmits the signals over the bus to the slave. which sees the signals a~ 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(cid:173)
`tive tirniog produced somewhere in the bus system is what we mean by skew.
`
`Address line waveforms at hus master
`
`ol--
`
`ol--
`
`Address line wavefonns at bus slave.
`
`flGURE 3.4 Skew in signal
`transmission. The delay D is the
`skew in the signals.
`
`Page 9 of 41
`
`

`
`94
`
`Bus Interconnections
`
`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 lO 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(cid:173)
`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(cid:173)
`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(cid:173)
`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
`
`l. setup time of data and control signals before clocking data into a buffer,
`2. address decode delay,
`·
`
`Page 10 of 41
`
`

`
`;;;;
`
`3.2
`
`The Bus Handshake
`
`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 lhe buffer. and
`5. one round-trip propagation delay (for the READ operation).
`The bus cycle time cannot be smaller than
`T SETUP + T DECODE + 2T SKE\1. + MAX(T HOLD• T RT-PRCJ>).
`where the MAX operation recognizes that propagation delay can be overlapped w1th 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(cid:173)
`tic. In practical ltuations. 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 accommodate 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(cid:173)
`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 perfonnance 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(cid:173)
`chronous protocol may be inappropriate because the bus runs at the speed of the slowest
`device. Intuitively speaking. it is advantageous to have fast transactions for fast devices
`and slow transactions for slow or djstant devtces, so that transaction time varies with the
`device rather than being fixed for all time by a system clock. The timing and control sig(cid:173)
`nals for a typical asynchronous bus that has these characteristics appear in Fig. 3.5.
`This bus is said to be aftJ/Iy mrerlocked a$)'ncl!ronous bus, and is by far the most pop(cid:173)
`ular asynchronous protocol in use today. The DEC Unibus for the PDP-II family is one
`notable implementation of this. protocol (Digiral Equipment, J979). The term jitlly inter(cid:173)
`locked stems from the way the two conrrol signals work mgether 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 requjres
`changes to altemate between the control signals and to occur sequentially, with a change
`in one signal armlng the other for its subsequent change. By interlocking in this manner,
`the information on address and data Jjnes is guaran1ced to be transmitted without confli ct
`and without loss or duplication by the bus.
`
`Page 11 of 41
`
`

`
`96
`
`Bus lnterconnecttons
`
`Add"" ~ I ~
`
`MASTER
`
`~ }'~ ,~ .... ~
`
`SLAVE
`
`... ~ "-V
`
`.... ~ 'II
`
`WRiiE
`
`~ Skew :~nd decode m Skew only
`
`READ
`
`FIGURE 3.5 Timing for a fully jnterlocked asynchronous bus.
`
`For the WRITE transaction, the bus master places address and data on the bus. After
`n 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 bas been observed and acted upon. Only then does SLAVE go
`low. Similarly, a new transaction cannot 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(cid:173)
`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 of 41
`
`

`
`3.2
`
`The Bus Handshake
`
`97
`
`This triggers the master to load its buffer from tl;le bus. During this period SLAVE musr
`remain high. and the data lines must be stable. If the slave were to change these signals
`prematurely. the master could read incorrect information. When the master has completed
`ils acceptance of data. it drops MASTER ("I' ve got it"). and then SLAVE drops ("1 see
`you've got it").
`The reasons for the interlocking become clearwhenweconsiderhow apwtially inter(cid:173)
`locked protocol can fail Consider the two situations shown in Fig. 3.6. In Fig. 3.6(a), we
`pennit SLAVE to drop a fixed time after it rises. without waiting for MASTER to drop.
`Likew1se. we also remove the interlock between the falling edge of SLAVE and the lead(cid:173)
`ing edge of MASTER. AJso 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(cid:173)
`nal skew. In this case, H MASTER drops and rises again while SLAVE is high. it may
`mistake the high value of SLAVE for a response to the next rransfer. This situation is
`Sbown in Pig. 3.6{b). Now the master may remove data and addresses too quickJy fTom
`the bus for the slave to accept the new da1a. As a result, one transaction is Jost.
`
`MASTER
`
`SLAV£
`
`(a)
`
`(b)
`
`FIGURE J.6 Ellamples of signaling with a panially
`interlocked asynchronous protocol.
`
`Although partial inlerlocldng as shown in Fig. 3.6 lacks the safety of full interlock(cid:173)
`ing, it can be made safe provided that master and slaves adhere to a strict set of timing
`constramts on the non interlocked transiltons. The advantage of eliminating part of the in(cid:173)
`terlockiQg is that the bus transaction can be made a linle faster so that the bus bandwidth
`can be greater than it wollld be in a fuJiy interlocked protocoL But tigbt constraints usu(cid:173)
`ally result in higher manufacturing cost, making the partiaJiy interlocked protocols less
`desirable in general , although useful in specitic applications where the extra expense is
`justified.
`Returning to Fig. 3.5, we note in this protocol shaded areas that represent roles simi(cid:173)
`lar to those represented by the shaded areas of the synchronous protocol. Addresses have
`to be raised before MASTER at least early enough to pennit address decoding and buffer
`setup, and to protect against skew on the address lines relative to MASfER. Hold times
`are not shown specifically. but ex1st nevertheless. Hold time is usually incorporated into
`
`Page 13 of 41
`
`

`
`98
`
`Buslnterconnectlons
`
`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
`normally be combined with hold rime, 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(cid:173)
`nous protocol because of extra propagation delays. The minimum cycle time for a READ
`operc1tion must account for
`
`I . 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 ftrst three .items in this list are comparable to lhose for synchronous buses, bur tbe
`propagation delay for the fully interlocked handshake is double that of a clocked bus. In(cid:173)
`formation is passed up and down the bus twice per transaction for asynchronous buses, but
`only once for synchronous buses. The second round trip is omiued for synchronous proto-(cid:173)
`~ol:; bccawe the dcvic~ are lmowu in advance to rc:;pond within a fil'icd maxiutwu tiute;
`The purpose of the second round trip for an asynchronous bus is to convey completion in(cid:173)
`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(cid:173)
`tages of synchronous and asynchronous buses. One such bus is the semisynchronous bttS
`that appears in Fig. 3.7. This bus has two control signals, CLOCK (from the master) and
`WAIT (from the slave). ln 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 ~ingle round trip is all that is necessary for a successt\d 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 WAlT, and the semisynchro(cid:173)
`nous bus behaves like a synchronous bus. If the slave cannot respond in one cycle, it
`raises the W AJT 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 WAlT. and the
`master accepts the slave response using tbe 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
`
`The Bus Handshake
`
`99
`
`ADDREss!
`
`MtoS
`
`S to M
`
`~ito S
`
`S toM
`
`0
`
`CLOCK o o on· o o o
`I n1
`II
`DATA D 01
`WRITE D
`
`READ
`
`WAIT
`
`n
`
`0
`
`FlGURE 3. 7 A semisynchronous bus with cycle times increased by aWAIT signal.
`
`asynchronous bu::.. However, the length of the semisynchronous bus is limited by there(cid:173)
`quirement that WAIT must lx asserted within a fixed period of time. So these buses can(cid:173)
`rot have an indefinitely long length. but there is no equjvalcnt timing cons1raint for asyn(cid:173)
`chronous buses.
`Another way to retain the advantage of the fast synchronous protocol while accom(cid:173)
`modating slow devices is with the usc 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(cid:173)
`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
`lransrnitting the data to the requesting module, which responds as a sla\'e. 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(cid:173)
`sumes that many different bus masters access the bus at different times, so that every
`module must also contain the logic for bus arbitration protocol in order to gain access to
`the bus as a mac;ter.
`The spl it-cycle protocol differs slightly in the information pa