🚀 go-pugleaf

..> Distributed arbitration...

I go both ways on this. 
I have worked with several systems where bus arbitration time
was one of the principal bottlenecks. IE. full bus bandwidth
could never be acheived in a real system because (1) all those
asynch signals were being synchronized, and (2) the system
spent much of its time asking "please can I use the bus"
instead of actually using it.

Nubus distributed arbitration seems simple enough, but the wave
form of scheduling probably is not acceptable to hard real time
(fixed priority) scheduling (see Shan "a bus access should be
scheduled at the same priority as a bus access").

Futurebus+ distributed arbitration seems to further complicate things.
Potentially all of the bits in the arbitration code can flip
- at least O(N).  All are asynch signals.... because its distributed,
seems to me that you are limited by the response time of the *slowest*
arbitration logic in the system.   I shudder at the thought of trying
to assemble a system for a customer, customized with a single
board, available from only one vendor, and finding out that this crucial
board synchronizes all bus signals to a 4MHz clock. Ouch!
Other things that scare me about FUTUREBUS+ distributed arbitration
include the long and short arbitration cycles.  And another arbitration
mode is proposed as an improvement! And all of the priority manipulation
rules...

What we need is a distributed arbitration scheme that
(1) is positive - instead of waiting for a potentially long time
interval for stability of of the arbitration code, grants when
all contestants acknowledge the same winner (ok, that's already been done)

(2) is fast in special circumstances - like idle bus (without requiring
a special arbitration mode)

(3) supports stripped down priority manipulation (like, none)
in systems where it is appropriate.