FW: Re[2]: PCI I/O Space Consumption Limitation

["Taylor, Mike" <mike@buntypost.dundee.ncr.com>]

I thought PCI/ISA bridges used subtractive decode and therefore were only   
active in address spaces not acknowledged by any PCI bus. Aliasing by an   
ISA card would therefore be prevented in any PCI used I/O space. The 256   
bytes per I/O BAR restriction is therefore not due to ISA limitations.

However, page 197 states that devices which consume more space than they   
use, need not respond to the unused portion. Does this mean that an ISA   
bus can respond to such an unused portion of a PCI card's space?

Mike.
 ----------
From: 	pci-sig-request[SMTP:pci-sig-request@znyx.com]
Sent: 	21 August 1996 21:04
To: 	Mailing List Recipients
Cc: 	pci-sig
Subject: 	Re[2]: PCI I/O Space Consumption Limitation

 The restriction for the 256 byte I/O space comes from the fact that
 some ISA devices do not decode addresses above SA9 on the bus. These
 devices use addresses x100-x3ffH and there aliases like 1100-13ff,
 2100-23ff,etc. So, PCI devices are not assigned any address between
 x100-x3ff. In every 1K of I/O space available only the first 256 bytes
 are allocatable to PCI while the 768 bytes remain reserved for ISA
 devices. If PCI devices are allocated between x100-x3ff there is a
 possibility that some ISA devices using aliased address may not seen
 by their S/W. I have seen some of the old PCI VGA cards using aliases
 of their VGA addresses which the BIOS has no way of finding out. The
 only way to avoid this problem is to assign only the first 256 bytes
 of every 1K of I/O space.


______________________________ Reply Separator
_________________________________
Subject: RE: PCI I/O Space Consumption Limitation
Author:  Belvin Stephen E <belvin_stephen_e@smtp2.space.honeywell.com> at   

Internet
Date:    8/21/96 7:32 PM


 Tripathi:
   Thanks for responding to yet another of my questions.  As far as the
 discussion on page 197 goes, you're right that it is trying to suggest   
that
 designers memory map I/O.  My concern is that it doesn't suggest that an   
I/O
 BAR be used to represent no more than 256 bytes, it *requires* it.
   In my system, I have a non-prefetch memory BAR that, when properly
 configured, allows the expansion bus registers to be accessed via PCI   
memory
 operations.  I have also assigned a large, dedicated I/O space to allow   
access

 to the expansion bus bridge I/O section if enabled (256 KB total, or 4K   
per
 node).
   I would like to express my disappointment that the I/O space   
restriction is
 not a SHOULD (or even a PLEASE).
   

 Steve
 - - - - - - - - - - - - -
   

 On Aug 21, 1996, Devendra K Tripathi wrote:
   

 > It may be pointed here that you have to have a Memory BAR for
 > every I/O BAR. The point is that PCI does not encourage to use
 > I/O space at all. Obiously you have some reason to use such big
 > I/O spaces instead of mapping them to memory, but it may be
 > worth reveiwing those constraints.
 >
 > Thanks,
 > Tripathi.
   

 On Aug 21, 1996, Steve Belvin wrote:
  >> Hi.
  >>   I am developing a PCI expansion bus bridge and am concerned
  >> about what appears to be an I/O space consumption limitation.
  >>   Page 197 of the PCI Rev 2.1 spec states "Devices that map
  >> control functions into I/O space may not consume more than
  >> 256 bytes per I/O Base Address Register."  In response to
  >> this and repeated recommendations to minimize I/O space, I
  >> find that many devices are encouraged to minimize I/O space.
  >> In one book I read that "... subsystem designers should
  >> design a function so as to require no more than 32 bytes of
  >> user-definable configuration data."
  >>   I am well aware of the shrinking Intel I/O space problem
  >> but not all systems have I/O space limitations.  My system
  >> will use a MIPS processor and we plan to implement a large
  >> I/O space (from 10KB to 1MB).  Where practical, we follow
  >> IEEE Std 1212 register definitions as a guide, where I/O
  >> space is sacrificed for well organized control and status
  >> registers.  Fire Wire also follows this in its register
  >> organization.
  >>   I would think PowerPC host bridges would not find 10-20KB
  >> of I/O space to be a problem.
  >>   My question is:
  >>
  >>   o   Do designers follow the statement on page 197 and
  >> implement multiple I/O BARs where more than 256 bytes of
  >> I/O space are consumed?
  >>
  >>   TIA.
  >> Steve Belvin
   

   

 ------ Message Header Follows ------
 Received: from netcomsv.netcom.com by american.megatrends.com
   (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm))
   id AA-1996Aug21.193220.1665.22241; Wed, 21 Aug 1996 19:32:22 -0400
 Received: from znyx.com by netcomsv.netcom.com with SMTP   
(8.6.12/SMI-4.1)
  id QAA20415; Wed, 21 Aug 1996 16:07:31 -0700
 Resent-From: pci-sig-request@znyx.com
 Received: by znyx.com (5.65/1.35)
  id AA25176; Wed, 21 Aug 96 16:07:49 -0700
 Resent-Date: 21 Aug 1996 19:09:30 -0400
 Message-Id: <9608212305.AA25108@znyx.com>
 Date: 21 Aug 1996 19:09:30 -0400
 From: "Belvin Stephen E" <belvin_stephen_e@smtp2.space.honeywell.com>
 Subject: RE: PCI I/O Space Consumption Limitation
 Cc: "PCI Reflector" <pci-sig@znyx.com>
 Resent-Message-Id: <"VtLcE3.0.U86.CPv6o"@dart>
 X-Mailing-List: <pci-sig@znyx.com> archive/latest/3519
 X-Loop: pci-sig@znyx.com
 Precedence: list
 Resent-Sender: pci-sig-request@znyx.com
 To: Mailing List Recipients <pci-sig-request@znyx.com>

h
\I