Path-Based and Robustness Analysis: Removing Pessimism and Measuring Risk

Chapter overview

The default timing engine works on a graph. It computes one arrival time and one slew per pin, and every path through that pin shares them. This is fast, and it is safe. However, it is often pessimistic. A path can fail in the report even though it would pass in silicon.

Let us consider a common end-of-project situation. Twenty paths still fail by a few picoseconds. Fixing them costs area, power and an ECO loop. Each ECO loop can take a day or more. Before fixing anything, the designer wants a sharper answer: are these failures real?

This chapter gives five tools for that question, and for a few related ones:

• Path-based analysis recomputes each critical path with its own data, and removes pessimism.
• Parametric timing robustness measures the probability that the whole chip passes.
• Simultaneous switching inputs model gates whose inputs move together.
• Rail swing and waveform-aware pulse width checks look at the real shape of a waveform.
• Instance libraries fix cases where one instance needs a different library.

Notice that the first two make the answer less pessimistic or more informative. The next three make the analysis more realistic, which can expose failures that a plain report hides. Thus, this chapter is about accuracy in both directions.

Learning objectives

1. Explain why graph-based analysis is pessimistic at multi-input pins, using slew numbers.
2. Run path-based analysis with report_timing -⁠retime and read the retimed columns and header.
3. Choose between regular and exhaustive path-based modes, and set the exhaustive path limit.
4. Describe how path-based analysis treats AOCV depth and signal integrity windows.
5. Set up a parametric timing robustness run and read its five slack properties.
6. Apply a simultaneous-switching derate and a switching window, and predict when the window is tested.
7. Set rail swing and waveform-aware pulse width thresholds, and report both checks.
8. Bind an instance to its own library with set_instance_library and confirm the binding.

Chapter roadmap

The chapter moves from the most used feature, path-based analysis, to more specialized checks. Figure 1 shows the order. Come back to it whenever you lose your place.

Path-based and robustness analysis on one page

Five features that make slack closer to silicon

Key commands

Table 1 lists the commands and settings covered in this chapter, grouped by section. Do not try to memorize them now. Each one is explained when it is first needed.

1  Path-based analysis (PBA)

1.1  The concept

Every timing report starts from a simple picture. Signals travel from a launch flop, through gates and wires, to a capture flop. Each gate adds a delay. That delay depends on two things. One is the load the gate drives. The other is the slew of its input – how fast the input edge rises or falls.

A slow input edge gives a larger delay, because the gate starts switching later and switches more slowly. A fast input edge gives a smaller delay. Thus, the input slew of every gate matters for the slack of every path through it.

In graph-based analysis (GBA), the tool walks the design once, pin by pin. Each pin keeps one worst arrival and one worst slew. When two paths meet at a gate, the gate output is computed from the worst of its inputs. Every path through that gate then inherits the worst value – even a path that never had it.

Let us consider Figure 2. Two paths meet at the NAND gate U3. The input from U1 has a slow slew of 120 ps. The input from U2 has a fast slew of 30 ps. We want to time the path from FF2 to FF3, drawn in red.

Why GBA is pessimistic at a merge point

Two paths share gate U3, but only one has a slow slew

In GBA, U3 uses the worst input slew, 120 ps, to compute its delay and its output slew. Thus, the path from FF2 is charged for a slew it never sees. The slower output slew of U3 then also slows FF3's setup check. The error grows with every merge point along the path.

Path-based analysis (PBA) fixes this. It takes one path at a time and recomputes every delay along it with that path's own slews. This is called retiming a path. In Figure 2, PBA computes U3 with the 30 ps slew. The slack moves from −0.03 ns to +0.02 ns.

1.2  Why it matters

PBA removes pessimism without changing the design. A path that passes in PBA is not a real violation, so it does not need a fix. On a large design, PBA often clears many small GBA violations. Each cleared path saves an ECO change, which saves area, power and a re-run.

In most settings, the GBA slack is a safe bound on the PBA slack. In other words, PBA slack is typically equal to or better than GBA slack. Thus, GBA stays the safe first pass for the whole design. PBA is the sharper answer for the paths that matter.

