235568470 Cdc Tutorial Slides

Clock Domain1

Clock Domain2

Clock Domain Crossing: Issues and Solutions Udit Kumar, DCG Sakshi Gupta,TRnD Bhanu Prakash, DCG March 12 , 2012

Agenda  What is Clock Domain Crossing (CDC)  The Problem ? The trend…  Leads to Chip Failure ….no software fix..

 How CDC Issues look like  And recommendations around them

 Special case CDC Issues  Design is CDC OK but Silicon has issues ??

 Different flows available (with Atrenta Spyglass) when to use what..  Appendix 2

List of Keywords Keyword

Meaning

CDC

Clock domain Crossing

Structural Check

Looking into structure of design.

Functional Check

Apply formal method to prove design works as expected. (Kind of Simulation!)

Gray code

Encoding where state change has only1 bit change

Spyglass

An EDA tool to perform CDC analysis, from Atrenta

ip_block

Spyglass term, to check CDC at IP boundary.

sgdc

Spyglass design constraints

Abstract model

A CDC model of an IP which can be used at SoC

3

Clock in a Digital System Clk

F F1

F F2

 Digital system consists of combinational and sequential logic.  Clock triggers flops leading to state changes (viz. State Machines).  Clock is the fastest signal in a synchronous system.

Main Properties Of Clock  A clock has

Tp

 Period of repetition (linked with its frequency)  Phase depicts rise & fall transitions  A flop can be triggered thru any of clock phases.

+ve -ve

Phase

Domain of a clock  Logic which is triggered by clock (or derived clocks)  Also known as Synchronous system.

 Conversely, domains with clocks of variable phase and frequency are different clock domains.  Also known as Asynchronous. Domain 27Mhz

Domain 100Mhz

Why have multiple clock domains?..  SoC have multiple interfaces with very different clock frequencies

Why have multiple clock domains?  To reduce Clocktree balancing complexities.  Consider clocks to various blocks as asynchronous. Synchronous clocks but considered Async.

The CDC Path Setup/ Hold

Setup/ Hold

 When clocks are a-synchronous, the signals that interface between are called clock domain (CDC) paths.  Within each domain, data transfer is protected by Setup & Hold checks of flops.  No check exists on CDC path

CDC is related to Asynchronous clock domains

The CDC Paradigm

 Heterogeneous applications having Dozens of Clocks  Traditional STA checks or functional simulation do not verify CDC problems!  Responsibility for validating CDC issues is shifting from verification engineers to logic designers

Why is it important?  Multiple cases of Chip failure due to this effect across the world.  Chip Failures in past, failure Cost.  – Wrong clock connections  – IP data convergence issue.

st_ck soft_reset_active_stbus

gdp_proc_clk

st_ck

ctrl_req_int

ctrl_req

11

Clock Domain crossings Dos & Don't

Meta-stability  A flip-flop needs input to be stable before and after the clock edge. (Setup & Hold Time) .  In CDC crossing, there will be setup & hold violations.  Then, the output of flip-flop may take much longer time to reach a valid logic level. This is called metastability.

Very close

MTBF - Mean Time Between Failure   

Reciprocal of failure rate Should be as high as possible Failure means signal goes metastable after first stage synchronizer and continues to be metastable one cycle later when it is sampled in the second stage synchronizer flop. Techno dependent

Synchronizing clock frequency

Duration of metastable output (1/Tau)

data changing frequency

14

Example on how to calculate MTBF  MTBF (Mean Time Between Failures): Average time a system will run between failures.  A system has 4000 components with a failure rate of 0.02% per 1000 hours. Calculate MTBF.  No of failure per hour=  (Failure rate) * (Number of components)  (0.02 / 100) * (1 / 1000) * 4000 = 8 * 10-4 per hours

 MTBF = 1 / (8 * 10-4 ) = 1250 hours

15

Clock crossing: Minimum Solution "A synchronizer is a device that samples an asynchronous signal and outputs a signal that is synchronized to a local or sample clock” [1]. Asynchronous signal FF1

D

Da

Q

A

synchronizer

FF2

D

Q

AW

FF3

D

Q

As Synchronized signal

C1 Clk C lk A A W A S

