1- —u._.-._
`
`--
`
`—
`
`.
`
`.-
`-
`
`"
`
`1
`
`C1 Syitectm H
`
`
`More than likely, the busy -condition will have been cleared by the time
`the master retries the transaction. It is pcmible. however, that the master
`may have to melee several attempts before succeeding. A target is only
`permitted to use this option is there is a high probability that it will be
`able to complete the transfer the first time that the master retries it.
`ofiaerwiseitmgstuseopfimfluee.
`‘3; ' in the third.-case-(optiortthree), the target has to access a slow medium to
`fetch the requested data and it will take longer than IIS clocks. in this case,
`the target latches the adqlress, command and the firet set of byte enables
`and their issues a retry to the initiator. The initiator is thereby forced to
`end the transaction with no data transferred and is required to retry the
`transaction again latefusing precisely‘ the same address, command and
`byte enables. The target, meanwhile, proceeds to fetch the requested data
`and set it up in a buffer for the master to read later when it retries the
`transaction. When the target sees the master retry the transaction, it
`attempts to match the second request with the initial
`request by
`comparing the start address, command and
`byte ertables to those
`latched earlier. If they match, the requested data is transferred to the
`master. if they aren't an exact match, the target interprets this as a new
`request (for data other than that in its limiter) and issues" a retry to the
`master again. To summarize,
`if the master doesn't duplicate the
`transaction exactly each time it retries the transaction, it will never have
`its read request fulfilled. The target is not required to service retzies from
`its buffered data that aren't exact matches. Option three is referred to as a
`delayed transaction. It can also be used for a write transaction (e-.g.. where.
`the bus master is not permitted to proceed with other activities until it
`. accomplishes the write]. In this case,
`the target latches the address,
`cornmand, byte enables and the first data item and issues the retry. It then
`proceeds to write the data item to the slow
`Each time that the
`master retries the write transaction it will receive a_ retry until the target
`device has aclmowledge receipt of the date. when the target is ready to
`permit the transfer and the master next attempt! the access, the target
`compares the address, command, byte enables and the write data I0
`determineifthisisthesarnemaster thatirtifiallyrequestedtitewritfi
`transfer.
`'
`'-
`
`-_
`
`-
`
`'
`
`.
`
`Page 11 1 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 111
`
`Petitioners HTC & LG - Exhibit 1019, p. 111
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`Different Master Attempts Access To Device with
`Previously-Latched Request
`
`master attempts to access the target and the target can only deal
`If a
`with one latched request at a time, it must issue a retry to the master without
`latching its transaction inforination.
`
`_i_
`El.
`
`Special Cycle Monitoring While Processing Request
`
`.
`
`If the target is designed to monitor for special cycles, it must be able to
`process a special cycle during the same period of time that is processing a
`previously latched read or write request.
`
`Delayed Request and Delayed Completion
`
`the request phase and the
`A delayed transaction consists of two parts:
`completion phase. The request phase occurs when the target latches ‘the
`request and issues retry ‘to the master. This is referred to as the delayed
`request
`transaction. Once the transaction has been latched,
`the target
`{typically a bridge to a slow expansion bus)
`the litanaactinri on the
`target bus. When the transfer completes on the target bus, this is referred to as
`the delayed completion transaction. This is the start of the completion phase.
`A delayed transaction must complete on the target bus before it is permitted
`to complete on the initiating bus. The master is required to periodically re-
`attempt the transfer until the target finally asserts TRDY-# and allows the data
`to be transferred. This ends the COtI.'l]:|lEl‘i0I1.'phflSB of the delayed transaction.
`
`Handling Multiple Data Phases
`
`When the master is successful in completing the first data phase. it may
`proceed with more data phases. The target may issue a disconnect on any
`data phase after the first The master is not required to resume the transaction
`later. Both the master and the target consider the original request fulfilled.
`
`Master or Target Abort Handling
`
`A delayed transaction is also considered completed if it receives a master
`abort or a target abort rather than a retry on a re-attempt of the retried
`‘transaction. The target compares to ensure that the master is the one that
`originated the request before it issues the master or target abort to it. This
`means that the transaction on the target bus ended in a master abort because
`
`
`
`97
`
`Page 112 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 112
`
`Petitioners HTC & LG - Exhibit 1019, p. 112
`
`

