Re: PCI arbiter implementation

[kevin.normoyle@Eng.Sun.COM (Kevin Normoyle)]

> I am considering implementing a PCI arbiter for 4 PCI bus masters, in
> a programmable logic device. (ie Altera, Xilinx etc)
 


This reminds me of a question I have, which may have already been addressed 
here. (sorry if so)

Assume, say, 4 PCI devices, each trying to send writes to a memory controller.
Whenever the memory controller's buffers back up, it forces any new
writes from PCI to retry. 

These PCI devices release their request whenever
they are forced to retry. (this is pci protocol, right...)


With enough requestors going at the same time on the bus, one or more
devices can be starved, and never successfully complete a transaction.

i.e.  with the right relationships between
retry latencies, write transactions, and memory controller behavior,
one PCI device could lock out another PCI device.
(with a simple round-robin arbiter)


The memory controller may force a retry time and time again to the same 
transaction request because in between each retry it took another transaction 
from someone else.

The same problem exists for any bridge with finite
thruput that's less than peak PCI thruput, or any target with finite
thruput with finite thruput that's less than peak PCI thruput.

(reads don't cause the problem because since the bus is circuit-switched,
so they don't create post-transaction behavior at the bridge. writes do)


The problem is that the devices don't keep their request asserted
between retries, (apparently there are deadlock issues if they
do) and there is no requirement for adaptive state that gives
devices that were retried higher priority.

Basically the problem is inherent in the bus arbitration protocol.

Alternatively, if the target accepts 1 more address whenever it's "full",
and it doesn't retry for a certain latency, (enough to cover the
time needed for space to be created for the data transfer), 
then you can have fairness...although it might not be best for the bus thruput,
if the possiblity of transactions to other devices exist while waiting for
this target to make room. 

But that's just a more involved case that can have the same problem
under the right circumstances.


It seems that the problem is that pci arbitration is not "stateful", 
i.e. if a transaction is retried, it gets thrown into the pool
of equal priority requestors again.

Now I understand that the general case requires the retried transaction
to not get a constant grant, because of deadlock issues. (in case
the retry is do to address locking, or a target has to get the bus
to do some master stuff before it can accept an IO transaction as
a target etc....)

But for basic flow control, it seems like there should be a fairness
algorithm built into the arbiter (requires some state since requests
are forced to be deasserted).

This is a basic arbiter/fairness issue, that has been addressed specifically
over the years by other shared bus architectures. Is it just ignored here
or am I missing something key?

comments? (i am not an expert on pci issues, so go easy on me)

-kevin
(sorry if so)

³