1. ASYNC 2000 Eilat April 2 - 6 1 Priority Arbiters Alex Bystrov David Kinniment Alex Yakovlev University of Newcastle upon Tyne, UK

2. ASYNC 2000 Eilat April 2 - 6 2 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

3. ASYNC 2000 Eilat April 2 - 6 3 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

4. ASYNC 2000 Eilat April 2 - 6 4 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

5. ASYNC 2000 Eilat April 2 - 6 5 Static or dynamic priority Request lock register Control and Interface requests grants Priority logic priority busses

6. ASYNC 2000 Eilat April 2 - 6 6 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 ?

7. ASYNC 2000 Eilat April 2 - 6 7 Static priority arbiter

8. ASYNC 2000 Eilat April 2 - 6 8 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

9. ASYNC 2000 Eilat April 2 - 6 9 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

10. ASYNC 2000 Eilat April 2 - 6 10 Two more requests

11. ASYNC 2000 Eilat April 2 - 6 11 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

12. ASYNC 2000 Eilat April 2 - 6 12 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

13. ASYNC 2000 Eilat April 2 - 6 13 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

14. ASYNC 2000 Eilat April 2 - 6 14 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.

15. ASYNC 2000 Eilat April 2 - 6 15 Results 0.6  AMS Process DPA l R 0 only to G 0 4.94nS 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)

16. ASYNC 2000 Eilat April 2 - 6 16 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