However, PBA is slow. Each retimed path needs its own delay calculation for every stage. Retiming every path in a design is not practical. The tool therefore retimes a chosen set of critical paths, as we will see below.

1.3  Running PBA

PBA is requested through report_timing with the -⁠retime option. The following command retimes the worst setup paths and writes a short summary file.

tempus> report_timing -retime path_slew_propagation \
          -max_paths 500 -nworst 5 \
          -path_type summary_slack_only -late \
          -analysis_summary_file pba.summ   ;# PBA on setup paths, summary to file

Each argument has a clear job:

• -⁠retime path_slew_propagation – retime each path, propagating its own slew from stage to stage. Without -⁠retime, the report is plain GBA. This is the value you will use most often.
• -⁠max_paths 500 – the number of GBA paths the report considers. In the regular-mode description below, this plays the role of N. A larger value catches more paths but costs more run time.
• -⁠nworst 5 – at most this many paths per endpoint. This plays the role of M. Without it, one bad endpoint could fill the whole report with its own paths.
• -⁠path_type summary_slack_only – one line per path, with slack only. This keeps a 500-path report short enough to scan.
• -⁠late – setup analysis. Use -⁠early for hold. Forgetting this switch gives you the wrong check type.
• -⁠analysis_summary_file pba.summ – writes a summary of the PBA run to a file. Keep it with the run, so later runs can be compared.

The mapping of N and M to -⁠max_paths and -⁠nworst follows the usual meaning of these options. Confirm the exact behavior with help report_timing in your installation.

The constraint report also accepts retiming. Use report_constraint -⁠retime with a retime value, so the violation summary reflects PBA slack. Confirm the allowed values with help report_constraint.

1.4  Reading a PBA report

A retimed report can show three extra columns. Add them with the report_timing_format global or with the -⁠format option of report_timing:

• retime_slew – the slew recomputed along this path. Compare it with the GBA slew to see where the pessimism was.
• retime_delay – the stage delay recomputed with that slew.
• retime_incr_delay – the incremental delay after retiming, stage by stage.

The report header names the retime method, for example Retime Analysis {Path-Slew ...}. The line Slack Time(original) shows the GBA slack of the same path. Thus, one report shows both numbers side by side.

Retime Analysis {Path-Slew}
Slack Time(original)   -⁠0.030
Slack Time              0.020

Figure 3 breaks the same path into stages. It shows where the gain comes from.

Where retiming gains its slack

The path from Figure 2, with GBA and retimed values side by side

In this illustrative case, the path gained 0.050 ns from retiming. If the gain is very large on one stage, look at that stage's retime_slew. A large drop in slew usually points to a merge pin with a slow side input.

1.5  Retiming the clock path too

PBA can retime only the data path, or the clock paths as well. Clock trees also have merge points, for example clock muxes and clock gating cells. The launch and capture clock paths can carry GBA pessimism of their own.

The variable timing_disable_retime_clock_path_slew_propagation controls this. When it is true, only the data path is retimed. When it is false, the clock paths are retimed as well.

Let us consider Figure 4. Two clocks meet at a clock mux. In this illustrative case, GBA gives the mux output the worse of the two slews, 110 ps. The launch and capture clocks of CLKA then carry a slew they never see.

Retiming the clock path

A clock mux merges a fast clock and a slow clock

tempus> set timing_disable_retime_clock_path_slew_propagation false   ;# retime clock too

Note the double negative in the name: "disable" set to false means clock retiming is on. It is better to retime the clock path when the clock tree has merge points with mixed slews. Otherwise, the launch and capture clocks keep their GBA pessimism, and PBA removes only part of it. Retiming the clock typically costs extra run time, so check the run time on a small path set first.

1.6  Regular and exhaustive modes

The tool has two ways to choose the paths it retimes. In regular mode, it works in three steps:

1. It takes the top N GBA paths with slack below a limit S, with at most M paths per endpoint.
2. It retimes each of them with its own slews.
3. It reports the retimed paths whose PBA slack is still below S, sorted by GBA slack.

Figure 5 compares regular mode with the exhaustive mode described below.

Regular and exhaustive PBA

How the tool picks the paths it retimes, and how it sorts the result

