Synchronizers, Arbiters, GALS and Metastability David Kinniment - PowerPoint PPT Presentation

Synchronizers, Arbiters, GALS and Metastability David Kinniment University of Newcastle, UK Based on contributions from: Alex Bystrov, Keith Heron, Nikolaos Minas, Gordon Russell, Alex Yakovlev, and Jun Zhou 1 TUBS 1 July 2009

Outline  What’s the problem? Why does it matter?  Time and distributions  Noise – decisions are not deterministic.  Synchronizer latency, can it be avoided?  Measuring and some interesting effects 2 TUBS 1 July 2009

What’s the problem: The digital IP world and the rest of the world Everything else, or Reality Your system The synchronizer is the guy that allows timing flexibility 3 TUBS 1 July 2009

Synchronizers and arbiters Input  Synchronizer Your system Decides which clock cycle to use for the input data Input 1  Asynchronous arbiter Your system Decides the order of inputs Input 2 4 TUBS 1 July 2009

Time Comparison Hardware  Digital comparison hardware (which compares integers) is easy – Fast – Bounded time  Analog comparison hardware (which compares reals like time) is hard – Normally fast, but takes longer as the difference becomes smaller – Can take forever, (Buridan’s Ass ~1340)  Synchronization and arbitration involve comparison of time  Known to early computer designers: – Lubkin 1952, Catt 1966 – Chaney and Littlefield 1966/72 5 TUBS 1 July 2009

Asynchronous Network (Sparsø, ASYNC 2005) Multiple Clocks Synchronization required Arbitration required Asynchronous Sparsø 6 TUBS 1 July 2009

Synchronization of data  Non pausible clocks require data synchronization  You have a limited time to synchronize.  Synchronizer circuits may fail to work in that time  System sometimes fails (you fly into a mountain)  Synchronization time = latency VALID D Q D Q #1 #2 CLK b CLK a 7 TUBS 1 July 2009

Synchronization of clocks  Clock paused to prevent contention  Wait for MUTEX output to resolve  Can take forever (with decreasing probability)  This may not be acceptable (you fly into a mountain) Request Grant MUTEX Run C Ack Delay Clock 8 TUBS 1 July 2009

Trends  Communications are limiting performance  Difficulty (Impossibility?) in maintaining one clock per chip  Need reduce wasted power in clocks  Timing closure problems – Interconnect delay times long – Variability increases  Move towards asynchronous networks 9 TUBS 1 July 2009

Metastability is.... Set-up time violated D Request Q D ∆ t in Clock Q Processor Clock Clock ∆ t in -> 0 Not being able to decide… 10 TUBS 1 July 2009

Metastability in a Latch I2 I1 V2 I1 I2 V1 V1 V2 V2 V1 Stable points V1 Metastable Point V2 11 TUBS 1 July 2009

Simple Linear Model R 1 V 2  Simple linear model V 1 - + leads to two -A*V 1 C 1 exponentials  τ a is convergent, τ b is V 2 V 1 divergent V 1 V 2 A C R . C R . g m = τ = τ = 1 1 2 2 , Q2 Q1 1 2 R A A τ + τ 2 d V ( ) . dV 1 = τ τ + + − 1 1 2 1 0 . . ( 1 ). V − 2 2 1 2 1 t t dt A dt A τ τ = + V K . e K . e a b 1 a b 12 TUBS 1 July 2009

Synchronizer  t is time allowed for the Q to change between CLK a and CLK b  τ is the recovery time constant, usually the gain-bandwidth of the circuit  T w is the “metastability window”  τ and T w depend on the circuit  We assume that all values of ∆ t in are equally probable / τ t e = MTBF VALID D Q D Q #1 #2 T . f . f w c d CLK b CLK a 13 TUBS 1 July 2009

Typical responses Q Output Clock  All starting points are equally probable  Most are a long way from the “balance point”  A few are very close and take a long time to resolve 14 TUBS 1 July 2009

Event Histogram The intercept is ~T w The slope is -1/ τ Log Probability of event Events depends on ∆ time Propagation delay - Propagation delay Normal delay 15 TUBS 1 July 2009

Synchronizer state of the art  You require about 35 τ s in order to get the MTBF out to about 1 century. (That’s for 1 synchronizer)  There is nothing else you can do while synchronizing  Each typical static gate delay is equivalent to about 5 τ Synchronizers are analog devices, so worse affected by scaling  Bigger SoCs, in future systems so more synchronizers, worse reliability  Inputs can be ‘malicious’ i.e. always causing metastability. 16 TUBS 1 July 2009

