arbiter fairness

[frank.story@tempe.vlsi.com]

I hope no one minds, but I started a new thread for the below topic.

Its not paranoid, it is feasible and it can be resolved by the arbiter. 
Generally, todays arbiters are fairly simple and don't account for 
situations such as described by Jim. The arbiter could be made fairer 
by adjusting the priority of retried masters. Dynamically scaling 
priorities in an arbiter is a topic that has been broached at several 
PCI forums, and perhaps will eventually see the light of production.

> From: holeman@lumeria.mpd.tandem.com (Jim Holeman)
> Subject: Re: Problem w/ Matrox Millenium - Related question
> 
> SOMEWHAT RELATED QUESTION -
> 
>  On a somewhat related note concerning the behavior of host bridges -
> 
>  PCI provides for relative fairness of allowing multiple devices to have
>  access to the PCI bus.
> 
>  However, suppose that multiple high bandwidth PCI devices are attempting 
>  to burst large amounts of data to host memory concurrently.  Is possible/
>  likely/unlikely/? that these devices could
>             a) fill all of the host bridge's PCI to memory write FIFO's
>             b) cause the bridge to begin retrying subsequent PCI to memory
>                write attempts until a FIFO becomes available.
>             c) reach a quasi-stable condition in which one of the devices
>                acquires the bus writes a burst which fills up the
>                FIFO's again and releases the bus. The next device then
>                acquires the bus and is retried. The first device reacquires
>                the bus...just as the FIFO becomes available, fills it up 
>                again, and releases the bus. The second device gets retried
>                again, and so on.  Thus the first device gets its data moved
>                while the second device gets starved.
>  Is this paranoid, or is this feasible?  If so, are there any guarantees and/or
>  ways to calculate how long such a condition could last.
> 
>  thanks,
>  holeman@mpd.tandem.com


Frank Story                    frank.story@tempe.vlsi.com
VLSI Technology                602-752-6098
Computing Products Group
‡üì