[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.