RE: REQ#/GNT# behavior at RST# deassertion

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

Section 4.3.3, page 141 of the 2.1 specification states that "The
central resource, or any component containing an arbitration unit, may
require a weak pull-up on each unconnected REQ# pin ...", but they don't
mention GNT#.  Section 4.2.4 talks about the general handling of
indeterminate inputs and implies that pull-up resistors are allowed.  I
specify internal pull-ups (~50K) for all REQ# (arbiter) or GNT# (master
agent) inputs.

Cliff Kimmery
Honeywell Inc.
kimmery@space.honeywell.com

>----------
>From: 	kevin.normoyle@Eng.Sun.COM[SMTP:kevin.normoyle@Eng.Sun.COM]
>Sent: 	Wednesday, December 18, 1996 2:35 PM
>To: 	Mailing List Recipients
>Subject: 	REQ#/GNT# behavior at RST# deassertion
>
>
>The spec says
>	"While RST# is asserted, the arbiter must ignore all REQ#
>	lines since they are tri-stated and do not contain a valid
>	request. The arbiter can only perform arbitration after
>	RST# is deasserted. A master must ignore its GNT# while
>	RST# is asserted." (GNT# is also undriven during RST#)
>
>The problem:
>
>IF REQ# inputs only become valid the cycle after RST# deasserts,
>then the GNT# won't be valid until the cycle after that.
>(assuming a fast reacting arbiter)
>
>So I would think a master should also ignore GNT# for 1 or 2 more
>cycles after the RST# deassertion, otherwise there's the potential
>for multiple people seeing GNT# in the cycle after the RST#
>deassertion.
>
>This makes me want to put pullups on GNT#, since that isn't a spec
>requirement, and I don't want contention on the RST# deassertion.
>
>
>Any comments?
>
>-kevin
>
>
¬øç