THE ARBITER
THE ARBITER
THE ARBITER
1
1
1
THE ARBITER
Ed McCreight and Lissy Bland
Dragon-88-01 January 1988 
© Copyright 1988 Xerox Corporation. All rights reserved.
Keywords: abiter, Dragon, DynaBus access, serial access, Device Request Ports, DBus controller, OR functions
Maintained by: Bland.pa
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
THE ARBITER
1.0 Brief Description
The Arbiter serializes accessses to the Dynabus among 64 potential requesting devices. It is designed to work with up to 7 other identical chips; together they implement a distributed arbiter function. The arbitration system follows rules of priority and precedence in making grants to requesting devices. There are are 6 discrete priority levels, with 0 being the most urgent and 6 the least urgent. Priorities 2 and 7 are illegal. Access is always granted to the requester at the most urgent priority. The rule of precedence assures that when there are multiple outstanding requests at the same highest priority level, the arbiter approximates a round-robin order in granting requests.
Because there is one arbiter chip on each Dragon board and because the arbiter has available pins, it also implements 2 other functions: First, it acts as a DBus controller for its board. And second, it performs the OR function for the Owner, Shared, and Synchronous Stop bits.
2.0 Pin-Out
[Artwork node; type 'Artwork on' to command tool]
Figure 1: The Logical Pin-Out of the Arbiter.
3.0 Block Diagram of the Chip
[Artwork node; type 'Artwork on' to command tool]
4.0 Detailed Description of Each of the Functional Blocks
There is one arbiter chip on each board, located near the board-to-backpanel interface. Devices always communicate with the arbiter on their board.
4.1 Requesting Device - Arbiter Communication
4.1.1 The Device Request Ports
Each arbiter chip has 8 Device Request Ports. Each requesting device is connected to a particular Device Request Port. During system initialization, the Device Request Ports are loaded with a 9-bit record that describes their requesting device. This 9-bit record, pictured in Figures 1a and 1b, contains the type of the requesting device, and values for request priorities and lengths.
Requesting devices are of 2 types, the normal type and the memory type. Normal devices can make requests at 2 priority levels, high and low. All high priority requests for a device are exhausted before any of its low priority requests are granted. Memory type devices always make requests at the same priority level; however, requests may be of two different lengths: 2 or 5 cycles. The arbitration system guarantees to grant these requests in the order received.
Requesting devices communicate to their arbiter over 2 wires, nRequestOut[0..1]. The 4, bit combinations for nRequestOut[0..1] have the following meanings:
Normal Device
0 (HH): Release this device's demand for system-wide hold, if any
1 (HL): Demand system-wide hold
2 (LH): Add a Low priority request
3 (LL): Add a High priority request
Memory Type Device
0 (HH): Release this device's demand for system-wide hold, if any
1 (HL): Demand system-wide hold
2 (LH): Add a request for a 2-cycle packet
3 (LL): Add a request for a 5-cycle packet
Depending on the type of the requesting device and the bit pattern that the requesting device has sent, the arbiter determines the priority and length of the request. For example, if a Normal Type Device sends a 3 (High priority request) to its Device Request Port, the arbiter looks in the High portion of the Device Request Record to learn exactly what a high priority request for that requesting device means as well as the length of the request. (The reason for this indirection is to keep the number of pins that requesting devices must reserve for communication with the arbiter to an absolute minimum.)
Note: If one or more of the arbiter's Device Request Ports is not connected to a requesting device, the extraneous Device Request Port or Ports think that they are constantly receiving a 0 (clear system-wide hold) from their (non-existant) requesting devices.
[Artwork node; type 'Artwork on' to command tool]
Figure 1a: The information encoded by the 9-bit Device Request Record for Normal Devices. (ArbDBus.sch shows the loading of the this information from the DBus as the DPriority wires. InputFSM.sch shows the interpretation of the Device Request Record wires from the DevPriority wires.
[Artwork node; type 'Artwork on' to command tool]
Figure 1b: The information encoded by the 9-bit Device Request Record for Memory Type Devices. The 3, high-order bits are not used.
Each Device Request Port has two counters, each of which can count up to 6 outstanding requests. One counter is for high priority requests (ICtrFIFO.icon in the InputFSM.sch); the other is for low priority requests (InputCtr.icon in the InputFSM.sch). If the Device Request Port is connected to a Memory Type Device, only the counter for low priority requests is used. This means that Normal Devices can accumulate up to 12 requests while Memory Type Devices can accumulate only 6 requests. (Note that the arbiter actually computes the MIN of the number of outstanding requests and the number 6 to determine the number of outstanding requests.)
Application Note: The arbiter's counters, that only note up to 6 outstanding requests, may or may not require requesting devices to implement additional logic. For example, a processor that simply stops processing information until it receives a reply to its single outstanding request, need not implement any special logic to avoid building up a queue that contains more than 6 outstanding requests. However, other requesting devices, including the display and memory controllers, will need to carefully control their queues of outstanding requests.
The arbiter uses two mechanisms to help requesting devices control the number of outstanding requests. First, replies are assigned high priority levels (0-1), and queries are assigned lower priority levels (3-6), so that eliminating the queue is higher priority than filling it. And, second, if any device queue is filling up, the device can assert Hold. While Hold is asserted, no new queries can be registered; however, replies can go out. Thus, the Hold mechanism permits slower devices, like memory controllers, to limit the number of new requests that can accumulate while waiting for the information needed for earlier requests to become available.
4.1.2 The Best Local Request
The logic in ComPipe2.sch selects the best local request among the devices connected to a particular arbiter. PE-8-3-Hold.icon (PE = Priority Encoder) finds the minimum priority level among the abiter's 8 requesting devices. AmongBest.icon identifies all devices that have a request pending at this minimum priority level. The arbiter sends this priority level to the other arbiters as ArbReqOut[0..2]. In addition, the arbiter remembers to which requesting device at that minimum priority level it would give the grant if it were allowed to make a grant. If more than 1 device is requesting at the minimum priority level, the arbiter follows a clockwise round-robin order in making grants.
4.1.3 The Grant
When an arbiter has permission to make a grant, it notifies a particular requesting device over its nGrant wire. There is one nGrant wire for each device request port, for a total of 8 nGrant wires. These wires are named nGrant[i] where i is the number of the Device Request Port. nGrant[i] is asserted during every grant cycle to Device Request Port[i]. An arbiter can make back-to-back grants to the same requester, but the current arbiter implementation will not be able to follow a 2-cycle grant immediately with another grant to any device attached to the same arbiter because that arbiter needs a cycle to update itself before making another grant.
In addition, there are circumstances that require 1 dead cycle on the DynaBus following a 2-cycle grant as the following scenario explains:
1. Arbiter A received a 2-cycle grant at prioirity 0 or 1.
2. While Arbiter A has the DynaBus, the other arbiters look for another priority 0 or 1 request.
 If they find a priority 0 or 1 request, that request can be granted if nBusyIn is not asserted during the 3rd cycle following the previous grant.
 However, if the other arbiters cannot find a priority 0 or 1 request, they must delay making a grant for one cycle while Arbiter A updates its ArbReqOut wires to reflect its new minimum priority. This is true because it is possible that Arbiter A's next best priority is 2 (Set Hold). If Arbiter A were not allowed to assert this Hold, it is possible that a request coming from another arbiter to one of Arbiter A's requesting devices would overflow that requesting device's queue.
Each arbiter communicates additional information to its requesting devices about the grant that it would make (if it were allowed to make a grant) one cycle before the grant would be made. This information is sent over 2 wires. The requesting devices may choose to utilize or ignore this information.
1. nHiPGrant is an Output wire that is asserted one cycle before the first cycle of a grant iff the arbiter is responding to a high-type request from the requesting device. At all other times the state of DHiP is undefined.
2. DLongGrant is an Output wire that is asserted one cycle before the first cycle of a grant iff the arbiter is responding to a long-packet (5-cycle) request from the requesting device. At all other times the state of DLongGrant is undefined.
After making the grant, the arbiter updates its local precedence pointer for requests of that priority. Finally, it decrements the appropriate request counter.
4.2 Inter-Arbiter Communication
There can be at most eight arbiters in a Dragon system. These arbiters exchange priority information across the system backpanel. In the maximal configuration, an arbiter drives one 3-bit, Input/Output port, ArbReqOut and receives information from the other seven arbiters over the OtherArbInT[7 x 3] wires. Together, ArbReqOut[1 x 3] and OtherArbInT[7 x 3] are known on the backpanel as InterArb[8 x 3]. If no device is requesting service from particular arbiter j, the value of InterArb[j] is 7, NoRequest. If any of the arbiter's requesters is asserting Hold, it is as if that arbiter is instead making a request at priority value 2, Hold.
4.2.1 The Best Global Request
The logic in ArbPipe4.sch finds the best global request. Each arbiter has two precedence pointers for each priority level, one local and one global. These precedence pointers are initialized over the DBus during startup. Every time a request is granted at a particular priority level, each arbiter updates its global precedence pointer for that priority level, and if the grant was to one of its requesting devices, it updates the local precedence pointer as well.
The updating of the global precedence pointers takes advantage of the configuration of the arbiters. It is as if the 8 arbiters are in a circle. Each arbiter knows which other arbiters is its nearest clockwise neighbor (one hop away), which is next nearest (two hops clockwise), etc. When the precedence pointer for each priority level is initialized during startup, each arbiter learns that the precedence pointer is x hops away clockwise, where x = 0 means that that arbiter holds the precedence pointer. The arbiters must be numbered so that the arbiter that is one counter-clockwise hop from the arbiter holding the precedence pointer is arbiter 1, etc. (See Figure 4). After initialization, it is responsibility of each arbiter to keep track of the precedence pointer as it moves around the circle.
[Artwork node; type 'Artwork on' to command tool]
Figure 4: The numbering and configuration of the arbiters.
4.2.2 The Grantee
Because the minimum length grant is 2 cycles, all arbiters know that for at least 2 cycles after a grant is made, no further arbitration may take place. If the arbiter that received the grant needs the bus for more than 2 cycles, it asserts nBusyOut until it is nearly finished. nBusyOut is received by all arbiters as nBusyIn. This implementation of nBusyIn means if future arbiters have other packet lengths greater than 2 cycles, the current arbiters should work correctly with them.
4.3 DBus Functions
4.3.1 Initialization of the Arbiters
System initialization takes place over the DBus. The DBus is used to initialize the configuration of the arbiters. The DBus address to access the arbiter DBus registers is bbbb 0000 0000 0ppp where bbbb is the slot number (equivalent to SlotNo[0..3]) and ppp is the Path Number. The Path Number specifies a path to a particular shift register on the specified device. Data is transferred serially to the specified shift register over the DBus's DSerialIn wire; the most significant bits are loaded first. For the arbiter the following values for the Path Number are defined:
000:
 Chip Identification register (ChipID), Read Only, 16 bits. (Type 1, currently version 1)
001:
 Device Request Ports Configuration register (DRPC), Read/Write. There are 8 ports. Each is 9 bits wide, for a total of 72 bits. The most significant 9 bits are are for port 0. The least significant 9 bits are for port 7. (Figure 1 illustrates how the information the Device Request Port Record is encoded.)
010:
 Arbiter Configuration Register (ArbCnf), Read/Write, 4 bits. The least significant bit, (HySelDec), controls the hybrid selection logic (c.f. Section 1.3.2). The 3 most signficant bits specify the number of the arbiter (ArbNo). Note that all arbiters in a system must be loaded with different numbers and that the numbers must correspond to the wiring pattern of ArbReq.
011:
 Board Identification Register (BoardID), Read Only, 2 bits. This register is loaded from the BdVersion pins whenever an arbiter configuration register is not accessed. It may be read to recover the board version. The connection pattern between BdVersion wires and nDHybridSel wires plus Vdd and Gnd is used to encode information additional information about the board including: revision number and board type. (See BdVersion[0..1] in 5.0)
4.3.2 Address Interpretation for Hybrids
The arbiter performs part of the address decoding for the DBus on a board. Whenever a DBus address of the form bbbb xxxx xxxx xxxx is transmitted on the DBus (bbbb is the board slot number) the arbiter drives its DHybridSel[i] lines according to the following algorithm:
HySelDec=L: =bbbb hhhh hxxx xxxx => DHybridSel[i] = (hhhhh ' 24-i) ¬= 0.
HySelDec=H: =bbbb hhhh xxxx xxxx => DHybridSel[i] = ((hhhh MOD 16) = i + 1) ' ¬DAddress.
If xxxx is 0000, the all the DHybridSel lines are forced to 0.
If HySelDec is low the final stage of decoding must be done in external logic, but more decoded values are possible.
4.4 OR Functions
The arbiter performs the OR function for the Synchronous Stop, Shared, and Owner bits. The algorithm used in performing this 64-way OR is illustrated in Figure 5. Shared.sch contains this logic. Here are the 5 steps.
[Artwork node; type 'Artwork on' to command tool]
Figure 5: The algorithm used for computing the OR function.
(1). Each arbiter computes the 8-way OR of the Shared (nSharedOut) and Synchronous Stop (nSStopOut) wires from its own requesting devices. Each arbiter notes whether Owner (nOwnerOut) has been asserted by one of its requesting devices.
(2). Each arbiter sends the results of (1) to all the arbiters (itself included) as nBSharedOut, nBStopOut and nBOwnerOut.
(3). Each arbiter receives the 8 values for nBSharedOut and nBStopOut on its 8 nBSharedIn and nBStopIn wires. It notes whether owner has been asserted on its nBOwnerIn wire.
(4). Each arbiter communicates the result of the 64-way OR to its requesting devices over its atomic nSStopIn, nSharedIn and nOwnerIn wires. Because these are atomic wires, requesting devices are notified sequentially.
(5) . Finally, in the case of Synchronous Stop, each arbiter tells itself to stop by sending nSStopIn to itself as nStopAct.
4.5 Starting the Arbiter
The arbiter system starts by using the interaction between Reset and Synchronous Stop. Here are the rules:
(1). Assert Reset This takes about 10 cycles.
(2). Assert Reset and Synchronous Stop simultaneously. The arbiters begin listening for requests but nobody is making any requests.
(3). Release Reset but hold Synchronous Stop. At this point all other devices in the system begin making requests.
(4).  Release Synchronous Stop. At this point the arbiters start making grants.
5.0 Detailed Description of Each Pin
Pin Name I/O Pin Description
nRequestOut[0..1] I These 8 x 2 wires are used by requesting devices to communicate to their arbiter. See Section 4.1.1 for a complete explanation of their use.
nGrant O The arbiter uses these 8 x 1 nGrant wires to respond to requesting devices. nGrant is 1 during every grant cycle to its particular port and 0 otherwise.
nSStopOut  I These 8 x 1 wires are used by requesting devices to initiate a Synchronous Stop.
nSharedOut  I The 8 x 1 nSharedOut wires are used by requesting devices to communicate to their arbiter whether they think that a particular real DBus address refers to data present in multiple caches.
nOwnerOut I nOwnerOut is asserted by a requesting device if it is the owner of a particular address.
nHiPGrant O This wire is asserted one cycle before the first cycle of a grant if the arbiter is responding to a high-type request from the requesting device. At other times the state of nHiPGrant is undefined.
nLongGrant O This wire is asserted one cycle before the first cycle of a grant iff the arbiter is responding to a long-packet (5-cycle) request from the requesting device. At other times the state of nLongGrant is undefined. 
nSStopIn O nSStopIn is the OR of all 8 nBSStopIn wires, delayed by a pipeline stage.
nSharedIn O nSharedIn is the result of ORing the 8 nBSharedIn wires, delayed by a pipeline stage. Each arbiter uses nBSharedIn to tell its requesting devices whether a particular real address is or isn't shared data.
nOwnerIn O The arbiter transfers the value of nBOwnerIn to nOwnerIn and distributes it to each of its requesting devices.
  
  Note that for Synchronous Stop and Shared the arbiter performs the Or function and provides a intermediate storage in the pipeline. For Owner, the wires themselves perform the OR, so that the arbiter's role is reduced to that of providing intermediate storage in the pipeline.
DSerialOut O When DSelect is asserted, DSerialOut sends information from a specified register on the arbiter to the DBus. (This is a Tri-state wire.)
DSerialIn I The arbiter's internal registers receive input from the DBus via the DSerialIn pin.
nDReset O When nDReset is asserted in conjunction with ¬Synchronous Stop for 10 clock cycles the arbiter resets to ready if for operation.
nDFreeze O unused
DExecute O DExecute asks the arbiter to perform an execute cycle instead of a a data/address transfer on the next positive edge of DShiftCK.
DAddress O DAddress indicates that the DShiftCK cycle is transferring address bits. Components are implicitly deselected when DAddress is asserted.
DShiftCK O DShiftCK is the Shift clock for the currently selected scan path. Data is transferred on the positive edge of this signal. If the DAddress line is active, the DShiftCK is used to transfer component address bits instead of data bits. The implication is that DSerialIn, DExecute and DAddress are guaranteed stable by the DBus controller for many nanoseconds after the rising edge of DShiftCK.
nDHybridSel[0..4] O These 5 bits are used to select a particular hybrid on a board. They are used in one of two ways depending upon the value of the HySelDec bit of the arbiter configuration register . If HySelDec is True, nDHybridSel is used in decoded form; that is, if a wire is high, it selects the corresponding hybrid on the board. If HySelDec is False, nDHybridSel is used as a 5-bit binary number that an external decoder uses to determine the which hybrid on the board is selected.
  
  In addition, nDHybridSel is used in combination with BdVersion to encode the type of the board. (c.f. BdVersion)
DBdSel O The value of DBdSel is computed by the following equation:
DBdSel = ((SlotNo = the 4 high-order bits of the internal DAddress register) ' ¬ DAddress). When true, DBdSel indicates that communications from the DBus are intended for this board.
SlotNo[0..3] I  An integer from 0..15, that is communicated tfrom the Backpanel that uniquely encodes the position of the arbiter in the machine.
BdVersion[0..1] I A number from 0..3. The connection pattern between BdVersion wires and nDHybridSel wires plus Vdd and Gnd is used to encode information additional information about the board including: revision number and board type. Note that there are 49 (72) possible connection patterns most of which have no meaning at this time.
CKOut O CKOut is used in the clock skew elimination scheme that is implemented by the clock generator.
Clock I This is the DynaBus clock.
RecAdj I RecAdj is an approximately 3V analog signal that sets the threshold on 2V external logic receivers.
ArbReqOut[0..2] O This is a three-bit field that carries the minimum (best) priority level at which a particular arbiter has any device requesting.
OtherArbInT[0..20] I These 7 x 3 wires are used to communicate the highest priority request that is pending with each of the other arbiters in the system. Each group of 3 wires corresponds to ArbReqOut wires for one of the other 7 arbiters in the system.
nBusyOut O nBusyOut is asserted by the arbiter holding the grant until it is nearly finished. It is connected to the nBusyIn wire. (nBusyOut is needed because the length of grants, 2 or 5 cycles, is not known.)
nBusyIn I nBusyIn is connected to nBusyOut. When it is not asserted, the arbiters are free to make another grant.
nBSStopOut O nBSStopOut is the OR of all 8 nSStopOut wires. When a device requests a Synchronous Stop, its arbiter sends nBSStopOut to all 8 arbiters (including itself).
nBSStopIn[0..7] I The 8 nBSStopIn wires receive values from the 8 nBSStopOut wires (one from each arbiter). The OR of these 8 wires determines whether a Synchronous Stop should occur.
  Note that Synchronous Stop can be asserted anywhere in the machine. Very shortly after it is asserted the arbitration system stops making grants, but will continue to accumulate requests. When Synchronous Stop is released, the accumulated requests will be granted. Synchronous Stop can be used to help debug the machine by stepping the machine 1 transaction at a time. This is done by asserting Synchronous Stop, then releasing Synchronous Stop for 1 cycle before reasserting it. N.B. This will be true when the bus in the first implementation is fixed. The fix is contained in [Indigo]<Dragon7.0>Arbiter25>ArbSysTests.mesa.
nBSharedOut O nBSharedOut is the OR of the 8 nSharedOut wires. Each arbiter sends nBSharedOut to all 8 arbiters (including itself), in order to determine the number of cached copies that exist for a particular real address in memory.
nBSharedIn I The 8 x 1 nBSharedIn wires are connected to the 8 nBSharedOut wires (one from each arbiter). The OR of these 8 wires determines whether a particular real address is shared data. Each arbiter is able to send out a nBSharedOut for one transaction and compute the OR of the 8 nBSharedIn for the transaction that is one stage further in the pipeline during the same cycle. (See Figure XX )
nBOwnerOut O One cycle after a requesting device asserts nOwnerOut to its arbiter, that arbiter asserts nBOwnerOut to all the arbiters (including itself) in the system.
nBOwnerIn I nBOwnerIn receives its value from the nBOwnerOut wire. Note that a single arbiter can receive a value for nBOwnerOut for one transaction and receive a value for nBOwnerIn for a transaction one stage further in the pipeline during the same cycle.  
nStartGrant O nStartGrant is asserted by an arbiter during the first cycle of a grant. The combined nStartGrant wire for all 8 arbiters performs an OR of the nStartGrant wires for the individual arbiters so that it is low if it is the first cycle of a grant for any of the arbiters. Having the nStartGrant wire low during the first first cycle of any grant is not necessary for the correct functioning of the system; however, it is useful for debugging because it makes it easy to determine when grants are being made.
nStopAct I When asserted (at all arbiters synchronously), nStopAct causes the arbiters to postpone all grants.
TInv[0..1] I/O TInv (Test inverter) is an inverter that was included in the design solely for testing purposes.  TInv[0] is the input; TInv[1] is the output.
  
TRec2v[0..2] I/O TRec2v (Test Receiver 2 Volts) is included in the design solely for testing purposes. TRec2v[0] is the input wire to an inverter. TRec2v[1] is an analog input signal. TRec2v[2] is the output of the inverter.
[Artwork node; type 'Artwork on' to command tool]
TIOBus
 O TIOBus (Test IO Bus) is an experiment intended to generate a Receive/Adjust signal automatically. (It can be ignored.)
6.0 DC Characteristics
Note that for the 2 volt logic, signals are active low off chip and active high on chip. The 2 volt bus transceivers invert to accomplish this transformation.
Pin Name or Type Signal Type Voltage  Current
Group A 2V input L 0.65 .035 ma
Group B 2V open drain(output) L 0.2 92 ma
Group C 5V input L 1.0 0
  H 4.0 0 
Group D 5V output L 0.5 2 ma
  H 4.0 0
DSerialOut 5V Tri-state L 0.5 2 ma
  H 4.5 2 ma
RecAdj analog input 2-4.5 V  0.1 ma
Test Signals unspecified
Pin Type Pin Name
Group A nRequestOut
 nSStopOut[0..7]
 nSharedOut[0..7]
 nOwnerOut
 nHIPGrant
 nLongGrant
 nSStopIn
 nSharedIn
 nOwnerIn
 OtherArbInT[3 x 7]
 nBusyIn
 nBStopIn[1 x 8]
 nBSharedIn[1 x 8]
 nBOwnerIn[1 x 8]
 nStopAct
Group B nGrant
 ArbReqOut
 nBusyOut
 nBSStopOut
 nBSharedOut
 nBOwnerOut
 nStartGrant
Group C DSerialIn
 nDReset
 nDFreeze
 DExecute
 DAddress
 DShiftCk
 SlotNo
 BdVersion
 Clock
Group D nDHybridSel
 DBdSel
 CkOut
 
7.0 AC Characteristics
A. Definitions
The timing characteristic of each port are described in this section. It is generally assumed that the charcteristics of all the wires connecting a chip to a particular component are the same, so that Dynabus signals, DBug Bus signals, Backpanel signals, (etc.) may be characterized as a group.
[Artwork node; type 'Artwork on' to command tool]
Figure 6: Input Signal Characteristics
Ts (setup time) = the mimimum time a signal must be stable before the rising edge of the clock.
Th (hold time) = the mimimum time a signal must be stable after the rising edge of the clock.
[Artwork node; type 'Artwork on' to command tool]
Figure 7: Output Signal Characteristics
Tcycle = the time interval between successive rising edges of the clock
Tpd (propagation delay) = the waiting time after the clock is high until an output becomes valid.
Tm (maintenance of old data) = the time after rising edge of next clock cycle that old data remains valid.
B. Values
Qualififed Pin Name Tmin Ttypical Tmax
Tcycle 20ns 25ns 35ns
Ts.Dynabus In (setup.Dynabus In)  3ns 
Th.Dynabus In (hold.Dynabus In)  1ns
Tpd.Dynabus Out (propagation delay.Dynabus Out)  5ns
Tm.Dynabus Out (maintain.Dynabus Out)  2ns
   
   
8.0 Application Schematic of the Circuit
[Artwork node; type 'Artwork on' to command tool]
Figure 8: The full arbiter configuration.
9.0 Physical Pin-out For Each Package
No Name  No Name No Name No Name
4 nGrant.0 37 nOwnerOut 73 TIOvdd 110 ArbReqOut.0
5 nRequestOut.0.0 38 nSharedOut.0 74 TIOgnd 111 OtherArbIn.0.0
6 nSStopIn 39 nSharedOut.1 77 Ckout 112 OtherArbIn.1.0
7 nRequestOut.0.1 40 nSharedOut.2 78 Clock 113 OtherArbIn.2.0
8 nGrant.1 41 nSharedOut.3 80 nDHybridSel.0 114 OtherArbIn.3.0
9 nRequestOut.1.0 42 nSharedOut.4 81 nDHybridSel.1 115 OtherArbIn.4.0
10 nRequestOut.1.1 43 nSharedOut.5 82 nDHybridSel.2 116 OtherArbIn.5.0
11 nGrant.2 44 nSharedOut.6 83 nDHybridSel.3 117 OtherArbIn.6.0
12 nRequestOut.2.0 45 nSharedOut.7 84 nDHybridSel.4 119 ArbReqOut.1
13 nOwnerIn 46 nSStopOut.0 85 DBdSel 120 OtherArbIn.0.1
14 nRequestOut.2.1 47 nSStopOut.1 86 SlotNo.0 121 OtherArbIn.1.1
15 nGrant.3 48 nSStopOut.2 87 SlotNo.1 122 OtherArbIn.2.1
16 nRequestOut.3.0 49 nSStopOut.3 88 SlotNo.2 123 OtherArbIn.3.1
17 nSharedIn 50 nSStopOut.4 89 SlotNo.3 124 OtherArbIn.4.1
18 nRequestOut.3.1 51 nSStopOut.5 90 BdVersion.0 125 OtherArbIn.5.1
19 nGrant.4 52 nSStopOut.6 91 BdVersion.1 126 OtherArbIn.6.1
20 nRequestOut.4.0 53 nSStopOut.7 92 nBSStopIn.0 127 ArbReqOut.2
21 nLongGrant 54 DBus.0 93 nBSStopIn.1 128 OtherArbIn.0.2
22 nRequestOut.4.1 55 DBus.1 94 nBSStopIn.2 129 OtherArbIn.1.2
23 nGrant.5 56 DBus.2 95 nBSStopIn.3 130 OtherArbIn.2.2
24 nRequestOut.5.0 57 DBus.3 96 nBSStopIn.4 131 OtherArbIn.3.2
25 nRequestOut.5.1 58 DBus.4 97 nBSStopIn.5 132 nStartGrant
26 nGrant.6 59 DBus.5 98 nBSStopIn.6 133 OtherArbIn.4.2
27 nRequestOut.6.0 60 DBus.6 99 nBSStopIn.7 134 nBOwnerOut
28 nRequestOut.6.1 61 TInv.0 100 nBSSharedIn.0 135 OtherArbIn.5.2
29 nGrant.7 62 TInv.1 101 nBSSharedIn.1 136 nBSharedOut
30 nRequestOut.7.0 63 TRec2v.0 102 nBSSharedIn.2 137 OtherArbIn.6.2
31 nHiPGrant 64 TRec2v.1 103 nBSSharedIn.3 138 nBSStopOut
32 nRequestOut.7.1 65 TRec2v.2 104 nBSSharedIn.4 139 nStopAct
  66 RecAdj 105 nBSSharedIn.5 140 nBusyOut
  67 TIOBus.0 106 nBSSharedIn.6 141 nBusyIn
  68 TIOBus.1 107 nBSSharedIn.7  
  69 TIOBus.2 108 nBOwnerIn  
  70 TIOBus.3    
  71 TIOBus.4    
  72 TIOBus.5
[Artwork node; type 'Artwork on' to command tool]