`
`INTERFACING
`
`Harold 8. Stone
`
`Page 1 01'41
`
`Samsung Exhibit 1020
`Petitioners HTC & LG - Exhibit 1020, p. 1
`
`Petitioners HTC & LG - Exhibit 1020, p. 1
`
`
`
`Microcomputer
`Interfacing
`
`HAROLD S. STONE
`LNVEEWG .MHERST
`
`vfl AWISON-WESLEY PUBLISHING COMPANY
`READING. Efi$
`NENJJ PAH‘. CAIJFCRMA
`LONIN
`
`MBTEFDAM
`
`DOV NILLS. CN'|'AF||O
`SYIXE
`
`Page 2 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 2
`
`Petitioners HTC & LG - Exhibit 1020, p. 2
`
`
`
`This book is in the ADDISON-WESLEY SERIES IN ELECTRICAL ENGINEERING
`
`SPONSORING EDITOR: Tom Robbins
`PRODUCTION EDITOR: Mafia Sorofskin
`
`TEXT DESIGNER; Herb Carmel!
`
`ILLUSTRATOR: Jay‘: Publishers Service Inc.
`COVE! DESIGN! AND ILLIJSTRATOR: T. A. Philbarooix
`
`ART COORDINATOR: Jascph Venn
`PRODUCTION MANAGER: Sue Zorn
`
`PRODUCTION COORDINATOR: Helen IV}-the
`
`T1Bm1Ioflhishmkwm0umnsedinTm:sRmI1mm:Mugaflnlu202tnIhfunnfim
`SciemesCoapornionu1dwnsprinwdbyR.R.Dnm1¢ll¢yandSons.
`
`Lllru-y IlCony'mC:ulogInglnPnII|icat|onDuta
`
`sauna, I-lamldS., 1933-
`
`Bibl50:mphy=p-
`L
`l.'[‘it|:. 'I'K?E68.l53S'J'6
`ISBN 0-101-07403-6
`
`2. m.
`62l.33l9’5835
`
`31-17619
`
`AACRZ
`
`Reprinted with corrections, February 1983
`
`Cap}-‘right © I982 by Addison-Wesley Publishing Conqaany, Inc.
`
`Allliglmtsmsclwd.Nopanofmisboukmayherqm¢Jcad,smradmarenievalsystan.mmmnined,mmy
`fctmorbynnyrlrans,flecmnic.mufl:mfital,ptntocopyh1g.mu:ding,wadn'wisc,uidnnd:priwufium
`pa-nismon‘ of the pubhs‘he:.Pn‘n1edinIheUnited SmasofAm:nca‘ .Pu’n1edsim;lmneonsIyin(i.
`N0-Ill-IIMO3-6
`mrnancamxoonmsu
`
`Page 3 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 3
`
`Petitioners HTC & LG - Exhibit 1020, p. 3
`
`
`
`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 U0 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 bars. 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. (Ttie 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 intemal
`bus runs slow enough to be extended to a second chassis with little or no perfonnance
`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 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 inforrnation that one module needs to convey to another in order to invoke a remote
`
`Page 4 of 41
`
`88
`
`Petitioners HTC & LG - Exhibit 1020, p. 4
`
`Petitioners HTC & LG - Exhibit 1020, p. 4
`
`
`
`3.1
`
`'
`
`Bus Functions
`
`89
`
`Data transfer control
`
`FIGURE 3.1 Bus signal and control lines.
`
`function, response, or change of state in the remote module. In order to pass the infonna—
`tion, the bus itself has to be controlled and operated correctly. The other two groups are
`dedicated to different aspects of the latter function.
`y
`The mood group of signal lines controls the timing of the data transfer. This group is
`oftencalled the data ltartdsltake 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. If 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
`sndchange 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 V CC to
`ground through the output stages of the conflicting gates. The high current through this
`
`Page 5 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 5
`
`Petitioners HTC & LG - Exhibit 1020, p. 5
`
`
`
`so
`
`Buslrttereottneetlorte
`
`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 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 U0 ports in an interrupt-priority resolver.
`
`3.2 THE BUS HANDSHAKE
`
`Handshake protocols fall generally into three broad classes:
`
`1. 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
`
`Petitioners HTC & LG - Exhibit 1020, p. 6_r
`
`Petitioners HTC & LG - Exhibit 1020, p. 6
`
`
`
`3.!
`
`TI‘! Bus Hflldilldna
`
`91
`
`Synelvonous 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
`witli 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. 'I‘he addresses and data
`
`teach 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.
`
`
`
`Data 7
`
`t
`
`:7;
`
`a
`
`WRITE
`
`READ
`
`WRITE
`
`V/'/(1 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 wavefomis. 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-
`oeiver 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 dtis specific slave by producing a signal that forces the slave to load data front
`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
`dable for at least the duration of the logic delay through the decoder.
`
`Page 7 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 7
`
`Petitioners HTC & LG - Exhibit 1020, p. 7
`
`
`
`
`
`FIGURE 3.3 Typical slave internal stnicture.
`
`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 aWRl'I'E 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 infonnation 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 rnernory chip, the subsequent delay accounts for the write-access time to
`memory. usually on the order of it!) to 2(1) ns for moderate-speed metal-oxide silicon
`(MOS) devices. Other devices can be bus slaves as well. including U0 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
`
`Petitioners HTC & LG - Exhibit 1020, p. 8
`
`Petitioners HTC & LG - Exhibit 1020, p. 8
`
`
`
`
`
`'I'he 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-
`ing delay in the slave, as well as other factors we oowexarnine.
`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 the 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 wavefonns at bus slave.
`
`FIGURE 3.4 Skew in signal
`transmission. The delay D is the
`skew in the signals.
`
`Page 9 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 9
`
`Petitioners HTC & LG - Exhibit 1020, p. 9
`
`
`
`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.
`lt 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
`
`. setup time of dataand control signals before clocking data into a buffer,
`I
`2. address decode delay,
`‘
`
`Page 10 of41
`
`Petitioners HTC & LG - Exhibit 1020, p. 10
`
`Petitioners HTC & LG - Exhibit 1020, p. 10
`
`
`
`3.2
`
`'I1'IOBl..l8HII'l!ll'Il|fl
`
`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
`
`Tsarur ‘l’ Tnecooe ‘l’ 2Tsro~:w 4‘ MAX(Tr-roLo- Tar-r-nor).
`
`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 accommodate devices whose access time is greater than the tirrre
`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 runs at the speed of the slowest
`device. lntuitively 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-
`nals for a typical asyncluonous bus that has these characteristics appear in Fig. 3.5.
`This bus is said to be afully interlocked asynchmnoas 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 termfully inter-
`locked stems from the way the two control signals work together during a bus transaction.
`The conuol 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 orduplication by the bus.
`
`Page 11 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 11
`
`Petitioners HTC & LG - Exhibit 1020, p. 11
`
`
`
`on
`
`Bus Intereomections
`
`MASTER
`
`SLAVE
`
`
`
`WRITE
`
`R EAD
`
`% 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 Inernory 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 goth").
`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»
`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
`
`Petitioners HTC & LG - Exhibit 1020, p. 12
`
`Petitioners HTC & LG - Exhibit 1020, p. 12
`
`
`
`3.2
`
`1'heBusHanr:IehaIre
`
`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. Ifthe slave were to change these signals
`prematurely, the master could read incorrect inforrnation. When the master has completed
`its acceptance ofdata, it drops MASTER (“l‘ve got it"), and then SLA\«’Edr-ops (“I see
`you've got it").
`The reasons forthe 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
`pennit 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
`somevd-rat 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
`the bus 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 nianufacturing cost. making the partially interlocked protocols less
`desirable in general. although useful in wific 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 ‘I3 of 41
`
`Petitioners HTC & LG - Exhibit 1020, p. 13
`
`Petitioners HTC & LG - Exhibit 1020, p. 13
`
`
`
`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
`nomrally 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 . deskevv {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-
`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-
`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.
`
`Sernlsynchronous 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 senrisynchronous 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 sernisynchro-
`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
`
`Petitioners HTC & LG - Exhibit 1020, p. 14
`
`Petitioners HTC & LG - Exhibit 1020, p. 14
`
`
`
`:2
`
`11-nfluel-Iandehdto
`
`so
`
`FIGURE 3.7 A semisynchronous bus with cycle times increased by a WAIT signal.
`
`asynchronous bus. However, the length of the sernisynchronous 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 accorn-
`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 remnds 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 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 the
`protocols studied above. For a READ transaction the master supplies a unique identifier
`for itself together with the