Overview of

CDC Methodology

Synopsys

© Synopsys 2012 1
 Agenda

• Background
• CDC Methodology objectives
• Step-by-step methodology
• Release Checks

© Synopsys 2012 2
 Why CDC Methodology?
• Common issues in design with multiple clock domains
– Unsynchronized signal – causes Metastability
– Incorrect choice of CDC scheme for the signal(s) in question
 E.g Choose level synchronizer for pulse signals
– CDC signal not as per design intent
 E.g data not stable when qualifying signal is being synchronized (DMUX)
– Clock frequency outside the valid range of operation for a given
scheme
– Re-convergence issues in synchronized CDC signals
– Incorrect constraints used during synthesis/PNR
– Isolation of CDC signals in netlist for insertion/placement of meta-
stable flops

© Synopsys 2012 3
 Why CDC Methodology?
• How to address them?
– Tackling complex CDC issues need multi-pronged approach
– Requires disciplined approach at each stage of design and
verification
– No single tool can address all CDC issues
– Well defined and consistent Methodology required for the design
teams

© Synopsys 2012 4
 What the methodology offers?

• Guidelines at each stage

– Design
– Verification
– Synthesis
– Tool usage
– Synchronizer usage
– Sign off criteria

© Synopsys 2012 5
 Guidelines for Architecture Stage
1. Identify clock domains at the highest level of architecture
– Optimum logic partition and trade-off for placing function in specific clock
domain
2. Identify different clock combinations and frequency range
– Helps in deciding proper synchronizer for CDC signals
3. Identify and minimize signals crossing clock domains while
partitioning the design
– Less is always better !
– E.g : Locate state machines and status registers in the clock domain that
they are used in
o Reduces CDC signals;
o Avoids issues for read-2-clear/update status bits
4. Make a list of all signals that cross clock boundaries & operating
frequency of clock combinations
– Working document to cross-reference with CDC signals identified by tool

© Synopsys 2012 6
 Guidelines for Micro-Architecture Stage
• DesignWare Synchronizer Methods
– DesignWare Library provides a set of recommended CDC protocols
available as DesignWare Synchronizer components
– Widely used by a number of customers for many years
– Flexible, configurable and includes features to enable/simplify
verification of CDC paths
– See https://www.synopsys.com/dw/doc.php/doc/dwf/manuals/sync_appendix.pdf
− Basic synchronization — DW_sync
− Temporal event synchronization — DW_pulse_sync,
DW_pulseack_sync
− Simple data transfer synchronization — DW_data_sync,
DW_data_sync_na, DW_data_sync_1c
− Data flow synchronization — DW_fifo_s2_sf, DW_fifo_2c_df,
DW_stream_sync
− And lot of other schemes....

© Synopsys 2012 7
 DW_sync synchronizer
• Flexible FF based synchronizer module with
parameters for
– Signal width (1 to N)
– Number of FF stages (0, 2 with neg-pos, 2, 3, 4)
– Test mode to insert “hold latch” - for meeting hold-times in single
scan-chain across the clock domains
– Verification mode – explained later
• Has synchronous/asynchronous reset inputs
• “test” pin to enable “scan mode”

© Synopsys 2012 8
 DW_pulse* synchronizer
• Flexible synchronizer module based on transferring
toggle signal on input events
– Rising edge, Falling edge, pulse, Both edges, etc
– Internally uses DW_sync for CDC
– Optional Output register stage

© Synopsys 2012 9
 DW_datasync* synchronizer

• CDC for data bus

– Uses DW_pulse*_sync
– Two are shown here
– More available as per
requirement and clock
types

© Synopsys 2012 10
 Guidelines for Micro-Architecture Stage