The sort order matters. Let us consider four paths, shown in Table 2. Assume the slack limit S is +0.020 ns, so all four are reported. Path P1 is worst in GBA, but it gains the most from retiming. Path P3 gains very little.

The first line of the report is P1, which passes after retiming. The worst real slack, −0.025 ns, sits on the third line. Thus, do not read the top line of a regular PBA report as the worst real slack.

There is a second, quieter risk. Regular mode only retimes the paths it picked from GBA. At a busy endpoint, the worst PBA path may not be among the top M GBA paths. Regular mode can then miss it entirely.

Figure 6 shows how this happens at one endpoint.

How regular PBA can miss the worst path

Six paths into one endpoint, each with its GBA and PBA slack

In exhaustive mode, set with -⁠retime_mode exhaustive, the tool searches for the true worst PBA path at each endpoint. It retimes up to L paths per endpoint, going deeper than the GBA order. The limit L is set with a global:

tempus> set_global timing_pba_exhaustive_path_nworst_limit 20000   ;# default is 10K
tempus> report_timing -retime path_slew_propagation -retime_mode exhaustive \
          -max_paths 100 -late   ;# true worst PBA path, sorted by PBA slack

The default limit is 10K paths per endpoint. If the L-th path at an endpoint still violates in GBA, the search may have stopped too soon. The tool then issues a warning that the result is incomplete. The exhaustive report is sorted by PBA slack, so its first line is the worst real slack.

When should you raise L? Raise it when the incomplete-search warning appears. A higher limit gives a complete answer at the cost of run time. If the warning keeps appearing, the endpoint has a huge number of near-critical paths, which is itself worth a closer look.

1.7  PBA with AOCV and signal integrity

PBA also changes two other parts of the calculation.

AOCV depth. With AOCV, the stage count of a path decides its derate (see Analysis Modes, CPPR and AOCV). GBA works with a pin-based count, which can differ from the real depth of one path. Thus, the AOCV derate can differ between GBA and PBA. Two retime values handle this:

• -⁠retime aocv – retime the AOCV depth of the path.
• -⁠retime aocv_path_slew_propagation – retime both the AOCV depth and the slew.

The timing_aocv_analysis_mode global still controls how launch and capture depth are counted. When AOCV is on, it is better to use aocv_path_slew_propagation, because it removes both kinds of GBA pessimism together.

Signal integrity. Crosstalk depends on timing windows – the time ranges in which nets can switch (see Signal Integrity Delay Analysis). PBA recomputes the victim timing window for the path being retimed. The aggressor timing windows always stay as GBA computed them. Thus, PBA sharpens the victim side only.

Figure 7 shows why this can remove an attacker from a path.

PBA and crosstalk timing windows

The victim window is recomputed for one path; the aggressor window is not

The report header then lists the active methods, for example { Path-Slew SI WP EWM }. Here, SI most likely marks crosstalk-aware retiming, and EWM the equivalent waveform model from Base Delay Calculation. Confirm every tag with help report_timing.

2  Parametric timing robustness (PTR)

2.1  The concept

A normal report gives one slack per path, computed at a fixed number of sigmas. Each path is judged on its own. However, the chip passes only if every endpoint passes at the same time, on the same piece of silicon.

Parametric timing robustness (PTR) answers that chip-level question: what is the probability that all endpoints meet timing together? A result of 0.977 means that, under the statistical model, about 977 chips in 1,000 meet timing on all endpoints.

PTR needs the tpsng license. The tool estimates the probability by Monte Carlo (MC) sampling per timing arc. In simple terms, it draws random delay values for the arcs from their statistical data. It then times the design with those values, and repeats. Figure 8 shows the loop.

How Monte Carlo sampling builds a pass probability

Each sample is one possible chip; the share of passing samples is the probability

Each sample gives one worst chip slack. Many samples build a curve of worst chip slack. Let us consider Figure 9. The shaded tail to the left of zero is the chance that at least one endpoint fails.

Chip slack as a distribution

Sampling the delays many times gives a spread of worst chip slack

The numbers in Figure 9 can be checked by hand. Zero slack sits (0.050 − 0) / 0.025 = 2 sigma below the mean. For a normal curve, about 97.7% of samples lie above that point.

