CHAPTER 12

Post-route optimisation qualification

After detailed routing the wires are real, so the delays are real too, and some of them are worse than the plan assumed. Post-route optimisation repairs what it can by resizing, buffering and ECO routing. This chapter checks four things: that the timing numbers come from detailed extraction in every active view, that the repair helped, that it did not damage the route it started from, and that the area and power it cost are known. It does not replace signoff timing.

12.1 Stage purpose

Chapter 11 left you with a legal, connected route and a timing baseline taken on detailed parasitics. That baseline usually still has violations. Two kinds matter here. A setup violation means data arrives too late for the capturing clock edge. A hold violation means data changes too soon after it. Both are measured as slack, the margin to the requirement. WNS is the worst negative slack and TNS is the sum of the negative slacks at the endpoints.

Routing adds a third group, which is about wires that now sit next to each other. Signal integrity, or SI, is the effect of a switching neighbour on a victim net. It shows up as extra delay, as a glitch on a quiet net, or as a slower transition. Design rule violations, or DRVs, are limits on capacitance, transition and fanout set in the constraints or the library. Do not confuse them with the geometric DRC of Chapter 11. They are electrical limits, and they share only the letters.

The command for this stage is optDesign -postRoute. The reference says it repairs design rule violations, glitch violations and setup violations on base and SI delay by default, and that it runs ECO routing unless you prohibit it. Hold fixing and power recovery are separate requests. In multi-mode multi-corner mode it works on all active views together.

Keep four ideas apart. Tool completion means the command returned. Analysis coverage means every active view, both check types and every violation class were really evaluated. Stage qualification means the results meet your project budget and the repaired route is still legal. Signoff is a later activity with its own tools, and it can disagree with the numbers here. An optimisation run that finished with a smaller TNS has completed. It has not yet been qualified.

12.2 Entry prerequisites

Must already be true	Why
Chapter 11 is qualified: zero DRC on the whole die, regular nets connected, antenna clean, with the reports saved	Optimisation starts from this route, and the saved reports are what you compare with afterwards.
The timing baseline from Chapter 11 is stored, taken with detailed extraction	Every claim of improvement in this chapter is a comparison with it.
The analysis views are active and the methodology lists them	A view that is not active is not optimised and not reported.
The methodology states the extraction effort level, the analysis type, SI settings and which violations are in scope	Card O-01 compares the session against this list.
Extraction scale factors have been generated	The reference asks for the default and detailed factors before optDesign runs.
Project budgets for setup, hold, DRV, area and power exist	This book sets no such numbers.

12.3 Relevant files and analysis context

The commands read the database and the session modes, and they write report directories. By default optDesign writes its timing reports into a directory called timingReports and prefixes the files with the design name and the stage. Use -outDir and -prefix so the baseline, the intermediate runs and the final run each keep their own directory. A rerun with the same names overwrites the earlier evidence.

Three records travel with every timing number. First, the extraction mode: setExtractRCMode -engine postRoute selects detailed extraction, and -effortLevel selects native, TQuantus, IQuantus or standalone Quantus. Unless you set the effort level, optDesign -postRoute uses postRoute medium, or low without a Quantus technology file, while timeDesign -postRoute defaults to native detailed extraction. Clock DRV fixing in post-route optimisation does not work with the signoff effort level, which is meant for ECO flows after it. Second, the SI setting: timeDesign and optDesign in post-route mode turn SI-aware delay calculation on unless you set it false, and it needs on-chip variation analysis. Third, the view list, because a number without its views does not say what it covers.

Views deserve a second sentence. Auto view pruning can drop views during optimisation to save run time. The -expandedViews option restores them at the end and writes a report directory per view. The log summary can therefore list fewer views than the per-view reports do, and the overall TNS counts each endpoint once at its worst view, so it is not the sum of the per-view values.

12.4 Checks and command cards

12.4.1 Pre-stage checks

O-01Modes in force at entry

