vsync track c

30
Synchronization Issues in Multiple- Clock Domain Designs Reuven Dobkin vSync Circuits ltd. www.vsyncc.com May 4, 2010

Upload: alonagradman

Post on 07-May-2015

600 views

Category:

Education


1 download

TRANSCRIPT

Page 1: Vsync   track c

Synchronization Issues in Multiple-Clock Domain Designs

Reuven DobkinvSync Circuits ltd.www.vsyncc.com

May 4, 2010

Page 2: Vsync   track c

Outline

Multiple Clock Domain designs Metastability and MTBF Common synchronization mistakes Advanced synchronization with EDA

tools

Page 3: Vsync   track c

Multiple Clock Domain (MCD) Designs

Page 4: Vsync   track c

Multiple Clock Domains (1)

Where can I encounter MCD? Everywhere!

Single clock domain distribution is cumbersome in large designs due to: Variations (cells and interconnect) Clock uncertainty (skew) limits the performance Actually we always have ‘mesochronous’ clocks

(same freq, slightly different phase), which are “synchronized” by timing assumptions (maximal skew)

Page 5: Vsync   track c

Multiple Clock Domains (2)

System-on-Chip (ASIC or FPGA) Usually consists of multiple IP-blocks Each IP works with its own clock Local / Global clock gating Dynamic Voltage and Frequency Scaling (DVFS):

The speed of each module may change over time for power reduction

Page 6: Vsync   track c

Taxonomy of Multiple Clock Domains

Classf

Synchronous00

Mesochronousc0

Multi-synchronousdrifts0

PlesiochronousVariesfd<

Periodicfd>

Asynchronous

R. Dobkin, R. Ginosar, "Fast Universal Synchronizers," PATMOS, 2008

Page 7: Vsync   track c

Inter-MCD Communication

Data transfer between different clock domains should be performed carefully

Incoming data change near receiver clock sampling edge causes metastability, which may lead to a functional failure Either set-up or hold time is not satisfied

Transmitter ReceiverDATA

TX_CLK RX_CLK

RX_CLK

DATA

Page 8: Vsync   track c

Metastability and MTBF

Page 9: Vsync   track c

Metastability

What happens when the data changes during sampling?

The sampling FF becomes metastable

Metastability: the FF goes into an unstable intermediate state presenting non-deterministic delay

Page 10: Vsync   track c

Asynchronous FailuresClock

tpd

tsu+ th

In 1

Out 1

In 2

Out 2

Data conflict Long Delay

In 3

Out 3

Metastability

Terrible data conflict

© 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures

Page 11: Vsync   track c

Synchronization Failure

Long delay due to M/S causes violation of cycle time

Not a singular problem! It spreads through the entire circuit, causing total failureFailures due new M/S

event or incorrect function

Page 12: Vsync   track c

M/S Handling: The Two-Flop Synchronizer

Allow time for Metastability settling Why two flops? (could actually be 1,2,3…) Settling time (S): 2 cycles Latency (from RDY+ to data latching): At least 2, up to 3 Why synchronize RDY and not data? Is this circuit enough? (NO)

data

BFF

Clock B

FF1 FF2RDY enable

Page 13: Vsync   track c

MTBFMean Time Between Failures

Given metastability at t = 0, probability of metastability at t > 0 = e-t/

2 FO4 gate delay Failure: Still metastable by next clock

Failure = p(enter m.s) p(still m.s. after T) Rate(failure) = Rate(enter m.s) p(still m.s. after T)

=W Fc Fd e-T/

MTBF = 1/ Rate( failure) =

T

C D

e

W F F

Page 14: Vsync   track c

MTBF (various frequencies)0.13m, tau=66ps, W=132ps, FD=FC/10

1.E+00

1.E+02

1.E+04

1.E+06

1.E+08

1.E+10

1.E+12

0 0.5 1 1.5 2

S = Settling Time (clock cycles)

MT

BF

(se

c)

One day

One year

100 years

10K years

200M

Hz

400M

Hz

600M

Hz

