Re: Arbitration question (GNT#->FRAME# latency)

["Johnson, Ralph" <ralphj@bit3.com>]

Tom,

I have observed that some arbiters will dynamically vary the width of the GNT# 
signal, dependent on system bus activity.  The minimum was a ONE clock cycle 
GNT#.  This was observed on a Digital Alpha platform, with arbitration provided 
by Intel EISA-PCI bridge components.  Unless you know your host environment, 
design for a one clock cycle GNT#.

Ralph Johnson
ralphj@bit3.com


>I have a question for PCI designers out there:
>
>The last paragraph of section 3.4.1 (Arbitration) says:
>
>    "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 possibility of losing its turn on the bus."   
>
>Does anyone know of an arbiter/PCI chipset that doesn't always assert
>GNT# for at least two clock cycles?  We have not yet encountered a
>chipset that does not provide at least two clocks for GNT#.
>
>I am interested in this because I would like to use the first cycle
>when GNT# and Idle are detected to turn on output enables, and the
>second cycle when GNT# and Idle are detected to assert FRAME# and
>address.
>
>I have found that many PCI buffers are designed such that the Z-to-low
>and Z-to-high path is not considered the critical path, since the output
>enable could be driven a clock earlier.  But for the GNT#/FRAME# case,
>this assumption is bad.  If I could rely on GNT# being asserted for at
>least two clocks, I could turn on the output enable in one clock and
>then assert FRAME#/AD in the next clock and still meet the Tval requirements.
>
>Thanks in advance for any insight/help,
>Tom
>
>--
>Tom Hicks   Fore Systems
>Design Engineer   174 Thorn Hill Rd
>Adapter Group   Warrendale, PA 15086
>thicks@fore.com 

M”„