Synchronizing cell should come from special cell library.

16

Special Cell Properties

Sync. Cell has less Tau

Total number of synchronizer instance in the system contribute to system MTBF.

17

Having a Synchronizer is not enough, one needs to follow more rules !

18

No combinational logic at crossing point Unconstrained path has delay imbalance, leading to loss of data & glitches.

Make sure that CDC signal is directly coming from a flop. 19

Re-convergence after Sync Can also Lead to Bad FSM triggering

Actual

Chip Killer !!

Compute the controls & then do one transfer across domain

20

Crossing fast to slow domain Data Hold problem (Signal crosses from a fast clock domain to a slow clock domain)

To avoid CDC issues, Hold the data till a time-out (using Pulse extenders).

Q1

D1

Clk1 Clk1 Counter

==N

clk2

Hold data (for minimum 3 RX clock edge) till the transfer takes place (Traffic police).

21

Handshake based data transfer  Handshake, where control path is synchronized & data path is follower.

clk_A domain

clk_B domain

 Disadvantage  Delay in synchronizing control signals (in both directions) affects the thru-put. Logic in control path ensures that transfer on “Data bus” is coherent.

22

Bulk data transfer using FIFO  When throughput is important, FIFO based synchronizers fit well.

clk_A Domain

clk_B Domain

Control bits transfer should be gray coded. Flow control using FIFO’s overflow/underflow. 23

Types of CDC Checks  Structural Checks  looks for presence of corrective logic (viz. synchronizer) at crossing.

 Functional Checks  Formally verify that protection is error free.

Functional CDC (assertion based)

Structural CDC 1

2

3

1. Missing or incorrect synchronizer. 2. In-correctly implemented CDC protocols. 3. Re-convergence issue.

24

Why Functional CDC Checks ?  Validates by looking at hardware that  FIFO is being written when overflow?  Hand shaking scheme not functionality correct ?  Gray-code behavior breaks?

25

Not so obvious Silicon Issues

 CDC OK on RTL……  Can we assume Silicon will work ?

26

Multi-bit data bus CDC issue, due to physical implementation

Logic in Serial (Control) Path is used to ensure that transfer on multi-bit (Data) is coherent. Loop Delay of Control Path should be Less than Stable time of Data

27

Physical View Huge delay imbalance

100 ns

1ns

Not Checked In flow

Capture Period : 5 ns

Data path is severely skewed due to No constraints & also due to Physical constraints 28

Constraints for such paths Skew Limit for the bus 100 ns

1ns

Capture Period : 5 ns

Need to constrain data bus even though transfer is on an Asynchronous interface. 29

Related Issues Shoot-thru with-in a clock domain

Clock assignment leading to shootthru Shoot Thru @IP data_int

data_in

clock

dout_out

D

clk

clk

Shoot Thru may occur if capture clock is delayed

clock2

Any assignment in the clock path.

VHDL: Due to Delta Delay In Verilog NonBlocking can trigger new events

31

How to solve the shoot-thru problem  Silicon behavior is no longer the same as RTL simulation  Root cause is change in scheduling of events in a RTL simulator

 How to avoid ?

 Force event scheduling at such crossings by explicit delay  X_delayed <= x after 1 ns; (VHDL)  X_delayed <= # 1 x; (Verilog)

NOTE: Force scheduling should not be done on clock path

Checker for this is on the way… 32

Glitch across CDC paths

33

Agenda       

Glitch in CDC Impact of Glitch in Asynchronous circuits Recommendations to avoid glitch in CDC Different approaches to run CDC checks on SOC Solution to CDC problems - SpyGlass tool How Spyglass tool works? Conclusion

34

Glitch in CDC  Glitch is an un-wanted pulse, mostly created when multiple signals converge thru. Combo logic  STA is not applicable to asynchronous interfaces Expected o/p : Constant Low Actual o/p : Low-High-Low

35

Recommendations to avoid Glitches  Don’t use combinational logic on data path

Ck1

Ck1

Ck2

Ck2 Ck1

36

Recommendations to avoid Glitches  Don’t use combinational logic on control path Q

Q

qualifier

qualifier Ck1

Ck1

Ck2

Ck2

37