800MHz1 GHz

© 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures

Page 15: Vsync   track c

MTBF: Low Voltage is Deadly !

At nominal Vdd range (0.9—1.1V), MTBF(1T) is millions of years

At half nominal Vdd, ckt is only 2-3x slower, but MTBF is less than one year!

20

40

60

80

100

0.4 0.6 0.8 1 1.2

Vdd (V)

Gat

e D

elay

(p

s)

1.E-06

1.E+00

1.E+06

1.E+12

1.E+18

1.E+24

1.E+30

MT

BF

(ye

ars)

90nm

NORMAL

© 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures

Page 16: Vsync   track c

vs. VDD and temperature Tau significantly increases at low temperature and low supply

voltage

Tau vs. VDD, T

0

200

400

600

800

1000

1200

1400

1600

1800

-50 -25 0 25 50 75 100 125 150

Temperature, ºC

Ta

u,

ps

V=0.4V

V=0.5V

V=0.6V

V=0.7V

V=0.8V

© 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures

Page 17: Vsync   track c

: Recent findings (1)

S. Beer, R. Dobkin, R. Ginosar, A. Kolodny, "The Devolution of Synchronizers," Proc. of ASYNC, 2010.

We thank our partner GiDEL for supporting this research.We also thank Freescale Semiconductor for their support.

Page 18: Vsync   track c

: Recent findings (2)

We thank our partner GiDEL for supporting this research.We also thank Freescale Semiconductor for their support.

S. Beer, R. Dobkin, R. Ginosar, A. Kolodny, "The Devolution of Synchronizers," Proc. of ASYNC, 2010.

Page 19: Vsync   track c

Common Synchronization Mistakes

Page 20: Vsync   track c

Not Really Errors !

Most examples actually work as planned They may not scale, or not be portable They may fail when assumptions change

Page 21: Vsync   track c

Avoiding Synchronization

Myth: “since MTBF is a million years, there is no metastability and I don’t need a synchronizer”

Truth: Lots of metastability events per second Design should be “metastability-tolerant”, not

“metastability-free”

Page 22: Vsync   track c

One Flop Synchronizer

Long delay may lead to setup violation Works if TSETTLE+TPD+TSETUP < TCYCLE

Use with caution, only in latency-critical situations Real life – year 2005: 10MHz design with hundreds of clocks

(signals used as clocks). Works, although unintentionally…

R

ASENDER RECEIVER

R

A

Page 23: Vsync   track c

Greedy Path

Typically wrong “edge detector” Advise against in SoC methodology Use with caution, only in latency-critical situations

SENDER RECEIVER

R

R2

D

R1R3

Page 24: Vsync   track c

Parallel Synchronizer

This one is extremely dangerous!

...

Page 25: Vsync   track c

Advanced Synchronization

Page 26: Vsync   track c

Conclusion from previous slides Growing number of clock domain crossings

(CDC) calls for an automatic CDC handling approach: Correct by design flexible synchronizer IPs

Customized for the specific targeted FPGA / ASIC technology

Enforced methodology avoiding synchronization pitfalls Tool-based CDC verification

Sign off the design for each new change including porting to another technology

Page 27: Vsync   track c

Correct by design synchronizers Guided requirement

specification Different interface

protocols Simulation models Synthesis constraints Efficient clock relation

handling Different operating

conditions handling FPGA/ASIC design

flows support

vSync Generator

Page 28: Vsync   track c

Tool-based CDC verificationvSync Checker

CDC Identification CDC Classification Different operating

conditions handling Design Reliability

Grading RTL and GL support Similar tools are

available from Mentor, Atrenta and Real Intent

Page 29: Vsync   track c

Summary

Synchronization is essential in most of the designs we deal with today

Analyze all system requirements including reliability before choosing correct synchronizer

Need EDA tools for reliable integration of multiple CDCs

Validate each synchronizer Make this part of design methodology Use EDA tools for CDC verification

Page 30: Vsync   track c

Thank you!

You are welcome to visit us at www.vsyncc.com