ASYNC 2000 Eilat April Priority Arbiters Alex Bystrov David Kinniment Alex Yakovlev University of Newcastle upon Tyne, UK

ASYNC 2000 Eilat April Outline of presentation l Need for different arbitration disciplines l Types of arbiter l A static priority arbiter l A dynamic priority arbiter l Speed improvements l Results l Conclusions

ASYNC 2000 Eilat April Arbitration l Complex systems may require that some requests overtake others l Here three input channels require access to a single output port l Each request may have a different priority l Priority can be topologically fixed, or determined by a function Dynamic priority arbiter line 0 control line 1 control line 2 control P1 r1 g1 P2 r2 g2 P0 r0 g0 Data switch Output line Data control

ASYNC 2000 Eilat April Types of arbiter l Topologically fixed –priorities determined by structure, e.g. daisy-chain Start requests order of polling ~r 1,r 1 g1g1 d1d1 r2r2 g2g2 d2d2 rnrn gngn dndn l Static or dynamic priority –determined by fixed hardware, or priority data supplied

ASYNC 2000 Eilat April Static or dynamic priority Request lock register Control and Interface requests grants Priority logic priority busses

ASYNC 2000 Eilat April Metastability and priority l Lock the request pattern –incoming requests cause Lock to go high –following MUTEX ensures that request wins or loses l Evaluate priorities with a fixed request pattern MUTEX Lock r s l w ?

ASYNC 2000 Eilat April Static priority arbiter

ASYNC 2000 Eilat April Quasi speed independent Assumptions l s+ must occur before Lock+ –The physics of the MUTEX are such that if r+ is before Lock+, s+ must be asserted l 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 More than one request l Priority needed if requests are competing l Shared resource free –resolution required only if second request arrives before the lock signal due to first request l Shared resource busy –Further requests may accumulate, and one may be higher priority

ASYNC 2000 Eilat April Two more requests

ASYNC 2000 Eilat April Dual-rail priority module C C C C r1r1 r3 r3 r2 r2 r1 r1 r2r2 r3r3 f1f1 f2f2 f3f3 g1g1 g2g2 g3g3 Completion Detector Priority Logic l Dual rail request inputs l One-hot grant output

ASYNC 2000 Eilat April Dynamic priority sq r* C Lock Register Priority Module MUTEX C s*q r R 0-7 Lock r 0-7 s 0-7 Reset completion detector res_done done P 0 P 1 P 7 G 0-7 Valid Invalid Priority data

ASYNC 2000 Eilat April Accelerated grant l Valid and Invalid signals are generated from the Lock register l Tree computation of grant l Only one channel needs to be valid for the node to be valid l Not all nodes need data evaluation l Data comparison uses dual rail or one hot techniques Root MCC Maximum Calculation Cells Slow computation G4 Done

ASYNC 2000 Eilat April sq r* G1 G2 G3 R1 R2 R3 Lock Lock Register Priority Module MUTEX s1 MUTEX s2 MUTEX s3 C C C Concurrent PM reset l Not speed independent. –Assume that Lock reset is faster than the resource. l Reset of the PM can take place concurrently with grant.

ASYNC 2000 Eilat April Results 0.6  AMS Process DPA l R 0 only to G nS l R 1.. R 7 arrive while processing R 0, then R 0 reset –13.45nS l Priority module –2.74nS (no priority data required) –7.63nS (all priority inputs compared)

ASYNC 2000 Eilat April Conclusions l Arbitrary priority discipline l Resource allocation a function of parameters supplied by active requests (or fixed statically) l Quasi speed independent request locking and priority evaluation l Accelerated grant where possible l Speed improvements possible with relative timing assumptions