Guidelines for multiple-FF Register Synchronizers for 1-bit signal
1. Instantiate DW_sync, DW_pulse* components from DW library for
1-bit signal. Do not use code your own synchronizer
– DW_sync for level signal (stable for multiple destination clock periods)
– DW_pulse* otherwise; supports edge/pulse/toggle trigger
2. Two stage synchronizer may not be always appropriate
– Pass separate parameter variable (for F_SYNC_TYPE) to decide # of stages in
each destination clock domain
3. Always register a signal in source clock domain before double
synchronization
4. If DUT’s input signal is directly given to DW_sync, provide an
option to filter (stable for multiple clocks) synchronized signal
– To filter out the capture of glitches in input signals
5. If pseudo-static CDC signal if not synchronized should still be
passed through a dummy (DW_sync with 0 FFs) synchronizer

© Synopsys 2012 11
 Guidelines for Micro-Architecture Stage
Guidelines for Synchronizers for multi-bit signals
1. Instantiate appropriate components from DW library as per CDC
signal’s property/behaviour
– For data synchronization with qualifiers, choose methods from
DW_data_sync*
– For FIFOs, choose methods from DW_fifo_*
– For FIFO controllers, choose methods from DW_fifoctl*
– For gray code synchronizer, use DW_gray_sync
– For group of unrelated signals, can use DW_sync (multi-bit). E.g control
register bits
2. Do not hard-code parameter options but use “defines” for
flexibility
3. Avoid re-convergence by moving logic that uses multiple
synchronized (non-static) signals to source clock domain and
generate separate CDC signal
4. List/describe all CDC synchronizer components in data book

© Synopsys 2012 12
 Guidelines for RTL coding Stage
CDC signal naming conventions
1. Name each clock signals with “clk” prefix followed 1 or 2 letter
suffix
– clka, clk_rx, clk_tx, clkh, etc
2. Name all CDC signals with prefix that indicates source,
destination clocks, type of signal (level, pulse), etc
– r2tl_<xxx> means level signal from clk_rx to clk_tx domain
– sr2tl_<xxx> means synchronized version of above signal
– h2xp_<xxx> means pulse signal from clkh to clkx domain
3. All CDC synchronizers should have unique instance names
with pointer to source signal name and destination clock
domain
– E.g DWC_usb_bcm21_<signal name>_tsyzr for a DW_sync instance with
clk_tx as destination clock
4. Closely link qualifier signal and corresponding data signal by
using DW_data_sync*; Otherwise have similar signal names
Naming to help generation of synthesis constraints and CDC
report review
© Synopsys 2012 13
 Guidelines for RTL coding Stage
RTL Design partitioning
1. Allow only 1 clock per module with functional logic
2. All CDC synchronizers should be instantiated in separate
module; if possible separate module for each combination of
clock pair;
3. For cores with configurable “async or sync reset” option,
connect “reset” signal to
– “rst” input of DW synchronizers in “async” mode and tie “init” input to “1”
– “init” input of DW synchronizers in “sync” mode and tie “rst” input to “1”
4. Default (reset) value of input signal to DW_sync should be “0”;
Otherwise invert before connecting
5. Connect DUT’s scan-mode control signal to “test” input of DW
synchronizers and use paramter define for “TST_MODE”;
Otherwise hard-code both test and TST_MODE to “0”
6. Update working document of list of CDC signals & exception
report with justifications for unsynchronized CDC signals

© Synopsys 2012 14
 Guidelines for RTL & GL verification
1. Use define for “VERIF_EN” parameter of DW synchronizers
– Option to select range of random delays of 0-1, 0-1.5, 0-2, 0-3 destination clock
cycles before synchronizer
2. Each configuration must be regressed with VERIF_EN = 2 and
DW_MODEL_MISSAMPLES enabled before compilation
– Emulate meta-stability delays due to set-up/hold violations in RTL simulations
– For multi-bit CDC synchronizer (and even for dummy synchronizer), each bit
delay has individual “random” delay
– Enables detection of functional issues due to re-convergence & multi-bit
synchronizer skews

© Synopsys 2012 15
 Guidelines for RTL & GL verification