`
`PCI Szstern Architecture
`run target responded nrin a target ahorthemuse of abroken target. Inboth of
`these cases, the master is not required to repeat the trartsaetion.
`
`commands That can Use Delayed Transactions
`
`A delayed transaction ._nqnr_1s11y t;onsist_ pi a single data phase and is used for
`t1-tefollawingcanuriandsz
`" " ‘
`‘
`'-'-— --
`
`-
`
`Interrupt Acicnewledge.
`I
`- 1/0 read.
`0
`I/O write.
`
`a Memory read.
`0 Configuuation read.
`a Cnnfiguratisnwriie.
`
`The delayed transaction could also be used with the memory write
`commsnds,butit'sresultsinbettaerperfonnameta postthewrite snpermit
`the master to complete the write quickly.
`
`Delayed Read Prefetch
`
`A delayed read can result in the reading rnnre data than indicated in the
`master's initial data phase if the target knows that
`refetching data doesn't
`alter the contents of memory lacatiens (as it would memory-mapped IIO
`ports] The target can prefetch more data than initially requested under the
`following circu1n£lanI:e'.i:‘
`
`I
`
`o
`
`The master has used the memory read line or memory read multiple
`command, thereby
`that it lmowe the target is preietehable
`
`The master used a memory read command, but the bridge that accepted
`the delayed transaction request recognises that the address falls within a
`range defined as prefelichable.
`
`Ii1 :11 other cases, the target (i.e., the bridge) cannot perfdnn any-thing elite!
`than the single data phase indicated by I.’ne originating master.
`
`Request Queuing and Ordering Flul
`
`A target device (typically a bridge} can be designed to latch and plate“
`multiple delayed requests. The device must, however, ensure that
`'1“
`_.
`
`11'
`'
`
`‘
`
`as
`
`P398 113 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 113
`
`Petitioners HTC & LG - Exhibit 1019, p. 113
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`'
`
`' " '
`
`transactions are perfonned in the proper order. Table 6-3 defines the rules
`that the device must observe in order to ensure that posted memory writes
`and deleyedtransactlons are performed in fltejitroper order. The table 347:5
`extracted from the specification. The following abbreviations are used in the
`table:
`
`PMW =- posted memory write. The master is permitted to end a memory
`write immediately it the device posts it.
`DRR = delayed read request A delayed read request occurs when the
`target latches the address, command and byte enables and issues a retry
`to the master. It is then the responsibility of the target to perform the read
`on the target bus to fetch the réquted data.
`-
`DWI! - delayed writ: request. A delayed write request occurs when the
`target latches the address, command, byte enables and write data and
`issues aretry to the rnastenltis then the responeibilityofthe targetto
`perform the write on the target bus.
`DEC = delayed read completion. A delayed read completion occurs
`when the device that latched a read requt completes reading. the
`requested data on the target has and has the data ready to deliver to the
`master that originated the request. The device is'now waiting for the
`to retry its read so that it may deliver the data to the
`
`master.
`
`DWC = delayed write completion. A delayed write completion occurs
`when the device that latched a write request completes writing the data
`on the target for the master that originated the write. The device is now
`waiting for the originating master to retry its write so that it may confirm
`th_e delivery of the write data.
`
`The table is formatted as follows:
`
`The first column represents a delayed transaction request (one of five
`types) that has’ just been latched.
`The second column indicates whether the transaction just latched can pass
`a previously-posted merrtorjr write
`The third column indicates whether the transaction just latched can pass a
`previously‘-Ia tched delayed read request.
`The fourth column indicates whether the transaction just latched can pass
`a previously-latched delayed write request
`The fifth colunm indicates whether the transaction just latched canpass a
`previously-latched delayed read completion.
`
`99
`
`.‘..;_h|.'
`
`Page 114 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 114
`
`Petitioners HTC & LG - Exhibit 1019, p. 114
`
`

`
`.4
`PCI System Architecture.
`
`0-
`
`The sixth azolmnn irldicates whether the transacfion just latched can pass a
`previously-laldied delayed write completion.
`
`irnmediahely following the table was extracted from the
`The rule list
`specification. The superscripts in each box corresponds to the rule list.
`
`‘Asian example; the-table indicates that a_po§tgd__meInory write an pass (be
`performed) a delayed read or wrife request or a delayed write completim, hint
`it is not permitted to pass another posted memory write or a delayed read
`oomplefion.
`
`!
`'
`
`; Rules
`Table 6-3. Orderi
`Delayed Request
`'
`
`
`
`Delayed
`
`
`
`CO lE1'.'i.01'I
`
`'
`
`1. Transactions of the same type cannot pass each other.
`2.. A posted memory write can pass a delayed request.
`3. A delayed request canrlot complete before a posted memoxy write.
`4. A posted memory write or a delayed request cannot pass a delayed mead
`connpletlon.
`5 A delayed completion cznpass a delayed request.
`6. A deiayed rend completion caxmot pass a posted memory write.
`7. A delayed wzite completion can pass a posted memory write.
`8. A posted memory write at a delayed read request can pass a
`write completion.
`
`"
`
`4
`
`3
`
`The primary rule is that all device accesses must complete inorder from III! A
`program.u1er‘spen'pective.In thefollowinglist. theauthorhas attempted”
`explain each table entry.
`
`
`
`100
`
`Page 115 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 1-15
`
`Petitioners HTC & LG - Exhibit 1019, p. 115
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`'“ " ""
`
`'
`
`"
`
`l
`
`_ .___
`
`1. A newly-latched PMW cannot pass (be completed before] a previously-
`PMW because all writes have to complete in the order in which they have
`been latdued.
`
`2. A newly-latched PMW can pass a previmrsly-latched DER This is
`permitted because the master has already completed l:he write while the
`other master has" not yet completed its read From the programmer's
`standpoirtt, this means thewiitae completed before the read.
`' '3.“ A newly-1atched-PMW- can -pass a-previously-iatdted DWTIL This is
`permitted because the master has already completed the posted-write
`while the other master has not yet oocrnpleted its delayed write. From the
`programmer’s standpoint, this means the posted-write oompleted before
`the delayed write.
`4. A newlyelatched PMW cannot pass a previorrsly-latdted DRC. From the
`programmer's perspective, the write has already oornpleted but the read
`has not. One master originated the read before the write was performed
`by the other master, so the programmer expects to getbaclt the read data
`as it looked before the write oocurred.
`5. A newlyslatdted PMW can pass a previoua1y—1atd1ed DVVC. The device
`has completed the write to the target and is waiting for the delayed
`master to reattempt the write so that it can let the master complete the
`write. From the prograrnmer"s perspective. the posted—write has already
`oompleted while the delayed write hasn't.
`this were
`If
`6. A newlyilatched DER cannot pass a. previously-PMW.
`permitted. the read might felscll state data [because the posted write might
`be to one of the locations to be read).
`.
`'3'. A newly—1at1:l1ecl DRR cannot pass a previourlyvlatohed DRR. The roads
`must complete In the order the programmer generated tliem.
`B. A newly-latched DRE cannot pass a previoualyblatched DWR. The write
`was originated before the read and must therefore occur before the read
`(incasethey targetthe samelocatiorns.
`9. A newly-tatctted DRE cannot pass a previously-latched BBC. The roads
`must complete in the order the programmer generated them.
`10. A newly-latched DRR can pass a_ previously-latched DWC. The target has
`already been written to and updated, so it contains fresh information. The
`device may therefore initiate the read from the target to fetch the data
`requested by the originator.
`11. A newly-latched DWR cannot pass a previously-PMW. From the
`programmers perspective, the posted write occurred before the delayed
`write {wl-dch has not yet completed). The device must perform the posted
`write befiore the newly-accepted delayed write so that
`the data is
`delivered to the target(s) in the correct order.
`
`,
`
`101
`
`Page 116 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 116
`
`Petitioners HTC & LG - Exhibit 1019, p. 116
`
`

`
`_.
`
`_ _ _______
`
`_
`
`PC] Szstem Architecture
`
`12. A newly-latched DWR cannot pass at previ.ous'ly—1at::hed DRR. It is the
`progr-ammer’s intention that the reed occur before the write.
`13. A newly-latched DWR cannot pass a previously-latched DWR. It is the
`programmer's intention that the two writes occur in the order received.
`14. A newly;-latched DWR cannot pass a previously-lalrlted DRC. The
`_Pl‘I'.'.!g'i'a_!!l'_.\‘.1"{lE!.' initiated the read before the write, so the read must be
`pemu'ttedtocompIe7lé(dn&1éor1gr:ns'tingbus‘,tbeforefitewr-rte‘
`15. A newly-latched DWR can pas a previously-latched DWC. The data for
`the first wdte (the DWC) has already been delivered to the target, so the
`data from the second write (the DWR) can now be delivered. The targetfs)
`will receive the data in the order intendedby lheprogrammer.
`15. A newly-latched DRC cannot pass a previous1y—PMW. If the write and
`read are accessing the same locations, the read would return stale data.
`From the pl'OgIaI!'lI1'lE1"5 perspective, the write has already completed and
`the target data updated. If reading from the same locatiorqs},
`the
`programmer therefore expects -to receive the newIy—w1-itten data.
`17. A newly-latched DRE can pass a previously-latched DRE. The DRC is
`associated with 1: DR Iiiat was received prior to the DRR that is still
`outstanding. The data I1-ontthe DRC can therefore be -delivered to the
`requesting master immediately.
`18. A newly-latched DRC can pass a previouslydatched DWR. The data
`associated with theDR-C was requested prior to the reception of the DWR
`by the deirioe. Ihe read data can therefore be delivered to the requesting
`master inurrediately {before the write is performed on Ihetarget bus).
`19. A newlytlatched DRC cannot pass a previously-latched DRC. Read
`requests must be performed in the order that they were received.
`20. A. newly-latched DRC cannot pass a previouslydatrhed DWC. The data
`associated with the DRC was requested prior to the reception of the DWR
`that caused the owe The read data can therefore be delivered to the
`requesting rnssmr immediately (before the write is performed on the
`“I89? 535)»
`21. A newly-latched DWC can pass a previously-PMW. Writes must complete
`in the order they are received and the write associated with the DWC was
`received prior to the write associated with the PMW.
`22.. A newly-latched DWC can pass a previousljr-lalnhed DRR. The wdte
`originated before the read. so the music: that originated the write can be
`told about its completion immediately.
`23. A newlydatched DWC can pass a previously-latcls-ad DWR. The Write
`associated with the DWC originated before the write that originated fl‘-E
`DWR. The master that originated the DW-C em therefore be told about the
`write completion irnrnediately.
`
`'
`
`1132
`
`Page 117 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 117
`
`Petitioners HTC & LG - Exhibit 1019, p. 117
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`
`24. A newly-latdied DWC unnot pass a previously-latched DRC. The read
`associated with the DRC originated before the write associated with the
`DWC. The master that originated the read must therefore be given the
`read data befote the master that originated the write is told of its
`completion.
`5. A newly-latched DWC cannot pass a previously—-latched DWC. The write
`iE5°<=i?-ted. with *-he PmVi°!I§1x-Evslyktsd PWS3 nrisineised bef9r_e_Ihs
`em‘; associated with the just completed DWC. The completions must
`therefore be reported to the originating masters in that order.
`
`Locking, Delayed Transactions and Posted Writes
`
`The following rules must be followed when a device permits. delayed
`traniand alsosupports locking:
`-
`
`
`
`.='~..°I2»-so1°
`
`1. A target that acoeprts a locked access (Le, it latches the request] must
`.
`behave as a locked target.
`The target cannot accept any posted writes after aocepting a delayed lock
`requestmoving in the same direction {except as noted by rule five).
`While locked, the target may continue to accept delayed requests.
`Posting of write data in the opposite direction of the locked aooess must
`be disabled once lock has been established on the destination bus.
`
`Posting of write data from the locking master is allowed.
`Once loci: has been established (between the originatirtg master and the
`actual target), the device stays locked until LOCK# and FR.AMIi# are
`sampled deasserted (on the same rising-edge of the clock) on the
`uriginafingbus.
`‘
`'
`
`
`Fast Back-to-Back Transactions
`
`Assertion of its grant by the PCI bus arbiter gives a PC! bus master access to
`the bus for a single. transaction. If a bus niaster desires another aooeas, it
`hould continue to assert its ItEQ# after it has asserted FRAMI-ht for the that
`transaction. If the arbiter continues to assert its GNT# at the end of the first
`lramactim, the master may then immediately initiate a second transaction.
`However, a bus master attempting to perform two, back—to—bar:k transactions
`usually must insert -an idle cycle between the two transac|:ions. This is
`illustrated in figure 6-5. When it doesn't have to insert the idle cycle between
`the two bus uansactims, this is retemed to as fast back-to-back transactions.
`'I‘hiseeno:nl}rocmrifIhereisa guarantee that thEreWiilnDtIJeconte|1tion(on
`
`103
`
`Page 118 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 118
`
`Petitioners HTC & LG - Exhibit 1019, p. 118
`
`

`
`PCI System Architecttire
`
`any signal lines) between the masters and/or targets involved in the two
`transactions. There are two scenarios where this is the case.
`
`1.
`2.
`
`In the that case, tin.-master guarantees that there will be no contention.
`In the second case,
`the master and the community of PCI
`targets
`collectively provide the guarantee.
`
`The sectiorls that followdescribe tl'aese—two scenarios,
`
`.
`
`.
`
`104
`
`“__
`
`uu-uh.n.|..s- .
`
`-
`
`Page 119 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 119
`
`Petitioners HTC & LG - Exhibit 1019, p. 119
`
`

`
`Cha tei: 6: PCI Bus Arbitration
`
`4._.
`
`Figure 5-5, Back-fa-Back Trmsadions With an Idle State In- ztween
`
`105
`
`Page 120 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 120
`
`Petitioners HTC & LG - Exhibit 1019, p. 120
`
`

`
`———.--7 __
`
`~'_
`
`‘
`
`PCI System Architecture
`
`Decision to Implement Fast Back-to-Back capability
`
`The subsequent two sections describe the rules that permit deletion ofthe idle
`state between two transactions. Since they represent a fairly oonstraining set
`oi-‘roles. the designerofa hos rnsstershouldmakeaninformedclecisionas so
`'w11'ether or motifs worth the additional logiclt would talteto inrplementit. _
`
`'
`
`‘
`
`'
`
`Assumethat, tltenatureofaparlzicolarlmsrrlaslaerissuch thatit typically
`performs long burst transfers whenever it acquires bus ownership. In tltis
`case, including the extra logic to support fast back~to-beck tnrnseefions would
`not make a great deal of sense. Percentage-wise, you're only saving one clock
`tickof Iatmcy inbetween each pair of long transfiers.
`
`Assume that the nature of another master is such that it typically performs
`lots oisInal1dainhursts.IoI:hiscase,iIs:[tmion oftheextra logicmay resultht
`a measurable increase in perfomtance. Since eedt of the small transactions
`typically only consists of a few clock ticks and the master performs lots of
`these small transactions in rapid succession, the savings of one clock tickin
`between each irartsaction pair can amount to the removal of a fair percentage
`ofoverheadnormallyspentinbusidle time.
`
`scenario one: Master Guarantees Laok__ot Contention
`
`In this scenario (defined in revision 1.0 of the specification and still true in
`revision 2.2:), the master must ensure that, when it performs two back-to-back
`transactions with no idle state in between the two, there is no "Contention on
`any ofthesignals clrivenby lhebus master or onthose driventgythe target.
`An idle cycle is required wheitever AD[31:El], C/BE#[3:0], FRAME!‘ and
`lRDY#are drivenbydiiierentmasters firomone clockcycle laothe next. The j
`idler-ycleallowsonecyclefortltemastercuurentiy drivingthesestgralsto
`surrender control (cease driving} before the next bus master begins to drive
`the bus. This prevents-bus contention.
`
`-
`
`How Collision Avoided On signals Driven By Master
`
`The master must ensure that the same set of output drivers are driving the
`ntaster-relatedsignals attheendoftheEirsttra.nsactionancIt-ltesbsrtoftl'IE
`second. This means that the masiaer must ensure that it is driving the bus at
`tlieendofthefii-sttransactionarldatthestartoithesecond.
`
`106
`
`Page 121 of2_35
`
`Petitioners HTC & LG — Exhibit 1019, p. 121
`
`Petitioners HTC & LG - Exhibit 1019, p. 121
`
`

`
`'“ ' '""""
`
`'
`
`'
`
`'
`
`'
`
`-
`
`_
`
`*
`
`‘
`
`Chagter 6: PCI Bus Arbitration.
`
`To meet this criteria, the first transaction must he a write transaction and the
`second transaction eanbeeithera read or awrihe butrnustbe-initiated by the
`same master. Refer to figure 6-6. When the master acquires‘ busowneishtp
`and starts the first tmnsaction (dock ed,ge- one), it asserts FRAM'E# and
`continues to assert its REQ# line to request the busagain. after the ootnpletion
`of the current transaction. When the address phase is completed (clock edge
`two), the master drives the first set of data bytes onto the AD bus and sets the
`byte rmables to indicate which data paths contain vafid data bytes. At the
`conclusion -of the first (clock edge three) and any subsequent data phases, the
`busmasterisdriving the Aflbusandlitebyteeltabies. FI.tt'ti1ermo1'e,thebI.|s
`master is asserting IRDY# during the final data phase. On the rising-edge of
`the PCI clock where the final data item is transferred (clock edge three),
`FRAME! has already been deasserlaed and I‘RDY# asserted (along with TRDWF
`and DEVSE‘L#]. It, on this same clock edge (dock edge three) the -master
`samples its__GN'I'# still asserted by the arbiter, this indicates that it has retained
`bus ownership for the next trtmsaclion.
`
`In the clock cell immediately following this clock edge {clock edge three), the
`mastercanitnmediatetyreassertfikrmltflilitt anctdriveanewstartaddress and
`command onto the bus. There isn’t a collision on the 1'-'.RAME# signal because
`the same output driver that was driving FRAME?! deasserted at the end of the
`firstu‘ansaetionbeginstoassettFRAME#atd-nestartoftheseeond
`transaction. There isn't a collision on theAD bus or the C/‘BE bus because the
`same master's drivers that were driving the final data item and byte enables at
`the end of the first transaction are driving the start address and command at
`the start of the second transaction.
`
`At the end of the address phase of the seeosnd transact-ion [clock edge four),
`the same master that was deasserting IRDY# at the end of the first transaction
`begins toreassert it (so thereisnoootlisionbetween two differentlRDY#'
`drivers).
`.
`
`I-low Collision Avoided On Signals Driven By Target
`
`The signals asserted by the target of the first transaction at the completion of
`the final data phase (clock edge three) are TRDY# and D_EVSEL# (and,
`possibly, STOW}. Two clocks afterthe end of the data phase, the target may
`also drive PERRtt. Since it is a rule in this scenario that the same target must
`he addressed in the second transaction, the same target again drives these
`signals. Even if the target has a fast address decoder and begins to assert
`DEVSEL#{and TRDY#tfitis s w'rite)duringetoI:Itee]1 fonrinthe second
`
`
`
`107
`
`Page 122 of 235
`
`_
`_
`_
`_
`Pet1t1oners HTC & LG — EXh1b1t 1019, p. 122
`
`Petitioners HTC & LG - Exhibit 1019, p. 122
`
`

`
`PCI Sxstem Architecture
`
`Iransstztion, the fact that it is the sari: target ensurm that there is not a
`oollision on TRDY# and DEVSEL# {and possibly STOP# and PERR1!) between
`output drivers associated with two different targets.
`
`How Targets Recognize New Transaction Has Begun
`
`It
`
`is a rule that all PCI targets must recognize either of the following
`as
`start of a new
`
`Jr-
`
`o Bus idle (FRAME? and 1RDY# deasserted) on I risirtgeedge of the PC]
`dock followed on the next rising-edge by address phase in progress
`[FRAME# asserted and IRDY# deassertedl.
`Final data phase _inpro_g-tess [FRAME#deasserted and IRDY#aaserted,) an
`a. rising-edge of the PCI clock, followed on the next rising-edge by address
`phase in Pl'°S1'¢ss (FRAME? asserted and IRDY# dessserted}.
`
`In
`
`Implementation of support for this type of fast bacloto-beck capability is
`optional for an initiator, but all targets must-‘be able to decode them.
`
`Fast Back-to-Back and Master Abort '
`
`'
`
`'
`
`
`
`When 5. master experiences a master short on a transaction during a fast back-
`3
`to-baekseries. itmsymnth-1ueperfomfin5fasttransactions(aslm1gasirsIill
`has its GNT#). No target responded to the aborted transaction,
`the-oeby _'
`ensuring that there witlnot be a collision on the target-related signals. If the _-.'
`transaction that ended with a master abort was a special cycle, the targetm 1'
`that received the message were already given sufifidem time (by the master)
`to process the message and should be prepared to recognise another
`transaction- The author would like to note that this portion of the 2.1
`specification states thatthe ta1get(s) ofthespecial cyelewere givenfiveclocb
`after the last data hamter to process the message. This conflicts with the
`specification description of the special cycle which cites four clocks
`required aiterthelastdetairsnsier.
`
`-2'
`
`Le»..,,.,.,,__I.
`_,.
`
`103
`
`Page 123 of 235
`
`"— *—Petitioners-H-TG&—LG — Exhibit 1019, p_._ 123
`
`Petitioners HTC & LG - Exhibit 1019, p. 123
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`Wrife Write
`
`'
`
`lownsbuaaoznd
`
`Figure 6-6. Arbitration For Fast Back-To-Back
`
`109
`
`Page 124 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 124
`
`Petitioners HTC & LG - Exhibit 1019, p. 124
`
`
`

`
`
`
`A target supports this capability if it meets the following criteria:
`
`no
`
`-
`
`,..2
`
`’
`
`Page 125 of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 125
`
`PCl System Architecture
`
`
`
`scenario Two: Targets Guarantee Lack of contention
`
`In the second scenario (defined in revision 2.0 of the specification and still true
`2.1), the entireoomutunity o.fPCI targets thstreside on the.PCI bus
`and the bus master collectively guarantee lack of contmtzion during fast bacJr--
`to-hack transactions. A constraint incurrecl when using the master-guaranteed
`:i1ethocl(deEin'ed in revision 1:0 ofthe specification) is that the master can only.. -
`perform fast back-to-back transactions if both transactions access the same
`target and thefirst transaction is_a write.
`
`.
`
`The reason that somatic one states that the target of the first and second
`tmnsacfions must be the same targetis to prevent the poss'il:il.ity of a collision
`on the tsrget—retated signals: TRDY#, DEVSEM and S'I'OP# (and. possibly,
`PERR#). This possibility can be avoided if:
`
`1. All targets have medium or slow address decoders and
`2. All targets are capable of cliscetning that a new transaction has begun
`without a transifion through the bus idle state and are capable of latching
`the address and command associated with the second transaction.
`
`If the full suite of targets cm a. PCI ‘bus meet these requirements, then any bus
`master that
`is fast back-to-back capable can perform fast back-to-back
`transactions with difierent targets in the first and second h-ansactions. The
`first transaction must still he a write, however, and the second hmnsactimt
`must be performed by the same master {to prevent collisions on master-
`related signals).
`
`The previous statement implies that there is a method to determine if all
`targets support this feature. During system configuration (at powenup].
`software polls each device's configuration status register -and checks the slate
`of its FAST BACK—TO-BACK CAPABLE hit. The deslgrter of a device
`harclwires this read-only bit to zero if the device doesn't support this feature;
`while hardwiring it to a one indicates that it does. If all devices indicate
`support for this capability, then the configuration software can set each W5
`'master‘s FAST BACK-T0-BACIC ENABLE bit in its conflglarafion command
`register [this bit, and therefore this capability is optional for a bus Inaateri
`When this bit
`is set, a rnasber is enabled to perform fast back-to-bid‘
`transactions with different targets in the first and second transactions.
`
`Petitioners HTC & LG - Exhibit 1019, p. 125
`
`

`
`Chapter 6: PCI Bus Arbitration
`
`I
`
`I Nomlallye target reoogrlizes a. bus idle condition by sampling FRAMB#
`and IRDY# deassertecl. It then expects and recognizes the start of the next
`I1‘aII.sacl:'ton bysampIi11&FRAMH asserted and IRDY# deasserted. At that
`point, it latches the address and command and begins address decode. To
`support the feature under discussion, it must recognize the oompletion of
`the final data phase of one transaction by sampling FRAME# deaaserted
`and 'IRDY# and T_RDY#
`'IJ_1is would then. be immediately-
`‘ ‘followed by the start of the next transaction. as indicated by sampling
`FRAME# asserted and 1RDY# deasserted on the next rising-edge of the
`PCI clock.
`.
`The target must ensure that there isrft corttention on TP.DY#, DEVSBM
`and 5TOP#- (and, possibly, PERM‘). If the target has a med.'u.rm or slow
`addreafdecoder, this provides tlie guarantee. If the target has a fast
`address decoder, it must delay assertion of these three signals by one
`clock to pre'i'ent coentenfion. Note that this does not aifect the DEV5BL#
`timingfield in the de'v‘ioe's configuration status register. The setting in this
`field is used by the bus’s subtractive decoder to adjust when it asserts
`DEVSEL# to claim transactions unclaimed by PCI davioes. During the
`second transaction of a fast back-to-‘back transaction pair, the subtractive
`decoder most delay its assertion of DEVSEU! if it normally I:lai.I:ns -during
`the medium or slow_tl.me slot (otherwise, a collision may ocour on
`DEVSEUP, 'I.'RDY#, and S'I‘0P# (and, possibly, PERM).
`The-reare twocttcumstanceswtterrsiargetwitha fastaddress decoder
`doesn't have to insert this one clock delay:
`
`o
`
`5
`
`1-
`
`1.
`
`'I'hecurrenttt'aIIs'actior1wasprooededby'a busidle state (FRAME#and
`IRDY? deasserted).
`2. The ourrently-addressed target was also addressed in the previous
`transaction. This ensures a tank of oontention on TRDY#, 5'I‘OP# and
`DEVSEM (because it was driving these signals during the previous
`transaction).
`
`
`State of FlEO# and GNT# During HST#
`
`While RST# is asserted, all masters must tri-state their-REG? output drivers
`and must ignore their GN'I'#' inputs.
`'
`
`
`
`111
`
`1 5 1:235
`
`Page 2 °
`
`Petitioners HTC & LG — Exhibit 1019, p. 126
`
`Petitioners HTC & LG - Exhibit 1019, p. 126
`
`

`
`PCI Sygtem Architecture
`
`
`Pullups on REO# From Add-In Connectors
`
`In a system with PCI add-in connectors, the axbiter may require a weak pullup
`on the KEQ# inputs that are wired to the add-in connectors. This will keep
`them from floating when the connectors are unoccupied.
`
`
`Broken Master
`
`The arbiter may amunte that a master is brukenif the arbiter has issued G-‘NT#
`to-the'master,tl_1ebushasbeenidlefor16 r.locl<5,and themasterhasnot
`assertedFRAME#tostartits_trarIsaclinn.'Ihe arbiteris permitted to ignore-all
`further requests from the broken master and may optionally report the failure
`to the operating system (in a device-specific fashion).
`
`Page 12?‘ of 235
`
`Petitioners HTC & LG — Exhibit 1019, p. 127
`
`Petitioners HTC & LG - Exhibit 1019, p. 127
`
`

`
`Chapter 7: The Commands
`
`
`Chapter 7
`
`The Previous Chapter
`
`-
`
`pre_1ri_ons_cha1';-ter_p—roVided_a._dascrip'tioztx of -PCI bus arbitratioti.
`
`In Thie Chapter
`
`This chapter defines the types of oommands, or_ trartsaciion types, that a bus
`master may izfitiate when