2.2  Why it matters

Fixed-sigma signoff treats each path on its own. In a large chip, many paths are each "probably fine". However, the chance that all of them pass together can be lower than the chance for any single path.

For example, assume 100 independent paths, each passing with probability 0.999. The chance that all pass is 0.999¹⁰⁰, about 0.905. Real paths share cells and are not independent, so the real number differs. Still, the example shows why a chip-level view adds information.

PTR shows that combined risk as one number. Thus, it helps the designer decide whether small residual violations really threaten yield. It also gives a common language for the discussion between designers and managers.

2.3  The library data PTR needs

PTR needs Liberty Variation Format (LVF) data – statistical delay tables inside the library. Each table gives a sigma for each combination of input slew and output load, much like a normal delay table.

A form of LVF with moments is strongly recommended. Plain sigma tables describe only the spread of a delay. Moments also describe how the mean shifts and how lopsided the distribution is. Real delay distributions are often lopsided, with a longer tail on the slow side. Moments let the samples follow that shape.

Figure 10 shows a lopsided delay and the moment that describes each of its features.

What moment LVF describes

A lopsided delay distribution next to a symmetric sigma-only model

The sigma table groups are listed in Table 3.

These groups carry a sigma_type of early or late. An early table describes the fast side of the distribution; a late table describes the slow side. The constraint tables are the exception: they have no early or late split.

The moment groups are:

• ocv_std_dev_* – the standard deviation of the value.
• ocv_mean_shift_* – how far the mean moves from the nominal value.
• ocv_skewness_* – how lopsided the distribution is.

The moment groups have no sigma_type. They can sit in the same library as the ocv_sigma_* groups, so one library can serve both normal SOCV runs and PTR.

2.4  Running PTR

The following script turns PTR on and runs it on one path group.

tempus> set_analysis_mode -timing_robustness true   ;# enable robustness analysis
tempus> set timing_disable_retime_clock_path_slew_propagation false   ;# PBA on clock too
tempus> set_delay_cal_mode -socv_lvf_mode moments   ;# use moment LVF data
tempus> set_delay_cal_mode -socv_accuracy_mode ultra   ;# statistical accuracy setting
tempus> set P1 [report_timing_robustness -check_type setup -path_group R2R \
          -target_PTR 0.95 -run_time_limit 15]   ;# setup PTR for group R2R
tempus> report_property $P1   ;# print the result properties

The setup lines each have a reason:

• set_analysis_mode -⁠timing_robustness true – turns the robustness engine on. Without it, report_timing_robustness has nothing to work with.
• timing_disable_retime_clock_path_slew_propagation false – retimes the clock paths too, so clock pessimism does not distort the probability.
• -⁠socv_lvf_mode moments – tells delay calculation to read the moment tables. Without moment data in the library, this setting has nothing to use.
• -⁠socv_accuracy_mode ultra – selects the statistical accuracy level used in this flow. Confirm the other levels and their run-time cost with help set_delay_cal_mode.

The options of report_timing_robustness are:

• -⁠check_type setup – the kind of check to evaluate. Use the check type that worries you, typically setup at the slow corner.
• -⁠path_group R2R – the path group to analyze; here, register-to-register paths. One group at a time keeps the run small.
• -⁠target_PTR 0.95 – the pass probability you aim for. The quantile in the result is reported at this target.
• -⁠run_time_limit 15 – a limit on the run time of the analysis. Confirm its unit with help report_timing_robustness.

The result is stored in the variable P1. It holds five properties, read with report_property:

• slack_mean – the mean of the worst-slack distribution.
• slack_stddev – its standard deviation, the width of the curve.
• slack_skewness – how lopsided it is. A negative skew means a longer tail toward failing slack.
• slack_ptr – the pass probability, the share of samples where every endpoint passes.
• slack_quantile – the slack at the target probability. In Figure 9, 95% of samples have slack above 0.009 ns.

Let us check the quantile by hand. For a normal curve, the 5% point lies 1.645 sigma below the mean. Thus, 0.050 − 1.645 × 0.025 ≈ 0.009 ns. A positive quantile at the target means the target is met.

