Priority Arbiters
Alex Bystrov
David Kinniment
Alex Yakovlev
University of Newcastle upon Tyne, UK
ASYNC 2000 Eilat April 2 - 6
1
Outline of presentation







Need for different arbitration disciplines
Types of arbiter
A static priority arbiter
A dynamic priority arbiter
Speed improvements
Results
Conclusions
ASYNC 2000 Eilat April 2 - 6
2
Arbitration



Complex systems may
require that some
requests overtake others
Here three input
channels require access
to a single output port
Each request may have
a different priority
Priority can be
topologically fixed, or
determined by a function
Data
Data
switch
line
control
line 0
P0
control r0
g0
line 1
control
line 2
control
ASYNC 2000 Eilat April 2 - 6
Output
P1
r1
g1
Dynamic priority arbiter

P2
r2
g2
3
Types of arbiter

Topologically fixed
– priorities determined by structure, e.g. daisy-chain
requests
~r1,r1 g1 d1
r2 g2 d2
rn gn dn
Start
order of polling

Static or dynamic priority
– determined by fixed hardware, or priority data supplied
ASYNC 2000 Eilat April 2 - 6
4
Static or dynamic priority
ASYNC 2000 Eilat April 2 - 6
grants
Request lock register
priority busses
requests
Control and Interface
Priority logic
5
Metastability and priority

Lock the request pattern
– incoming requests cause Lock to go high
– following MUTEX ensures that request wins or
loses
?
Lock
r

l
MUTEX
s
w
Evaluate priorities with a fixed request
pattern
ASYNC 2000 Eilat April 2 - 6
6
Static priority arbiter
Lock
R1
s* q
MUTEX
r1
s1
C
G1
C
G2
C
G3
MUTEX
R2
r2
s2
s* q
r
Priority Module
r
MUTEX
R3
s* q
r3
s3
r
Lock Register
s
C
ASYNC 2000 Eilat April 2 - 6
q
r*
7
Quasi speed independent
Assumptions

s+ must occur before Lock+
– The physics of the MUTEX are such that if r+ is
before Lock+, s+ must be asserted

The three inputs to the Lock bistable are
implemented as a single complex gate set.
– A faster non speed independent implementation in
which the gate is separate is possible
ASYNC 2000 Eilat April 2 - 6
8
More than one request


Priority needed if requests are competing
Shared resource free
– resolution required only if second request arrives
before the lock signal due to first request

Shared resource busy
– Further requests may accumulate, and one may
be higher priority
ASYNC 2000 Eilat April 2 - 6
9
Two more requests
Lock
R1
s* q
MUTEX
r1
s1
C
G1
C
G2
C
G3
MUTEX
R2
r2
s2
s* q
r
Priority Module
r
MUTEX
R3
s* q
r3
s3
r
Lock Register
s
C
ASYNC 2000 Eilat April 2 - 6
q
r*
10
Dual-rail priority module
f1
r1
r2
r2
r3
Priority Logic
r1
f2
f3
C
g1
C
g2
C
g3
r3


Dual rail request
inputs
One-hot grant
output
ASYNC 2000 Eilat April 2 - 6
Completion
Detector
C
11
P0<0..3>
P1<0..3>
Priority data
P7<0..3>
Reset completion
detector
R0-7
s* q
res_done
Invalid
Lock
Priority Module
Dynamic priority
MUTEX
done
s0-7
r0-7
C
G0-7
Valid
r
Lock Register
s
C
ASYNC 2000 Eilat April 2 - 6
q
r*
12
Accelerated grant




Valid and Invalid signals
are generated from the
Lock register
Tree computation of grant
Only one channel needs
to be valid for the node to
be valid
Not all nodes need data
evaluation
Data comparison uses
dual rail or one hot
techniques
ASYNC 2000 Eilat April 2 - 6
G4
Maximum Calculation Cells

Slow
computation
Done
Root MCC
13
Concurrent PM reset
Not speed
independent.
– Assume that
Lock reset is
faster than the
resource.

Reset of the PM
can take place
concurrently
with grant.
MUTEX
s1
R1
MUTEX
s2
R2
Priority Module

C
G1
C
G2
C
G3
MUTEX
s3
R3
Lock Register
s
q
Lock
r*
ASYNC 2000 Eilat April 2 - 6
14
Results



0.6m AMS Process DPA
R0 only to G0 4.94nS
R1 .. R7 arrive while
processing R0, then R0
reset
– 13.45nS

Priority module
– 2.74nS (no priority data
required)
– 7.63nS (all priority inputs
compared)
ASYNC 2000 Eilat April 2 - 6
15
Conclusions





Arbitrary priority discipline
Resource allocation a function of parameters
supplied by active requests (or fixed
statically)
Quasi speed independent request locking
and priority evaluation
Accelerated grant where possible
Speed improvements possible with relative
timing assumptions
ASYNC 2000 Eilat April 2 - 6
16