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

[Robert.Hormuth@natinst.com (Robert Hormuth)]

     Are you sure the arbiter is not changing the GNT to a different device 
     while a cycle is still pending.  I have seen chipsets that will give a 
     GNT to a device while a cycle is still pending and then pull that GNT 
     away and give the bus to the HOST-PCI bridge instead.  This is 
     completely legal as long as the GNT is removed while another cycle is 
     going on.
     
     
     
Robert Hormuth
Staff Design Engineer, VXI Embedded Group 
National Instruments
6504 Bridge Point Parkway
Austin, Texas 78730
roberth@natinst.com
(512) 433 - 8630 Phone
(512) 433 - 8641 Fax
     
______________________________ Reply Separator _________________________________
Subject: Re: Arbitration question (GNT#->FRAME# latency)
Author:  "Johnson; Ralph" <ralphj@bit3.com> at Internet 
Date:    10/1/96 8:28 AM
     
     
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 
     
Received: from natinst.com by hail.natinst.com with SMTP
  (IMA Internet Exchange 2.0 Enterprise) id 2514C2F0; Tue, 1 Oct 96 11:51:59
-0500
Received: from falcon.natinst.com (falcon.natinst.com [130.164.1.7]) by
natinst.com (8.7.5/8.7.3) with ESMTP id LAA25959 for
<robert.hormuth@hail.natinst.com>; Tue, 1 Oct 1996 11:51:58 -0500 (CDT)
Resent-From: pci-sig-request@znyx.com
Received: from natinst.com (natinst.com [130.164.1.1]) by falcon.natinst.com
(8.8.0/8.8.0) with ESMTP id LAA27658; Tue, 1 Oct 1996 11:51:57 -0500 (CDT)
Received: from netcomsv.netcom.com (uumail1.netcom.com [163.179.3.50]) by
natinst.com (8.7.5/8.7.3) with SMTP id LAA25950; Tue, 1 Oct 1996 11:51:50 -0500
(CDT)
Received: from znyx.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
	id IAA23071; Tue, 1 Oct 1996 08:55:56 -0700
Received: by znyx.com (5.65/1.35)
	id AA05307; Tue, 1 Oct 96 06:36:19 -0700
Resent-Date: Tue, 01 Oct 96 08:28:19 CDT
Date: Tue, 01 Oct 96 08:28:19 CDT
From: "Johnson, Ralph" <ralphj@bit3.com>
Encoding: 45 Text
Message-Id: <9609018441.AA844183728@ccmailgw.bit3.com>
Cc: thicks@fore.com
Subject: Re: Arbitration question (GNT#->FRAME# latency)
Resent-Message-Id: <"flv0n.0.bG1.UqHKo"@dart>
X-Mailing-List: <pci-sig@znyx.com> archive/latest/3734
X-Loop: pci-sig@znyx.com
Precedence: list
Resent-Sender: pci-sig-request@znyx.com
To: Mailing List Recipients <pci-sig-request@znyx.com>