Outline  What’s the problem? Why does it matter?  Time and distributions  Noise – decisions are not deterministic.  Synchronizer latency, can it be avoided?  Measuring and some interesting effects 17 TUBS 1 July 2009

The arbiter (MUTEX) •Asynchronous arbitration,No time bound •Seitz metastability filter •Grants cannot occur until after the latch resolves any metastability Request 1 Grant 1 Request 2 Grant 2 Gnd 18 TUBS 1 July 2009

Arbitration time  Unlike a synchronizer, an arbiter may take for ever.  It usually doesn’t, long responses are rare.  On average the time should only be τ longer than the normal response, so DEAD time ought to be low  Outputs are always monotonic Request 1 Request 2 t m Grant 1 Grant 2 19 TUBS 1 July 2009

Gate metastability filter  Half levels due to metastability need to be removed – Low (or high) threshold inverters – Measure divergence  Filters define the time to reach a stable state 0 Vdd/2 Vdd/2 Vt =Vdd/4 0 Vdd/2 20 TUBS 1 July 2009

Resolution time can be affected 2.1 1.9 1.7 Low Start Volts 1.55V 0 50 100 150 200 250 300 350 400 450 500 High Start 1.5 1.3 1.1 ps • The start/finish points make a difference • Grant appears when trajectory crosses the filter threshold • Gate metastability filter shows more variation • Seitz filter shows more delay 21 TUBS 1 July 2009

Event distribution  Assumption: Time between two events (R1 and R2) is evenly distributed  Typically it is not.  Can be as much as 7:1 variation.  Here there are more cases where R1 is just after R2  Arbitration may Distribution of event times not be fair 22 TUBS 1 July 2009

Non uniform probabilities and time  Time for metastability averaged over a distribution T in a MUTEX is:   T = ∫ T τ ∆ w   Average _ time ln . d t ∆ in   t in 0  If T = ∞ , Average_time = τ BUT For a malicious input, distribution limited by noise  If T = 4ps, T w =25ps , Average_time = 4 τ  Noise can sometimes make average time faster 23 TUBS 1 July 2009

Predicting performance  MUTEX circuits are fast  BUT delay times may not be easy to predict – Cannot rely on ALL times being fast  Synchronizers are known to be unreliable 24 TUBS 1 July 2009

Future processes  Synchronizers and arbiters don’t work well in nanometre technologies, especially at Vdd low Vdd  Worse that gates! Why?  A gate input is either HIGH I ds I ds Ground – Output pulled down Vdd/2  Or LOW Vdd I ds I ds – Output pulled up  A metastable gate is neither – Both transistors can be off Ground  Vdd decreases with process shrink, – g m very low  Synchronization time constant τ = C/g m 25 TUBS 1 July 2009

Robust synchronizer • Jamb latch synchronizer Vdd slow for low V dd , low temp Reset Data • In metastability, both Clock outputs are the same 0V • Extra p-types are switched fully on, so g m increases, and τ improves 26 TUBS 1 July 2009

Results Measurement Results (ps) Vdd(v) Jamb Latch B Robust Synchronizer 1.8 35.55 34.92 1.7 37.29 35.76 1.6 40.93 38.25 1.5 52.36 43.07 1.4 66.17 50.36 1.35 75.35 58.19 τ (metastability time constant) vs Vdd 27 TUBS 1 July 2009

Outline  What’s the problem? Why does it matter?  Time and distributions  Noise – decisions are not deterministic.  Synchronizer latency, can it be avoided  Measuring and some interesting effects 28 TUBS 1 July 2009

Does noise affect τ ?  Probability of escape from metastability does not change with gaussian noise (Couranz and Wann 1975 ) Trajectories 0.7 0.5 0.3 0.1 Volts -0.1 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 -0.3 -0.5 -0.7 Time 29 TUBS 1 July 2009

Does noise affect τ ?  Probability of escape from metastability does not change with gaussian noise (Couranz and Wann 1975 ) Trajectories 0.7 0.5 0.3 0.1 Volts -0.1 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 -0.3 -0.5 -0.7 Time 30 TUBS 1 July 2009

Can noise change the failure rate? D Q D ∆ t in Clock Q Clock ∆ t in -> 0 Or maybe not..… 31 TUBS 1 July 2009

The normal case Probability Probability of initial difference due t n to noise component P 1 (v) Probability of initial difference due to input clock data overlap P 0 (v) T >> t n Convolution Result of convolution P(v) Time 32 TUBS 1 July 2009

The malicious input Probability of initial difference due to t n noise component P 1 (v) Probability of initial difference with T << t n zero input clock data overlap P 0 (v) Probability Result of convolution P(v) Time 33 TUBS 1 July 2009