Question it answers	Which extraction engine, SI setting, analysis mode and optimisation settings will the run use?
Stage	Before optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Route qualified in Chapter 11, session open.
Legacy UI	getExtractRCMode -engine -effortLevel -coupled getDelayCalMode -SIAware getAnalysisMode -analysisType -cppr getOptMode -nonDefault getSIMode -nonDefault

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-engine -effortLevel -coupled` show the extraction engine, the post-route effort level and whether coupling is output. `-SIAware` shows the SI-aware setting. It reads false by default and when set false, and timeDesign and optDesign in post-route mode turn it on unless it is set false. `-analysisType -cppr` show the analysis type and the clock path pessimism removal setting. `-nonDefault` lists only the settings whose value differs from the default.
Scope and view	Whole session. These settings are global, not per view.
SI needs on-chip variation	SI-aware delay calculation requires multi-mode multi-corner mode and the analysis type onChipVariation, and SI analysis requires coupled extraction. The getter cannot tell an unset value from false, so confirm SI delay in the run summary and search the scripts for setDelayCalMode -SIAware false.
Effect on session	reads or reports only
Output	Values on the console.
Fields that matter	The engine and effort level, coupling on, the analysis type on-chip variation, and a non-default list that matches the methodology.
Healthy	Engine and effort level as the methodology says, on-chip variation and coupling on, and non-default settings equal to the methodology list.
Warning	A non-default optimisation setting that nobody can explain.
Hard stop	The analysis type is not on-chip variation, coupling is off, or a script sets SI-aware false with no recorded reason.
Common misuse	Reading the settings after the run. A script that changed a mode during the run is then invisible. Record before running and compare after.
Root cause and fix	Set the modes in the methodology order, record them, and rerun the baseline if any of them changed.
Rerun after a fix	Rerun O-01 after any mode change, and the baseline of O-03.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-02Analysis view coverage

Question it answers	Are all the views that the methodology requires active, and does each active view have constraints that cover its checks?
Stage	Before optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Views defined in the multi-mode multi-corner setup of Chapter 3.
Legacy UI	report_analysis_views -type active all_setup_analysis_views all_hold_analysis_views report_analysis_coverage -view <v>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-type active` selects the active views. The values setup and hold select the views for those checks. `-view` names the view that the coverage report analyses.
Scope and view	Per view. Run the coverage report once for every active view.
Effect on session	reads or reports only
Output	A hierarchical view report, Tcl lists of view names, and a coverage report per view.
Fields that matter	Which views are active, which are setup and which are hold, and per view the numbers of met, violated and untested checks.
Healthy	The active lists equal the methodology, and no view reports untested checks that the project expects to be tested.
Warning	A defined but inactive view that the methodology marks as optional, listed as not evaluated.
Hard stop	A required view is inactive, or a view has untested checks that nobody can explain.
Common misuse	Counting views from the optDesign log. Auto view pruning can leave a view out of the summary even though it is active.
Root cause and fix	Activate the missing view in the analysis-view setup, or record why it is excluded, then repeat the baseline.
Rerun after a fix	Rerun O-02 after any change to the view setup.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-03Baseline timing with detailed extraction

Question it answers	What do setup and hold look like per view before any repair, with detailed parasitics?
Stage	Before optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-01 and O-02 passed.
Legacy UI	timeDesign -postRoute -expandedViews -outDir <dir> timeDesign -postRoute -hold -expandedViews -outDir <dir>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-postRoute` runs extraction and timing analysis at the post-route stage. Early Global Route does not run in this mode. `-expandedViews` adds a report directory for every active view. `-outDir` names the directory that receives the reports. `-hold` restricts the run to hold timing.
Scope and view	All active views, setup and hold as separate runs.
Setup and hold are separate	The timeDesign run reports setup unless -hold is given. Run both, and read each against its own views.
Effect on session	changes analysis configuration; writes files; runs an expensive analysis
Output	Summary and path reports in the chosen directory, with one subdirectory per view.
Fields that matter	WNS, TNS, number of violating paths and all paths per view, DRV counts, and the list of views in the summary.
Healthy	Every required view appears in the per-view reports, and the numbers equal the Chapter 11 baseline if nothing changed since.
Warning	The numbers differ from the Chapter 11 baseline with no recorded reason, for example a changed extraction mode.
Hard stop	A required view is missing, which leaves it NOT EVALUATED, or the log shows no detailed extraction.
Common misuse	Overwriting the baseline directory by reusing its name. Use a fresh -outDir for each run.
Root cause and fix	Fix the mode or the view setup, and rerun with a new directory.
Rerun after a fix	Rerun after any reroute or mode change.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

12.4.2 Post-stage checks

O-04Post-route optimisation run

Question it answers	Did post-route optimisation of DRV, glitch and setup violations finish, and what do its summary lines say?
Stage	After the baseline
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-01 to O-03 passed and the baseline is stored.
Legacy UI	optDesign -postRoute -expandedViews -outDir <dir> -prefix <p> optDesign -postRoute -drv optDesign -postRoute -incr optDesign -postRoute -noEcoRoute

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-postRoute` selects the stage after routing. `-expandedViews -outDir -prefix` write per-view reports to a named directory with a named prefix. `-drv` corrects max_cap and max_tran violations only. It cannot be used with -incr. `-incr` optimises setup incrementally on the paths that still violate. An earlier optDesign run on all path groups must exist. `-noEcoRoute` prohibits ECO routing during the run.
Scope and view	All active views, the whole design. -selectedNets can limit -drv and -hold runs.
Fanout and SI slew	The reference says post-route mode does not fix maximum fanout violations unless setOptMode -opt_fix_fanout_load is set, and SI slew violations only if -opt_post_route_fix_si_transitions is true. Record both settings. Set the fanout option from the first optDesign -preCTS call onward. In post-route mode -incr works only on high-effort path groups. By default post-route optimisation also calls ccopt_pro to repair clock DRVs.
Effect on session	changes analysis configuration; updates the design database; writes files; runs an expensive analysis
Output	A log with a final summary, report directories, and a changed database.
Fields that matter	WNS, TNS and violating paths per setup view before and after, DRV counts, whether ECO routing ran, and the changes the log lists.
Healthy	Setup and DRV violations fall to zero or to the project budget in every active view, and the summary lists every view.
Warning	Violations fall but remain in one view, with a recorded plan for -incr or for a waiver.
Hard stop	WNS or TNS gets worse, a required view is missing from the summary, or ECO routing was prohibited and the route was not repaired another way.
Common misuse	Treating optDesign returned as qualified. The command stops when it cannot improve, and the log summary may list fewer views than the design has.
Root cause and fix	Read the per-view reports, then rerun with -incr for what remains. For DRV only, use -drv.
Rerun after a fix	Rerun O-03 to compare, and O-08 for the physical state.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-05Hold fixing after routing

