The Dragon arbiter chip is part of a Dragon computer system. There is one arbiter chip on each Dragon board, located physically near the board-to-backpanel interface. The main function of this set of identical chips is to control time-multiplexed access to the DynaBus, Dragon's main data bus.

The arbiter implements six discrete priority levels. Dynabus access is always granted to a requester requesting at highest priority. Within each major priority level, there is the concept of precedence. Precedence is assigned on nearly a round-robin basis. Within each arbiter, and separately at each priority level, the last grantee device has lowest precedence. Likewise, at each priority level, the last grantee arbiter has lowest precedence.

Each arbiter has eight device request ports. Each of these ports can have up to three requests pending, of two types each. Associated with each type is a priority level [0..7) and a packet length (2 or 5 cycles). These sixteen parameter pairs (8 requesters x 2 types) are loaded into the arbiter during system initialization via the DBus scan path.

Smaller priority numbers have more urgent priority. This convention assigns the priority value 7, corresponding to an unconnected, passively-pulled-up port, the least urgency. In fact, 7 means NoRequest.

The two types of request at a single port are called L and H. The priority number assigned to type L must be no smaller than that assigned to type H, because within a single request port a type H request is preferred over a type L request independent of the priority numbers assigned to them.

There can be at most eight arbiters in a Dragon system. These arbiters exchange priority information across the system backpanel. Each arbiter drives one three-bit port and receives the other seven. A fixed pinout for output and input ports is implemented by rotating the inter-arbiter wiring, a nice trick suggested by J. Gastinel.

The arbiter also computes system-wide shared and owner, and serves as DBus address decoder.

During system initialization, the system DBus controller must load into each arbiter the priority level and packet length associated with both types of request for each of its eight request ports.

It is helpful here to consult ArbiterImpl.mesa, the Rosemary RTL simulation of the Arbiter. This can be found in [Indigo]<Dragon>Top>Arbiter24.df. Italics are used to indicate pipeline registers.

0: drqIn[i] in arbiter j is loaded from the DRQ[j][i].Req wire pair, which carries a request from arbiter j's requester i.

1: At this stage, each requester i is handled independently. The request counters, one for each type t, drqCtrs[i][t], are updated with new counts that reflect the contents of drqIn[i] and grants from stage 4. The hold flipflop, drqHold[i], is updated. The best request for a port, together with its type and length, are registered in drqPrior1[i] and drqInfo1[i].

2: At this stage the separate requests i of arbiter j are combined to form a common request, arbReqOut[j].

3: All arbiters exchange priority information over the backpanel using the ArbReq wires, and LastCycle, and these are recorded in arbReqIn and lastCycIn, which are identical in all arbiters.

Each arbiter computes the identity of its own best requester, taking both priority and precedence into account. This requester is coded in unary form in bestDev, and its type and length are recorded in bdInfo3[j].

4: The information in bdInfo3[j] is sent to all requesters attached to arbiter j on DHiPGrant[j] and DLongGrant[j]. Requesters can use this information to set up multiplexers in anticipation of receiving grant in the next cycle.

Each arbiter decides first whether a grant will be made at all, globalGrantStart, and second whether the grant will be made to itself, localGrantStart. The priority of the winning request is computed on all arbiters, and the winning arbiter computes dGrant, a unary encoding of grantees.

The unary-coded representation of the best local device from the previous stage, bestDev is re-coded in binary and stored in bestDevCoded.

The number of cycles remaining in the current local grant, localBusCyclesLeft, is computed, and LastCyc is asserted FALSE if necessary.

5: The winning arbiter communicates dGrant as DRQ[j][i].DGrant to all devices on its board.

The board rover pointer, arbRovers[p], for the winning priority level is recomputed identically in all arbiters.

The device rover pointer, devRovers[p], for the winning priority level is recomputed only in the winning arbiter.

The DBus isn't right yet.