A.G.P. Interface Specification
`
`Revision 1.0
`
`CLK
`eeeee
`eeeee
`eeeee
`eeeee
`eeeee
`eeeee
`""" """
`"""
`%%%%%
`
`An
`
`""" """
`
`"""
`»»»»»
`
`
`
`
`RB F#
`
`REQ#
`
`
`
`Figure 3-31 PCI Transaction Between A.G.P. Request and Data
`
`Figure 3-30 shows the quickest that the A.G.P. compliant master can enqueue a request, perform a PCI
`transaction and then start returning read data. Two clocks are required between the completion of the A.G.P.
`request and the start of a PCI transaction, this is required because the A.G.P. REQ# line must be deasserted
`when P|PE# is asserted to indicate that the current request is the last to be enqueued. The earliest the
`A.G.P. compliant master can request a PCI transaction is on clock 3, and the earliest the arbiter can grant
`permission is on clock 4, which allows the PCI compliant master to initiate its request on clock 6. The two
`clocks between the PCI transaction and the read data is caused because of potential contention on TRDY#.
`This can occur when the PCI compliant master is the core logic and the target is the A.G.P. compliant master.
`
`3.6 Arbitration Signaling Rules
`
`3.6.1 Introduction
`
`This section describes the rules that the A.G.P. compliant master’s REQ# signal and the A.G.P. compliant
`arbiter’s GNT# signal need to follow for correct A.G.P. operation. These rules are a necessary part of the
`A.G.P. protocol.
`
`The rules associated with the master’s REQ# output signal provide an early indication to the A.G.P.
`compliant arbiter as to when an access request transaction will complete. The arbiter may take advantage of
`this to eliminate idle bus clocks between transactions.
`
`The rules associated with the GNT# signal minimize the amount of read data buffering required in the master
`while allowing back-to-back 8 byte transactions without idle bus clocks. In order to achieve back-to-back
`
`July 31,1996
`
`Page 61 of 161
`
`51
`
`Petitioners HTC & LG — Exhibit 1024, p. 61
`
`Petitioners HTC & LG - Exhibit 1024, p. 61
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`Some of the
`data transactions the arbiter may pipeline grants . The master must be able to accept them.
`rules in this section are necessary to limit the number of pipelined transactions that can be outstanding. This
`section will not attempt to describe the arbitration priority algorithms. This is a chipset specific
`implementation issue.
`
`3.6.2 A.G.P. Compliant Master’s REQ#
`
`The A.G.P. compliant master asserts its REQ# signal when it wants to issue either a PCI cycle or enqueue
`requests using P|PE#. The master will de-assert REQ# depending on the type of access request. When
`issuing an A.G.P. access request over the AD bus using P|PE# the master must keep its corresponding
`REQ# asserted until one clock prior to de-asserting P|PE# asserted and REQ# deasserted on the same
`clock edge is an early indication that the current access request transaction is the last and PIPE# will
`deasserted one clock later. The arbiter may utilize this to avoid idle bus clocks when asserting GNT# for a
`subsequent transaction. This rule implies that REQ# will be deasserted for at least one clock between back-
`to-back P|PE# access request transactions. The master should concatenate as many address requests as
`possible into a single P|PE# access request transaction.
`
`When an A.G.P. compliant master or a pure PCI compliant master issues a PCI transaction using FRAME#
`(and no other access requests are pending) it will de-assert REQ# when it asserts FRAME#. If another
`access request is pending the master will keep its REQ# asserted.
`
`These rules are summarized in Table 3-1 1:
`
`Current Access Request
`
`Nfixt
`Access
`
`Request
`
`PCI using FRAME#
`
`A.G.P. using P|PE#
`
`Keep REQ#
`aSSeITed-
`
`De-assert REQ# one clock
`prior to de-asserting PIPE#.
`
`F RAM E#.
`
`.
`
`.
`
`. Keep REQ# asserted De-assert REQ# one clock
`prior to de-asserting P|PE#.
`Concatenate if possible.
`
`De-assert REQ#
`
`De-assert REQ# one clock
`
`When asserting
`
`prior to de-asserting P|PE#.
`
`Table 3-11 A.G.P. Arbitration Rules
`
`Figure 3-8 Multiple Addresses Enqueued, Maximum Delay by Master shows an access request using
`P|PE#. The master deasserts REQ# one clock prior to de-asserting P|PE#. Simultaneous SideBand and
`AD Access Request Generation is Not Allowed. An A.G.P. compliant master that is configured to issue
`commands over the sideband signals is not allowed to generate commands with P|PE# over the AD bus.
`
`52
`
`Page 62 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 62
`
`Petitioners HTC & LG - Exhibit 1024, p. 62
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`3.6.3 GNT# and ST[2::0]
`
`The A.G.P. compliant arbiter will assert GNT# to initiate PCI or A.G.P. (non-sideband) activity. The
`ST[2: :0] signals are only meaningfirl while GNT# is asserted and are used to communicate the type of PCI
`or A.G.P. activity being initiated. The ST[2: :0] encodings are shown in Table 3-8 A.G.P. Status Signals.
`
`3.6.4 GNT# for Single Transactions
`
`For PCI and A.G.P. access requests GNT# will stay asserted until the arbiter samples either FRAME# or
`P|PE# asserted. The A.G.P. compliant master must drive P|PE# or FRAME# so that it is asserted either
`one or two clocks after the clock it samples GNT# asserted. Therefore GNT# will be asserted to an A.G.P.
`compliant master for a minimum of two clocks and a maximum of three clocks (for a single access request
`when the bus is idle). If the A.G.P. compliant master does not assert P|PE# or FRAM E# from either the
`same clock that GNT# is first sampled asserted or the followin clock, the arbiter may de-assert GNT# and
`consider the master inoperative. A pure PCI compliant masterl on the A.G.P. bus may take longer to assert
`FRAM E# after sampling its GNT# asserted. A pure PCI compliant master may be considered inoperative
`if it doesn’t drive FRAME# within 16 idle bus clocks after GNT# is asserted.
`
`For read and write data transfers, GNT# will be asserted along with the corresponding ST[2: :0] signals for
`one clock cycle per transaction. This is summarized in Table 3-12.
`
`A.G.P. Transaction Type
`
`GNT# Duration
`
`PCI Cycle
`
`Until FRAME# sampled asserted
`
`AD Access Request
`
`Until PlPE# sampled asserted
`
`
`
`One lx clock period per transaction
`One lx clock period per transaction
`
`Table 3-12 GNT# Duration
`
`Figure 3-31 shows an A.G.P. compliant master asserting REQ# to run a PCI cycle. The master samples
`GNT# asserted on clock edge #4 with ST[2: :0] encoding of ‘l 1 1’ indicating permission to generate either a
`PCI cycle or an A.G.P. request. The master is allowed to take one or two clocks to assert FRAME#. In this
`example the master asserts FRAME# one clock after sampling GNT# asserted. Since no subsequent access
`request is pending the master de-asserts REQ# at the same time it asserts FRAM E#. The arbiter samples
`FRAME# asserted on clock edge #3 and de-asserts GNT# clock 6. In this case GNT# is asserted for two
`clocks. If the master would have taken an additional clock to assert FRAME# the arbiter would have
`
`asserted GNT# for three clocks. Once the arbiter asserts GNT# (ST=l 1 1), the arbiter will continue driving
`it until either PIPE# or FRAME# are sampled asserted.
`
`Figure 3-11 shows a read data transaction. The arbiter asserts GNT# for a single clock with an ST[2: :0]
`encoding of ‘00x’ indicating permission for the target to drive either high or low priority read data. Both the
`master and the target sample GNT# asserted on clock edge #2. The master must be ready to accept data on
`the next clock edge. The target is allowed to take one or two clocks to assert TRDY# and begin driving read
`
`15 A PCI 2.1 compliant master that does not generate A.G.P. transactions.
`
`July 31,1996
`
`Page 63 of 161
`
`53
`
`Petitioners HTC & LG — Exhibit 1024, p. 63
`
`Petitioners HTC & LG - Exhibit 1024, p. 63
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`data. In this example the target asserts TRDY# and begins driving read data one clock afier sampling GNT#
`asserted. GNT# is only asserted for one clock since this is a single read transaction consisting of four data
`phases.
`
`§4
`
`E5
`
`is
`
`
`
`
`9
`
`
`
`
`
`CLK
`
`-----
`AD
`°'BE# ----- @9636!
`T
`3
`Z
`AD_STBxi “““ fi"‘
`IRDY#? """ fi"‘
`
`eeeee
`eeeee
`eeeee
`eeeee
`eeeee
`eeeee
`
`
`sn12uo]}x Ilflllllfillllfili{l§I|Ilfillllfilillfillllfilire
`RBF#§
`
`
`€36
`E
`2
`
`Figure 3-32 Write Data Followed by Read
`
`Figure 3-32 shows a 32 byte write followed by a read. The arbiter asserts GNT# on clock edge #2 for a
`single clock with an ST[2: :0] encoding of ‘O10’ indicating permission for the master to drive low priority
`write data. Both the master and the target sample GNT# asserted on clock edge #2. The target must be able
`to accept write data on the next clock. The master is allowed to take one or two clocks to assert IRDY# and
`begin driving write data. In this example the target asserts IRDY# and begins driving write data one clock
`afier sampling GNT# asserted. GNT# is only asserted for one clock since this is a single write transaction
`consisting of eight data phases.
`
`3.6.5 GNT# Pipelining
`
`In order run back-to-back 8 byte data transactions (in 2x data transfer mode) without idle bus clocks between
`transactions the arbiter must pipeline GNT#s. The arbiter limits the number of outstanding GNT#s resulting
`from pipelining, to minimize the master’s GNT# tracking logic. The master must be able to support the same
`number of outstanding pipelined GNT#s. The rules associated with attaining these goals are documented in
`this section.
`
`When GNT# is pipelined the new bus driver is responsible for correctly sequencing from the current
`transaction to the next. If an idle bus clock is required between transactions to allow for bus turnaround, the
`new bus driver is responsible for guaranteeing the turn around bus clock.
`
`0
`
`If GNT# is pipelined for an access request or for write data the master is responsible for correctly
`sequencing from the previous transaction to the next.
`
`0 When GNT# is pipelined for read data the target is responsible for correctly sequencing from the
`previous transaction to the next.
`
`The rules governing the earliest point that GNT# may be pipelined for the next transaction is solely
`dependent on the current transaction type. If the current transaction is read data, the arbiter must wait to drive
`
`54
`
`Page 64 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 64
`
`Petitioners HTC & LG - Exhibit 1024, p. 64
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`GNT# for the next transaction such that GNT# is first sampled asserted on the last data phase of the current
`read. The last data phase is defined as the last rising lx clock edge of the data transaction. This rule (along
`with proper use of the RBF# signal) minimizes the amount of low priority read data buffering required in
`the master. For a sequence of back-to-back 8 byte data transactions (in 2x data transfer mode) GNT# will be
`asserted on every lx clock edge since, by definition, every lx clock edge is the last data phase of a
`transaction.
`
`If the current transaction is write data, GNT# for the next transaction can be asserted on the clock
`
`immediately following the GNT# for the current write data while there are less than four outstanding write
`data GNT#s. The arbiter tracks the number of outstanding write data GNT#s and will only assert a GNT#
`for a subsequent transaction if there are less than 4 outstanding write data GNT#s. The arbiter increments its
`write data GNT# counter when it asserts GNT# for write data and decrements the counter when it samples
`IRDY#” asserted by the master for a write data transaction. The master must be able to handlefive
`pipelined GNT#s (this assumes that a master doesn’t consider a GNT# “canceled” until the data transaction
`has finished, one request currently being handled and four more enqueued). This rule allows back-to-back 8
`byte write data transactions to proceed when the master takes two clocks to assert the initial IRDY# after
`sampling GNT# asserted.
`
`If the current transaction is a PIPE# request, GNT# for a data transaction can be asserted immediately
`following the GNT# for the current access request. Since REQ# will stay asserted (but doesn’t indicate
`another request) until one clock prior to P|PE# de-assertion, it is impossible to pipeline a GNT# for
`another PCI or P|PE# access request if the current transaction is a P|PE# access request. Note that a
`GNT# for a P|PE# access request could immediately be followed by up to four GNT#s for write data
`transfers (or three writes and one additional transaction). The master’s GNT# pipeline logic must be able to
`handle this case.
`
`If the current transaction is a PCI cycle, GNT# for the next transaction can be asserted immediately
`following the GNT# for the current PCI cycle. Note that a GNT# for a PCI cycle could immediately be
`followed by up to four GNT#s for write data transfers (or three writes and one additional transaction). The
`master’s GNT# pipeline logic must be able to handle this case. An A.G.P. pipelined transaction is not
`allowed to start (after a PCI transaction) until the bus is IDLE (F RAM E# and IRDY# deasserted) for one
`clock. Table 3-13 entries refer to the earliest clock edge off which the arbiter can drive GNT# asserted for
`the next cycle.
`
`1° The count is 4 when a latched version of IRDY# is used to decrement the number of outstanding grants.
`Since the target could use either a latched or unlatched version the target is required to handle 4
`outstanding pipelined transactions.
`
`July 31,1996
`
`Page 65 of 161
`
`55
`
`Petitioners HTC & LG — Exhibit 1024, p. 65
`
`Petitioners HTC & LG - Exhibit 1024, p. 65
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`Current AD Activity
`
`PCI
`
`A.G.P.
`Command
`
`Read Data
`
`Write Data
`
`PCI or A.G.P.
`Command
`
`FRAM E# of
`current
`transaction
`sampled
`asserted.
`
`REQ# sampled
`asserted after
`being
`deasserted.
`
`2nd to last data
`phase of current
`transaction.
`
`Next
`
`AD
`
`A°tiVitY
`
`Read Data
`
`F RAM E# of
`current
`transaction
`
`sampled
`asserted.
`
`P|PE# of
`current
`transaction
`
`sampled
`asserted.
`
`(Depends on
`RBF#)
`
`(Depends on
`RBF#)
`
`Write Data
`
`F RAM E# of
`current
`transaction
`
`sampled
`asserted.
`
`P|PE# of
`current
`transaction
`
`sampled
`asserted.
`
`2nd to last data
`
`phase of current
`transaction to
`allow max. of
`
`40 bytes of
`buffering in
`master. See
`section
`
`describing
`RB F# signal.
`(Depends on
`R B F#)
`
`2nd to last data
`
`phase of current
`transaction.
`
`Immediately
`following
`GNT# for
`current write
`while <4
`
`outstanding
`GNT#s.
`
`Immediately
`following
`GNT# for
`current write
`
`(Depends on
`RB F#) while
`<4 outstanding
`GNT#s.
`
`Immediately
`following
`GNT# for
`current write
`while <4
`
`outstanding
`GNT#s.
`
`Table 3-13 Current/Next AD Activity
`
`Figure 3-16 shows a sequence of back-to-back 8 byte read data transactions in 2x data transfer mode. The
`target samples GNT# asserted on clock edge #2 and responds by asserting TRDY# and driving read data
`(L6) on the following clock. The arbiter can assert the GNT# for the second read data transaction (H4) on
`clock edge #3 since that is the last data phase of the L6 read data transaction. GNT# is asserted on every
`clock edge so that an 8 byte read data transaction can occur on every clock edge.
`
`56
`
`Page 66 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 66
`
`Petitioners HTC & LG - Exhibit 1024, p. 66
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
` V
`
`JAD
`
`L _____ _;___
`E 3559393099;
`amt -----+~aaaaaaaaaas
`
`
`
`Figure 3—33 GNT# assertion for 16. 8. and then 16 byte Read Transfers
`
`Figure 3-33 shows a sequence of 2); read data transactions. GNT# for The second read transaction (M) is
`asserted ml the clock edge #4 which is the last data phase of the R1 read transactioii. GNT# for the third
`read transaction (R3) is asserted on clock edge #5 which is the last data phase of the R2 1'ead transaction.
`
` °”‘:
`AD; ----- +mswwwwmmwmwmwawx
`<wBE#% ----- -+~n+»xwx»xmxsxmxsxmxsxmxsxmxsxmxg
`AD—STBx? """ 'T"
`x
`/
`x
`/
`x
`/
`x
`/
`x
`/
`x
`/
`3
`/
`%
`RBF#§
`E
`i
`i
`i
`i
`i
`i
`
`i F
`
`igure 3—34 GNT# Assertion for next Read Data after long Data Transfer
`
`July 31, 1996
`
`Page 6? of 161
`
`57
`
`Petitioners HTC & LG — Exhibit 1024, p. 67
`
`Petitioners HTC & LG - Exhibit 1024, p. 67
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`Figure 3-34 shows a 40 byte read transaction followed by another read transaction in 2x data transfer mode.
`GNT# for the second read data transaction (R2) is asserted on clock edge #7 which is the last data phase of
`the R1 read transaction.
`
`
`
`CLK
`_
`. 999999
`eeeee
`eeeee
`eeeee Maaeaeaeaa
`cm: —————
`
`
`
`
`Figure 3-35 GNT# assertion for Back to Back Write Data Transfers
`
`Figure 3-35 shows back-to-back 8 byte write data transactions in 2x data transfer mode. The following
`figures show that a maximum of 3 transaction are outstanding and will transfer data. The reason that it is
`only 3 and not 4 is that these diagrams assume that the arbiter is not using the latched version of IRDY#.
`When the latched version is used then all the number of grants outstanding are increased by one, since the
`arbiter delays the decrement. However, the arbiter can have 4 actually outstanding otherwise dead clocks
`can occur on the bus.
`
`The master samples GNT# asserted on clock edge #2 and asserts |RDY# and drives write data W1 two
`clocks after sampling (clock edge #4). On clock edge #2 the arbiter increments its write GNT# counter to 1.
`Since the GNT# counter is less than three the arbiter asserts GNT# for write data W2 on clock edge #3 and
`the arbiter increments the write GNT# counter to 2. Since the GNT# counter is still less than three the
`
`arbiter asserts GNT# for write data W3 on clock edge #4. Even though GNT# is asserted on clock edge #4
`the write GNT# counter does not increment since |RDY# for W1 is sampled asserted on clock edge #4. The
`arbiter continues asserting GNT# on every clock edge sustaining the back-to-back 8 byte transfers since the
`write GNT# counter is always less than three. In fact it is this waveform that established the need to allow
`up to three outstanding write GNT#s.
`
`58
`
`Page 68 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 68
`
`Petitioners HTC & LG - Exhibit 1024, p. 68
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`CLK
`
`
`
`eeeee
`eeeee
`An
`mmfi eeeee 3eeeee +~@@@@@@@@@@@@e
`
`
`
`
`31
`
`
`
`GNT#§
`ST[2::0]
`
`
`
`
`Figure 3-36 Back to Back GNT# with Delay on Initial Transfer
`
`Figure 3-36 shows a sequence of 16 byte write data transaction in 2x data transfer mode. The master asserts
`|RDY# and drives write data W1 two clocks after sampling GNT# asserted on clock edge #2. On clock
`edge #2 the arbiter increments its write GNT# counter to 1. Since the GNT# counter is less than three the
`arbiter asserts GNT# for write data W2 on clock edge #3 and the arbiter increments the write GNT# counter
`to 2. Since the GNT# counter is still less than three the arbiter asserts GNT# for write data W3 on clock
`
`edge #4. Even though GNT# is asserted on clock edge #4 the write GNT# counter does not increment since
`|RDY# for W1 is sampled asserted on clock edge #4. Since the write GNT# counter is still less than three
`the arbiter asserts GNT# for write data W4 on clock edge #5. Since there is no |RDY# asserted on clock
`edge #5 the write GNT# counter increments to three and the arbiter is prohibited from asserting GNT# for
`W5 on clock edge #6.
`|RDY# for W2 is asserted on clock edge #6 decrementing the write GNT# counter to
`two. This allows the arbiter to assert GNT# for W5 on clock edge #7. This again increments the write
`GNT# counter to three and prohibits GNT# assertion for W6 on clock edge #8. Note that on clock edge #5
`four GNT# have been pipelined to the master and the first transaction is still underway. This is the worst
`case scenario that the master’s GNT# pipeline logic needs to account for.
`
`July 31,1996
`
`Page 69 of 161
`
`59
`
`Petitioners HTC & LG — Exhibit 1024, p. 69
`
`Petitioners HTC & LG - Exhibit 1024, p. 69
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`CLK
`
`
`Ao %%%%%s%%%%%esmaaaeamawae t
`c/354;; »»»»»
`—————
`A°—STBX§::§:I:'_L/i8'_L/i€‘_\_/_“
`
`
`
`
`~.>-—z
`
`’3______
`5.;
`
`Figure 3-37 Pipelined GNT#s - Read and Writes (part 1)
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`CLK
`
`AD
`ClBE#
`AD_STBx§
`
`TRDY#§
`GNT#'*’
`sT[2::o1
`
`E
`5
`
`E
`
`E
`
`
`%%%%%%
`%%%%%
`%%%%%
`§"'%-iv''
`T’
`
`
`Q‘
`
`
`
`' "E ' ' ' ' ' "5 ' ' ' ' ' ' "E
`
`' ' ' "'3' ' ' '
`
`
`
`'
`
`8-88
`
`Figure 3-38 Pipelined GNT#s - Read and Writes (part 2)
`
`Figure 3-37 shows the first half of a long sequence of write data transactions mixed with read data
`transactions. While Figure 3-38 shows the conclusion of the transaction. These need to be Viewed as a
`single figure for the following discussion. The first three GNT#s are for write data transactions. The master
`inserts a wait state between the write data transactions. The GNT# asserted on clock edge #5 is for read
`data transaction R1. Note that the GNT# for R1 on clock edge #5 did not cause the write GNT# counter to
`increment from two to three. The write GNT# counter only increments for GNT#s associated with write
`data transactions. The arbiter dc-asserts GNT# on clock edge #6 and waits to assert GNT# for read data
`R2 on clock edge #10 which is the last data phase of read data transaction R1. Note that by this time the
`write GNT# counter decremented to zero by sampling |RDY# asserted on clock edges #6 and #8. Note also
`that the write GNT# counter does not increment on clock edge #10 since the GNT# is for a read data
`transaction. The target is responsible for inserting the idle clock for bus turnaround between transactions W3
`and R1. Read data transaction R2 is a 40 byte transaction so the next GNT# assertion is delayed by the
`arbiter until clock edge #15 which is the last data phase of R2. The GNT# on clock edges #15 is for write
`
`60
`
`Page 70 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 70
`
`Petitioners HTC & LG - Exhibit 1024, p. 70
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`data transaction W4. This causes the write GNT# counter to increment. The master is responsible for
`inserting the idle clock for bus turnaround between transactions R2 and W4. The arbiter asserts GNT# for
`W5, W6 and W7 on clock edges #l6,l7 and 18# respectively. The arbiter is prohibited from asserting
`GNT# on clock edge #19 for another transaction since the write GNT# counter is at three.
`
`3.6.6 GNT# Interaction with RBF#
`
`The A.G.P. compliant arbiter will not assert GNT# for a low priority read data transaction if the RBF#
`signal is asserted. In the case where RB F# is asserted on the same clock edge as GNT# is asserted, the
`master is required to accept that transaction. The arbiter must deassert GNT# immediately upon sampling
`RBF# asserted so that no further low priority read data transactions are signaled. RBF# only prohibits
`GNT# from being asserted for low priority read data transactions. GNT# assertion for high priority read
`data, write data, and access requests can still be generated even though RBF# is asserted.
`
`
`
`Figure 3-39 LP GNT# Pipelining Stopped While RBF# is Asserted
`
`Figure 3-39 shows the master asserting the RB F# signal indicating that it can’t accept fiirther low priority
`read data. The master samples GNT# asserted on clock edge #2 with ST[2: :0] indicating a low priority
`read data transaction. The master asserts RBF# on clock edge #3 because it doesn’t have sufficient buffer
`space to take the next two low priority read transactions. The arbiter has already asserted GNT# on clock
`edge #3 which is the last data phase of L6. The master must accept the GNT# on clock edge #3 for read data
`transaction L7. The arbiter samples RB F# asserted on clock edge #3 and deasserts GNT# until it samples
`RBF# deasserted on clock edge # 5. Note that if the arbiter didn’t deassert GNT# immediately upon
`sampling RB F# asserted on clock edge #3, then GNT# would be asserted on clock edge #4. This would
`increase the minimum amount of low priority read data buffering required in the master.
`
`3.7 A.G.P. Sequencer State Machine Equations
`
`This section will provide a concise statement of protocol rules to allow a designer to verify the correctness
`of his A.G.P. compliant bus sequencer. TBD.
`
`July 31,1996
`
`Page 71 of 161
`
`61
`
`Petitioners HTC & LG — Exhibit 1024, p. 71
`
`Petitioners HTC & LG - Exhibit 1024, p. 71
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`3.7.1 Error Reporting
`
`The error reporting philosophy of PCI applies to A.G.P. as well. This philosophy requires any device
`involved in the transfer or storage of permanent or retained system state (e.g., disk) to detect and report parity
`errors, and to compute parity. Devices involved with transient data only (e.g., graphics) are not so required.
`Since the sole purpose of the A.G.P. is the connection of video display devices, no provision has been made
`in the current spec for detecting or reporting of any bus errors. The current thinking is that if this becomes an
`issue in the future, bus parity detection and reporting will be added in essentially the same way as it is
`currently done on the PCI bus.
`
`Admittedly this approach begs the question of address errors on writes to system memory (a problem that did
`not occur on PCI when graphics devices were targets only), as well as the possibility of data corruption on
`ancillary channels such as VBI. Nonetheless, this position seems to be congruent with current graphics
`accelerator practice, and therefore remains the current plan.
`
`62
`
`Page 72 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 72
`
`Petitioners HTC & LG - Exhibit 1024, p. 72
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`4. Electrical Specification
`
`4.1 Overview
`
`4.1.1 Introduction
`
`As with the protocol enhancements, the A.G.P. electrical specification extends PCI to provide a much higher
`performance graphics interface. Most of the electrical interface requirements are based on the PCI spec, and
`this document will reference that spec wherever possible.
`
`The A.G.P. physical interface is optimized for a point to point topology using a 3.3V signaling environment.
`The baseline performance level utilizes a 66 MHz clock, to provide a peak bandwidth of 266MB/sec.
`
`A.G.P. includes an option for higher performance levels, providing peak bandwidths of 533MB/sec”. This
`optional mode uses a double-clocked data technique to transfer twice the data per each A.G.P. clock. This
`A.G.P. mode, referred to as 2X transfer made (also 2X mode or A.G.P.-13318), requires additional interface
`timing strobes and different signal timings from the 1X mode. Components supporting the 2X transfer mode
`must also support the 1X mode. 2X mode requirements are a superset of the 1X mode timings.
`
`The next section establishes a conceptual framework by which to understand the two modes.
`
`4.1.2 1X Transfer Mode Operation
`
`The 1X mode, 66 MHz A.G.P. interface can be designed using common I/O buffer technology. Since A.G.P.
`is a point to point interface, adjustments have been made in the system timing budgets that relax component
`input requirements relative to PCI.
`
`Conceptually, the 1X mode A.G.P. operation is similar to PCI. All timings are referenced to a single clock,
`the A.G.P. clock.
`
`4.1.3 2X Transfer Mode Operation
`
`The A.G.P. protocol provides Qword access granularity. Qword transfers normally take two clock cycles in
`the 1X mode. Likewise, sideband address commands normally take two clocks per each 16-bit command.
`The 2X transfer mode provides a mechanism for doubling the data transfer rate of the AD, CI B E# and SBA
`signals”. With 2X transfer, Qword transfers only require one clock cycle, and sideband commands only
`require one clock per 16-bit command.
`
`17 533MB/sec results from the actual minimum clock period of l5ns.
`
`18 “l33 ” connotes a 133MHz peak transfer rate.
`
`19 The clock mode of these signals is controlled as a unified group; independent control of the clocking
`mode for sub-groups is not provided.
`
`July 31,1996
`
`Page 73 of 161
`
`63
`
`Petitioners HTC & LG — Exhibit 1024, p. 73
`
`Petitioners HTC & LG - Exhibit 1024, p. 73
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`The 2X transfer mode is implemented as a timing layer beioi I-‘ the 1X protocol's flow control mechanisms.
`This timing layer. referred to as the inner‘ loop. specifies timing relationships for the reliable transfer of data
`from the output latches at the transmitting device to the input latches at the receiving device. The logical
`protocol mechanisms operate above this layer. via an outer loop. to control the actual transfer of data
`between the data queues. A model showing these various time domains is shown in Figure 4~1.
`
`Inner Loop
`
`Outer Loop
`
`Transmitter
`_,._.TTT
`“‘-..
`I
`
`-
`
`.
`
`Receiver
`_e_.m
`
`_
`
`-.
`
`K
`
`timing
`
`I Timing E
`
`timing
`
`A.G.P. CLK
`
`Figure 4-1 2X Mode Time Domains
`
`The outer loop of both devices operates from a common A.G.P. clock, and outer loop controls are specified
`relative to this clock (as in the 1X operation mode). The inner loop timings use additional source
`synchronous timing signals to realize the data transfer. Note that the only clock defined in the system is the
`A.G.P. clock.
`
`Source timed strobes. where the device sourcing the data also sources a timing signal for use by the receiver.
`are used since data transport delays are nulled out at the receiver. These source synchronous stmbes a1'e
`derived fi'o1n the COI.l]lJ10I1 A.G.P. clock at the transmitter, placed at the center of the output data valid
`window. and used by the receiver to directly capture data at the interface.
`
`The inner loop and outer loop timing dependencies are defined by a set of relationships between the strobes
`and the A.G.P. clock. The relationship allows for a deferniinisrir transfer of data between the inner and
`outer loops. These timing dependencies are specified in such a way as to allow implementation flexibility at
`the receiver. A tradeoif can be made between the latency through the inner loop and the implementation
`technology andfor design complexity. Refer to the A.G.P. Design Guide for more information.
`
`The timing model presented above contains four different time domains. to be detailed in the following
`sections:
`
`Transmiti’Rec eive Outer Loop
`
`Transmit to Receive Inner loop
`
`I
`
`I
`
`64
`
`Page 74 of 161
`
`July 31, 1996
`
`Petitioners HTC & LG — Exhibit 1024, p. 74
`
`Petitioners HTC & LG - Exhibit 1024, p. 74
`
`

`

`A.G.P. Interface Specification
`
`Revision 1.0
`
`0
`
`0
`
`Transmit Outer to Inner Loop
`
`Receive Inner to Outer Loop
`
`4.1.3.1 TransmitlReceive Outer Loop
`
`The outer loop between the devices uses the 1X mode A.G.P. timings for bi-directional control information
`transfer between the transmitter and receiver.
`
`4.1.3.2 Transmit to Receive Inner loop
`
`Transfer of data20 between the transmit and receive inner loop circuits is accomplished using a timing strobe
`sent from the transmitter to the receiver, with a set of simple timing relationships between the data and strobe.
`Both edges of the strobe are used to transfer data, with the first half of data corresponding to the falling edge
`of the strobe, and the second half corresponding to the rising edge.
`
`The transmit strobe edges are positioned near the center of the minimum data valid window, to give the
`receiver a good input data sampling window for all the various system timing skew cases. A minimum data
`valid before strobe edge (tDVb), and a minimum data valid after strobe edge (tDva) are specified. The
`transmit strobe/data timings are shown in Figure 4-2.
`
`Transmit Strobe
`
`tDvb
`
`tDva
`
`tDvb
`
`tDva
`
`Trenemiteete
`
`Figure 4-2 Transmit Strobe/Data Timings
`
`The receive strobe input is directly used to capture data into the device. Again, both edges of the strobe are
`used to capture data, since new data is valid on each edge. A minimum setup (tDsu) and hold time (tDh)
`relative to the strobe edges is therefore required, as shown in Figure 4-3.
`
`
`
`tDsu
`
`tDh
`
`tDsu
`
`tDh
`
`Receive Strobe
`
`Receive Date
`
`Figure 4-3 Receive Strobe/Data Timings
`
`2° Data refers to any of the 2X capable signal groups: AD[31:0], C/BE[3:0]# or SBA[7:0].
`
`July 31,1996
`
`Page 75 of 161
`
`65
`
`Petitioners HTC & LG — Exhibit 1024, p. 75
`
`Petitioners HTC & LG - Exhibit 1024, p. 75
`
`

`

`Revision 1.0
`
`A.G.P. Interface Specification
`
`4.1.3.3 Transmit Outer to Inner Loop
`
`The next timing relationship to understand is the relationship between the outer loop and inner loop at the
`transmitter. These timing specs are needed to create a deterministic data relationship between the inner loop
`transfer and the related outer loop flow control events (e. g. |RDY#). The relationship is specified by
`relating the output strobe to the A.G.P. clock, as shown in Figure 4-4. Note that two clock periods, T1 and
`T2, are shown since the strobe pulse is permitted to cross the A.G.P. clock boundary.
`
` tTSf MIN
`
`tTSf MAX
`
`Transmit Strobe
`
`V
`
`tTSr
`
`i
`
`/
`
`\
`
`Figure 4-4 Transmit Strobe/Clock Timings
`
`To guar