Re: On I/O and memory address space (corrections)

[Steve Glaser <glaser@hpn.lkg.dec.com>]

It was pointed out to me by one of our bridge experts that I got some
of the I/O space decoding stuff wrong.  On rereading that part of the
PCI-to-PCI bridge spec...

1. The I/O base and limit registers are optional in PCI-to-PCI
bridges.  There are three legal configurations: none, 16 bit and 32
bit.  Good bridges (like ours) do 32 bits.

2. There is an ISA Enable bit to deal with the fact that the original
PC only decoded some of the address bits on I/O space transactions and
over the years various folks have used this kludge in interesting
ways.  This lack of decoding and the curse of compatability is the
reason for the 256 byte I/O space restriction we have nowdays in PCI.

3. PCI-to-ISA bridges are never on the secondary PCI.  I thought I saw
this somewhere in real life but I was wrong.  The spec even says so.

This means that you may be taking a risk if you depend on I/O space
working behind an arbitrary bridge.  If the bridge is on your card,
then you have control and can pick a good one.  I don't know how many
bridges in the real world do it right (or at least enough right).  I
assume that any imperfect situation will get better over time.  There
are lots of reasons for new system designs to use newer chips.

On memory space stuff and a related dicussion going on the reflector at
present....  The PCI-to-PCI bridge spec explicitly DOES NOT SUPPORT
"below 1Mb devices" on the secondary PCI bus.  There's only three of
base/limit registers to tell the bridge what addresses it should claim
(one for memory, one for I/O (optional), and one for prefetchable
memory (optional)).  There's nothing provided for "below 1Mb memory".

I still stand behind my recomendation that devices implement as many
shadows as make sense and let software pick up the pieces.  This is
especially important for the prefetchable/non-prefetchable memory
case.

Steveg

>Subject: Re: On I/O and memory address space 
>Date: Mon, 10 Feb 97 13:25:34 GMT
>From: Steve Glaser <glaser>
>To: Mailing List Recipients <pci-sig-request@znyx.com>

>> Bob Goudreau <goudreau@dg-rtp.dg.com> wrote:
>>> Ali Najafi <alinajafi@simei.aztech.com.sg> wrote:

>>> Second way: Make all the registers I/O mapped...
>>> ...
>>> What I like to do is to map everything to memory. This is what PCI spec has
>>> suggested and also seems quite natural and practical and also helps using
>>> the bus bandwidth efficiently. It is also OK to map evrything to I/O space

>>	Devices should always allow control functions to be mapped into
>> 	Memory Space.

>Please consider carefully whether the memory space copy should be
>marked prefetchable or not.   There are a few considerations:

>1. Registers with read side effects are usually a bad idea, but if you
>have them, then they must be non-prefetchable.

>2. If you want to do burst reads/or writes to your device from a host,
>then the memory space should be marked prefetchable.

>3. Prefetchable devices can incur extra overhead reading useless CSRs
>(i.e. stuff that the host will later ignore). This is particularly bad
>if the device "stops" a read transfer after each word as the bridge
>will keep reading until it gets its cache line, thus incurring multiple
>big latencies for the job (one for each word in the cache line when
>software was expecting to spend only one total).

>Also note that I/O space only devices are unlikely to work behind a
>PCI-to-PCI bridge since the bridge ususally doesn't have enough address
>space decoding to do the job.  The PCI-to-PCI bridge I/O space decoding
>is frequently just enough to allow the PCI-to-ISA bridge to sit on the
>secondary bus and not much more.

>My preferred solution:

>If burst traffic is ever desireable to the device, make three copies of
>the CSRs, one in I/O space, one in Prefetchable Memory space and one in
>Non-Prefetchable Memory space.  That way software can decide what it
>wants and you don't have to make any hard decisions up-front.

>If no burst traffic is interesting and the memory space consumed is
>modest, then skip the prefetchable memory space.
>------------
>Steve Glaser				Digital Equipment Corporation
>glaser@lkg.dec.com (or HPNLKG::GLASER)	550 King Street	LKG1-2/W6
>+1.508.486.7212  FAX: +1.508.486.5279	Littleton, MA 01460-1289
zÜÌ