Question it answers	Are hold violations repaired in every hold view without damaging setup?
Stage	After setup is repaired
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-04 finished, and the filler cells, if any, are known to the tool.
Legacy UI	optDesign -postRoute -hold -holdVioData <name> optDesign -postRoute -setup -hold optDesign -postRoute -hold setOptMode -opt_post_route_setup_recovery auto setOptMode -opt_post_route_hold_recovery auto

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-hold` corrects hold violations and writes a summary file named prefix_hold.summary. `-holdVioData` writes the top 50 remaining hold paths as text, csv and a detailed text file. `-setup -hold` runs setup and hold together, which can reduce the number of ECO route passes. `-opt_post_route_hold_recovery` controls the hold recovery step in these runs.
Scope and view	All active hold views. -selectedNets and -selectedTerms can limit the repair.
Filler cells	The reference says optDesign removes the filler cells that setFillerMode identified at the start and adds them back at the end. If filler cells exist, identify them with setFillerMode before the run.
Effect on session	changes analysis configuration; updates the design database; writes files; runs an expensive analysis
Output	A hold summary file, optional violation data files, and a changed database.
Fields that matter	Hold WNS and TNS per view, the remaining violating paths, the reasons for hold paths left unfixed when verbose output is on, and the setup change caused by the repair.
Healthy	Hold violations are zero in every hold view, and setup WNS and TNS are within what the project allows.
Warning	A few hold violations remain with a reason in the log, such as no room for a delay cell.
Hard stop	Setup WNS or TNS degrades beyond what the project allows, or hold violations remain on paths the project requires clean.
Common misuse	Reading only the hold summary. Hold repair is setup aware, but by default it may degrade setup TNS (-opt_hold_allow_setup_tns_degradation defaults to true), so re-measure setup after every hold run.
Root cause and fix	Use -holdVioData to list the paths that remain, set -opt_verbose true to see why, then fix them with a targeted change or a waiver.
Rerun after a fix	Rerun O-03 for setup and hold, and O-08.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-06Timing after optimisation, per view

Question it answers	Is the final timing better than the baseline in every view, and did any view get worse?
Stage	After optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-04 and O-05 finished.
Legacy UI	timeDesign -postRoute -expandedViews -outDir <dir> timeDesign -postRoute -hold -expandedViews -outDir <dir>

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-postRoute -expandedViews` run detailed extraction and write a report directory per active view. `-outDir` names the final directory, which must differ from the baseline. `-hold` restricts the run to hold timing.
Scope and view	All active views, setup and hold separately.
Same endpoints	Compare counts of endpoints first. If the totals differ, the two runs did not analyse the same design, and nothing else in the comparison is safe.
Effect on session	changes analysis configuration; writes files; runs an expensive analysis
Output	Reports per view, plus summaries for setup and for hold.
Fields that matter	WNS, TNS and violating endpoints per view against the baseline, the endpoint count in both runs, and the engine and effort level used.
Healthy	Every view is equal or better than the baseline, the endpoint totals match, and the remaining violations are within the project budget.
Warning	One view improved while another got worse, for example hold repair that cost setup.
Hard stop	A view has more violating endpoints than in the baseline, or the endpoint totals differ between the two runs.
Common misuse	Comparing the optimisation log with the baseline. Use the same command, the same views and the same extraction mode for both.
Root cause and fix	Find the worst view and its paths with the path reports, then rerun O-04 with -incr or repair that group.
Rerun after a fix	Rerun O-06 after every optimisation step.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-07DRV and SI results