3. Design must be regressed with:
1. lowest, typical and highest ratio of source and destination clock frequency
in RTL and GL simulations
2. In CRV test environment, add random frequency variation of destination
clock within target range during simulations
Configuration pclk (MHz) hclk (MHz) hclk offset w.r.t. pclk (ns)
No.
(Offset 0 ns)
1 30 99.969 Random4 (Example: -12.0863)
2 48 99.99 Random5 (6.687)
3 60 100.345 Random6 (13.45)
4 30 30 Random1 (1.1511)
5 48 30 Random2 (15.0891)
6 60 30 Random3 (-0.9824)
7 30 200.096 Random7 (-2.0863)
8 48 200.01 Random8 (16.687)
9 60 201.63 Random9 (3.45)

4. GLS scripts to be generated and packaged such that GLS with

“timing” check can be run
– This requires to identify first stage of CDC synchronizer and declare
“no_timing_check” on these specific paths to avoid “X” generation &
propagation

© Synopsys 2012 16
 Guidelines for RTL verification
Use of assertions for CDC verification
1. To check/validate the assumptions made for selection and
operation of CDC synchronizer, add assertions to check
– Qualified data is stable after its qualifier has changed in the source domain
– Input signal in DW_sync is stable for at least 2 destination clock periods
and does not have glitches
– Unsynchronized CDC signals are stable for long periods or change only
once after reset; They are supposed to be pseudo-static
– When a FIFO is being flushed, reset or cleared, there must not be any push
from or pop into the FIFO
– Pointers do not jump values (unless reset on both domains) when gray-
code synchronizer is used
– For free-running FIFOs with equal data rate at input and output &
continuous data transfer (e.g SDR to DDW), read and write pointer
difference is always > 1

© Synopsys 2012 17
 Guidelines for RTL verification
Use of assertions for CDC verification
2. Validate re-convergence triggers during simulation
regressions with DW_MODEL_MISSSAMPLES
– Collect statistics of all random values of “mis-samples”;
– Check that there are more “non-zero” delay rather than “0” delay injected in
each DW_sync instance; Increases probability of finding re-convergence
issues
– Note that some of the assertions mentioned in #1 will have to
disabled/changed during regression with DW_MODEL_MISSAMPLES with
random delay range of 0-3 clocks (un-realistic scenario)

Some of these assertions are added in relevant DW_sync,

DW_data_sync, synchronizers of next release (2012.06)

© Synopsys 2012 18
 Guidelines for Synthesis constraints
