The Evolution of Clocks and Resets
Traditional clock and reset mechanisms typically were based on a master clock and reset distributed throughout the chip. Today, the die size is large enough that it is impractical to distribute the same fast clock to all parts. In addition, power management dictates that there be multiple VDD and clock domains on the chip that can be turned on and off independently. Clock frequencies in communicating domains (asynchronous or not) can differ by an order of magnitude and clock frequencies are allowed to vary dynamically based on throughput requirements or for power optimization. The proliferation of gated clocks for power optimization has introduced new tools in the design flow. The process of adding clock gates traditionally done by logic designers is now being automated to ensure that no power savings are left on the table. The premise for usage of gated clocks is that there is no modification of the original functionality. Logical equivalence checking tools need to be employed in the design flow to ensure this is indeed the case.
The large amount of clock gating, the variety of clock gating techniques, the nontrivial control circuitry involved and the likelihood that most of it is automatically inserted by a synthesis tool or power optimization tool further complicates verification. The implementation of power-up reset is also more complex today as it is designed to optimize power and physical layout. It is imperative that clock and reset schemes be comprehensively verified prior to analysis of the rest of the design. Empirical evidence suggests that a lot of issues initially diagnosed as being control or datapath-related are eventually traced to improper clock and reset behavior.
Exacerbating the verification problem is the fact that synthesis and power optimization tools are not glitch-aware and that there exists a distinct possibility that glitch-susceptible logic is inserted during optimization phases. This suggests that verification tools for clock and reset analysis be operable at the RT level as well as at the gate level. The following section details some real-life examples of the issues mentioned.