Priority Arbiters

1. Priority Arbiters Alex Bystrov David Kinniment Alex Yakovlev University of Newcastle upon Tyne, UK

2. Outline of presentation • Need for different arbitration disciplines • Types of arbiter • A static priority arbiter • A dynamic priority arbiter • Speed improvements • Results • Conclusions

3. Dataswitch Outputline Data control line 0control P0 r0 g0 line 1control Dynamic priority arbiter P1 r1 g1 line 2control P2 r2 g2 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

4. requests ~r1,r1 g1 d1 r2 g2 d2 rn gn dn Start order of polling Types of arbiter • Topologically fixed • priorities determined by structure, e.g. daisy-chain • Static or dynamic priority • determined by fixed hardware, or priority data supplied

5. Control and Interface grants requests Priority logic Request lock register priority busses Static or dynamic priority

6. l MUTEX Lock s r w 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 ?

7. Lock MUTEX r1 s1 R1 s* q G1 C r MUTEX r2 s2 Priority Module R2 s* q G2 C r MUTEX r3 s3 R3 s* q G3 C r Lock Register s q C r* Static priority arbiter

8. 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

9. 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

10. Lock MUTEX r1 s1 R1 s* q G1 C r MUTEX r2 s2 Priority Module R2 s* q G2 C r MUTEX r3 s3 R3 s* q G3 C r Lock Register s q C r* Two more requests

11. f1 r1 C g1 r1 f2 r2 C g2 r2 Priority Logic f3 r3 C g3 r3 CompletionDetector C Dual-rail priority module • Dual rail request inputs • One-hot grant output

12. Priority data Invalid MUTEX s* q C Valid r s q C r* Dynamic priority P0<0..3> P1<0..3> Priority Module P7<0..3> Reset completion detector res_done done Lock s0-7 r0-7 R0-7 G0-7 Lock Register

13. G4 Slowcomputation Done 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 Maximum Calculation Cells Root MCC

14. MUTEX s1 R1 G1 C MUTEX s2 Priority Module R2 G2 C MUTEX s3 R3 G3 C Lock Register s q Lock r* 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.

15. 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)

16. 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