3  Simultaneous switching inputs (SSI)

3.1  The concept

A library delay table is measured with one input switching while the other inputs stay still. This is a clean, repeatable setup for characterization. In real circuits, however, two inputs of a gate can switch at almost the same moment. The output then moves at a different speed from the table.

Let us consider the NOR2 gate in Figure 11. Its output Y falls when an input rises. A NOR2 has two pull-down transistors in parallel, one per input. If A rises alone, one transistor discharges Y. If A and B rise together, two transistors discharge Y in parallel, so Y falls faster.

In Figure 11, the single-input delay is 40 ps. With both inputs switching, it is 28 ps. Thus, the real delay is 30% smaller than the library table says. The exact speed-up depends on the cell and on how close the two edges are.

Two inputs switching together

When B switches inside the window that opens at A's edge, the output falls faster

3.2  Why it matters

A faster output edge shortens the data path. For a setup check, a shorter path is good news. For a hold check, a shorter data path is the dangerous case. Data may change before the capture flop has held it.

Thus, ignoring simultaneous switching can hide real hold violations. Those failures do not depend on clock frequency, so the chip would fail at any speed. SSI modeling applies a derate to chosen cells when their inputs switch together.

3.3  Command breakdown

The derate uses set_timing_derate with the -⁠input_switching option:

tempus> set_timing_derate 0.5 -fall -data -early -delay_corner tt_800 \
          -power_domain pdDefault \
          -input_switching [get_lib_cells NOR2*]   ;# halve early fall delay on NOR2

Each part of the command narrows where the derate applies:

• 0.5 – the derate factor applied to the delay. A factor below 1 makes the delay smaller, which is the pessimistic direction for hold.
• -⁠fall – apply only to falling output transitions. For a NOR2, the falling output is the case with parallel pull-downs.
• -⁠data – apply only on data paths, not clock paths.
• -⁠early – apply in early analysis, which is used for hold checks.
• -⁠delay_corner tt_800 – apply only in this delay corner. Other corners keep their own settings.
• -⁠power_domain pdDefault – apply only to cells in this power domain.
• -⁠input_switching [get_lib_cells NOR2*] – the library cells that get the SSI treatment. Here, every NOR2 variant.

The value 0.5 is an example. The right factor for your library should come from characterization or from your library team. Too small a factor creates false hold violations; too large a factor misses real ones.

3.4  The switching window

Two inputs count as simultaneous when the second one switches inside a switching window. The window opens at the edge of the first input. By default, the window equals the early delay of the pin that switches first.

For example, assume A switches at 100 ps, and the early delay from A is 40 ps. The window then runs from 100 ps to 140 ps. If B switches at 120 ps, it falls inside the window. If B switches at 160 ps, it does not, and no SSI derate applies.

Figure 12 draws both cases.

The switching window in numbers

A opens a 40 ps window at 100 ps

To size the window per library, define and set a float property:

tempus> define_property -type float -object_type lib k_input_switching_window_rise   ;# rise
tempus> define_property -type float -object_type lib k_input_switching_window_fall   ;# fall
tempus> set_property [get_libs slow] k_input_switching_window_rise 1.1   ;# window factor

• define_property -⁠type float -⁠object_type lib – creates the property on library objects. It must exist before it can be set.
• k_input_switching_window_rise and k_input_switching_window_fall – one property for rising and one for falling inputs.
• set_property [get_libs slow] ... 1.1 – sets the value for the library slow. Confirm with help how the value 1.1 scales the default window in your installation.

These property settings persist when the constraints are written out as SDC. Thus, a later session that reads that SDC keeps the same windows.

3.5  When the window is tested

The clocks of the two inputs decide whether the tool tests the window at all. Figure 13 lists the five cases.

Clock relationships and the SSI window

Whether the tool tests the switching window depends on the clocks of the two inputs

The reasoning follows from what the tool can know:

• Synchronous, same frequency and phase – the arrival times are known, so the tool tests the window.
• Synchronous, different frequency or phase – the edges have no single fixed offset to test, so the tool treats them as always simultaneous.
• Physically exclusive – the clocks never exist on the chip together, so the inputs never switch together.
• Logically exclusive – the tool tests the window if the period and phase match.
• Asynchronous – nothing rules out an overlap, so the tool assumes one.

