Page 1 of 41
`
`HTC-LG-SAMSUNG EXHIBIT 1020
`
`

`
`Microcomputer
`Interfacing
`HAROLD S. STONE
`
`UNIVERSITY OF MASSACHUSETIS, AMHERST
`
`-yliy ADDISO~WESLEY PUBLISHING COMPANY
`READING, MASSACHUSETIS
`MENLO PARK, CALIFORNIA
`LONDON
`AMSTERDAM
`DON MILLS, ONTARIO
`SYDNEY
`
`Page 2 of 41
`
`

`
`This book is in the ADDISON-WESLEY SERIES IN ELECTRICAL ENGINEERING
`
`SPONSORING EDITOR: Tom Robbins
`PRODUCTION EDITOR: Marilee Sorotskin
`
`TEXT DESIGNER: Herb Caswell
`IU..USlRATOR: Jay's Publishers Service Inc.
`COVER DESIGN AND Ill..USlRA TOR: T. A. Philbrook
`ART COORD INA TOR: Joseph Vetere
`
`PRODUCTION MANAGER: Sue Zorn
`PRODUCTION COORDINATOR: Helen Wythe
`
`1be text of this book was composed in Times Roman on a Mergenthaler 202 by Information
`Sciences Corporation and was printed by R. R. Donnelley and Sons.
`
`library of Congress Cataloging in Publication Data
`
`Stone, HaroldS., 1938-
`Microcomputing interfacing.
`
`Bibliography: p.
`I. Interface circuits. 2. Microcomputers--Circuits.
`I. Title. TK7868.!58S76
`621.3819'5835
`ISBN0-201-07403-6
`
`81-17619
`
`AACRZ
`
`Reprinted with corrections, February I 983
`
`Copyright © 1982 by Addison-Wesley Publishing Company, Inc.
`
`All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any
`form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written
`permission of the publisher. Printed in the United States of America. Printed simultaneously in Canada.
`
`ISBN 0.201-07403-6
`IIO>I'.rollliK-IJ0.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 UO 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 fromthe 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 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 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(cid:173)
`ries information that one module needs to convey to another in order to invoke a remote
`
`88
`
`Page 4 of 41
`
`

`
`3.1
`
`Bus Functions
`
`89
`
`Address, data, commands
`
`Data transfer control
`
`Arbitration
`
`FIGURE 3.1 Bus signal and control lines.
`
`function, response, or change of state in the remote module. In order to pass the informa(cid:173)
`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(cid:173)
`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. If module A
`spews forth a logic 0 while module B attempts to transmit a logic I 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
`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 the conflicting gates. The high current through this
`
`Page 5 of 41
`
`

`
`90
`
`Bus Interconnections
`
`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 first two groups of signals, the infor(cid:173)
`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(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 microcomputers as well. For ex(cid:173)
`ample, an arbitration protocol for selecting one of several potential bus transmitters is also
`suitable for selecting one of several UO ports in an interrupt-priority resolver.
`
`3.2 THE BUS HANDSHAKE
`
`Handshake protocols fall generally into three broad classes:
`
`l . 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(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 the least complex of the three
`protocols, but they als~, 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
`
`The Bus Handshake
`
`91
`
`Synchronous Buses
`
`The timing of a typical synchronous protocol is illustrated in Fig. 3.2. The top waveform
`is the 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 waveforms. 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 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
`
`I I
`
`I
`
`I
`
`WRITE
`
`READ
`
`WRITE
`
`~ Setup, decode , and skew delay ~ 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 are(cid:173)
`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
`the bus when the clock reaches the active phase of its cycle. The decoder has to produce
`its signal 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
`
`

`
`92
`
`Bus Interconnections
`
`Clock
`Data
`Address
`
`I
`
`Bus master
`
`r--
`I Decode I
`~ BufferJ
`Bus slave
`
`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 information 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 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 metal-oxide silicon
`(MOS) devices. Other devices can be bus slaves as well , including UO ports and discrete
`registers. Some devices respond faster than the moderate-speed memory, but the fixed(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 disconnect logically from the data lines.
`
`Page 8 of 41
`
`

`
`3.2
`
`The Bus Handshake
`
`93
`
`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
`tum 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-time 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(cid:173)
`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(cid:173)
`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
`
`

`
`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 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(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
`
`I. 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 the 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 SKEW + MAX(T HOLD• T RT-PRop),
`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(cid:173)
`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 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 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(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 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(cid:173)
`nals for a typical asynchronous bus that has these characteristics appear in Fig. 3.5.
`This bus is said to be a fully interlocked asynchronous bus, and is by far the most pop(cid:173)
`ular asynchronous protocol in use today. The DEC Unibus for the PDP-11 family is one
`notable implementation of this protocol (Digital Equipment, 1979). The termfully inter(cid:173)
`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 arming the other for its subsequent change. By interlocking in this manner,
`the information 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 Interconnections
`
`I ~
`
`MASTER
`
`,.~
`
`"~ ill~
`
`""
`
`SLAVE
`
`'-Ill
`
`.,J
`
`-.~
`
`'-,_.~
`
`'II
`
`WRITE
`
`~ Skew and decode m Skew only
`
`READ
`
`FlGURE 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 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 tlJe bus. During this period SLAVE must
`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
`its acceptance of data, it drops MASTER(' 'I've got it''), and then SLAVE drops (''I see
`you've got it").
`The reasons for the interlocking become clear when we consider how a partially inter(cid:173)
`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(cid:173)
`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(cid:173)
`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
`the bus for the slave to accept the new data. As a result, one transaction is lost.
`
`MASTER
`
`SLAVE
`
`(a)
`
`(b)
`
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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(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 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
`
`

`
`98
`
`Bus Interconnections
`
`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 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(cid:173)
`nous protocol because of extra propagation delays. The minimum cycle time for a READ
`operation must account for
`
`1. 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(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 omitted for synchronous proto(cid:173)
`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(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 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 semisynchro(cid:173)
`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 of 41
`
`

`
`3.2
`
`The Bus Handshake
`
`99
`
`/
`
`ADDREss!
`
`M to S
`
`S toM
`
`CLOCK DO on· o on
`I n1
`II
`DATA D Dl
`WRITE n
`
`M to S
`
`S toM
`
`D
`
`READ
`
`WAIT
`
`D
`
`0
`
`FIGURE 3. 7 A semisynchronous bus with cycle times increased by aWAIT signal.
`
`asynchronous bus. However, the length of the semisynchronous bus is limited by there(cid:173)
`quirement that WAIT must be asserted within a fixed period of time. So these buses can(cid:173)
`not have an indefinitely long length, but there is no equivalent timing constraint 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 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(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
`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(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 master.
`The split-cycle protocol differs slightly in the information passed on the bus from t