Clock Domain Crossing (CDC)

Clock Domain Crossing (CDC) Erik Seligman CS 510, Lecture 17, March 2009

Agenda • Introduction to Clock Domain Crossing (CDC) • Basic Synchronizers • Datapaths and Reconvergence • Handshake Synchronization • Checking CDCs With Conformal

What Is A Clock Domain Crossing (CDC)? • Different clocks within a single design • Many possible reasons, here are a few: • Complying with multiple protocols • SoC Integration: IP from many sources • Saving area/power, limiting fast clock use • Dangers when signals cross domains • Incorrect functionality if not synced • Not properly covered by validation

Review: Setup & Hold Time • Each flop has a setup and hold time • Setup time: Time before clk edge • Hold time: Time after clk edge • Data expected ready by setup time, and stable during hold time clk data_good bad_setup bad_hold

Problems At Asynchronous Clock Domain Crossings • When does new value arrive? • Source clk not coordinated with dest clk • Chance of arriving in setup/hold window • What does this mean? • Possibility of ‘metastable’ (halfway) state • Value may settle either way • Multiple fanouts may detect different values 1 1 good 0 0 bad

Why Discuss in FV Class? • CDC is low hanging fruit for FV vendor • Needs deeper analysis than typical linting • But light checks compared to hardcore FV  CDC often done with FV tools • Mentor 0in, Cadence Conformal, RealIntent • In other direction, Lint vendors expanding to CDC: Synopsys LEDA, Atrenta Spyglass • Some CDC checks may add assertions • For checking in simulation or FV

CDC Checks in Simulation • Simulation: inject random metastability • Useful, but hard to get right • Sometimes delay a value change • Allow 1-cycle value to be missed • Depends on # of random tests • Technique beyond scope of this class • Class is on formal methods!

How To Safely Cross Domains? • Require synchronizer: structure to reduce risk of metastability • Simplest synchronizer: two flops • Metastability very unlikely: second flop will choose a value if first is metastable • One-cycle uncertainty in transition • Account for in the logic! f3 data f1 f2 out ck ck2

Basic CDC Checks • Structural: Identify asynchronous CDCs • Note: synchronous signals are OK, little metastability risk if properly timed • But same-frequency != synchronous • If no synchronizer, report error • Functional: Assert signal held long enough • Due to uncertainty of capture time • Hold for 2+ receiver cycles: create assert • May need longer depending on relative freq • More detailed discussion in TOV lecture

Another Check: Combo Logic data[2] f1a ck f3 data[1] f1b f2 out[1] ck ck2 • Why is combo logic bad on sync path?

Another Check: Combo Logic data[2] f1a 0->1 ck 0? f3 data[1] f1b f2 out[1] 0->1 ck ck2 • Why is combo logic bad on sync path? • Remember: uncertain capture time • Suppose f1a and f1b both transition 01

Another Check: Combo Logic data[2] f1a 0->1, but slower ck 1 f3 data[1] f1b f2 out[1] 0->1 ck ck2 • Why is combo logic bad on sync path? • Remember: uncertain capture time • Suppose f1a and f1b both transition 01 • For an instant, maybe f1a!=f1b… •  f2 == 1

Danger: False Negatives! • CDC can be a ‘noisy’ check • Many reported unsynced crossings are OK • Common reasons for false negatives?

Danger: False Negatives! • CDC can be a ‘noisy’ check • Many reported unsynced crossings are OK • Common reasons for false negatives? • Constant signals (VSS, VCC) • Near-constant signals • Parameters set during reset & never changed • Reset pins! • Alternate-mode signals • Valid in only some operating modes, includes clk • Scan and other ultra-slow interfaces • Use your tool carefully & specify these things! • “Blind” run rarely seen as valuable • Don’t waste DE time reporting bogus errors

Datapaths & Off-By-One Issue f3 data[2] f1 f2 out[2] ck ck2 f3 data[1] f1 f2 out[1] ck ck2 f3 out[0] data[0] f1 f2 ck ck2 • What happens on transition from 000 to 111?

