Post-CTS Optimization - Timing Closure Guide

The goals of post-CTS optimization include:

• Fixing remaining design rule violations

• Optimizing remaining setup violations

• Correcting timing with propagated clocks

At this point in the design flow, the clocks are inserted and preferably routed. Since timing analysis uses the actual clock delays, you should adjust the timing constraints as follows. Typically, users have separate SDC files for pre-CTS and post-CTS timing analysis. Use the update_constraint_mode command to update the SDC files for each operating mode.

• Set the clocks to propagated by adding the following to your SDC file(s):

set_propagated_clock [all_clocks]

• Adjust the clock uncertainty (set_clock_uncertainty SDC) to model only jitter.

You need to update the constraints after clock tree synthesis to adjust clock jitter according to the design. Modeling only the jitter avoids making the timing appear worse than it is. Remember that, since the actual clock skew data is now available, it is possible that critical path timing will be worse.

• Remove or change the SDC constraints that are not valid postCTS like clock_uncertainty or clock_latency. You may need to adjust the clock latencies on the IOs so IO timing does not become the critical path by either adjusting the virtual clock source latencies:

set_clock_latency -source xxx <clock>

Or adjust IO constraints directly (set_input_delay/set_output_delay) or use the update_io_latency command.

• Adjust derating applied per each delay corner.

• Make sure RC scaling factors are tuned properly.

o Clock routing will use a different scale factor than the signal nets.

 Signal nets use -preRoute_cap

 Clock nets use postRoute_clkcap (if defined) or -postRoute_cap.

Run timing analysis to check the timing:

timeDesign -postCTS -outDir ctsTimingReports

If the timing is not similar to pre-CTS timing results check the following:

• Was CTS able to achieve the skew constraints? Are these skew constraints within the set_clock_uncertainty set during preCTS timing?

• Was clock uncertainty adjusted after CTS to only model jitter?

Post-CTS Optimization Command Sequences

Typically the same options applied during preCTS optimization are used for postCTS optimization.

• Use the timeDesign command to check the post-CTS timing:

timeDesign -postCTS -outDir postctsTimingReports

The timing at this point should be similar to the pre-CTS timing results. If there is a large jump in negative slack, investigate whether the end points are latches. A jump in negative slack may occur for latches now that their real skew is used for timing analysis. If the large slack is occurring at other points used GTD to analyze the paths.

Double-check the clocks are propagated and that the skew is within

your specifications.

• To optimize timing after the clock tree has been built, use the following commands:

optDesign -postCTS -outDir postctsOptTimingReports

• To take advantage of useful skew when optimizing timing in post-CTS mode, use the following commands:

setOptMode -usefulSkew true optDesign -postCTS [-incr]

If you have already performed detail routing on the clock tree, EDI System performs global and detailed ECO routing automatically using NanoRoute in post-CTS useful skew mode. If you do not want EDI System to do this, specify the -noECORoute parameter as follows:

setOptMode -usefulSkew true

optDesign -postCTS -noECORoute [-incr]

If you specify -noECORoute before running optimization, EDI System performs trial routing to estimate clock delays.

• If clock gating cells are on the critical path you can enable clock gate cloning during post-CTS optimization:

setOptMode -postCtsClkGateCloning true Hold Optimization

At this point run timing analysis to report hold violations:

timeDesign -postCTS -hold -outDir postctsHoldTimingReports

Timing optimization to fix hold violations can be performed at this point. This is recommended if your design has a significant number of hold violations because they are easier to fix prior to routing. If the number of hold violation is low you can wait until after routing the signal nets.

To perform hold optimization:

optDesign -postCTS -hold -outDir postctsOptHoldTimingReports

Tips for Performing Hold Optimization on High Peformance Designs

• Try to avoid providing very weak buffers for Hold fixing because they are more sensitive to routing detour and SI.

• For Multi-Vth design, make sure to run leakage optimization (through optDesign or optLeakagePower) before running Hold fixing since leakage reduction improves Hold timing.

• For a design with many hold violated paths, it is highly recommended to run hold fixing at postCts stage already (although there is no need to achieve 0ns slack at this stage). Then, use postRoute hold fixing to fix the remaining violations. You can use a negative hold target slack to focus hold fixing on the paths with large violations and fix the remaining hold violations after routing. For example, the following sets a hold target slack of -200ps:

setOptMode -holdTargetSlack -0.2

• By default Hold fixing can degrade setup TNS (but not Setup WNS).

This can be changed through:

setOptMode -fixHoldAllowSetupTnsDegrade true|false

• To exclude some path_group/clockDomains from hold fixing you can apply:

setOptMode -ignorePathGroupsForHold {groupA groupB ...}

• Things to watch out for:

o Make sure that the clock trees are well balanced (inter and intra clock trees).

o Avoid over constraining the clock uncertainty.

o Reduce local placement congestions. Adding cell padding may sometime help.

o If you want to allow Setup WNS degradation, you should set a negative setup target slack (setOptMode -setupTargetSlack )

• In Verbose mode (setOptMode -verbose true), Hold fixing will print a detailed report where each net not buffered will be sorted through several categories.

o This will allow the user to identify what are the most critical issues to resolve.

o It will help the user in understanding why a given net was not buffered.

o The different categories listed in the log file are :

*info: XXX net(s): Could not be fixed because of 'no legal location'