Arbiter (electronics)
From Wikipedia, the free encyclopedia
Arbiters are used in asynchronous circuits to order computational activities for shared resources to preventing concurrent incorrect operations.
Computers without Clocks by Ivan Sutherland and Jo Ebergen provides the following information on Arbiters:
- An Arbiter is like a traffic officer at an intersection who decides which car may pass through next. Given only one request, an Arbiter promptly permits the corresponding action, delaying any second request until the first action is completed. When an Arbiter gets two requests at once, it must decide which request to grant first. For example, when two processors request access to a shared memory at approximately the same time, the Arbiter puts the requests into one order or the other, granting access to only one processor at a time. The Arbiter guarantees that there are never two actions under way at once, just as the traffic officer prevents accidents by ensuring that there are never two cars passing through the intersection on a collision course.
- Although Arbiter circuits never grant more than one request at a time, there is no way to build an Arbiter that will always reach a decision within a fixed time limit. Present-day Arbiters reach decisions very quickly on average, usually within about a few hundred picoseconds. When faced with close calls, however, the circuits may occasionally take twice as long, and in very rare cases the time needed to make a decision may be 10 times as long as normal.
Contents |
[edit] Arbiters give rise to indeterminacy
Arbiters break ties. Like a flip-flop circuit, an Arbiter has two stable states corresponding to the two choices. If two requests arrive at an Arbiter within a few picoseconds (today, femtoseconds) of each other, the circuit may become meta-stable before reaching one of its stable states to break the tie. Classical arbiters are specially designed not to oscillate wildly when meta-stable and to decay from a meta-stability as rapidly as possible, typically by using extra power. The probability of not reaching a stable state decreases exponentially with time after inputs have been provided.
[edit] Arbiters in computers
Arbiters are required in computers which have multiple CPUs or other devices accessing memory, and have more than one clock. It is then possible for requests from two unsynchronized sources to come in at nearly the same time. "Nearly" can be very close in time, in the sub-femtosecond range. The memory arbiter must then decide which request to service first. As mentioned above, it is not possible to do this in a fixed time.
A reliable solution to this problem was found in the mid 1970s. Although an arbiter that works reliably in a fixed time is not possible, one that sometimes takes a little longer for the hard case can be made to work. It is necessary to use a multistage synchronization circuit that detects that the arbiter has not yet settled into a stable state. The arbiter then delays processing until a stable state has been achieved. In theory, the arbiter can take an arbitrarily long time to settle, but in practice, it seldom takes more than a few gate delay times. The classic paper is [Kinniment, Eng, and Woods 1976], which describes how to build a "3 state flip flop" to solve this problem, and [Ginosar 2003], a caution to engineers on common mistakes in arbiter design.
This result is of considerable practical importance. Multiprocessor computers will not work reliably without it. The first multiprocessor computers date from the late 1960s, predating the development of reliable arbiters. Some early multiprocessors with independent clocks for each processor suffered from arbiter race conditions, and thus unreliability. Today, it's a solved problem.
[edit] See also
[edit] References
- D.J. Kinniment, C.Eng, and J.V. Woods. "Synchronization and arbitration circuits in digital systems" Proceedings IEEE. October 1976. (Large PDF file)
- Carver Mead and Lynn Conway. Introduction to VLSI Systems Addison-Wesley. 1979.
- Ivan Sutherland and Jo Ebergen. "Computers without Clocks" Scientific American. August 2002.
- Ran Ginosar. "Fourteen Ways to Fool Your Synchronizer" ASYNC 2003.