3.6  Combining derates and the GBA–PBA link

An SSI derate multiplies with any user derate on the same arc. For example, a user derate of 0.90 and an SSI derate of 0.50 give 0.90 × 0.50 = 0.45. A 40 ps arc then becomes 40 × 0.45 = 18 ps in early analysis. The report shows the product in the "User Derate" column.

Figure 14 shows this rule together with the GBA–PBA rule below.

How the SSI derate combines

The derates multiply, and the GBA decision carries into PBA

The decision to apply SSI is taken in GBA. If GBA applies it to an arc, PBA applies it too, even if the retimed windows would no longer overlap. This keeps the rule that GBA bounds PBA. Thus, a PBA report may still show an SSI derate that looks surprising at first.

4  Rail swing and waveform-aware pulse width

Both checks in this section look at the real voltage shape of a waveform, not only at its 50% crossing. The usual delay numbers say when a signal crosses the middle. These checks ask how far and how long it really goes.

4.1  Rail swing checks

A healthy signal swings almost fully between ground and the supply. Let us consider Figure 15. A weak driver feeds a long wire and many receivers. It needs a long time to charge all that capacitance.

A weak driver on a heavy load

One small buffer must charge a long wire and eight inputs

If the input of the driver toggles again before the output settles, the output never reaches the rail. A receiver then sees a level that is neither a clean 1 nor a clean 0. It may switch late, draw extra current, or fail to switch at all. The rail swing check catches this.

Figure 16 shows two signals. The green signal reaches both rails. The red signal peaks at 0.88 of the supply and then settles at 0.20, so it misses both thresholds.

The thresholds are globals, written as ratios of VDD:

tempus> set timing_rail_swing_checks_high_voltage_threshold 0.95   ;# ratio of VDD
tempus> set timing_rail_swing_checks_low_voltage_threshold 0.05    ;# ratio of VDD
tempus> report_constraint -check_type rail_swing -all_violators    ;# list failures

• timing_rail_swing_checks_high_voltage_threshold 0.95 – a rising signal must reach 95% of VDD. With VDD = 0.80 V, that is 0.76 V.
• timing_rail_swing_checks_low_voltage_threshold 0.05 – a falling signal must drop below 5% of VDD, 0.04 V in the same example.
• report_constraint -⁠check_type rail_swing -⁠all_violators – lists every signal that misses a threshold.

Rail swing check

A signal must rise above the high threshold and fall below the low threshold

Because the thresholds are ratios, the same setting works at every voltage corner. The usual fixes are a stronger driver, a smaller load, or buffering the long net.

4.2  Waveform-aware minimum pulse width

A minimum pulse width (MPW) check makes sure a clock pulse stays high, or low, long enough for a flop to respond. The regular check measures the width at the 50% crossings. However, a slow edge spends part of that time far from the rail. There, the flop may not yet see a valid level.

Let us consider Figure 17. At 50%, the pulse is 0.32 ns wide. At the 75% level, it is only 0.28 ns wide. Assume a 0.30 ns requirement. The regular check passes with 0.02 ns margin. The waveform-aware check fails by 0.02 ns.

The width loss comes from both edges. In Figure 17, each edge takes 0.08 ns to go from 0 to 100%. Moving the measurement from 50% to 75% costs a quarter of each edge. That is 0.02 ns on the rise and 0.02 ns on the fall.

Regular and waveform-aware pulse width

The same pulse measured at two voltage levels

The measurement levels are globals. The requirement and the report take a -⁠waveform_aware_type option:

tempus> set timing_waveform_aware_pulse_width_checks_high_voltage_level 0.75   ;# high level
tempus> set timing_waveform_aware_pulse_width_checks_low_voltage_level 0.25    ;# low level
tempus> set_min_pulse_width 0.1 [get_clocks clk1] \
          -waveform_aware_type absolute   ;# requirement on clk1
tempus> report_min_pulse_width -waveform_aware_type both \
          -pins FF1/CP -verbose   ;# regular and waveform-aware

