Re: IO and Bursting

[Dave New <den@aisinc.com>]

Brian Sassone wrote:
> 
> Are bursts to IO address space always forbidden on PCI?
> 
It's not the burst/non-burst that you should be worried about,
Brian.  I suspect that you are implying that you would like to do a
*single-address* burst to I/O space, so you can stream data
in/out an I/O port.  A reasonable, request, in my opinion.

Unfortunately, this is *not* defined for PCI.

You *could* do such a thing via private arrangement between
a bus master and target, but bridges won't support it, and
neither will anyone's off-the-shelf chipsets.  I wouldn't
recommend it.

The big deal is what do you do with a disconnect/retry?  The
master (or bridge) is supposed to retry the transfer sometime
later, and is expected to produce an updated target address, based
on how much data was sent up until the disconnect.  The target is
likewise expected to keep track of the current address during
a burst, since the address is only sent once at the beginning
of the burst (and at the start of retries).  As a matter of
fact, it's counting on having the proper address presented
to it during the retry, so it can "identify" which master is
retrying the cycle (only checking the address and byte enables
leaves another big "hole" in the PCI spec, but that's another
story...).

There is nothing about doing I/O (rather than memory cycles) that would
allow you to imply (or dis-imply) being able to do burst cycles to
a target.  If the target allows it, it will happen.  If not, it won't.

The AMCC (for example) has an input FIFO at a single address.  If
you attempt to burst to it, it will disconnect after the first
data is transferred, forcing the master into single-cycle mode to
transfer the data.  This is proper behavior, because PCI doesn't
define single-address bursts.

One possible way to solve this might be to add additional C/BE
definitions to the PCI spec, so that everyone would "know" what
the score is, and allow for single-address bursts.

This subject was talked to death many months ago, with the result
that nothing was done.  You will find the keepers of the spec
remarkably resilient to change suggestions (this is not necessarily
bad, mind you -- a lot of folks depend on having something stable
to design to, warts and all 8-).

We designed around this by decoding a large block (4 MBytes) of
address sapce, and "funneling" it into the input FIFO.  This constrains
the largest block you can transfer without re-setting up the operation,
of course (no "continuous DMA" here! 8-), and tends to lead to
unnecessary "address hogging".  But hey, we've got 4 GBytes to
play with, so what's a few MBytes?

Cheers,

-- DaveN

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave New, den@aisinc.com    | Machine vision?
Applied Intelligent Systems |      I'm glad *they* can see the future...
3980 Ranchero Drive         | 
Ann Arbor, MI  48108        |        Opinions expressed are mine.    | PGP 2.6
(313) 332-7010              | 08 12 9F AF 5B 3E B2 9B  6F DC 66 5A 41 0B AB 29
(313) 332-7077 FAX
)xe