1. Set false-path only for unqualified (independent) CDC signals
reaching first-stage of DW_sync or unsynchronized CDC signals
2. Use set_max_delay (of 1 dest clock) for qualifier signal reaching
first-stage of DW_sync inside DW_datasync
– Else constraint #3, below will not be proper
3. Use set_max_delay (#of sync stages – 0.5 dest clock period) for
qualified data signal inside DW_datasync
– Ensures that stable data is available when synchronized qualifier samples it
4. Use set_max_delay (of 1 dest clock) for toggle signal in
DW_pulsesync;
– ensures that synchronizer works with minimal delay between 2 pulses in
source clock domain

© Synopsys 2012 19
 Guidelines for Synthesis constraints
5. Document all input signals directly given to DW_sync as
“asynchronous” or unconstrained
6. Document all output signals that can be driven by two or more
clocks
– ensure that separate output delay constraint is given for each
corresponding clock in which it is driven
7. Document an input signal that is sampled in multiple clock
domain in DUT
– ensure that input signal is constrained with each corresponding clock in
which it is sampled

Note: Consistent CDC signal naming convention will help in

setting up these synthesis constraints and packaging them
into coreKit easily

© Synopsys 2012 20
 Review / Checklist
1. Architecture stage
– List of CDC signals (with functional behavior), clock domains, type of DW
synchronizer required
2. RTL Coding
– Run lint tool (Leda) to identify all CDC signals and check
− whether proper/consistent naming is followed
− any CDC signal that does not pass through DW synchronizers
− any combinational logic in CDC signal
– Update signal names, synchronizers, add module names in which synchronizers
are present and CDC exceptions & justifications
3. RTL & GL Verification
– Regression summary report with various recommended verification (clock
frequency) strategies
– Report on DW_MODEL_MISSAMPLES statistics
 Re-convergence are functionally verified
– CDC related Assertion coverage reports
 CDC Signal behavior assumptions validated
4. Synthesis
– Unconstrained I/O paths check
– Timing constraints for CDC paths

© Synopsys 2012 21
 Summary
 CDC issues are addressed
 by proper design process
 Usage of well designed CDC synchronizer methods from DW
Foundation Library
 Verification techniques to validate most of CDC assumptions
and re-convergence
 Using lint tools to identify CDC paths
 Proper synthesis constraints to ensure proper functioning
after PNR

 Usage of CDC tools like Questa (0in), etc can improve

productivity during reviews

© Synopsys 2012 22
 BACK-UP

© Synopsys 2012 23
 Comparison
0in identifies Our CDC methodology
1. the CDC schemes used in DUT 1. Rely on usage of std DW synchronizer
– But does not indicate whether they are
schemes
properly selected (e.g pulse v/s level) – CDC synchronizer selection validated
using assertions
2. Re-convergence paths – Have to rely on manual review (or
– but does not indicate functional unreliable leda) of non-DW synchronizer
problem; schemes
3. the un-synchronized paths & 2. Do not identify re-convergence paths
combo logic in CDC signal ‒ But verified for functional behavior using
“mis-samples”
4. CDC issues like marked in next
slide 3. Possible/done using Leda/DC Lint
5. Does not check CDC assumptions 4. Cannot identify except through manual
after PnR (synthesis constraints) review
5. Ensured through proper timing
6. Does improve efficiency of review
constraints
and productivity due to generation
of single comprehensive report 6. Time consuming and less reliable due
to manual reviews stages with different
7. Easy/std format to add CDC reports
exceptions to filter out justified 7. Need to generate perl scripts
CDC paths

© Synopsys 2012 24
 CDC Methodology page

• http://sp-
sg/sites/team%20sharepoint/IIPWorkspace/Methodologi
es/Wiki%20Pages/CDC%20Methodology.aspx

© Synopsys 2012 25
 Tools for CDC
Dynamic analysis
• This is a process of Determination and Validation of appropriate Properties for every
Synchronizer (Also called Assertions based analysis)
• Just having a synchronization circuit connected is only part of the solution
• The associated logic must interact correctly with the synchronization circuit to ensure
valid operation.
• To ensure this, assertions need to be specified that check correct functionality of the
synchronization circuits and validates correct use of the synchronizers by the
environment in which they are instantiated.
• You can automatically specify these properties once for every synchronizer and
automatically attach them to all instances of the corresponding synchronization
building blocks.
• The property checks for CDC synchronization circuit elements in general are as
follows. This technique of property generation is also referred to as CDC AEP
(automatically extracted properties)
– Control signal stability assertions
– Data signal stability assertions
– Handshake protocol check assertions
– Assertions for FIFO synchronizers
– Gray coded assertions for read and write pointers
– FIFO protocol (full/empty check) assertions
– Data integrity checks

© Synopsys 2012 27
 Automated techniques for CDC
Several automated techniques are used by CDC tools to tackle CDC
issues. Some of them are listed below.
Structural analysis
• To Identify CDC Signals and appropriate Synchronizers
• To Identify Structural Defects before and after Synchronization
– Convergence in the Crossover Path
– Divergence in the Crossover Path
– Divergence of Meta-stable Signal
– Re-convergence of Synchronized Signals
• Leda has six rules that check all the above structural checks for
CDC signals. The purpose of these rules is to provide the following
information.
– NTL_CDC01 - Reports all the unsynchronized CDC paths in the design.
– NTL_CDC02 - Reports all convergence in the crossover paths in the design.
– NTL_CDC03 - Reports all divergence in the crossover paths in the design.
– NTL_CDC04 - Reports divergence of any meta-stable signal in the design.
– NTL_CDC05/07/08 - Reports all kinds of re-convergence of synchronized
signals in the design

© Synopsys 2012 28