Re: FFs for GNT and REQ

["Weng Tianxiang" <wtx@umem.com>]

Hi,
My opinion is wrong. Please follow Richard's opinion. PCI specs 2.2 section
3.4.1 is the authority description we must follow.

Weng

----- Original Message -----
From: Richard Walter <rwalter@Brocade.COM>
To: <wtx@umem.com>; <pci-sig@znyx.com>; <Thomas.Zipper@icn.siemens.de>;
<S.Spaeth@alcatel.de>
Sent: Friday, September 08, 2000 11:35 AM
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.
>
>