Speeding Up Timing Constraint Creation, Refinement And Validation

We are dealing with designs integrating many features and working with cutting-edge process technologies. Design methodologies and the design and process complexities can be overwhelming.

To leverage the advancements in EDA tools and to achieve optimal power, performance and area results while overcoming design complexities, it is important to have a qualitative timing constraint file that captures the design/clocking intent appropriately and completely. It also should aid the implementation, optimization and timing-closure. And it needs to incorporate timing signoff accuracy by perceiving the consequences and nuances associated with the constraints.

Keeping minimal sets of pessimistic constraints and traditional ways of constraints refinement and validation includes:

1. Addressing errors, warnings, lint and check-timing issues;
2. Time-consuming timing violation cleanup iterations at various implementation stages;
3. Relying on time-consuming gate-level-simulations, and
4. Error-prone manual reviews for constraint refinement are no longer sustainable.

When timing constraints are obtained from diversified sources, sometimes there are few design details available. They can be written with minimal knowledge of design operation, sdc-constraints behavior conforming to the design intent, or sdc precedence-rules that were written without considering the effects on timing accuracy and optimization. All of those factors can impact the ability to meet design targets. But playing it safe with minimal and pessimistic constraints can further aggravate the problem and can yield poorer, sub-optimal results.

It is important to gauge the completeness and quality of constraints, and also understand the repercussions of various constraint issues from stem-to-stern for accurate, reliable and optimal results. Successful timing constraint formulation not only requires a thorough understanding of the design and IPs used, but also requires expertise in understanding the behavior of various timing constraints, block and IP integration issues, their consequences in PPA optimization and timing signoff.

Implementation and signoff tools fairly guide the user on some of the basic constraint issues, and also on some of the timing issues associated with the input constraints. But many constraint issues are not directly, or even indirectly, reported to the user. These constraint issues could affect PPA optimization and timing-signoff accuracy. Constraint issues might not affect PPA optimization and timing-signoff accuracy in higher process nodes, but due to the predominant lower-node effects like high crosstalk, miller-effect, and leakage-currents and power densities, constraints need to be accurately defined to avoid optimism/pessimism in implementation and signoff. Inaccuracies in clock-sources, clock-relationships, static signals, etc., could have a significant impact in lower process nodes.

Constraint linting/checking, generation and validation tools have been on the rise recently. These tools go beyond the basic constraint-linting issues and identify deeper issues (by checking against a set of pre-defined rule-sets) that affect the optimization and signoff. The numerous constraint checks and issues pointed out by these tools can be overwhelming, and the native checks/features might need tweaks to tailor to your needs and cater to some of the additional checks based on previous design/constraint experiences. Only when we understand the seriousness and the impact of these constraints does it makes sense to do the changes required to meet the overall design objectives.

To sail through a sea of issues with ease, issues/checks need to be prioritized and categorized based on dependencies and interrelated issues, design-implementation stages with waivers included. Actual design-specific repercussions need to be focused on instead of possible generic repercussions. Essentially, the designer need to be aware of any opens with the timing constraints, the consequences on optimization and signoff and what existing tools/framework point out these opens effectively for quicker resolution of constraint issues.

Effectively, the approach to timing constraint formulation, analysis, refinement and validation requires tools, utilities and procedures that help with:

• Comprehensively identifying lint issues, missing constraints and dropped-off, ignored, overwritten, unused, duplicate, or unrealistic constraints, then making necessary changes for constraint completeness and compactness.
• Refining constraints to make them implementation-friendly so engineers can more effectively plan scan-clocking and CTS-implementation for better optimization and closure. That can be done without inducing optimism/pessimism, thereby improving signoff accuracy and preserving design-intent.
• Judging tradeoffs among constraint complexity, over- and under-optimization and signoff accuracy, and accordingly making appropriate design execution decisions.
• Consolidating constraints (reports) that might need review, locating probably incorrect constraints and segregating those that might need changes.
• Altering constraints for runtime improvements.
• Seeking any additional design information for addressing any of the above items and also in identifying timing issues upfront and providing feedback for any design/clocking changes.

Overview of certain constraint types and their significance
Clocks and clock relationships. Clock-definitions (primary and generated clocks) are the first and foremost part of timing constraints in a synchronous design that need to be complete and accurate. Inappropriate clock definitions affect delay, slew, latency, skew and crosstalk calculation accuracy, and all of these seriously affect optimization and signoff.

Further understanding of clock-structure, clock-selection criteria, clock-relationships (synchronous, asynchronous, logically exclusive, physically exclusive) help in the effective planning of scan-clocking (based on functional clocking), CTS-implementation and optimization by updating the constraints with static-signal and case-value definitions, set_clock_group/false-paths (for accurate crosstalk analysis), and any multi-cycle-path relationships between clocks.

Timing exceptions. While timing exceptions (false-paths, multi-cycle-paths, max/min-delays) relax the default single-cycle timing requirements, one needs to have a thorough understanding of the design and preferably have an automated approach to validate whether the design exceptions follow the design intent. Also, constraints that don’t conform to the sdc syntax requirements and the expected behavior could be ignored by the implementation and signoff tools and would defeat the whole purpose of the defined timing exceptions. So, it is crucial to review ignored exceptions/unexpected timing behavior with the applied exceptions and refine the constraints to benefit from timing relaxation while preserving the design intent.

I/O constraints. Most of the standard I/O interfaces (DDR, SPI, PCI, I2S, HDA etc) have I/O specifications or requirements that need to be captured in the defined constraints. Apart from this, all I/O constraints would need to be accurate and complete for proper crosstalk analysis, optimization and signoff.

Case values. Using constraints like set_false_path for specifying static signals does not reduce crosstalk impact on timing. Static signals and their constant values, when specified as case-values, help greatly on reducing crosstalk pessimism and the timing. Sometimes, the probable static signal information (if not already constrained/missed) can be checked from reports like – not inferred clock-gating-checks on complex gates, unexpected clock crossovers/reconvergences/non-unate clock paths, etc. Once we know these additional static signals, we can update the case-value constraints.