VMEbus Arbitration

By John Rynearson, Technical Director, VITA

Question: How does VMEbus arbitration work?

VMEbus supports multiple masters. Since the VMEbus is a shared resource, each master must be granted the bus so that no two masters can drive the bus at the same time. This is called bus arbitration.

The Early Days

When the VMEbus was young most systems contained a single processor board and the VMEbus was used for simple address/data accesses to memory and peripherals. Life was simple because all interrupts were handled by the single processor board and the memory map from the VMEbus’s viewpoint was the same as the memory may from the single processor board. Arbitration was simple too. When the system booted up, the single processor board asked for the bus, got it, and then just kept it forever.

While VMEbus systems can still operate this way, many applications now require multiple processors to meet real-time requirements.

One CPU, Two CPU, Three CPU, and more....

Demanding applications today require concurrent operations. Since the VMEbus supports arbitration and multi-master systems, it is a natural for multi-processor applications. However, having more than one processor in a system makes configuration even more important. The right choices mean the system will meet it goals and provide reliable operation while the wrong choices mean that the system will perform poorly if at all. In multi-processor systems only one master can used the bus at a time. The VMEbus specification offers a number of choices for acquiring and releasing the bus.

Arbitration

The VMEbus can support up to 21 masters in a system. Since VME only provides four separate bus request levels and allows two or more masters to request the bus at the same time on the same request level, proximity to slot one is used to determine who gets the bus next. Thus if a master in slot 3 requests the bus on bus request level 1 and a master in slot 7 requests the bus on the same level at the same time, the board in slot 3 will see the daisy chained grant line first and will take over the bus. The requesting master in slot 7 will have to wait until the master in slot 3 is finished. Then assuming no board in slots 1 through 6 is requesting the bus, the master in slot 7 will receive the grant signal and take over the bus.

The system controller function, always located in slot 1, must provide all the arbitration functions. Arbitration can be set up for priority mode, round robin mode, or single level mode. Priority mode gives priority to bus request level 3, then 2, then 1, and finally 0. If a bus request of higher priority is received, the arbiter on the system controller asserts the BCLR* (Bus CLeaR) signal telling the current master that a board with higher priority wants the bus. The VMEbus standard does not specify how long the current master can retain the bus. It is up to the system designer to make that decision. The VME64 standard states:

If the current master is performing a complex task that must be completed before bus mastership is given up, then it may retain the bus until the task is completed. The system designer must determine whether or not keeping the bus to complete a task will degrade overall system performance. Usually the BCLR* signal is connected (via a jumper or a programmable register) to an on-board interrupt line on each master. When the BCLR* signal is asserted, the on-board interrupt informs the master that some other board wants the bus. It is at this point that the system design makes the decision regarding when bus tenure will end. Priority mode is good for systems with many background tasks that can be carried out at a low priority, but can be safely suspended for occasional high priority tasks.

Besides priority mode, the arbiter can also be set up to run in round robin mode. In this mode the bus is granted to bus request levels 3, 2, 1, and 0 in sequence without regard to priority. This mode works well for applications that have tasks of equal priority and bus allocation on an equal basis is the goal.

Releasing the Bus

When releasing the bus, boards can use one of two modes: RWD (release when done) and ROR (release on request). RWD means that the board gives up the bus when it determines that a specific task is completed. It usually gives up the bus by writing to a status register that deasserts the BBSY* (Bus BuSY) signal allowing another board to arbitrate for and be granted the bus. ROR, on the other hand, is used by a board which constantly monitors the bus request lines (BR3* through BR0*). In ROR mode, a board will keep the bus as long as none of the bus request lines are asserted. When one or more bus request lines is asserted, then in ROR mode, the board will give up the bus on the next cycle. Usually this bus release mechanism is implemented in hardware and software intervention is not required. ROR mode is good for systems where specific tasks can be easily suspended and then restarted. Since ROR is released via hardware it is faster and reduces software overhead.

Fairness

But what happens in a heavily loaded system with many masters that all want the bus often. In such a system the first four boards closest to slot one can hog the bus. Other boards further away from slot one may become bus starved. To prevent this situation, bus requesters can be programmed to only request the bus when the bus request lines are not asserted. Operating in this manner is called FAIRNESS and is supported by most current high performance CPU boards. FAIRNESS insures that all boards even in a heavily loaded system eventually get the bus.

In simple VMEbus systems a single level arbiter (SGL) can be used. It only monitors bus request level 3 and ignores bus request levels 2, 1, and 0. System designers are cautioned to be sure that the board they choose to be system controller contains the functions that they require. Some boards will claim system controller capability when they only support SGL.

Summary

In a multiprocessor system it is important to match the application requirements with the appropriate arbitration modes. Priority and round robin modes are available, and modules can release the bus under software control or via hardware. The system designer must select the arbitration modes and release mechanisms that furnish the best system operation.

This page last updated: Sep 19, 1999

Reprinted from the VITA Journal with permission from VITA.

Return to the main VMEbus FAQ Page