dave@dtg.nsc.com (David Hawley) (12/20/89)
In article <38508@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > The one word that keeps coming up wrt Futurebus+ is *Arbitration*. > I am repeating what I have heard, but have no independent knowledge myself. The basic Futurebus+ arbitration protocol uses 3 asynchronous handshake lines to generate 6 bus states. The transitions are caused by: State 0 (Idle) -> 1 First board with a bus request. State 1 (Bus Request) -> 2 Last board to react to requests. State 2 (Arbitration) -> 3 Winning competitor. State 3 (Error Check) -> 4 Last board to react to error, or master's transition to disconnection phase. State 4 (Xchg Mastership) -> 5 Master, on completion of bus transaction. State 5 (Update Status) -> 0 Last board to update internal state. A new master can begin transfers in State 5. The arbitration timing in State 3 is based on the speed of winner's logic relative to that of any other competitors; it can be optimized for the arbitration number that is being used by the board. The rising edges for the transitions out of States 1, 3, and 5 require delays to account for wire-OR glitch effects on the backplane (5-15ns, depending on backplane length). Arbitration takes place in parallel with data transfers, so in many cases the arbitration time may be hidden. If there is usually only one master in the system, rearbitration is not necessary to reuse the bus (the current master "parks" on the bus if there is no new request). However, in a multi-master system where the bus is usually idle, the inevitable latency may be unacceptable. An idle-bus arbitration protocol (devised by John Theus) can be used to supplement the basic arbitration protocol; if only one board is competing for the bus, it can begin transfers as early as State 2 above. In a heavily-loaded parallel processing system, the degree of fairness may become more important than the arbitration latency; in the design of a real-time system, the degree of schedulability (number of priority levels available) may be more important for overall system performance. The (CISC) Futurebus+ protocol provides both of these. In any system, the relative transaction length and overhead must be considered as well. So does it look like you can get decent performance out of this? What are your major concerns? What type of arbitration system would YOU design? What are its drawbacks? \"""/ Dave Hawley [o.o] National Semiconductor Corp. dave@dtg.nsc.com - \O/ - (408)721-6742
fenton@trantor.harris-atd.com (S. Fenton McDonald) (06/07/91)
Question:
Where can one obtain a copy of the specification for the Futurebus+
Logic Layer, P896.1? I read that this document is out for a 30-day
review.
Please mail all responses to my address above--I don't always catch
everything on the net.
--
S. Fenton McDonald fenton@trantor.harris-atd.com
Harris Corp. Office (407) 727-5739
Fault Tolerance..........What a concept!