Vsync track c


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Variations cause: skew, jitter and drifts.
  • - While latches can present an intermediate voltage at the outputs, FF just present an non-deterministic delay (the chance of having intermediate voltage is very low thanks to the inverters asymmetry).
  • Here we allow one cycle for settling
  • This is easy to chart with Excel or similar tool. You can draw your own if you need to change any of the parameters. If you can decide how much MTBF you want, you can find out how long S should be. Alternative formats of drawing the data were published by Xilinx in 2002 (reference below). Note that if F C remains the same but we consider the slow corner (tau and W 50% higher, say tau=100ps and W=200ps), the MTBF values are smaller. But there is also a simpler way of approaching this.
  • FO4 gate delay depends (roughly) linearly or quadratically on voltage. But MTBF depends exponentially on delay, hence exponentially on voltage !!!
  • Vsync track c

    1. 1. Synchronization Issues in Multiple-Clock Domain Designs Reuven Dobkin vSync Circuits ltd. www.vsyncc.com May 4, 2010
    2. 2. Outline <ul><li>Multiple Clock Domain designs </li></ul><ul><li>Metastability and MTBF </li></ul><ul><li>Common synchronization mistakes </li></ul><ul><li>Advanced synchronization with EDA tools </li></ul>
    3. 3. Multiple Clock Domain (MCD) Designs
    4. 4. Multiple Clock Domains (1) <ul><li>Where can I encounter MCD? </li></ul><ul><ul><li>Everywhere! </li></ul></ul><ul><li>Single clock domain distribution is cumbersome in large designs due to: </li></ul><ul><ul><li>Variations (cells and interconnect) </li></ul></ul><ul><ul><li>Clock uncertainty (skew) limits the performance </li></ul></ul><ul><ul><li>Actually we always have ‘mesochronous’ clocks (same freq, slightly different phase), which are “synchronized” by timing assumptions (maximal skew) </li></ul></ul>
    5. 5. Multiple Clock Domains (2) <ul><li>System-on-Chip (ASIC or FPGA) </li></ul><ul><ul><li>Usually consists of multiple IP-blocks </li></ul></ul><ul><ul><li>Each IP works with its own clock </li></ul></ul><ul><ul><li>Local / Global clock gating </li></ul></ul><ul><ul><li>Dynamic Voltage and Frequency Scaling (DVFS): </li></ul></ul><ul><ul><ul><li>The speed of each module may change over time for power reduction </li></ul></ul></ul>
    6. 6. Taxonomy of Multiple Clock Domains R. Dobkin, R. Ginosar, &quot;Fast Universal Synchronizers,&quot; PATMOS, 2008 0 drifts Multi-synchronous Asynchronous f d >  Periodic f d <  Varies Plesiochronous 0  c Mesochronous 0 0 Synchronous  f  Class
    7. 7. Inter-MCD Communication <ul><li>Data transfer between different clock domains should be performed carefully </li></ul><ul><li>Incoming data change near receiver clock sampling edge causes metastability , which may lead to a functional failure </li></ul><ul><ul><li>Either set-up or hold time is not satisfied </li></ul></ul>
    8. 8. Metastability and MTBF
    9. 9. Metastability <ul><li>What happens when the data changes during sampling? </li></ul><ul><li>The sampling FF becomes metastable </li></ul><ul><li>Metastability : the FF goes into an unstable intermediate state presenting non-deterministic delay </li></ul>
    10. 10. Asynchronous Failures Clock t pd t su + t h © 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures In 1 Out 1 In 2 Out 2 Data conflict Long Delay In 3 Out 3 Metastability Terrible data conflict All look fine in RTL simulation! Rarely caught in GL (SU/H Warnings)! Do YOU run GL on your FPGA design?
    11. 11. Synchronization Failure <ul><li>Not a singular problem! It spreads through the entire circuit, causing total failure </li></ul>Long delay due to M/S causes violation of cycle time Failures due new M/S event or incorrect function
    12. 12. M/S Handling: The Two-Flop Synchronizer <ul><li>Allow time for Metastability settling </li></ul><ul><li>Why two flops? (could actually be 1,2,3…) </li></ul><ul><li>Settling time (S): 2 cycles </li></ul><ul><li>Latency (from RDY+ to data latching): At least 2, up to 3 </li></ul><ul><li>Why synchronize RDY and not data? </li></ul><ul><li>Is this circuit enough? (NO) </li></ul>data BFF Clock B FF1 FF2 RDY enable
    13. 13. MTBF Mean Time Between Failures <ul><li>Given metastability at t = 0, probability of metastability at t > 0 = e -t/   </li></ul><ul><li>  2 FO4 gate delay </li></ul><ul><li>Failure: Still metastable by next clock </li></ul><ul><ul><li>Failure = p(enter m.s)  p(still m.s. after T) </li></ul></ul><ul><ul><li>Rate(failure) = Rate(enter m.s)  p(still m.s. after T) =W  F c  F d  e -T/  </li></ul></ul><ul><li>MTBF = 1/ Rate( failure) = </li></ul>
    14. 14. MTBF (various frequencies) One day One year 100 years 10K years 200MHz 400MHz 600MHz 800MHz 1 GHz © 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures
    15. 15. 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! 90nm NORMAL © 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures
    16. 16.  vs. V DD and temperature <ul><li>Tau significantly increases at low temperature and low supply voltage </li></ul>© 2003 Prof. Ran Ginosar, Technion, 048878-VLSI Architectures
    17. 17.  : Recent findings (1) S. Beer, R. Dobkin, R. Ginosar, A. Kolodny, &quot;The Devolution of Synchronizers,&quot; Proc. of ASYNC, 2010. We thank our partner GiDEL for supporting this research. We also thank Freescale Semiconductor for their support.
    18. 18.  : 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, &quot;The Devolution of Synchronizers,&quot; Proc. of ASYNC, 2010.
    19. 19. Common Synchronization Mistakes
    20. 20. Not Really Errors ! <ul><li>Most examples actually work as planned </li></ul><ul><li>They may not scale, or not be portable </li></ul><ul><li>They may fail when assumptions change </li></ul>
    21. 21. Avoiding Synchronization <ul><li>Myth: “since MTBF is a million years, there is no metastability and I don’t need a synchronizer” </li></ul><ul><li>Truth: </li></ul><ul><ul><li>Lots of metastability events per second </li></ul></ul><ul><ul><li>Design should be “metastability-tolerant”, not “metastability-free” </li></ul></ul>
    22. 22. One Flop Synchronizer <ul><li>Long delay may lead to setup violation </li></ul><ul><li>Works if T SETTLE +T PD +T SETUP < T CYCLE </li></ul><ul><li>Use with caution, only in latency-critical situations </li></ul><ul><ul><li>Real life – year 2005: 10MHz design with hundreds of clocks (signals used as clocks). Works, although unintentionally… </li></ul></ul>
    23. 23. Greedy Path <ul><li>Typically wrong “edge detector” </li></ul><ul><li>Advise against in SoC methodology </li></ul><ul><li>Use with caution, only in latency-critical situations </li></ul>
    24. 24. Parallel Synchronizer <ul><li>This one is extremely dangerous ! </li></ul>
    25. 25. Advanced Synchronization
    26. 26. Conclusion from previous slides <ul><li>Growing number of clock domain crossings (CDC) calls for an automatic CDC handling approach: </li></ul><ul><ul><li>Correct by design flexible synchronizer IPs </li></ul></ul><ul><ul><ul><li>Customized for the specific targeted FPGA / ASIC technology </li></ul></ul></ul><ul><ul><ul><li>Enforced methodology avoiding synchronization pitfalls </li></ul></ul></ul><ul><ul><li>Tool-based CDC verification </li></ul></ul><ul><ul><ul><li>Sign off the design for each new change including porting to another technology </li></ul></ul></ul>
    27. 27. Correct by design synchronizers <ul><li>Guided requirement specification </li></ul><ul><li>Different interface protocols </li></ul><ul><li>Simulation models </li></ul><ul><li>Synthesis constraints </li></ul><ul><li>Efficient clock relation handling </li></ul><ul><li>Different operating conditions handling </li></ul><ul><li>FPGA/ASIC design flows support </li></ul>vSync Generator
    28. 28. Tool-based CDC verification vSync Checker <ul><li>CDC Identification </li></ul><ul><li>CDC Classification </li></ul><ul><li>Different operating conditions handling </li></ul><ul><li>Design Reliability Grading </li></ul><ul><li>RTL and GL support </li></ul><ul><li>Similar tools are available from Mentor, Atrenta and Real Intent </li></ul>
    29. 29. Summary <ul><li>Synchronization is essential in most of the designs we deal with today </li></ul><ul><li>Analyze all system requirements including reliability before choosing correct synchronizer </li></ul><ul><li>Need EDA tools for reliable integration of multiple CDCs </li></ul><ul><li>Validate each synchronizer </li></ul><ul><ul><li>Make this part of design methodology </li></ul></ul><ul><ul><li>Use EDA tools for CDC verification </li></ul></ul>
    30. 30. Thank you! You are welcome to visit us at www.vsyncc.com