Question it answers	Are the design rule violations and the SI glitches gone, and are the SI settings in force the ones the methodology expects?
Stage	After optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-06 finished and SI-aware delay calculation was on.
Legacy UI	reportTranViolation -outfile <f> report_constraint -all_violators \ -drv_violation_type {max_transition max_capacitance max_fanout} -view <v> timeDesign -postRoute -drvReports -outDir <dir> setSIMode -enable_glitch_report true

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-outfile` writes the transition violation report to a file. Run it after timeDesign or optDesign. `-drv_violation_type` selects max_transition, max_capacitance or max_fanout. `-drvReports` writes only design rule violation reports. `-enable_glitch_report` stores the glitch data that SI glitch fixing and the report_noise command rely on.
Scope and view	Per view for report_constraint. The others cover the active views.
Glitch fixing needs data	SI glitch fixing needs the glitch report enabled, and warns if it is disabled. The default is false. With it off, timeDesign and optDesign still write the SI glitch report file, but report_noise is not available. Set it before the timing update.
Effect on session	changes analysis configuration; writes files; runs an expensive analysis. Some commands in this card only read or report.
Output	Violation lists and the SI glitch report file.
Fields that matter	Pins and ports over the transition limit, counts of max_cap, max_tran and max_fanout violations, and glitch failures.
Healthy	Zero DRV violations in every active view, and the glitch report lists no failures.
Warning	Fanout or SI slew violations outside the optimisation scope, or glitch fixing run with the glitch report disabled, listed and owned.
Hard stop	Max_cap or max_tran violations remain after the run.
Common misuse	Assuming a clean setup summary means clean DRVs. Slack and DRVs are separate counts, and fanout and SI slew are off by default in post-route mode.
Root cause and fix	Set the missing option, for example fixing of fanout load, and rerun O-04 with -drv.
Rerun after a fix	Rerun O-07 after every DRV run.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-08Physical integrity before and after ECO route

Question it answers	Was the route clean before optimisation, and did the optimisation and its ECO routing leave it legal, connected and similar in wire and vias?
Stage	Before and after optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	Run once before optimisation and again after O-06.
Legacy UI	checkPlace <report_file> verify_drc -limit 0 -report <f> verifyConnectivity -type regular -report <f> verify_antenna -report <f> report_route -summary

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-limit 0` removes the cap of 1000 reported violations. `-report` names the report file. `-type regular` checks regular wires and vias. `-summary` prints only the summary tables of the route report.
Scope and view	Whole design. Use the same scope before and after, so that the two sets of reports compare.
Run it twice	Run these commands before optimisation and save the reports, then run them again afterwards. Without the first set you cannot say what optimisation changed. New wires and vias can also add antenna violations, so the antenna check is part of this card. Repeat the special-net checks of D-09 if the ECO touched the power routes.
Effect on session	adds GUI violation markers; writes files; runs an expensive analysis. Some commands in this card only read or report.
Output	Markers, report files and route summary tables.
Fields that matter	Placement violations, DRC and connectivity counts, wire length and via count per layer against the saved pre-optimisation values, and the new violation types.
Healthy	Zero placement, DRC and connectivity violations, and wire length and via count move by an amount that you expect.
Warning	A few new spacing violations that ECO repair can fix, with a recheck planned.
Hard stop	Any new open, short or antenna violation, or placement violations that make the optimised cells illegal.
Common misuse	Running only the timing report after optimisation. A timing improvement can come together with a route that is no longer legal.
Root cause and fix	Repair with ecoRoute -fix_drc as in Chapter 11, then repeat O-06 because the repair changes wires.
Rerun after a fix	Rerun O-06 to O-08 after every repair.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

O-09Area and power cost, and power recovery

Question it answers	How much area and power did the repair cost, and does the project allow power recovery now?
Stage	After optimisation
Product	Innovus Implementation. The reference entry names no separate licence requirement for this command.
Required state	O-08 passed.
Legacy UI	report_area -out_file <f> report_power -outfile <f> optPower -postRoute setOptMode -opt_leakage_to_dynamic_ratio 0.0 optPower -postRoute

Common UI	Not yet verified No Common UI form is printed. The provided files do not document one.
Mapping	Not established in the provided documentation
Options used	`-out_file` writes the area report to a file. `-outfile` writes the power report to a file. `-postRoute` runs power optimisation on the routed design. `-opt_leakage_to_dynamic_ratio` sets the priority between dynamic power at 0 and leakage power at 1.
Scope and view	Top level and per hierarchy module. Power depends on the views and activity that you set up.
Only if the project uses power recovery	Per the reference, the default ratio of 1.0 optimises leakage only. Power analysis needs correct power views, library leakage data and switching activity. This book does not set those up. Power optimisation can also run inside optDesign when setOptMode -opt_power_effort is set, and -incr switches it off.
Effect on session	changes analysis configuration; updates the design database; writes files; runs an expensive analysis
Output	Area and power reports, and for optPower a changed database.
Fields that matter	Standard cell area per module and total power, to be compared with values taken before optimisation with the same settings.
Healthy	Area and power are within the project budget, and optPower, if used, left timing and DRC checks clean.
Warning	Area growth that the budget allows but that is large compared with the last project.
Hard stop	Area or power above the budget, or a power run that degraded timing or created violations.
Common misuse	Using optPower to fix timing. It reduces power without degrading timing, so it is a separate step that must be followed by O-06 and O-08.
Root cause and fix	Run optPower only if the project uses it, with the ratio recorded, then recheck timing and physical state.
Rerun after a fix	Rerun O-06 and O-08 after any optPower run.
Verification	Legacy syntax checked against the Innovus Legacy text reference.