The script uses a 0.1 ns requirement on clk1 as a syntax example. Each setting does one job:

• timing_waveform_aware_pulse_width_checks_high_voltage_level 0.75 – a high pulse is measured where the signal is above 75% of VDD.
• timing_waveform_aware_pulse_width_checks_low_voltage_level 0.25 – a low pulse is measured where the signal is below 25% of VDD.
• set_min_pulse_width ... -⁠waveform_aware_type – takes absolute or source_width_ratio. An absolute requirement is a fixed time. A ratio requirement is relative to the source pulse width. Confirm the exact meaning with help set_min_pulse_width.
• reset_min_pulse_width – removes such requirements, for example before reading a corrected constraint set.
• report_min_pulse_width -⁠waveform_aware_type – takes regular, waveform_aware or both. The default is regular, so a waveform-aware check is not reported unless you ask for it.
• -⁠pins FF1/CP -⁠verbose – limits the report to one clock pin and prints the detail of the measurement.

5  Binding instances to a library

5.1  The concept

Normally, every instance of a cell takes its timing from the library set of its delay corner. If the netlist uses AND2X1, every AND2X1 instance uses the same table. This is simple and usually correct.

Sometimes one instance needs a different library. It may run at another voltage, or it may be a macro characterized at a slightly different corner. The command set_instance_library binds chosen instances to a named library, while the rest of the design keeps the normal one.

5.2  Why it matters

Three situations call for it:

• Multi-supply designs without power intent – some instances run at another voltage, but no power-intent file tells the tool. Without a binding, those instances are timed at the wrong voltage.
• Macros without a matching PVT – a macro library exists only at a corner that does not match the rest. The binding lets the corner still use it.
• Patching mis-bound instances – an instance picked up the wrong library and needs a quick correction, without rebuilding the library sets.

In each case, the wrong library gives wrong delays. That can hide real violations or create false ones on the affected paths.

5.3  How it works

Figure 18 shows the flow. The binding lives in a small Tcl file. That file is passed to the delay corner, so the binding applies per corner.

Binding instances to their own library

A side file names the library and instances; the delay corner reads it

set_instance_library -library newcell.lib -instance {iP/and1 iP/dff1}   ;# bind two instances

• -⁠library newcell.lib – the library the instances should use.
• -⁠instance {iP/and1 iP/dff1} – the hierarchical names of the instances to bind.

tempus> create_delay_corner -name slow_max -library_set complete_library_set \
          -pg_net_voltages {VDD2@0.9 VDD1@0.9} \
          -instance_library_file sil.tcl   ;# corner with instance bindings
tempus> report_instance_library -inst {iP/and1 iP/dff1}   ;# check the binding

• -⁠library_set complete_library_set – the normal library set for this corner.
• -⁠pg_net_voltages {VDD2@0.9 VDD1@0.9} – names a voltage for each supply net in this corner, here 0.9 V for both.
• -⁠instance_library_file sil.tcl – reads the binding file for this corner.
• report_instance_library -⁠inst – prints the binding for the named instances. The line User Setting : True means the binding was applied.

Keep four rules in mind:

• The library, here newcell.lib, must be part of an active create_library_set. Otherwise the binding cannot take effect.
• save_design writes the binding under ${::IMEX::silLibVar}/mmmc/, so a restored session keeps it.
• There is no voltage scaling for a bound instance. The library must already be at the right voltage.
• If several libraries are given, only the first is used. List one library per binding.

6  Worked example: are these failures real?

Let us join the features in one session. The assumptions are written as comments at the point of use.

The task. A block has 12 setup violations of up to −25 ps after GBA. It also has a clock pulse-width concern on FF1, and NOR2 cells on a hold-critical bus. The design is loaded with SOCV and moment LVF libraries (see SOCV and Wire Variation).

Step 1 – retime the setup failures

We start with regular PBA, because it is fast and shows how much pessimism GBA added. We retime the clock path too, so both sides of each check are sharp.

tempus> set timing_disable_retime_clock_path_slew_propagation false   ;# retime clock too
tempus> report_timing -retime path_slew_propagation -max_paths 200 -nworst 3 \
          -path_type summary_slack_only -late \
          -analysis_summary_file setup_pba.summ   ;# retime the top setup paths