Datapath Problem • Each synchronizer may be off by a cycle • All are independent • So during transition from 000 to 111, may sense 001, 010, 011, … or any other value! • Can we solve thru logic requirements? • Need to make sure only one bit can change • Then we know only real values are seen

Grey Codes: A Functional Solution • Common solution to datapath issue • Allow only one bit to change at a time • Thus, any value seen *did* actually appear • From 000, can only go to: 100,010,001 • And if the bit changes a cycle soon/late, only a real value is seen • 2-bit grey codes example: 00,01,11,10 • Can check with generated assertions • Functional (FPV-like) check in general

SVA Assertion: Grey Code • “Signal foo[6:0] is grey-coded” • Can you translate to SVA?

SVA Assertion: Grey Code • “Signal foo[6:0] is grey-coded” • Can you translate to SVA? gc_assert: assert property ( $countones(foo ^ $past(foo)) <= 1);

Reconvergence Problem • More general view of datapath issue • Problem: reconvergence of synced bits • CDC checks can flag cases • Is there a better way to synchronize? • Such that grey codes aren’t needed • Yes! • Have control signal coordinate data with mux

Mux-Based Sync f3 data[1] f1 out[1] ck ck2 out[0] data[0] f1 f3 ck en

Handshake/FIFO Protocols • Clock freq maybe configurable / unknown • Hard to design previous syncs for all cases • Hard to properly check for all cases • Maybe sometimes overconservative • Solution: handshake protocols • Sender stores data in FIFO • Explicit request/response for data • More logic & harder to check, but powerful

Handshake Sync Example (From Cadence white paper, see References)

Conformal CDC Checks • Included with Conformal license • That’s why we have it! • Set up env for Conformal version 8 • zsh • source ~eseligma/startup.cadence8 • Start lec with ‘-verify’ option • Actually runs separate core binary • Don’t try to do FEV in same session

Sample LEC CDC Do File(Structural Checks) read design <RTL design> set clock_domain rule -derived -either_phase -extract add synchronization rule dff_sync -dff 2 infinity -sync_chain buffer -cdc_path buffer single_destination -from -all -to -all add synchronization rule all2allmux2 -mux 0 0 -cdc_path buffer single_destination -from -all -to -all set cdc option -convergence_check add cdc check -structural -source -all -destination -all -from -all -to -all validate

Sample LEC CDC Do File(Structural Checks) read design <RTL design> set clock_domain rule -derived -either_phase –extract add clock 0 clk1 add clock 0 clk2 set sys mode verify add synchronization rule dff_sync -dff 2 infinity -sync_chain buffer -cdc_path buffer single_destination -from -all -to -all add synchronization rule all2allmux2 -mux 0 0 -cdc_path buffer single_destination -from -all -to -all set cdc option -convergence_check add cdc check -structural -source -all -destination -all -from -all -to -all validate

Debugging with Tools Menu: Clock Domain Crossing

Diagnosing A Missing Sync

Diagnosing A Convergence Issue

References / Further Reading • http://www.edadesignline.com/howto/205201913;jsessionid=Y5OIFHG055FBKQSNDLPSKHSCJUNN2JVN?pgno=1 • http://w2.cadence.com/whitepapers/cdc_wp.pdf • http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2069034541 • http://www.design-reuse.com/articles/9482/reducing-false-errors-in-clock-domain-crossing-analysis.html

Clock Domain Crossing (CDC)

Clock Domain Crossing (CDC)

Presentation Transcript

CDC Foundation Doing More, Faster

Yeast cell cycle landmarks

TPF Performance Task Force Update

CDC IT Directions CDC Project Management Summit Jim Seligman CDC Chief Information Officer

Overview of CDC Organization Structure

CLOCK

Overview of CDC Organization Structure

The Cottages At Hickory Crossing Dallas’ Premier Model of Permanent Supportive Housing

CDC

CDC

Diabetes

CDC

Consumer Directed Care Plus

Clock

Clock

SIM Maine CDC Status

Crossing

CLOCK

Further information: cdc-uganda@cdc

Verification of Clock Domain Refinements in the Synchronous Design Environment

Java phoneME CDC AMS

Clock Domain Crossing (CDC)