12.5 Required reports, artefacts and how to read them

Report	Fields that support qualification	Evidence class
Mode record (O-01)	engine, effort level, SI setting, analysis type, non-default settings	implementation
View coverage (O-02)	active setup and hold views, met, violated and untested checks	implementation
Baseline timing (O-03)	WNS, TNS, violating paths, DRVs, per view	preliminary
optDesign log and summary (O-04, O-05)	before and after WNS and TNS, views listed, DRV counts, ECO route status	implementation
Final timing per view (O-06)	WNS, TNS and endpoint counts per view, against the baseline	implementation
DRV and glitch reports (O-07)	violating pins, counts by type, glitch failures	implementation
Physical recheck (O-08)	placement, DRC and connectivity counts, wire and via totals	implementation
Area and power reports (O-09)	cell area, total power, with the settings used	preliminary

Timing numbers from this stage are implementation evidence at best. Extraction runs at several effort levels, and signoff timing uses its own tool and parasitics. The numbers tell you whether the repair worked inside the implementation tool. They do not say the design passes signoff.

The excerpt below imitates the style of a post-route optimisation summary. Its numbers are made up, and the layout and field names in your log can differ.

Reading a post-route optimisation summarySynthetic report, not tool output

optDesign -postRoute -expandedViews -outDir rpt_final -prefix final
...
Setup views included: func_ss_setup scan_ss_setup
Hold views included:  func_ff_hold
                          before      after
Setup WNS (ns)            -0.287     -0.045
Setup TNS (ns)           -21.840     -0.150
Violating endpoints          225          6
All endpoints               4000       4000
Hold WNS (ns)              0.008      0.008
DRV max_cap                    0          0
DRV max_tran                   4          0
DRV max_fanout                 0          0
ECO route                                done
Per-view reports: rpt_final/<view>/

Read it in four passes. First, the footer and the view lists: the summary names two setup views and one hold view. If your methodology has four active views, the log has already told you something is missing, even before any number is read. Second, the counts: the endpoint totals are equal at 4,000, so both runs analysed the same design, which is the first thing to confirm.

Third, the slack: WNS improved from -0.287 to -0.045 ns and the violating endpoints fell from 225 to 6, so the repair worked, yet WNS is still negative. The stage is not qualified until those six endpoints are repaired or waived under your budget. Fourth, the DRVs and the ECO route line: four transition violations went to zero, and the line shows ECO routing ran, which makes O-08 mandatory. The figure shows the same slack picture as a histogram of the endpoints, with the counts printed on the bars.

Figure 15. Endpoint slack before and after post-route optimisation, with a counted ledger

Read it. Six slack bins run from below -0.20 ns to above 0.20 ns. Each bin has two bars: the before run in amber and the after run in blue, with the endpoint count above each bar. The first three bins have negative slack and are shaded. The before bars in those bins add to 225 endpoints and the after bars add to 6, all in the bin from -0.10 to 0.00. Both runs count 4,000 endpoints, as the ledger shows. Values are illustrative.

Hold needs its own reading. This run did not request -hold, so the unchanged positive hold WNS is expected. It is a pass only for the view that appears in the list, and says nothing about a hold view that is missing. Section 12.7.1 shows that case.

12.6 Healthy, suspicious and hard-stop examples

Finding	Status	Why
Setup and hold zero in every active view, endpoint totals equal	PASS	Better than baseline everywhere, with matching coverage.
A few setup violations remain with a plan	WARN / REVIEW	Record the plan, the budget and the extraction mode.
Timing run whose log shows no detailed extraction	NOT EVALUATED	The numbers do not describe the routed design.
A required view is missing from the report set	NOT EVALUATED	Its checks were not evaluated.
Setup TNS worse after hold fixing, beyond the project allowance	HARD STOP	The repair damaged a result that was already measured.
Endpoint totals differ between baseline and final	HARD STOP	The comparison is not between the same designs.
New short or open after optimisation ECO route	HARD STOP	The optimised route is not legal or connected.
Glitch fixing ran with the glitch report disabled	WARN / REVIEW	The tool warns, and the glitch result is not reliable.
Multi-supply optimisation checks in a single-supply block	NOT APPLICABLE	No power domains exist.

12.7 Debugging, corrective action and reruns

Work from the numbers that did not move. A violation count that stays high after a run tells you which kind of repair is missing, and the table below lists the usual links.