What to look for. Compare Slack Time(original) with the new slack for each path. Assume nine paths now pass. The report is sorted by GBA slack, so the order may hide the worst PBA path.

Step 2 – confirm the true worst path

Regular mode may have missed a path, and its order is not the PBA order. Exhaustive mode answers both concerns.

tempus> set_global timing_pba_exhaustive_path_nworst_limit 10000   ;# keep the default 10K
tempus> report_timing -retime path_slew_propagation -retime_mode exhaustive \
          -max_paths 20 -late   ;# sorted by PBA slack

What to look for. First, check the log for the incomplete-search warning. If none appears, the first path is the true worst PBA path. Assume exhaustive mode confirms three failing paths. Only those three need an ECO.

Step 3 – model simultaneous switching on the bus

The hold-critical bus uses NOR2 cells whose inputs come from the same clock. SSI can make them faster than the tables say.

# Assuming the bus is clocked by one synchronous clock, so the window is evaluated
tempus> set_timing_derate 0.5 -fall -data -early -delay_corner tt_800 \
          -power_domain pdDefault \
          -input_switching [get_lib_cells NOR2*]   ;# faster fall when inputs switch together
tempus> report_timing -early -max_paths 20   ;# hold paths with SSI applied

What to look for. Check the "User Derate" column on the NOR2 arcs. A value of 0.5 shows that SSI applied. Any new hold failure here is a real risk, not pessimism.

Step 4 – check the clock pulse on its real waveform

tempus> set timing_waveform_aware_pulse_width_checks_high_voltage_level 0.75   ;# high level
tempus> set timing_waveform_aware_pulse_width_checks_low_voltage_level 0.25    ;# low level
tempus> report_min_pulse_width -waveform_aware_type both \
          -pins FF1/CP -verbose   ;# both checks on FF1

What to look for. If the regular check passes but the waveform-aware check fails, the clock edge at FF1 is too slow. The fix is usually on the clock driver, not on the data path.

Step 5 – measure the remaining risk

tempus> set_analysis_mode -timing_robustness true   ;# enable PTR
tempus> set_delay_cal_mode -socv_lvf_mode moments   ;# moment LVF
tempus> set P1 [report_timing_robustness -check_type setup -path_group R2R \
          -target_PTR 0.95 -run_time_limit 15]   ;# probability for R2R
tempus> report_property $P1   ;# slack_ptr, slack_quantile and the rest

What to look for. Read slack_ptr and slack_quantile. If slack_ptr is above the 0.95 target, the team has a measured basis to discuss the three small violations. Otherwise, the ECO goes ahead. Either way, the decision now rests on numbers, not on guesswork.

7  Common mistakes and how to catch them

Table 4 gathers the mistakes from this chapter. Each row gives the symptom you would see first.

8  Interview preparation

Chapter recap

Key takeaways

• GBA keeps the worst slew at each pin. PBA retimes a path with its own slews and removes that pessimism.
• Regular PBA is sorted by GBA slack. Exhaustive PBA finds the true worst path and is sorted by PBA slack.
• Retime the clock path too, and retime AOCV depth when AOCV is on.
• PTR turns many per-path slacks into one chip-level pass probability, using LVF data.
• SSI derates gates whose inputs switch together. Clock relationships decide when the window is tested.
• Rail swing and waveform-aware pulse width look at the real voltage shape of a signal.
• set_instance_library binds chosen instances to a library, with no voltage scaling.

Command recap

Compact glossary

Practical perspective

On a real project, PBA is the first step after GBA closure, not the last. Teams usually run regular PBA often and exhaustive PBA before each signoff milestone. SSI, rail swing and waveform-aware pulse width checks are added when the library and the technology call for them. PTR adds a different way to discuss residual risk. It turns "a few picoseconds of violation" into a probability that managers can weigh against an ECO.

What comes next

So far, every check has assumed a stable supply and fresh transistors. The next chapter, Power Domains, IR Drop and Aging, removes those assumptions. We look at paths that cross voltage domains, at supply droop, and at transistors that slow down with age.