RE: FFs for GNT and REQ

["Kimmery, Clifford (FL51)" <clifford.kimmery@honeywell.com>]

Since PCI arbitration is cooperative between an arbiter and the connected
masters, adding registers in the grant paths will not cause master
collisions as long as grant is asserted to only one master at a time.  If
clock delays are added in the grant path to some masters and not others,
collisions will undoubtedly occur.  Any delays inserted between a PCI
arbiter and the connected masters must be exactly the same number of clock
periods.

Adding clock delays in the request paths can never cause master collisions
even if some request paths have delays and some do not.  Since a PCI master
cannot know when the arbiter will grant a request, delaying the request
cannot create a collision.

A requesting master can only assert FRAME if the bus is idle and its grant
is asserted.  It doesn't matter if grant is removed on the same clock edge
that the master asserts FRAME, that master now owns the bus until the
transaction is completed.  The arbiter will assert grant to the next master
while the current transaction is active, but that next master cannot assert
FRAME until the bus becomes idle (for one clock period).

Adding clock delays in the request or grant paths will impact arbitration
performance is systems where most transactions are small.  Although PCI
arbitration occurs in parallel with bus transactions, a slow arbiter can
impact bus performance if the next master cannot be chosen before the
current bus transaction completes.  Since a minimum PCI transaction (when
changing masters) is three clock periods (address phase, data phase,
transition phase), an arbiter that takes longer than three clock periods to
choose the next master is not good.

Cliff Kimmery
Honeywell International
clifford.kimmery@honeywell.com


-----Original Message-----
From: Richard Walter [mailto:rwalter@Brocade.COM]
Sent: Friday, September 08, 2000 2:35 PM
To: 'wtx@umem.com'; pci-sig@znyx.com; 'Thomas.Zipper@icn.siemens.de';
'S.Spaeth@alcatel.de'
Subject: RE: FFs for GNT and REQ


Folks,

> -----Original Message-----
> From: Weng Tianxiang [mailto:wtx@umem.com]
>
> When your REQ# is asserted and once Bus Arbitor gives you GNT#,
> it will not disappear for at least 5 clocks or FRAME# is asserted,
> whichever comes first.

Wrong.

PCI 2.2, section 3.4.1, paragraph 2, sentence 1, page 70:
"The arbiter may deassert an agent's GNT# on any clock."

and

PCI 2.2, section 3.4.1, paragraph 13, sentence 3-4, page 71:
"The arbiter may remove GNT# at any time to service a higher
priority agent.  A master that has requested use of the bus that
does not assert FRAME# when the bus is in the Idle state and its
GNT# is asserted faces the possibiliy of losing its turn on the bus."

So, if you delay GNT# out of the arbiter by one clock with an external
register, the arbiter might be removing your GNT# to give one to
someone else, but you will not see this until one clock later.  This
could cause both you and someone else to think that it is ok to
start a cycle and collide.

> My reason is not from PCI specs, but from my reasoning: 5 clocks
> are needed to guarantee that some PCI masters behind bridge get
> the correct GNT# response from arbitor. That FRAME# is asserted
> means PCI Bus client has got the bus access. My guess is as much
> as 16 clocks may be generated by PCI bridge to wait for FRAME#
> assertion before arbitor deassert GNT#.

Arbitration only happens on a bus segment basis.  So, if there is a
bridge that separates two PCI busses, there will be two arbiters, one
for each bus.  And these arbiters are completely independent of each
other.

By the way, the 16 clock number from GNT# until FRAME# assertion is
really bad.  In fact, PCI 2.2, section 3.4.1, paragraph 13, sentece 1-2,
page 71: "The arbiter can assume the current master is "broken" if it
has not started an access after its GNT# has been asserted ... and the
bus is in the Idle state for 16 clocks.  The arbiter is allowed to
ignore any "broken" master's REQ# ..."  So, if you have a device which
does wait for 16 clocks from GNT# before it drives FRAME#, the arbiter
may never grant it the bus again.

So, delaying GNT# by one clock is not good.

Second, PCI 2.2, section 3.4.1, paragraph 1, sentence 2, page 70:
"Agents must only use REQ# to signal a true need to use the bus."

Depending on the design of the device delaying REQ# may be bad.
If the device holds REQ# active for the entire bus cycle that it
is running (which it is allowed to do) and then turns it off at
the end and someone externally delays the REQ# into the arbiter
by one clock, then from the arbiter's point of view, the device
might (for one clock) be requesting the bus when it doesn't have
a true need to use it.  This could cause GNT# to be asserted to
the device and yet he won't run a cycle.  The arbiter is allowed
to interpret this as a broken master and may disable the device
entirely.

So, delaying REQ# by one clock is not good.

Now, will any of these things happen in a real system.  Maybe or
maybe not.  Are you feeling lucky today? :)

> Weng Tianxiang
> Micro Memory Inc.
> 9540 Vassar Av.
> Chatsworth, CA 91311
> Phone: 818-998-0070, Fax: 818998-4459

-Richard Walter
Hardware Engineer
Brocade Communications Systems
rwalter@brocade.com
Note: I speak for myself, not for Brocade.