What you see	Likely cause	What to try
WNS unchanged after optDesign	Violating paths are on a group or a view that the run did not cover	Check O-02, then rerun with -expandedViews and read the per-view reports
Setup improves, hold gets worse	Setup repair shortened paths that hold needed	Run the hold repair, then re-measure setup
Hold repair degrades setup TNS	Delay cells added on shared endpoints, and the default allows it	Check the setting that allows setup TNS degradation and the hold recovery step
max_tran violations remain	Setting off, or violations on clock nets	Look at SI slew fixing and the clock DRV setting
Many glitch failures	Glitch fixing off, or run with the glitch report disabled	Enable the glitch report before the timing update, rerun, and read the SI glitch report file
New DRC after optimisation	ECO route made new wires	Run O-08, repair with ecoRoute -fix_drc, rerun O-06

12.7.1 Worked example: a view that the summary missed

Suppose the optDesign summary of the previous section lists three views, and the methodology names five. The first move is to compare the log with the view reports of O-02 rather than to trust the log.

The matrix in Figure 16 is the result of doing that. It lists each view and asks three questions: is it active, does the summary mention it, and does it have its own report. A view that fails the third question has no evidence at all. A view that fails only the second is covered, but the log is not enough to prove it.

Figure 16. Which analysis views each step covered, and the verdict per view

Read it. Five views are defined, one per row. Four are active and have their own report. The inactive view func_tt_hold has no numbers and is marked NOT EVALUATED. scan_ff_hold is active and passes, but the note marked with an asterisk says it is missing from the log summary and was found only in the per-view report. func_ss_setup is the only view that still fails, with 6 violating endpoints. Values are illustrative.

The matrix gives three different verdicts. func_ss_setup is a REVIEW: it ran and it fails. scan_ff_hold is a PASS that you could not have found from the log summary, which is why the per-view run of O-06 is required. func_tt_hold is NOT EVALUATED, and the status is not a pass. Either activate the view and rerun, or record a reason that your methodology accepts. Do not report it as met.

Decide in this order. Activate any required inactive view, rerun O-03 and O-06 with the same extraction mode, and compare endpoint counts. Then deal with func_ss_setup, as O-04 describes, using -incr. Only after that rerun the physical checks of O-08, because any further optimisation changes the route.

12.7.2 Worked example: what an ECO route does to a net

Optimisation adds buffers, and every added buffer needs a route. The reference says that when a net is modified, ecoRoute splits the wire: the part on one side of the new buffer stays with the original net and the rest is assigned to a new one. Figure 17 is a small model of this. A buffer is inserted into net N, the long M2 wire is ripped up between the two new pins, and the router reaches the buffer by going up to M3 on each side, with a via at each end of every M3 wire.

Figure 17. ECO route after a buffer is inserted into net N, with the change in coupling counted

Read it. Panel a shows net N on M2 track t3 running above net V on t4 for five pitches, from c2 to c7. In panel b a buffer sits on M1 under two pins. Net N is split into N1 and N2, the wire between c4 and c6 is ripped up, and two M3 wires at c4 and c6 connect the pins to the buffer through four vias. The side-by-side run on M2 falls to three pitches, and the two M3 wires now cross over net V. The ledger counts nets, vias, wire length and the run beside V. Values are illustrative.

Read the ledger as a trade. The side-by-side run falls from 5 to 3 pitches, which usually lowers the coupling to net V. Yet the wire grows from 7 to 9 pitches, four vias appear where there were none, and two new M3 crossings add coupling of a different kind. No one of these numbers decides the timing. They are the reason the extraction and the SI analysis must be rerun after the ECO route, and the reason the timing before the repair cannot be reused.

A short sequence follows. It repeats the baseline commands under new names and then the physical checks (Chapter 11 D-09 too, if power routes changed), so the before and after reports can be compared.

Recheck sequence after post-route optimisationIllustrative values

timeDesign -postRoute -expandedViews -outDir rpt_after
timeDesign -postRoute -hold -expandedViews -outDir rpt_after_hold
verify_drc -limit 0 -report drc_after_opt.rpt
verifyConnectivity -type regular -report conn_after_opt.rpt
verify_antenna -report ant_after_opt.rpt
report_route -summary

Compare the new wire and via totals with the summary saved before optimisation, and the endpoint counts of rpt_after with the baseline. If the DRC count is above zero, repair it and restart from the first line of the sequence. A repaired wire is a changed wire, and the timing of the nets it touches is old again.

12.8 Exit criteria and stage checklist

Modes. The extraction engine, effort level, SI and analysis settings were recorded and equal the methodology.
Views. Every required view is active, appears in a per-view report, and has no unexplained untested checks.
Baseline. The pre-optimisation timing is stored under its own directory, with the same modes as the final run.
Setup. Setup violations are zero or within the project budget in every active view, with equal endpoint totals.
Hold. Hold violations are zero in every hold view, and setup did not degrade because of the hold repair.
DRV and SI. Max_cap, max_tran and, if in scope, fanout violations are zero, and glitch fixing ran with its data enabled.
Route. Placement, DRC, connectivity and antenna are clean after the ECO route, and wire and via totals were compared with the baseline.
Cost. Area and power are recorded with the settings used and are within the project budget.
Limits. The report states what was not evaluated, and that signoff timing is still required.

