Systematic method for capturing “design intent” of Clock Domain Crossing (CDC) logic in constraints Ramesh Rajagopalan Cisco Systems Inc, San Jose, Ajay Bhandari Cisco Systems Inc, San Jose,

Authors Details Ramesh Rajagopalan,Cisco Systems Inc, phone(408) 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, phone: 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 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 - No false path will be analyzed for crossings 8)Qualifier signals - 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 ] [-rd_data ] [-wr_data ] [-rd_ptr ] [-wr_ptr ] [-rd_enable ] [-wr_enable ] [- depth ] [-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 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  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 – presented by us. clk_A D clk_B ACB F1F3F2 Integrated synchronizer Synchronizer using back to back flops as a library cell clk_A D clk_B A C B F1F3F2 Placed Cluster Separate Synchronizer Flops constrained with max delay timing constraints

CDC constraints for placement - for timing driven placement of data synchronizers Delay between D0 and E0 < one clock cycle of the destination clock When unconstrained, max delay requirement is violated due to  Placement of data bus register E far- away from register D  Scenic detour of the interconnect between D and E registers.  Set max delay constraint to mitigate this. M clk1 Dn En D0 E0 M clk1 Dn En Clk1 Clk2 Clk1 Clk2 Delay> 1 Clk2 Cycle clk1 D clk_2 ACB F1F3F2 Placed Cluster LOGICAL VIEW of Data Synchronizer of “Mux-recirculation” type PHYSICAL IMPLEMENTATION VIEW E0 D0 Integrated synchronizer Delay < 1 Clk2 Cycle

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