7. Verifying Clock Domain Crossingjaa/verification/lectures/7-2.pdf · (CDC) into synchronizers {...

$: 7. Verifying Clock Domain Crossingjaa/verification/lectures/7-2.pdf · (CDC) into synchronizers { this eliminates combinational glitches Source: Yu, \Clock Domain Crossing Design",Verilog$
Verification of Digital Systems, Spring 20197. Verifying Clock Domain Crossing 1

7. Verifying Clock Domain Crossing

Jacob Abraham

Department of Electrical and Computer EngineeringThe University of Texas at Austin

Verification of Digital SystemsSpring 2019

February 14, 2019

ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 1 / 25

Outline

Introduction to issues related to clock domain crossing (CDC)

Synchronizers

CDC protocols

Verification of CDC

Commercial tools

Further Reading:C. E. Cummings, “Clock Domain Crossing (CDC) Design andVerification Techniques Using SystemVerilog”, SNUG 2008J. Yu, “Clock Domain Crossing Design – 3 Part Series”, VerilogPro, http://www.verilogpro.com/M. Litterick, “Pragmatic Simulation-Based Verification of ClockDomain Crossing Signals and Jitter using System VerilogAssertions”, DVCON 2006.


Department of Electrical and Computer Engineering, The University of Texas at AustinJ. A. Abraham, February 14, 2019


Multiple Clock Domains

Clock Domain Crossing (CDC)

Different clocks in a large design, e.g., SoCs

Cases where CDC exist

Multiple signalling protocols on chipIntegrating IP from different sourcesLower power/area designs, limiting fast clocks

Dangers when data signals cross domains

Synchronization necessary for correct functionalityVerification holes


Review: Clocking – Setup and Hold Times




Clock Skew

Interconnect delay is becoming dominant in deep submicroncircuits

Could have hold time or setup time violations, especially with smalllogic delays


Metastibility and Synchronization Failures

Synchronization failure may occur if the data and clock donot satisfy setup and hold time restrictions

Although a latch has two stable states, it is inherently analog,and, under the right conditions, can enter a metastable state(where the output is between 0 and 1)Random noise will push the output to either 1 or 0 from ametastable statehowever, this may take some time, and the output may beincorrect

Equations can be derived for the probability ofsynchronization failure

Possible to find the mean time between failures (the output isnot resolved within a given time)




Example of Metastable Behavior

SPICE simulations of data being moved closer to clock edge

Circuit

SPICE waveforms

Solutions

Cascaded latches to reduce probability of failure

Self-timed systems


Analyzing Metastable Behavior

Probability of a Metastable State

1 Frequency of the destination domain

2 Rate of data crossing the clock boundary

Mean Time Before Failure (MTBF)

fclk: Synchronizing clock frequency

fdata: Frequency of data changing

X: Other factors

MTBF =1

fclk + fdata +X

Source: Dally and Poulton, Digital Systems Engineering, 1998




Clock Domain Crossing Signal Types

Static signals which only change during configuration (notduring operation)

Regular signals needing synchronization (such as interruptrequests)

Level or pulse-based handshake across interfaces(request-acknowledge)

Asynchronous FIFO

SVA for static signals

property p_static(clk, run, data);

@(posedge clk)

!$stable(data) |-> !run;

endproperty : p_static

assert property (p_static(clk_a, run_a, {x, y, z}));


Two Flip-Flop Synchronizer

Even if the first flop becomes metastable, due to the input datachanging very close the the clock edge (within setup/hold timeconstraints), there is still a full clock for the signal to becomestable before being sampled by the second flop

Generally a good idea to register signals in the source clockdomain before sending them across the clock domain crossing(CDC) into synchronizers – this eliminates combinational glitches

Source: Yu, “Clock Domain Crossing Design”, Verilog Pro, March 2016




SVA for 2-Flip-Flop Synchronizer

property p_stability;

@(posedge clk)

!$stable(d_in) |=> $stable(d_in) [*2];

endproperty : p_stability

property p_no_glitch;

logic data;

@(d_in)

(1, data = !d_in) |=>

@(posedge clk)

(d_in == data);

endproperty : p_no_glitch

assert property(p_stability);

assert property(p_no_glitch);


Registering Source Signals into a Synchronizer

Good practice to register data signals in the source clockdomain before sending them across a clock domain crossinginto synchronizer

Eliminates combinational glitches – these increase the rate ofdata crossing the clock boundary, reducing MTBF

Synchronizing slow signals into fast clock domain

Easy case

If the faster clock is > 1.5X the frequency of the slow clock

Faster destination clock will sample the slow signal more thanonce

Simple two-flop synchronizer would be fine




Registering Source Signals into a Synchronizer, Cont’d

If a pulse on the fast signal is shorter than the period of theslow clock, it can disappear before being sampled

Rule of Thumb: Signal must be wider than 1.5X the cycle width ofthe destination clock (Litterick, DVCon, 2016)


Single-Bit Synchronizer with Feedback Acknowledge

Source: Yu, “Clock Domain Crossing Design”, Verilog Pro, March 2016ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 13 / 25



Multiple Signals Across Clock Domain Crossing

Signals should not be synchronized individually

Two signals from the same source clock domain may arrive indifferent clock cycles in the destination domain, due to skew



Sequencing Signals Across Asynchronous CDC

Synchronizing two signals that require precise sequencing can bedisastrous

Data can be sent to a multi-bit flip-flop, with the control signalsynchronized through a two-flop synchronizer





Multi-Cycle Path Synchronizer – I

Idea: Convert pulse synchronization event into a single togglebefore being resynchronized into the destination clock domain



Multi-Cycle Path Synchronizer – II

Then, convert toggle back to a pulse in destination clock domain

Source: Yu, “Clock Domain Crossing Design”, Verilog Pro, March 2016ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 17 / 25



Complete Multi-Cycle Path Synchronizer

Note: Input data has to be held until synchronization pulse loadsthe data in the destination clock domain – takes at least twodestination clocksLimitation is that input data only needs to be synchronized notmore than once every three destination cycles



Multi-Cycle Path Synchronization with FeedbackAcknowledge





Synchronizing Pointers Across Clock Domains

Problem: Multiple-bit changesSolution: Use a Gray code counterExample Grey code counter for a FIFO

Source: Yu, “Dual-Clock Asynchronous FIFO in SystemVerilog”, Verilog Pro,

Dec. 2015


Asynchronous FIFO

Data written into the FIFO from the source clock

Data read from the FIFO in the destination clock domain

Gray-coded read and write pointers are passed to the clockdomains to generate full and empty status flags

Source: Litterick, “Pragmatic Simulation-Based Verification of Clock Domain

Crossing Signals and Jitter using System Verilog Assertions”, DVCON 2006ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 21 / 25



Assertions for Asynchronous FIFO

property p_bad_access(clk,inc,flag);

@(posedge clk)

inc |-> !flag;

endproperty : p_bad_access

property p_gray_code(clk,rst_n,data);

@(posedge clk) disable iff (!rst_n)

!$stable(data) |-> $onehot(data ^ $past(data));

endproperty : p_gray_coded

int wcnt, rcnt;

always @(posedge wclk or negedge wrst_n)

if (!wrst_n) wcnt = 0;

else if (winc) wcnt = wcnt + 1;

always @(posedge rclk or negedge rrst_n)

if (!rrst_n) rcnt = 0;

else if (rinc) rcnt = rcnt + 1;

Source: Litterick, DVCON 2006ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 22 / 25

Assertions for Asynchronous FIFO, Cont’d

property p_data_integrity

int cnt; logic [DSIZE-1:0] data;

disable iff (!wrst_n || !rrst_n)

@(posedge wclk)

(winc, cnt = wcnt, data = wdata) |=>

@(posedge rclk)

first_match(##[0:$] (rinc && (rcnt == cnt)))

##0 (rdata == data);

endproperty : p_data_integrity

assert property(p_bad_access(wclk,winc,wfull));

assert property(p_bad_access(rclk,rinc,rempty));

assert property(p_gray_code(wclk,wrst_n,wptr));

assert property(p_gray_code(rclk,rrst_n,rptr));

assert property (p_data_integrity);

Source: Litterick, DVCON 2006ECE Department, University of Texas at Austin Lecture 7. Verifying Clock Domain Crossing Jacob Abraham, February 14, 2019 23 / 25



Steps for Verifying Clock Domain Crossings (Atrenta)

Check for the presence of valid synchronizers

All asynchronous crossings and synchronous wheremetastability may occur

Check for the presence of separately synchronized signalswhich are converging

Ensure appropriate signals are Grey codedIf necessary, redesign synchronization to have a commoncontrol signal

Verify various crossings for possible data loss

All fast to slow crossingsSlow to fast crossings where clock edges may be closeAll asynchronous crossings

Check special synchronization schemes

Handshake synchronizationFIFO synchronizationMUX recirculation


Commercial Tools for Clock Domain Crossing Checks

Cadence Conformal

Synopsys Spyglass (Atrenta)

Mentor Questa



7. Verifying Clock Domain Crossingjaa/verification/lectures/7-2.pdf · (CDC) into synchronizers {...

Documents

Transcript of 7. Verifying Clock Domain Crossingjaa/verification/lectures/7-2.pdf · (CDC) into synchronizers {...