Systematic method for capturing “design intent” of
Clock Domain Crossing (CDC) logic in constraints
Ramesh Rajagopalan (rameraja@cisco.com), Cisco Systems Inc, San Jose, CA
Ajay Bhandari (ajayb@cisco.com), Cisco Systems Inc, San Jose, CA
Authors Details

Ramesh Rajagopalan ,Cisco Systems Inc, rameraja@cisco.com,
phone(408)3903607
Ramesh has been in the physical design field for over 19 years and he is currently a
Technical Leader with Switching Silicon Group at Cisco. Physical design of Custom
network switching ASICs and UltraSparc microprocessors form part of his experience.

Ajay Bhandari , Cisco Systems Inc, ajayb@cisco.com, phone: (408)5076115
Ajay Bhandari is currently a Senior Manager for Physical Design team with Switching
Silicon Group at Cisco. He has more than 18 years of experience in the field of ASIC
physical design.
Abstract
To avoid chip failures due to improper implementation of Clock Domain Crossing logic ,
we have evolved a systematic approach to capture design intents of Clock domain
crossing logic in a set of CDC constraints .
These CDC constraints would be used to analyze RTL netlist based CDC logic design and
report potential issues related to meta-stability, data coherency and data hold .
Elements of CDC logic such as asynchronous clocks, synchronous/asynchronous resets,
input port signals and their clock domains, quasi-static signals,, Qualifiers signals, false
cdc paths , case analysis signals and the type of synchronizers collectively indicate the
“design-intent” of the CDC logic.
Along with CDC constraints ( max delay constraints) for placement of CDC
synchronizers, proper implementation of CDC logic as per the design intent is realized.
References: Earlier DAC User track presentations by the authors:
Asynchronous Clock Domain Crossings Aware Physical Implementation of ASICs - Design
Automation Conference ( DAC ) USER_TRACK -2011
Prevention of Data Loss in Physical Implementation of FIFOs and Data Path Synchronizers Design Automation Conference (DAC) USER-TRACK 2012
Authors of both the previous User track presentations are
Ramesh Rajagopalan, Cisco Systems, Ajay Bhandari, Cisco Systems and
Namit Gupta, Atrenta
Motivation: To avoid chip failures due to improper
implementation of Clock Domain Crossing logic

Increase in Chip failures attributed to improper implementations of clock
domain crossings (CDC).

