slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Ramesh Rajagopalan ( rameraja@cisco.com ), Cisco Systems Inc, San Jose, CA PowerPoint Presentation
Download Presentation
Ramesh Rajagopalan ( rameraja@cisco.com ), Cisco Systems Inc, San Jose, CA

Loading in 2 Seconds...

play fullscreen
1 / 16

Ramesh Rajagopalan ( rameraja@cisco.com ), Cisco Systems Inc, San Jose, CA - PowerPoint PPT Presentation


  • 192 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Ramesh Rajagopalan ( rameraja@cisco.com ), Cisco Systems Inc, San Jose, CA' - sabina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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
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
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
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 domainsand 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
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:

  • CDC constraints for design analysis: - Constraints to validate asynchronous crossings in RTL by performing structural and functional validation .
  • 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
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
Benefits of capturing “design-intent” of CDC logic

Design Intent - Benefit of capturing it in constraint

  • Asynchronous Clocks used - No CDC path will be left out from analysis
  • Synchronous Resets - No undefined reset will be used as qualifier
  • Quasi-static signals - No static register will be checked for crossing
  • Custom FIFO definition - No FIFO will be declared as unsynchronized
  • Hand-shake protocol - Helps to reduce false handshakes
  • Input port clock domains - No conflict with top –down clock domains
  • cdc false paths - No false path will be analyzed for crossings
  • Qualifier signals - Helps identify valid crossings
capturing design intent in cdc constraints clocks and resets in the design
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
Capturing “design intent” in cdc constraints – Identifying FIFO Synchronizers in the design

FIFO

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>]

slide10
Capturing “design intent” in cdc constraints– Identifying Handshake protocol Synchronizers in the design

Hand Shake protocol

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.

capturing design intent in cdc constraints qualifying data synchronizers in the design
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

slide12
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.

slide13
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
CDC constraints for placement - for timing driven placement of double-flop synchronizers

C

A

A

B

B

C

Placed Cluster

D

D

F1

F1

F2

F2

F3

F3

clk_A

clk_B

clk_A

clk_B

Synchronizer using back to back flops as a library cell

Separate Synchronizer Flops constrained with max delay timing constraints

Integrated synchronizer

  • 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
CDC constraints for placement - for timing driven placement of data synchronizers

Delay> 1 Clk2 Cycle

Delay < 1 Clk2 Cycle

  • 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.
  • Delay between D0 and E0 < one clock cycle of the destination clock

Dn

A

B

C

Placed Cluster

D

F1

F2

F3

Dn

M

D0

E0

E0

M

D0

En

En

clk1

clk_2

clk1

clk1

Clk2

Clk1

Clk2

Clk1

Integrated synchronizer

LOGICAL VIEW of Data Synchronizer of “Mux-recirculation” type

PHYSICAL IMPLEMENTATION VIEW

limitations future work and conclusion
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