ArbiterTalk.tioga
D Curry - August 5, 1988 
1
Dragon Arbiter

  
TOC
General Characteristics
Pin Descriptions
Startup Procedure
Priority and Precedence
Device Request Port Modes
Debug Bus Formats
Input Buffer Management
Performance limitations
Attributes
Primary:
· Distributed arbitration (up to 8 per system)
· 8 logical devices per arbiter
· 6 priority levels
· 2 level round-robin at each priority 
· 6 deep request queues per device-priority
· System wide low priority grant hold
· System wide synchronous stop
Auxiliary Functions:  (unique device/board)
· Debug Bus first level decode
· OR function: Shared, Owner, Stop

<<[Artwork node; type 'ArtworkInterpress on' to command tool]>>
Primary Interface
Device Requests
nRequestOut (8x2)    - from devices

Device Grants
nGrant (8)        - to devices
nHiPGrant        - to all devices
nLongGrant        - to all devices
nStartGrant *        - to all devices

Arbiter coordination
ArbReqOut (3)        - to all arbiters
OtherArbInT (8x3)    - from each arbiter
nBusyOut*        - to all arbiters
nBusyIn        - from all arbiters
OR Function  Interface
From devices
nOwnerOut*     nSharedOut(8)    nSStopOut(8)
To arbiters
nBOwnerOut     nBSharedOut    nBSStopOut
From arbiters
nBOwnerIn*     nBSharedIn(8)    nBSStopIn(8)
To System
nOwnerIn     nSharedIn    nSStopIn
From System
                nSStopAct
Debug Bus Control Interface
Debug Bus Control
DSerialOut    - output
DSerialIn    - input
nDReset        - input
nDFreeze    - input
DExecute    - input
DAddress    - input
DShiftCK    - input
Selection Logic
SlotNo(4)    - input
BdVersion(2)    - input
nDHybridSel(5)    - output
DBdSel        - output
System
RecAdj        - input
Clock        - input
CKOut        - output
Reset - Stop - Start
Arbiters must be ready to operate before any other bus device becomes active.
Start Sequence:
0) Reset - 10 cycles
1) Synchronous Stop (and Reset)
Arbiters begin listening
No device is talking
2) Remove Reset (but maintain Synchronous Stop)
Devices begin to make requests
None granted
3) Remove Synchronous Stop
Arbiters begin making grants
Priority and Precedence
Each Arbiter computes the highest priority request of any of its local devices and outputs this to all other arbiters
Each Arbiter independently computes which arbiter should allocate grant based on:
Highest priority arbiter
Precedence: Which arbiter received previous grant at that priority
The one arbiter that wins, allocates the grant based on:
Highest priority device
Precedence: Which device received previous grant at that priority
Characteristics of current scheme
Each arbiter maintains a device precedence pointer for each priority.
Each arbiter maintains independent copies of the arbiter precedence pointer for each priority.
Each arbiter thinks of itself as arbiter 0.
<<[Artwork node; type 'ArtworkInterpress on' to command tool]>>
<<Distributed Arbiter Interconnect>>
Device Request Ports
Cache Type Device
0:    Clear Hold
1:    Set Hold
2:    Low    priority request
3:    High    priority request
Memory Type Device
0:    Clear Hold
1:    Set Hold
2:    Short    (2 cycle)  packet request
3:    Long    (5 cycle)  packet request
Port Mode Operation
Cache Type Device
6 request buffer for each priority
High priority requests granted first
Memory Type Device
6 request buffer
Grants issued in same order as requests
Device responsible for preventing overflow of Arbiter request buffer
Request Port Initialization
Cache Type     Ph Ph Ph Sh    Pl Pl Pl Sl  1
Pa - Priority high(3)
Sa - Size high
Pb - Priority low(3)
Sb - Size low
Memory Type    x  x  x  1    P  P  P  1   0
P - Priority(3)
Arbiter Debug Bus Formats
Arbiter Address format: BBBB 0000 0000 0PPP
B - Board Slot
P - Path
0 - 16 bits    - rd only - Chip ID
type, version
1 - 8*9 bits    - rd/wt - Device Config,
8 device port configs
2 - 4 bits    - rd/wt - Arbiter Config,
ArbNo, HySelDec
3 - 2 bits    - rd only - Board ID
type, version
Debug Bus
General Address Format
Device Addressing: BBBB HHHH bbb cc PPP
BBBB    - board
HHHH    - hybrid
bbb    - BIC
cc    - chip
PPP    - Path
Input Buffer Management
Two mechanisms:
Assign reply packets higher priority than request packets
Use Hold to prevent grants for request packets
Two Cycle Grant Limitations
1. After a two-cycle grant, THE SAME ARBITER cannot immediately make another grant.  Two mech:
  
  The earliest that other arbiters will allow the current grantee arbiter to make a new grant is the third cycle after he starts 
the previous grant.  They simply ignore his request.
  
  The grantee arbiter disables his own outgoing ArbReqOut until he has had time to recompute it   after decrementing the request 
counter corresponding to the grant that he is now making.
  
2. After a two-cycle grant at priority level 0 or 1, NO ARBITER can immediately make another grant at priority level 3 or greater.  
The grantee arbiter's
  request might have been masking a Hold.  If true, then ignoring would allow grants at any level, which could violate the Hold.
Future Packet Size Variations
Use  of Busy to communicate packet size to other arbiters => new packet sizes may be implemented by future versions of Arbiter.