Factors influencing the increase in failures:
1) Significant increase in the number of asynchronous clock domains and
their crossings in the current designs
2) Integration of multiple IPs from different vendors in SOCs/ASICs
To mitigate the risk of CDC related chip failures, we need
- a “Correct-by-Construction” methodology for CDC logic implementation
- a validation process to ensure that the design intent of CDC logic is met.
Use of cdc constraints in chip implementation
Primary step in an asynchronous CDC methodology is creation of cdc
constraints to be applied in implementation phase:
1) CDC constraints for design analysis: - Constraints to validate asynchronous
crossings in RTL by performing structural and functional validation .
2) CDC constraints for placement - for timing driven placement of
synchronizers
- These cdc constraints should be both accurate and complete in coverage.
Quality goals for cdc constraints:
- Should eliminate any possibility of passing an improper crossing as a good
crossing.
- Should reduce the noise due to false alarm ( reporting a good crossing as an
improper crossing)
To achieve these quality goals, cdc constraints needs to include the “design
intent “ of the CDC logic being implemented in the chip.
Elements of Clock Domain Crossing (CDC) logic
Different types of synchronizers are used in CDC logic design.
1) FIFO synchronizers – for high volume data transfer
2) Hand-shake synchronizer – for IP, portability and reuse
3) Data Synchronizers - With a control signal from source domain
synchronized using multi-flop in destination domain performing as a qualifier
responsible for ensuring that the data is stable when captured at destination.
4) Control synchronizers – A double ( or mult) flop synchronizer for domain
crossing of single bit control signals.
Elements of CDC logic such as
asynchronous clocks, synchronous/asynchronous resets,
input port signals and their clock domains, quasi-static signals,
, Qualifiers signals, false cdc paths , case analysis signals and
the type of synchronizers collectively indicate the “design-intent” of the CDC
logic.
Benefits of capturing “design-intent” of CDC logic
Design Intent
-
Benefit of capturing it in constraint
1) Asynchronous Clocks used - No CDC path will be left out from analysis
2) Synchronous Resets
- No undefined reset will be used as qualifier
3) Quasi-static signals
- No static register will be checked for crossing
4) Custom FIFO definition - No FIFO will be declared as unsynchronized
5) Hand-shake protocol
- Helps to reduce false handshakes
6) Input port clock domains - No conflict with top –down clock domains
7) cdc false paths
8) Qualifier signals
- No false path will be analyzed for crossings
- Helps identify valid crossings
Capturing “design intent” in cdc constraints
– Clocks and Resets in the design
Goal : To capture design intent in a CDC constraints that would be used to
validate asynchronous crossing logic both structurally and functionally in RTL
prior to synthesizing the design.
Step 1: To capture all Clocks and Resets used in the design
For each subchip in the RTL design, a list of clocks and resets as inferred by a
CDC analyzer (EDA vendor) tool is created.
After reviewing the list, valid asynchronous clocks and valid synchronous/
asynchronous resets are included in the cdc constraints. A structural CDC
analysis is also run using the clock and reset definitions.
Problem 1: How to ensure that all clocks and resets are defined in cdc
constraints?
Solution 1: Clocks: Report all the registers that are not getting a clock and
resolve for missing clock definitions. Also make sure to capture certain clocks
and their multiples that are used as synchronous clocks in specific subchips.
Resets: Synchronous resets that are not defined in cdc constraints could be
wrongly treated as a valid qualifier to validate a domain crossing. Synchronous
Resets appearing in the list of qualifiers in a structural CDC analysis must be
defined in the cdc reset constraints.
Capturing “design intent” in cdc constraints
– Identifying FIFO Synchronizers in the design
Step B: When RTL design undergoes
Structural CDC analysis by a EDA vendor
tool, get a list of Synchronizing schemes
identified by the tool to declare a domain
crossing as valid.
Problem 2: Not identifying a custom FIFO
structure defined in the design and hence
reporting the crossing as invalid.
Solution 2: In the cdc constraint, the
custom FIFO can be defined to pass the
crossing as valid. For example, the cdc
constraint would be
fifo [–memory <memory_name>] [-rd_data
<read_data>] [-wr_data<write_data>]
[-rd_ptr <read_pointer>] [-wr_ptr
<write_pointer>] [-rd_enable <read_enable>]
[-wr_enable <write_enable>] [depth<fifo_depth>] [-width < fifo_width>]
FIFO
Capturing “design intent” in cdc constraints
– Identifying Handshake protocol Synchronizers in the design
Problem 3: Even when the RTL design
does not use a “handshake” protocol, some
combination of signals passing through a
double flop structure from one FSM clock
domain to other FSM clock domain could
structurally appear similar to a “request”
and “acknowledge” signals to report a false
positive domain crossing.
Solution 3: For subchips that do not use a
handshake protocol for domain crossing,
checking for the presence of a REQ and
ACK signals of a handshake has to be
disabled during structural CDC analysis to
avoid false positive reporting.
Hand Shake protocol
Capturing “design intent” in cdc constraints
– qualifying Data Synchronizers in the design
Problem 4: A signal that indicates when the
data is stable to be sampled at destination
domain is a qualifier signal that gates the
domain crossing. When a valid qualifier is not
used to pass the crossing or an invalid signal is
used in place of a qualifier , then the design
intent has to be captured in the constraints.
Solution 4: A list of qualifiers used in the
structural CDC reporting would be reviewed to
ensure that only signals with the knowledge of
when the data would be stable for sampling at
destination domain are used.
For example, a valid qualifier to be used can
be defined in cdc constraints as
qualifier –name <> -from_clk <> -to_clk <> type
qualifier
Capturing “design intent” in cdc constraints
- quasi-static signals /delayed qualifier signals/false path
Problem 5 :Static flops , such as configuration registers would flag cdc violation.
Solution 5: By defining the names of such static signals in the cdc constraints , the
false cdc violatios due to static registers would not be flagged .
For example, cdc constraints would be
Quasi-static –name <net-name>
Problem 6: In a data synchronization , the reported “qualifier signal” could be
delayed through several registers before gating the domain crossing of the data
bus.
Solution 6: In such cases, the qualifier identified by the analysis tool may not be the
valid gating signal and it could be a static signal to be declared as quasi-static .
Problem 7: Some paths exist but will never be crossed. A false violation flagged on
such paths needs to be handled in cdc constraints.
Solution 7 : Defining cdc false paths at appropriate hierarchy level would reduce the
false cdc violations in the report.
For example, cdc_false_path –from/-to/-through could be used.
Capturing “design intent” in cdc constraints
- clock domains of
input port signals of subchips in context with top level
Problem 8: Primary input ports of subchips are associated with the respective
clock domains during the subchip level CDC analysis ( out of context with top
level ). However, once all subchips are used to assemble a top level for cdc
analysis, the in-context clock domains of the primary ports of subchips could be
different from the one defined at subchip level cdc analysis.
Solution 8: For example, port d1 of Blocks B2 assigned ck2 domain at subchip
level cdc analysis will have ck1 domain assigned when analyzed at top level.
Subchip b2 has to undergo cdc analysis with the correction from top level.
CDC constraints for placement - for timing driven placement of
double-flop synchronizers
A
D
clk_A
F1
B
F2
C
D
F3
clk_B
Synchronizer using back to back flops as a
library cell

