During post-route optimization, there should be very few violations that need correction. The primary sources of these timing violations include:
• Inaccurate prediction of the routing topology during pre-route optimization due to congestion-based detour routing
• Incremental delays due to parasitics coupling
Since the violations at this stage are due to inaccurate modeling of the final route topology and the attendant parasitics, it is critical at this point not to introduce any additional topology changes beyond those needed to fix the existing violations. Making unnecessary changes to the routing at this point can lead to a scenario where fixing one violation leads to the creation of others. This cascading effect creates a situation where it becomes impossible to close on a final timing solution with no design rule violations.
One of the strengths of post-route optimization is the ability to simultaneously cut a wire and insert buffers, create the new RC graph at the corresponding point, and modify the graph to estimate the new parasitics for the cut wire without re-doing extraction.
In addition to the timing violations caused by inaccurate route topology modeling, the parasitics cross-coupling of neighboring nets can cause the following problems that need to be addressed in high speed designs:
• An increase or decrease in incremental delay on a net due to the coupling of its neighbors and their switching activity.
• Glitches (voltage spikes) that can be caused in one signal route by the switching of a neighbor resulting in a logic malfunction.
These effects need to be analyzed and corrected before a design is completed. They are magnified in designs with small geometries and in designs with high clock speeds.
Data Preparation
SI optimization requires certain preparation:
• Make sure cdB libraries are specified for each cell for each delay corner.
• You must be in On Chip Variation (OCV) mode to see simultaneous clock pushout / pullin. Enable this using "setAnalysisMode -analysisType onChipVariation"
• Confirm your CeltIC settings match your signoff tool
• Confirm coupling filter settings match your signoff tool
• Enable SI CPPR through "set_global timing_enable_si_cppr true" (this is the default)
Additionally, consider the following techniques if you have difficulty achieving signal integrity closure on your design.
• Watch for routing congestion during floorplanning and especially after detailed routing.
o Consider running the congOpt command on the design to eliminate local hot spots or adjust your floorplan
• Use NanoRoute advanced timing with SI-driven routing options during detailed routing. For example:
o setNanoRouteMode -routeWithTimingDriven true
o setNanoRouteMode -routeWithSiDriven true
• Fix transition time violations.
o Slow transitions introduce a larger delay penalty or incremental delay.
• Prepare all of the required noise models.
o Highly-accurate CeltIC analysis requires the use of accurate noise models like cdB, ECHO, or xILM. The use of blackbox (missing) models could lead to a significant number of false violations.
You must recalibrate the noise library with each release of CeltIC. New features may not function properly when used with an old .cdB file.
o Characterize your memory and analog block using the make_cdb utility.
o Create XILM models for sub blocks to model their noise sensitivity at the chip level.
Post-Route Optimization Command Sequences
The Advanced Analysis Engine (AAE) is a new unified delay calculation engine that simultaneously computes base and SI delays. AAE can perform incremental SI delay computation during timing optimization; hence provide accurate feedback to optimization engine. AAE also capable of multithreading thus gives substantial runtime gains in timing closure.
Unlike the default flow, AAE based optimization does not require four steps optimization:
Default:
optDesign -postRoute
optDesign -postRoute -hold optDesign -postRoute -si -hold optDesign -postRoute -si
AAE (recommended):
optDesign -postRoute
optDesign -postRoute -hold To run AAE based SI fixing:
<Load routed data base with MMMC setup>
setAnalysisMode -analysisType onChipVariation -cppr both setDelayCalMode -engine default -SIAware true
optDesign -postRoute
optDesign -postRoute -hold
For more information on the AAE flow see the application note: PostRoute Optimization Using the Advanced Analysis Engine (AAE).
Tips for Performing Post-Route Optimization High Performance Designs
• For multi-VT designs, after routing there can be large WNS/TNS jumps due to the sensitivity of HVT cells
o runtime of postRoute optimization can be significantly impacted by large TNS
o Using optLeakagePower fixTimingOnly prior to optDesign -postRoute can massively speed up closure
Only works for multi-VT
Does not have much impact when designs has already
mainly LVT cells.
• The registers by default are marked + FIXED by clockDesign and
cannot be resized eventhough postRoute optimization can resize flops.
To temporarily set them as + PLACED during optDesign, you can apply:
setOptMode -unfixClkInstForOpt true
• The local density by default is limited to 98%. If optimization is prematurely exiting due to local placement hotspots this can be increased to 100% using
setOptMode -maxLocalDensity 1.0
• Make sure you are in OCV analysis (MMMC setup required) to calculate pushin/pullout timing properly:
setAnalysisMode -analysisType onChipVariation
Note if the design is not in OCV mode, clock SI pushout/pullin will not be correct.
• Make sure your extraction filters correlate to your signoff extraction
o when using iQRC the filters typically can be set to the exact signoff values
make sure to use setExtractRCMode -capFilterMode relAndCoup
StarRC has no total_c_th equivalent so set this to 0 for these flows
For postRoute optimization, you may want to force the tool
to only allow legal resizing to avoid placement legalization and thus limit routing changes:
setOptMode -postRouteAllowOverlap false Checking Timing
AAE is a fast SI engine so it does not perform circuit simulations to compute SI delays. Being a fast SI engine, it does not completely correlate with Celtic (signoff SI engine). AAE is tuned well to work with optimization engine in order to provide better QOR. So there is a tendency to be pessimistic compared to Celtic.
AAE being pessimistic compared to Celtic means it does not need 'setSIMode -analysisType pessimistic' setting for Primetime correlation. Please use 'setSIMode -analysisType default' in AAE and Celtic flows for better correlation.
Optimization final summary is AAE estimation based report only. So if you want to check your QOR, you need to run signalStorm+Celtic based timeDesign between setup and hold optimization or at the end of hold optimization. For example:
timeDesign -postRoute -si -outDir final_setup timeDesign -postRoute -si -hold -outDir final_hold
If you are using Encounter Timing System (ETS) for signoff timing make sure the CeltIC settings are consistent between EDI System and ETS.
If you are using PrimeTime-SI for signoff set "setSIMode -analysisType pessimistic" prior to timeDesign for better correlation.
Optimizing With 3rd Party SPEF or SDF
If you are using a 3rd Party tool for extraction or timing analysis the most important step is to make sure they correlate with EDI System's corresponding function. For example, if you are using a 3rd Party extractor make sure the RC scaling factors are set properly within EDI System. If you are using a 3rd Party timing analysis tool, make sure it correlates with EDI System by verifying SDC constraints are applied consistently between the tools. The delay calculation and timing analysis results between EDI System and the 3rd Party tool should also correlate.
If timing violations occur when using SPEF from a 3rd Party extractor you can import the SPEF into EDI System and perform optimization. You must import a SPEF for each RC corner. The flow is:
spefIn rc_corner1.spef -rc_corner rc_corner1 spefIn rc_corner2.spef -rc_corner rc_corner2 ...
optDesign -postRoute [-si] [-hold] -outDir spefFlowTimingReports
• The -si and -hold options are optional in the above command.
o Use -hold if you need to perform hold fixing based on the the SPEF.
o Use -si if you need to perform SI fixing based on the SPEF.
• optDesign will use the SPEF for initial timing to determine the best location to optimize the paths.
optDesign can also optimize based on SDF from a 3rd Party timing analyzer.
This is useful when the timing analyzer reports timing violations EDI System did not. The flow to optimize based on SDF is:
read_sdf -view view1 sdf1.sdf read_sdf -view view2 sdf2.sdf
optDesign -postRoute -useSDF [-hold] -outDir sdfFlowTimingReports
• Note in order to use SDF information in MMMC analysis mode, you should provide an SDF file for each active view in the design. If a view was not given an SDF file, EDI System will run detail extraction and delay calculation for that specific view.
• optDesign will run extraction to calculate slew values because SDF doesn't contain slews. The delays in the SDF will be used, but the slews must be generated. You can also spefIn to avoid the extraction.