Recommendations to avoid Glitches  Always use Glitch Free Mux in RTL  Tools can change Mux to AND-OR

38

Now, Checking the CDC Types of Checks When to use what?

39

Different Approaches to FULL Chip CDC  Full Chip FLAT (SINGLE RUN)  CDC verification will be done on the full SOC  Reports Crossings inside the various blocks CDC Verification done for crossings within & outside the blocks

Top_Block

40

Different Approaches to FULL Chip CDC  Hierarchical approach - “ip_block” based approach  Blocks CDC clean  Crossings inside the various blocks in the SOC will not be reported

41

Different Approaches to FULL Chip CDC  Hierarchical approach – “Abstraction” based approach  Blocks CDC clean  Crossings inside the various blocks in the SOC will not be reported

42

Conclusion on CDC checks  Need to have a new check exclusively for CDC.  CDC checks should be done both on RTL & Netlist (at least for Glitch!)  Structural checks should be done before Functional CDC checks to avoid noise  SoC level checks can be done at Interface of IPs.

43

List of Keywords Keyword

Meaning

CDC

Clock domain Crossing

Structural Check

Looking into structure of design.

Functional Check

Apply formal method to prove design works as expected. (Kind of Simulation!)

Gray code

Encoding where state change has only1 bit change

Spyglass

An EDA tool to perform CDC analysis, from Atrenta

ip_block

Spyglass term, to check CDC at IP boundary.

sgdc

Spyglass design constraints

Abstract model

A CDC model of an IP which can be used at SoC 44

References [1] William J. Dally and John W. Poulton, Digital Systems Engineering, Cambridge University Press, 1998 [2] Mark Litterick, “Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter Using SystemVerilog Assertions,” DVCon 2006 www.verilab.com/files/sva_cdc_paper_dvcon2006.pdf [3] Clifford E. Cummings, “Clock Domain Crossing (CDC) Design & VerificationTechniques Using SystemVerilog”, SNUG-2008, Boston. [4] Atrenta Spyglass, http://www.atrenta.com/solutions/spyglass-family/spyglass.htm

45

Thanks Thanks to DCG IP & SoC team to discuss various issue and for partnership in different projects CDC analysis.

APPENDIX

Shoot Thru can occur in verilog?

Why ? Non-blocking assignment can trigger additional events in the same time step.

ref : SNUG 2002 48

Verilog issue example 1

2

always @(posedge clock or negedge rst_n) begin if (rst_n == 1'b0) begin clock_half <= 1'b0; end else begin clock_half <= ~clock_half; end Non-blocking end assignment completion always @(posedge clock or negedge rst_n) begin if (rst_n == 1'b0) begin enb <= 1'b0; cnt <= 2'b0; end else begin cnt <= cnt +1; if (cnt == 2'b10) enb <= ~enb; else enb <= enb; end End

module dut(rst_n,clock,clock_half,enb,sig_b); input rst_n, clock, clock_half, enb; output sig_b; reg sig_a; reg sig_b;

3

4

always@(posedge clock_half or negedge rst_n) begin if(rst_n == 1'b0) begin sig_b <= 1'b0; end else begin sig_b <= sig_a; end End always@(negedge rst_n or posedge clock) begin if(rst_n == 1'b0) begin sig_a <= 1'b0; end else begin sig_a <= enb ; end End endmodule

49

Problem (c) – Transfer of Multiple signals across CDC boundary Multiple signal At the CDC boundary

50

Solution (c) - Use control signals to control transfer Control signal At the CDC boundary

Forward path

Reverse path

51

Reset Synchronization  Asynchronous resets must be de-asserted synchronously  Asynchronous de-assertion of resets may put the design into an unintended state asynchronous reset de-assertion in reset reset o_reset

A

F2

B

F3

C

reset de-assertion is synchronized and happens in o_reset after two clock edges

clk_B reset network

Reset Synchronizer reset asserted asynchronously in both reset and o_reset together

clk_B reset o_reset 52

Little's Formula  At steady state, the same number of processes are arriving in a queue as are leaving the queue. In this case, Little's formula applies: n= λW where: n = the average queue length W = the average wait time λ = the average arrival rate of processes If one knows two of the above variables, one can compute the third.