A post-route optimisation is qualified when it improved every view that matters, damaged nothing that was already clean, and states plainly what it did not evaluate. A run that only reports a smaller WNS has completed. The next chapter adds the physical finishing steps, and each of them can change timing again.

CHAPTER 12 SANITY CHECKS

12.9 Sanity check cheat sheet: Post-route optimisation

One row per command card. Read left to right: the check, the command that answers it, then what a healthy result, a result to review and a hard stop look like. Judge every row against your project budgets, because this book sets no universal limits.

Card	Check and when	Command	Healthy	Review	Hard stop
O-01	Modes in force at entry Before optimisation	`getExtractRCMode -engine -effortLevel -coupled` `getDelayCalMode -SIAware` `getAnalysisMode -analysisType -cppr`	Engine and effort level as the methodology says, on-chip variation and coupling on, and non-default settings equal to the methodology list.	A non-default optimisation setting that nobody can explain.	The analysis type is not on-chip variation, coupling is off, or a script sets SI-aware false with no recorded reason.
O-02	Analysis view coverage Before optimisation	`report_analysis_views -type active` `all_setup_analysis_views all_hold_analysis_views` `report_analysis_coverage -view <v>`	The active lists equal the methodology, and no view reports untested checks that the project expects to be tested.	A defined but inactive view that the methodology marks as optional, listed as not evaluated.	A required view is inactive, or a view has untested checks that nobody can explain.
O-03	Baseline timing with detailed extraction Before optimisation	`timeDesign -postRoute -expandedViews -outDir <dir>` `timeDesign -postRoute -hold -expandedViews -outDir <dir>`	Every required view appears in the per-view reports, and the numbers equal the Chapter 11 baseline if nothing changed since.	The numbers differ from the Chapter 11 baseline with no recorded reason, for example a changed extraction mode.	A required view is missing, which leaves it NOT EVALUATED, or the log shows no detailed extraction.
O-04	Post-route optimisation run After the baseline	`optDesign -postRoute -expandedViews -outDir <dir> -prefix <p>` `optDesign -postRoute -drv` `optDesign -postRoute -incr`	Setup and DRV violations fall to zero or to the project budget in every active view, and the summary lists every view.	Violations fall but remain in one view, with a recorded plan for -incr or for a waiver.	WNS or TNS gets worse, a required view is missing from the summary, or ECO routing was prohibited and the route was not repaired another way.
O-05	Hold fixing after routing After setup is repaired	`optDesign -postRoute -hold -holdVioData <name>` `optDesign -postRoute -setup -hold` `optDesign -postRoute -hold`	Hold violations are zero in every hold view, and setup WNS and TNS are within what the project allows.	A few hold violations remain with a reason in the log, such as no room for a delay cell.	Setup WNS or TNS degrades beyond what the project allows, or hold violations remain on paths the project requires clean.
O-06	Timing after optimisation, per view After optimisation	`timeDesign -postRoute -expandedViews -outDir <dir>` `timeDesign -postRoute -hold -expandedViews -outDir <dir>`	Every view is equal or better than the baseline, the endpoint totals match, and the remaining violations are within the project budget.	One view improved while another got worse, for example hold repair that cost setup.	A view has more violating endpoints than in the baseline, or the endpoint totals differ between the two runs.
O-07	DRV and SI results After optimisation	`reportTranViolation -outfile <f>` `report_constraint -all_violators \ -drv_violation_type {max_transition max_capacitance max_fanout} -view <v>` `timeDesign -postRoute -drvReports -outDir <dir>`	Zero DRV violations in every active view, and the glitch report lists no failures.	Fanout or SI slew violations outside the optimisation scope, or glitch fixing run with the glitch report disabled, listed and owned.	Max_cap or max_tran violations remain after the run.
O-08	Physical integrity before and after ECO route Before and after optimisation	`checkPlace <report_file>` `verify_drc -limit 0 -report <f>` `verifyConnectivity -type regular -report <f>`	Zero placement, DRC and connectivity violations, and wire length and via count move by an amount that you expect.	A few new spacing violations that ECO repair can fix, with a recheck planned.	Any new open, short or antenna violation, or placement violations that make the optimised cells illegal.
O-09	Area and power cost, and power recovery After optimisation	`report_area -out_file <f>` `report_power -outfile <f>` `optPower -postRoute`	Area and power are within the project budget, and optPower, if used, left timing and DRC checks clean.	Area growth that the budget allows but that is large compared with the last project.	Area or power above the budget, or a power run that degraded timing or created violations.

CHAPTER 12 CHEAT SHEET

12.10 Command cheat sheet: Post-route optimisation

Legacy UI commands. Angle brackets are placeholders, and values shown are examples, not project limits.

Command	What it produces

