The complexity of clock architectures is growing with larger designs. Functionality that was traditionally distributed among multiple chips is now integrated into a single chip.   As a result, the number of clock domains is increasing.  Power management is a dominant factor that impacts clock architecture (gating, power domains, voltage scaling).   Designing for multiple functional modes adds to clock architecture complexity.  For example, all these issues add logic into the clock trees.    As a result it is becoming more complex to verify designs for glitch and metastability issues.

There are very few established standards/methodologies for managing clock architectures.  Even the few established standards such as UPF (Universal Power Format) for power management and synthesis for power don’t go far enough to be clock architecture-aware with respect to glitch, data stability and metastability issues.  For example, clock gating insertion is done without full awareness of asynchronous crossings.  In fact, there are a myriad of issues relating to asynchronous clock domains that don’t have established standards.  Some of these are:

• Single bit synchronizers
• Asynchronous FIFO’s
• Handshake structures
• Clock Gating
• Re-convergence
• Design practices to mitigate glitches in asynchronous crossings
• Asynchronous/Synchronous resets crossing domains
• Reset Gating

In order to manage the design, implementation and verification of clocks in a design, more members in the design team need to be “clock/reset architecture” and “clock/reset implementation” aware.   This awareness is necessary for verifying correct functionality of the clocks when using semi-automatic CDC analysis tools and/or manual processes such as design reviews.

The clock architecture needs to be understood to generate requirements for the clock/reset networks.  Design standards for implementation can be generated from these requirements.  The design standards drive verification strategy: what can be automated using CDC tools and what must be relegated to other methods.  An example of what cannot be verified by CDC tools is the selection of an invalid combination of clocks in functional mode.

The following components need to be considered with regard to how they affect clock/reset architecture:

• Timing:  Static Timing Analysis & Clock Tree Synthesis
• Mode Selection: Test/Functional Mode, Clock mode select (Multiple Functional Modes), Configuration registers
• Power: Gating Control, Voltage Scaling
• Testability: Clocks for Scan, Clocks for At-Speed, BIST, Lock-up latches
• Quasi-static Domains

The clock/reset architecture specification needs to contain the following details in order to meet the requirements for design implementation and verification in the following manner:

- CDC Implementation Style and Design Practice

1. Single Bit Sync
2. Common Enable Sync (Data Bus)
3. Fast-to-Slow Crossings (FIFO; gray-code, read-before-write, write-before-read)
4. Multi-mode crossings (multiple frequency modes;  Data stability)
5. Data Correlation (Handshake)
6. Synchronizer cycle jitter management
7. Re-Convergence management of control bit crossings
8. Clock Gating management
9. Internally generated reset management

- Clock Domain Specifications

1. Synchronous Domains
2. Asynchronous Domains
3. Quasi-static Domains (very slow clocks )
4. Exclusive Domains ( clocks that are active when other related domains are static such as configuration register writing)
5. Resets and their Domains

- Functional Mode Configuration Specifications

1. Mode Control Pins and logic states
2. Configuration Registers settings
3. For multiple functional modes, mode control settings

- Primary Input/Black Box Specifications

1. Clock domains for the primary inputs
2. Clock domains for black box outputs

-Design Initialization Specifications

1. How to initialize the design (critical for CDC verification that requires formal verification)

The above specifications are critical to ensure an accurate setup for CDC analysis that will result in a complete and accurate analysis.   This will minimize the most frequent complaints about CDC analysis tools; noise (voluminous messages), false violations and incomplete analysis.   Also, by documenting the CDC specifications, all project engineers will be better equipped to review the validity of CDC analysis results.

Even with the best specifications, translating them to the constraints for the CDC tools needs a robust setup validation methodology to identify missing constraints.  Real Intent’s Meridian CDC tool has such a robust setup validation flow with supporting graphical debug/diagnosis to provide guidance on completeness and accuracy of constraint specifications.  Ease of setup has been cited as key considerations for many of our recent customers who have switched to Meridian CDC.

In summary, CDC analysis and verification is increasing in complexity.   The effectiveness of CDC analysis tools requires that designers have detailed knowledge of the design’s clock/reset architecture so that complete and accurate constraints can be provided to CDC tools and designers can meaningfully and efficiently review the validity of CDC analysis results.