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:
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:
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
- Clock Domain Specifications
- Functional Mode Configuration Specifications
- Primary Input/Black Box Specifications
-Design Initialization Specifications
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.