Modes in force at entry
`getExtractRCMode -engine -effortLevel -coupled`	The extraction engine, the post-route effort level and whether coupling capacitance is output. Record them with every timing report.
`getDelayCalMode -SIAware`	The SI-aware setting. It reads false by default and when set false, but timeDesign and optDesign -postRoute turn it on unless you set it false.
`getAnalysisMode -analysisType -cppr`	The analysis type and the clock path pessimism removal setting.
`getOptMode -nonDefault`	Only the optimisation settings that are not default. This is the optimisation record for the run manifest.
`setExtractRCMode -engine postRoute -effortLevel medium`	Changes the session. Selects detailed extraction at medium effort (TQuantus, needs a Quantus technology file). Set it before the baseline run and keep it.
`setAnalysisMode -analysisType onChipVariation -cppr both`	Changes the session. The reference recommends on-chip variation with clock path pessimism removal for post-route optimisation.

View coverage
`report_analysis_views -type active`	A hierarchical report of the active views with their modes and corners.
`all_setup_analysis_views`	A Tcl list of the active setup views.
`all_hold_analysis_views`	A Tcl list of the active hold views.
`report_analysis_coverage -view <v>`	Met, violated and untested check counts for one view. Run it per view.

Timing reports
`timeDesign -postRoute -outDir <dir>`	Native detailed extraction by default and setup timing analysis, with reports written to the directory. No Early Global Route runs in this mode.
`timeDesign -postRoute -hold -outDir <dir>`	The same for hold only.
`timeDesign -postRoute -expandedViews -outDir <dir>`	Adds one report directory per active view, restoring views that auto view pruning removed.
`timeDesign -postRoute -drvReports -outDir <dir>`	Design rule violation reports only, without the path reports.

Optimisation runs
`optDesign -postRoute`	Changes the database. Post-route optimisation of design rule violations, glitch and setup violations, on base and SI delay by default.
`optDesign -postRoute -hold`	Changes the database. Repairs hold violations after routing and writes a hold summary file.
`optDesign -postRoute -setup -hold`	Changes the database. Setup and hold in one command, which can reduce the number of ECO routing passes.
`optDesign -postRoute -drv`	Changes the database. Corrects maximum capacitance and maximum transition violations only, leaving setup and hold alone.
`optDesign -postRoute -incr`	Changes the database. Incremental setup optimisation on the paths that still violate. In post-route mode it covers only high-effort path groups and switches power optimisation off.
`optDesign -postRoute -noEcoRoute`	Changes the database. Prohibits the ECO routing that post-route optimisation normally performs. Use it only if you route the changes another way.
`optDesign -postRoute -expandedViews -outDir <dir> -prefix <p>`	Changes the database. Writes per-view reports for all active views into the chosen directory with the chosen prefix.

Settings that steer optimisation
`setOptMode -opt_fix_fanout_load true`	Changes the session. Lets optimisation correct fanout load violations, which post-route mode does not fix by default. Set it from the first optDesign -preCTS call.
`setOptMode -opt_post_route_fix_si_transitions true`	Changes the session. Lets post-route optimisation fix SI slew violations, which it does not fix by default.
`setOptMode -opt_hold_allow_setup_tns_degradation false`	Changes the session. Stops hold repair from degrading setup total negative slack. The default is true, which allows the degradation.
`setOptMode -opt_verbose true`	Changes the session. Writes more optimisation detail to the log, including reasons for hold violations left unfixed.

DRV and SI results
`reportTranViolation -outfile <f>`	Pins and ports that exceed the transition constraints, written to a file. Run it after timeDesign or optDesign.
`report_constraint -all_violators -drv_violation_type {max_transition max_capacitance max_fanout} -view <v>`	Every violating pin for the three design rule types in one view.
`setSIMode -enable_glitch_report true`	Changes the session. Stores glitch data for report_noise and SI glitch fixing, which warns when it is off.

Physical integrity after optimisation
`checkPlace <report_file>`	Placement violations of fixed and placed cells, with markers and a report file.
`verify_drc -limit 0 -report <f>`	Geometry violations without the 1000 cap, with markers and a report file.
`verifyConnectivity -type regular -report <f>`	Opens, dangling wires, unconnected pins and loops on regular routing.
`verify_antenna -report <f>`	Process antenna and maximum floating area violations on the routed design.
`report_route -summary`	Wire length per layer and via count per cut layer, to compare with the pre-optimisation route.

Area and power
`report_area -out_file <f>`	The standard cell area per hierarchy module and for the top level, written to a file.
`report_power -outfile <f>`	The power report, written to a file. Take it before and after with the same settings.

Power recovery, only if the project uses it
`optPower -postRoute`	Changes the database. Swaps gates for lower-power ones or deletes buffers without degrading timing. Leakage only unless the ratio is changed.
`optPower -postRoute -allowResizing`	Changes the database. Allows resizing for power. The command itself runs placement refinement, ECO routing and recovery, takes longer, and can still degrade timing.
`setOptMode -opt_leakage_to_dynamic_ratio <r>`	Changes the session. A value from 0 to 1 that sets the priority between dynamic power (0) and leakage power (1).