Priority Arbiters

ASYNC 2000 Eilat April 2 - 6 1

Priority Arbiters

Alex Bystrov

David Kinniment

Alex Yakovlev

University of Newcastle upon Tyne, UK


Outline of presentation

Need for different arbitration disciplines Types of arbiter A static priority arbiter A dynamic priority arbiter Speed improvements Results Conclusions


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

Dyn

amic

prio

rity

arb

iter

line 0

control

line 1

control

line 2

control

P1r1g1

P2r2g2

P0r0g0

Data

switch

Output

lineData

control


Types of arbiter

Topologically fixed– priorities determined by structure, e.g. daisy-chain

Start

requests

order of polling

~r1,r1 g1 d1 r2 g2 d2 rn gn dn

Static or dynamic priority– determined by fixed hardware, or priority data supplied


Static or dynamic priority

Req

ues

t lo

ck r

egis

ter

Control and Interface

req

ues

ts

gra

nts

Priority logic

pri

ori

ty b

uss

es


Metastability and priority

Lock the request pattern– incoming requests cause Lock to go high– following MUTEX ensures that request wins or

loses

Evaluate priorities with a fixed request pattern

MUTEXLock

rs

l

w

?


s q

r*C

MUTEX

Cs* q

r

MUTEX

Cs* q

r

MUTEX

Cs* q

r

G1

G2

G3

R1

R2

R3

Lock

Lock Register

Pri

ori

ty M

od

ule

r1

r2

r3

s1

s2

s3

Static priority arbiter


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


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


s q

r*C

MUTEX

Cs* q

r

MUTEX

Cs* q

r

MUTEX

Cs* q

r

G1

G2

G3

R1

R2

R3

Lock

Lock Register

Pri

ori

ty M

od

ule

r1

r2

r3

s1

s2

s3

Two more requests


Dual-rail priority module

C

C

C

C

r1

r3

r2

r1

r2

r3

f1

f2

f3

g1

g2

g3

CompletionDetector

Pri

ori

ty L

og

ic

Dual rail request inputs

One-hot grant output


Dynamic priority

s q

r*C

Lock Register

Pri

ori

ty M

od

ule

MUTEX

Cs* q

r

R0-7

Lock

r0-7

s0-7

Reset completion detector res_done

done

P0<0..3>

P1<0..3>

P7<0..3>

G0-7

Valid

Invalid

Priority data


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

Root MCC

Max

imum

Ca

lcu

latio

n C

ells

Slowcomputation

G4

Done


s q

r*

G1

G2

G3

R1

R2

R3

Lock

Lock Register

Pri

ori

ty M

od

ule

MUTEX

s1

MUTEX

s2

MUTEX

s3

C

C

C

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.


Results

0.6 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)


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

Priority Arbiters

Documents

Transcript of Priority Arbiters