A
clk_A
Integrated synchronizer
F1
C
B
F2
F3
Placed
Cluster
clk_B
Separate Synchronizer Flops constrained with max delay
timing constraints
Use integrated synchronizer (from library) for double flops used to synchronize
single bit control signal.
 This guarantees least amount of delay between synchronizer flops to ensure that
the delay between F2 and F3 does not make the signal metastable.

For all control signal synchronizers with non-integrated flops
 a max delay constraint is set for their placement.
 Max delay is set to (10% to 20%) of one clock cycle of the destination
clock
 Refer: Asynchronous Clock Domain Crossings Aware Physical
Implementation of ASICs - Design Automation Conference ( DAC )
USER_TRACK -2011 – presented by us.
CDC constraints for placement - for timing driven placement of data
synchronizers
Delay> 1 Clk2 Cycle
Delay < 1 Clk2 Cycle
Dn
Dn
D0
M
E0
En
clk1
Clk2
Clk1
Clk2
A
D
F1
clk1

Delay between D0 and E0 < one
clock cycle of the destination clock
B
F2
clk_2
LOGICAL VIEW of Data Synchronizer of
“Mux-recirculation” type
Placed
Cluster
E0
En
clk1
Clk1
M
D0
C
F3
Integrated synchronizer
PHYSICAL IMPLEMENTATION VIEW

When unconstrained, max delay requirement
is violated due to

Placement of data bus register E faraway from register D

Scenic detour of the interconnect
between D and E registers.

Set max delay constraint to mitigate this.
Limitations , Future Work and Conclusion

LIMITATIONS AND FUTURE WORK:

CDC constraints for Logic design analysis works at RTL level netlist and the
CDC physical delay constraints work at gate level netlist. There is no
common design environment to cross probe the implementation for debug.
 CDC logic checked at the RTL level
 Feedback on physical delay of CDC logic is post layout
CONCLUSION:
Design – intent aware cdc constraints improve the quality of CDC logic
implementation by improving the quality of CDC logic analysis prior to
synthesis .
- eliminates any possibility of passing an improper crossing as a good
crossing.
- reduces the noise due to false alarm ( reporting a good crossing as an
improper crossing)

CDC logic implemented with placement constraints eliminate meta-stability
issues in silicon