Datasheet

heetVME Bus Arbitration Using a GAL® 22V10
Introduction
The GAL22V10 provides a quick solution to bus arbitration and control needs. In this application note, we discuss how a VME bus arbitration circuit can be easily implemented within a GAL22V10, while leaving logic available on the GAL for other functions. In any bus-oriented system, there may be multiple devices that need exclusive accessto the bus. You need to provide some form of arbitration, ensuring that only one device has control of the bus at any point in time. This arbitration function is an ideal candidate for a GAL-based solution. For this example, we have chosen the VME bus standard and describe an approach for a GAL22V10 VME bus arbiter, including the ABEL source code for programming. Figure 1. The Bus ArbitrationProcess

Master 1

Master 2

Slave

Arbiter

BR(3:0) BG(3:0) BBSY BCLR

The bus arbitration process is defined in the following steps (the level of a bus master indicates which bus request line it used to gain access to the bus): 1) A bus request signal (BR3:0) is received by the arbiter. 2) If the bus is not busy, the arbiter returns a corresponding bus grant (BG3:0) 3) If the bus is busy,the arbiter asserts a bus clear request (BCLR) as long as one of the following conditions is true: • The current bus master is level 2, 1 or 0, and the active bus request line is 3 or 2. • The current bus master is level 0, and any other device is requesting the bus This protocol allows a higher priority device to take control of the bus in an orderly manner — the arbiter asserts BCLR, thecurrent bus master releases BBSY, and then the higher priority device gains control of the bus. Also note that if the current bus master is 3, then the arbiter gives control to another level 3 requester only when BBSY goes inactive — in other words, a level 3 master will be allowed uninterrupted access to the bus.

Design Example
A VME-based system is a good example of a bus that supports multiplebus masters, by requiring bus arbitration logic on the bus to resolve possible conflicting requests. The VME bus has a bus request line that a device asserts when it wants to gain control of the bus. The arbiter prioritizes these bus requests and asserts a bus grant to the device with the highest priority. Since you may wish to give some devices higher priority to bus access than others, the VME busprovides four bus request lines, with BR3 designated as the highest priority request, and BR0 as the lowest priority request. And since you may have more than four devices on the bus, or you may want to have more than one device sharing the same priority level, the bus standard must also support multiple masters with the same priority level. The VME bus allows more than one device on the bus toshare a bus request line by “daisy-chaining” the bus grant signal — the device physically closest to the bus arbitrator “sees” the bus grant first. If this device didn’t generate the bus request, then the bus grant is allowed to proceed to the next device on the bus. Figure 1 shows a simplified block diagram of a VME system, showing the handshaking between the arbiter and the other devices on thebus.

ABEL Source
The following is an ABEL source file that implements a VME bus arbiter in a GAL22V10. Note that the internal signals, Master1 and Master2, are used to hold the level of the bus request currently being served.

an9008_01

1

July 1997

VME Bus Arbitration Using a GAL22V10
Example 1: Module Arbiter Title Bus Arbiter with Priority Handling for GAL22V10 LatticeSemiconductor' Declarations arbiter device ‘p22v10’; “Inputs CLK !BBUSY !BR0,!BR1,!BR2,!BR3 !RESET !OE “Outputs !BCLR !BGIN0,!BGIN1!BGIN2!BGIN3 MASTER1,MASTER0 pin pin pin pin pin 1; 2; 3,4,5,6; 11; 13;

pin 23 istype ‘invert,reg_d’; pin 22,21,20,19istype 'invert,reg_d’; pin 15,14 istype ‘buffer,reg_d’;

MASTER = [MASTER1, MASTER0]; C, X, Z, L, H = .C., .X., .Z., 0, 1; Equations BGIN3 BGIN3.C BGIN3.AR...