What Do Timing Constraints Have To Do With Clock Domain Crossing?

As the complexity of designs has scaled, the need for complete and accurate timing constraints (defined typically as Synopsys Design Constraints or SDC) has become extremely critical. High quality timing constraints not only reduce the total effort required to achieve timing closure, but also reduce the number of iterations during that process. In the worst case, incorrect timing constraints can result in silicon failure or a re-spin.

Most of us are aware of this problem, but mostly in the context of synchronous timing closure. We know how to direct an optimization tool to ignore certain paths using false path exception. We know how an incorrect multicycle path exception can mask the timing failures from Static Timing Analysis (STA), or how an input delay specification with an incorrect clock can result in incorrect synthesis output.

On the other hand, asynchronous clock domain crossings (CDC) have become very common in today’s SoC. That’s because today’s SoCs have a challenging combination of interfaces, protocols and performance objectives that regularly results in multiple clock domains. Often, this is further complicated by multiple modes of operation and wide ranging clocking scenarios. This leads to ever increasing numbers of clock interfaces, where data is transferred between clocks of different frequencies and often between asynchronous domains. In this environment, designers, chip integrators and back end engineers must ensure the integrity of the clock domain crossing.

So, do timing constraints play a role in CDC verification? Absolutely yes!

CDC verification requires the clock definition, clock relationship and possible mode definitions which may already be captured in SDC. Even though CDC verification may happen much before timing analysis, creating the clocks, and capturing the clock relationships can be performed once and leveraged for CDC as well as STA.

So, what’s the problem?

Timing constraints are typically added late in the design flow in an effort to resolve timing violations, but not thought through at RTL. Why not create these constraints in a holistic way early in the design flow, and use them for both timing closure and CDC? This helps avoid bugs and discrepancies later on.

Let us take an example. Whereas set_clock_groups captures clock relationship concisely, additional constraints like set_false_path, set_clock_uncertainty also are used to capture clock relationships, which need to be understood in the context of CDC verification. What if you have a conflicting domain relationship as you go into CDC verification? The CDC verification results will be unreliable. If you can identify conflicting domain relationships and correct them before CDC verification, the resulting CDC verification will be a lot more effective.

If you use a timing constraints verification tool that enables you to generate proper timing constraints and validate the existing constraints to be correct, complete and consistent, that’ll help shorten your CDC verification cycle.

For further detail, please refer to Atrenta whitepapers “Verification of Multi-Clock Designs – The Bigger Picture,” and “Combining Structural and Functional Verification Techniques to Improve Effective CDC Verification.”