Analysis Modes, CPPR and AOCV: Choosing Early and Late Delays

Chapter overview

No two transistors on a chip are exactly alike. A buffer on one side of the die can be a little slower than the same buffer on the other side. Two buffers side by side can also differ, because of random effects inside each transistor. Timing analysis must allow for this, or the silicon can fail.

The simplest allowance is a flat margin: make some delays a bit later and others a bit earlier. However, a flat margin is crude. Applied carelessly, it hides real violations or invents false ones. Both mistakes are expensive. A hidden violation can kill a chip. A false violation costs area, power and weeks of fixing.

This chapter builds the allowance step by step. We start with the early and late sides of every check. Then we pick an analysis mode, place latencies and derates, and give back the pessimism on shared clock paths. Finally, we make the derate depend on path depth and distance. This is called advanced on-chip variation (AOCV).

All times in this chapter are in ns unless stated otherwise. Timing analysis here means static timing analysis.

Learning objectives

1. Explain which delays are late and which are early in a setup check and in a hold check.
2. Select single, bcwc or onChipVariation with set_analysis_mode, and predict what each one times.
3. Apply clock source latency with the right -⁠early, -⁠late, -⁠min and -⁠max flags for each mode.
4. Map each OCV derate to the data, launch clock or capture clock path.
5. Calculate a CPPR credit for setup and for hold, and read the + CPPR Adjustment line in a report.
6. Describe an AOCV table, its table IDs, and how stage count and distance select a value.
7. Load AOCV tables for one corner or for an MMMC library set, and enable AOCV analysis.
8. Combine AOCV and user derates in multiplicative and additive modes, including reference points.
9. Report AOCV derates, stage counts and arc properties in GBA and PBA.

Chapter roadmap

The chapter has two parts. Part A uses one flat variation factor everywhere. Part B makes that factor depend on how deep and how long a path is. Figure 1 shows the order. Come back to it whenever you lose your place.

Analysis modes, CPPR and AOCV on one page

Nine sections from early and late delays to depth-aware derates

Key commands

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

1  Early and late: the two sides of every check

1.1  The concept

Every timing check compares two times at the capturing flip-flop. The first is when the data arrives. This is the arrival time. The second is the latest (or earliest) moment the data is allowed to arrive. This is the required time, and it comes from the capture clock edge.

Variation can push both times around. A slow cell makes data arrive later. A slow clock buffer makes the capture edge arrive later. The tool cannot know which way each cell will go on a real die. So it assumes the combination that hurts the check most.

Thus, every delay in a check is used on one of two sides:

• Late – the slowest value the delay could have.
• Early – the fastest value the delay could have.

Think of a train and a platform gate. If you want to know whether a passenger always catches the train, you assume the slowest walk and the earliest departure. That pairing is exactly what the tool does with late and early delays.

1.2  Why it matters

If the tool used one value for every delay, it would assume that all cells vary together. Real dies do not behave that way. One path can be slow while its neighbor is fast. Without early and late values, a design can pass analysis and still fail in silicon. Thus, every signoff check needs both sides.

1.3  How setup uses them

A setup check fails when data arrives too late for the next capture edge. So the worst case is:

1. A late launch clock – the data leaves FF1 as late as possible.
2. A late data path – the data travels as slowly as possible.
3. An early capture clock – the next edge closes the window as soon as possible.

Let us consider Figure 2. The clock period is 2.0 ns.

• The launch clock reaches FF1 late, at 0.63.
• The late data path – clock-to-Q plus the logic – then takes 1.86. So data reaches FF2/D at 0.63 + 1.86 = 2.49.
• The capture clock reaches FF2 early, at 2.00 + 0.57 = 2.57.
• The setup time of FF2 is 0.10. So the required time is 2.57 − 0.10 = 2.47.

A setup check with early and late clocks

Launch and data are taken late; capture is taken early

For setup, slack is required minus arrival. Here it is 2.47 − 2.49 = −0.02 ns. Keep these numbers in mind. We will return to them when we remove pessimism in section 5.

1.4  How hold uses them

A hold check fails when new data arrives too soon and corrupts the value being captured. It compares the launch and capture of the same clock edge. So the worst case is the reverse of setup:

1. An early launch clock – new data leaves FF1 as soon as possible.
2. An early data path – it races through the logic.
3. A late capture clock – FF2 still needs the old value for a while.

Let us use the same clock tree with a second, very short path from FF1 to FF2. Figure 3 shows the numbers.

• The launch clock reaches FF1 early, at 0.57.
• The short data path takes 0.10 at its early value. So new data reaches FF2/D at 0.67.
• The capture clock reaches FF2 late, at 0.63.
• The hold time of FF2 is 0.05. So the data must not change before 0.63 + 0.05 = 0.68.

A hold check with early and late clocks

Launch and data are taken early; capture is taken late

For hold, slack is arrival minus required: 0.67 − 0.68 = −0.01 ns. We will fix this one with CPPR as well.

2  The three analysis types

2.1  The concept

The tool needs to know where its early and late values come from. Should both come from one library? Should setup use a slow library and hold a fast one? Or should one library be scaled up and down inside the same check? The analysis type answers this question.

The command is set_analysis_mode. Its two options for this purpose are shown below.

tempus> set_analysis_mode \
          -analysisType {single | bcwc | onChipVariation} \
          -checkType {setup | hold}

• -⁠analysisType – where early and late delays come from. The three values are explained in the next subsections.
• -⁠checkType – which check the session times: setup or hold. It is most useful in single mode, where it is one of two ways to time hold.

Figure 4 compares the three types side by side.

The three analysis types

One option decides where early and late delays come from

2.2  single

In single mode, the tool uses max delays only. There is no second library group and no early copy of each delay. Constraints given with -⁠max apply to both min and max analysis. For example, an input delay set only with -⁠max is also used when the tool times hold.

To time hold in single mode, use either of these two methods:

tempus> set_analysis_mode -analysisType single -checkType hold   ;# switch to hold
tempus> report_timing -early                                      ;# or ask for early paths

Single mode is useful for quick checks, for example early in a block's life. It is fast and simple. However, it cannot show what happens when two paths on one die vary differently.

2.3  bcwc

bcwc stands for best case, worst case. Setup uses the max library group, usually the slow corner. Hold uses the min library group, usually the fast corner. Each check therefore sees one corner at a time.

Let us consider what this means. In a bcwc setup check, the launch clock, the data and the capture clock all use slow delays. The whole die is assumed to be slow together. This is a fair picture of global process shifts. However, it does not cover a slow launch path next to a fast capture path.

2.4  onChipVariation

In onChipVariation (OCV) mode, early and late values are used inside the same check. This is the mode that matches Figures 2 and 3. It is the usual signoff mode, because it covers variation between two paths on the same die.

In OCV mode, report_timing -⁠late reports setup paths. report_timing -⁠early reports hold paths.

Table 2 sums up the three types.

Figure 5 shows the same comparison for one setup check, segment by segment. Read each row from left to right. In single and bcwc, all three segments use the same kind of delay. Only onChipVariation lets the two clock paths take opposite sides.

Which delay each analysis type uses

One setup check, split into launch clock, data path and capture clock

3  Clock source latency in each mode

3.1  The concept

A clock does not start at the clock pin of your block. It starts at a real origin, such as a PLL or an oscillator. Source latency is the delay from that real origin to the point where the clock is defined. It is outside the design, so the tool cannot calculate it. The designer gives it with set_clock_latency -⁠source.

Source latency also varies. The PLL output and the top-level routing can be a little faster or slower. So the designer usually gives more than one value. Each value can carry two kinds of flags:

• -⁠early or -⁠late – which side of the check the value is for.
• -⁠min or -⁠max – which library group the value belongs to.

Figure 6 shows where source latency ends and network latency begins. Network latency is the delay through the clock tree inside the design. We return to it at the end of this section.

Source latency and network latency

The clock definition point splits the total clock delay in two

3.2  How the mode picks a value

The tool picks a value by both flags, as Table 3 shows. In bcwc, both flags are needed. In OCV, the side of the check decides, and the min/max flag is optional – shown in brackets.

Let us read the bcwc row slowly. Setup reads only -⁠max values, because setup uses the slow library group. Within that group, launch still takes the late value and capture the early value. Hold reads only -⁠min values, and swaps the sides. Thus, in bcwc, a setup check never sees a -⁠min latency, and a hold check never sees a -⁠max latency.

In OCV, the logic is simpler. The side of the check decides: launch is late for setup and early for hold.

3.3  Practical example

Assume the PLL output can arrive between 0.30 and 0.36 ns after the reference edge.

tempus> set_clock_latency -source -late -max 0.36 [get_clocks CLK]   ;# slowest arrival
tempus> set_clock_latency -source -early -min 0.30 [get_clocks CLK]  ;# fastest arrival

For setup, the launch clock then starts 0.36 after the edge and the capture clock 0.30 after it. This difference of 0.06 ns reduces the setup slack. Figure 7 draws this with an assumed period of 2.0 ns.

Source latency in an OCV setup check

The launch side takes the late value, the capture side the early value

For hold, the two values swap, and the same 0.06 ns reduces the hold slack.

3.4  Network latency on ideal clocks

Network latency is the delay inside the design, through the clock tree. Before clock tree synthesis, there is no tree yet. The clock is ideal, and the designer estimates the tree delay with a network latency value.

Note that the -⁠max and -⁠min network latency values apply only to ideal clocks. Once a clock is propagated, the tool calculates the real tree delay from the cells and wires. The estimate is then no longer used.

4  OCV derates: which flag goes on which path

4.1  The concept

A derate is a factor that scales a delay. A late derate of 1.05 makes a 0.40 ns delay 0.42 ns. An early derate of 0.95 makes the same delay 0.38 ns. In OCV mode, derates create the early and late values used in Figures 2 and 3.

Where does the factor come from? Usually the library or methodology team measures how much delays spread on silicon. They turn that spread into a factor, such as ±5 %. The designer then applies it with set_timing_derate.

4.2  How the derates map to the check

set_timing_derate takes a side (-⁠early or -⁠late) and a path type (-⁠clock or -⁠data). Table 4 shows which pair applies to each path. Figure 8 puts the same mapping onto the circuit.

Thus, one set of four derates covers both checks. The tool picks the right one for each segment and each check. For example:

tempus> set_timing_derate -late -clock -cell_delay 1.05    ;# slow clock cells
tempus> set_timing_derate -early -clock -cell_delay 0.95   ;# fast clock cells
tempus> set_timing_derate -late -data -cell_delay 1.05     ;# slow data cells
tempus> set_timing_derate -early -data -cell_delay 0.95    ;# fast data cells

Where each derate flag lands

The same circuit, three path segments, two checks

4.3  Command breakdown

• -⁠late / -⁠early – the side of the check this factor feeds. A late factor is normally above 1.0. An early factor is normally below 1.0. Mixing them up makes the analysis optimistic.
• -⁠clock / -⁠data – the kind of path the factor applies to. Clock paths are the launch and capture clock networks. Data paths run from the launch flop to the capture pin.
• -⁠cell_delay – the factor applies to cell delays. The value is the factor itself, such as 1.05.
• -⁠delay_corner – in an MMMC session, limits the derate to one corner. We return to delay corners in Multi-Mode Multi-Corner Analysis. Section 8 shows this option in use.

5  Removing common path pessimism (CPPR)

5.1  The concept

Let us look again at our circuit, now with the clock tree drawn out in Figure 9. Buffer B1 drives both flip-flops. It sits on the launch clock path and on the capture clock path. Its nominal delay is 0.40 ns.

A clock tree with a common point

B1 is shared by the launch and capture clock paths

In the setup check, B1 is taken late (0.42) for launch and early (0.38) for capture. However, one buffer cannot be slow and fast at the same moment. Both clock edges pass through the same transistors, at most one clock cycle apart. The buffer cannot change its speed in that short time. The 0.04 ns difference is therefore not real. It is called common path pessimism.

The point where the launch and capture clock paths split is the common point. Everything before it is the common path.

5.2  Why it matters

Common path pessimism grows with the shared part of the tree. In a large design, the shared trunk can be long. Then every flop pair under it carries a false penalty. Without removal, the tool reports violations that do not exist. Engineers then fix them by adding buffers or upsizing cells, which wastes area and power.

5.3  How CPPR works

Common path pessimism removal (CPPR) gives this false penalty back. The tool works in three steps:

1. It finds the common point of the launch and capture clock paths.
2. It adds up the late-minus-early delay of every cell and net before that point.
3. It adds this sum to the slack as a credit.

For our setup check, the credit is 0.42 − 0.38 = 0.04 ns. The slack becomes −0.02 + 0.04 = +0.02 ns. Figure 10 shows the effect.

Slack before and after CPPR

The common buffer is given back as a credit

The same credit applies to hold. In the hold check, B1 is taken early (0.38) for launch and late (0.42) for capture. The difference is again 0.04 ns. So the hold slack of −0.01 ns becomes +0.03 ns.

5.4  Command breakdown

The command is simple:

tempus> set_analysis_mode -cppr true   ;# remove common path pessimism

• In the report, the credit appears as a separate line labeled + CPPR Adjustment. The arrival and required times stay as they were.
• CPPR works in all analysis modes, not only in OCV.
• It also handles reconvergent clock paths – clock paths that split and meet again before reaching a flop.

5.5  The CPPR globals

Nine globals adjust CPPR. Table 5 lists them, with what each name refers to. These descriptions are read from the names. Check the exact meaning, values and defaults with help before changing any of them.

6  AOCV: derates that depend on depth

6.1  The concept

A flat derate assumes every path varies by the same percentage. However, random variation does not behave that way. Think of tossing coins. One coin gives all heads or all tails. A hundred coins almost always give close to half and half. The random errors cancel.

Cells behave in a similar way. On a long chain, some cells are a little fast and others a little slow. They partly cancel. Here is a rough guide. Suppose each cell varies by about ±10 %. A chain of 16 similar, independent cells then varies by about ±10 % / √16 = ±2.5 % of its total delay. So a deep path varies by a smaller percentage than a single cell.

Advanced on-chip variation (AOCV) uses this fact. Its derate shrinks as the number of stages grows. A stage is one cell along the path, together with the net it drives.

6.2  Why it matters

A flat derate must be large enough to protect the shortest paths. Suppose the flat late derate is 1.10. Then every long data path carries far more margin than it needs. The tool reports violations that silicon would not show. Engineers upsize cells that never needed it.

AOCV removes this waste. It is also more honest about short paths. A one-stage path may get a derate above the flat value. Figure 12, after the next subsection, shows an illustrative late table against a flat OCV derate of 1.10.

6.3  Distance as a second axis

Variation also grows with distance. Two cells next to each other were made under almost the same conditions. Two cells at opposite corners of a large die may differ more. So an AOCV table can have a second axis: distance in microns. Each row is one distance and each column one stage count.

Figure 11 compares two paths with the same four stages. Path A sits in one small area. Path B is spread across the die. The stage count is equal, so only distance tells them apart.

Thus, the derate goes down with more stages and up with more distance. A deep, compact path gets the smallest derate. A shallow path spread across the die gets the largest.

Distance as a second axis

Two 4-stage paths, one compact and one spread out

Derate against stage count

A deep path earns a smaller derate than a shallow one

6.4  How the tool counts stages

The tool counts the stages along each path. The count is taken differently in the two analysis styles:

• Graph-based analysis (GBA) – the default style. It times each pin once, with the worst values from all paths through it. In GBA, AOCV uses stage count only. The distance row is chosen from the chip or core size.
• Path-based analysis (PBA) – re-times one path at a time, with the exact values of that path. It is slower but less pessimistic.

The chip or core size for GBA comes from the physical data, when it is loaded. Without physical data, the settings aocv_chip_size and aocv_core_size give it.

The clock path count also differs. In GBA, the count restarts at every clock branch point. In PBA, it starts at the CPPR common point of the launch and capture pair. Figure 13 shows why GBA is the more pessimistic of the two.

Stage counting in GBA and PBA

For the pair FF1 and FF3, PBA counts from P1, GBA from P2

Let us walk through Figure 13. The pair is FF1 (launch) and FF3 (capture). Their clock paths split at P1, so P1 is their common point. PBA counts the FF1 clock path from P1: B2 and B3, two stages. GBA cannot look at one pair at a time. It restarts at every branch point, so it counts from P2: only B3, one stage. One stage reads a larger derate from the table than two stages.

7  Setting up AOCV

7.1  The AOCV table format

AOCV tables use the Cadence format. Table 6 lists its fields.

The Voltage field deserves a short example. Suppose tables exist for 0.80 V and 0.90 V, and a cell runs at 0.85 V. The tool interpolates between the two tables. If the cell runs at 0.95 V, outside the range, the tool clamps to the 0.90 V table.

The Object ID names what the table applies to. It can be a library or a library cell, for example Cell stdcell/* for every cell in the library stdcell. It cannot be an instance in your design.

A table ID follows this pattern. Braces list the choices and square brackets mark optional parts.

{Early|Late}[-{Rise|Fall}][-{Clock|Data}]

Three rules about table IDs matter in practice:

1. Both Early and Late tables are required. Early tables feed the fast side of each check, and Late tables the slow side.
2. The rise/fall and clock/data parts are optional. A plain Late table covers every late delay.
3. When several tables match a delay, the most specific one wins. For example, Late-Rise-Data beats Late for a rising data delay.

Figure 14 shows rule 3 for one delay: a late, rising edge on a data path. Four tables could match it. The tool uses the one that names the most details.

Which table applies to one delay

Four table IDs match a late, rising data delay

7.2  Lookup and range

Figure 15 shows a lookup. Stage count picks the column and distance picks the row. A 4-stage path at 1000 µm reads 1.10 from the table.

When a stage count or distance is outside the table, the tool uses the last value in that direction. It never extrapolates.

Looking up an AOCV derate

Stage count picks the column, distance picks the row

7.3  Loading and enabling AOCV

First turn AOCV on. Then load the tables. For a single-corner session, use read_lib -⁠aocv:

tempus> set_analysis_mode -aocv true            ;# enable AOCV analysis
tempus> read_lib -aocv "myDerateLib.aocv.lib"   ;# load the AOCV tables

In an MMMC session, the tables belong to a library set. Attach them when you create the set, or add them to an existing set:

tempus> create_library_set -name slow -timing slow.lib -aocv test.aocv.lib   ;# new set
tempus> update_library_set -name slow -aocv test.aocv.lib                    ;# existing set

• -⁠name – the library set to create or update.
• -⁠timing – the timing libraries of the set.
• -⁠aocv – the AOCV table files for this set.

Note that -⁠aocv and -⁠socv are mutually exclusive on one library set. Statistical tables are the subject of SOCV and Wire Variation.

8  Combining and controlling AOCV derates

8.1  AOCV derates and user derates together

Many flows keep a small user OCV derate on top of AOCV. It covers effects the tables do not model, such as an extra margin set by the methodology team. The tool must then combine two numbers for each delay: the AOCV derate X and the user derate Y.

The global timing_aocv_derate_mode decides how:

• aocv_multiplicative – the default. The result is X × Y. For example, 1.07 × 1.02 = 1.0914.
• aocv_additive – the result is a sum, adjusted by two reference points.

8.2  Reference points

The globals timing_derate_aocv_reference_point and timing_derate_ocv_reference_point each take 0 or 1. The default is 1 for both. The first applies to the AOCV value X, the second to the user value Y.

In additive mode the formulas are:

• Both reference points 1: X + Y − 1.
• One reference point 0: X + Y.
• Both reference points 0: X + Y + 1.

One way to read these formulas is this. A reference point of 1 means the derate is written as a factor near 1, such as 1.02. A reference point of 0 means it is written as a change near 0, such as 0.02. The formulas then simply undo the extra "1" each factor carries. Figure 16 works all four cases with the same numbers.

Combining AOCV and user derates

One AOCV value and one user value, four ways

8.3  Corner and per-cell user derates

set_timing_derate can also target one corner and one set of cells. The first line below sets a late cell derate for the whole dcMax corner. The second adds an extra 0.02 on one instance.

tempus> set_timing_derate -delay_corner dcMax -late -cell_delay 1.01   ;# whole corner
tempus> set_timing_derate -delay_corner dcMax -late -cell_delay 0.02 \
          -add [get_cells U1]                                         ;# add 0.02 on U1

• -⁠delay_corner dcMax – limits the derate to the delay corner named dcMax.
• -⁠add – the value is added to the existing derate of the listed cells.
• -⁠multiply – the value scales the existing derate instead. Use it when the extra margin is a factor, not a step.

Assume -⁠add stacks on the corner value. Then U1 sees 1.01 + 0.02 = 1.03 as its late user derate, before AOCV is combined.

8.4  How stages are counted

Two more globals control the stage count:

• timing_aocv_analysis_mode – takes combine_launch_capture, launch_capture, clock_only or separate_data_clock. It decides how launch, capture, clock and data stages form the count. The names suggest which parts are counted together; confirm each value with help.
• timing_aocv_use_cell_depth_for_net – default false. From its name, it decides whether net derates use the cell depth of the path; confirm with help.

9  Reporting AOCV

9.1  Choosing the report

Three forms of report_timing show AOCV results. Table 7 compares them. Each step down the table is slower but less pessimistic.

• -⁠retime aocv – re-times the reported path with its own stage count.
• -⁠retime aocv_path_slew_propagation – also re-propagates the slews along that one path. Slews then come from this path only, not from the worst of all paths through each pin.

9.2  Columns and properties

Three report columns show the AOCV numbers: aocv_derate, user_derate and stage_count. One way to show them is to add them to the report format, as below. Confirm the exact column names with help report_timing in your installation.

tempus> set_global report_timing_format \
          {hpin cell delay aocv_derate user_derate stage_count arrival}   ;# show AOCV
tempus> report_timing -retime aocv                                      ;# PBA count

When reading the report, note that pin rows show a derate of 1.000. Only the arc rows carry the real derate. Thus, look at the cell and net arc rows.

The same values are stored as arc properties. Their names follow a fixed pattern, for example aocv_stage_count_data_late and aocv_derate_capture_clock_early_rise. Scripts can read them with get_property, for example to list every arc whose derate exceeds a limit.

10  Worked example: from flat OCV to AOCV

The task. A block fails setup by 0.02 ns on the path in Figure 9. The team suspects pessimism rather than a real problem. The team also plans to move from flat derates to AOCV tables. We will do both, step by step, and check each number.

Step 1 – OCV mode with flat derates

We first reproduce the failure, so that every later change can be measured against it.

# Assuming one setup corner, times in ns, flat 5 percent derates
tempus> set_analysis_mode -analysisType onChipVariation -checkType setup   ;# OCV
tempus> set_timing_derate -late -clock -cell_delay 1.05    ;# launch clock slow
tempus> set_timing_derate -early -clock -cell_delay 0.95   ;# capture clock fast
tempus> set_timing_derate -late -data -cell_delay 1.05     ;# data slow
tempus> report_timing -late                                ;# setup paths

The slack is −0.02, as in Figure 2. In the report, B1 appears twice. It shows 0.42 on the launch clock and 0.38 on the capture clock.

Step 2 – remove common path pessimism

tempus> set_analysis_mode -cppr true   ;# give back the common part
tempus> report_timing -late            ;# look for + CPPR Adjustment

The report now shows + CPPR Adjustment of 0.04, and the slack becomes +0.02. The 0.02 ns violation was pessimism on buffer B1. The 40 ps credit is well above the 20 ps threshold, so the threshold does not affect this path.

Step 3 – depth-aware derates

Now the team switches to the AOCV tables from the library team. It keeps a small user derate of 1.02 for late data, which replaces the flat 1.05.

tempus> set_analysis_mode -aocv true                          ;# enable AOCV
tempus> update_library_set -name slow -aocv blkA.aocv.lib     ;# attach tables
tempus> set_timing_derate -late -data -cell_delay 1.02        ;# small user derate
tempus> get_global timing_aocv_derate_mode                    ;# expect multiplicative
tempus> get_global timing_aocv_analysis_mode                  ;# confirm, do not assume
tempus> report_timing -retime aocv_path_slew_propagation      ;# PBA count and slew

hpin        cell      delay  aocv_derate  user_derate  stage_count
U7/Y        BUFX2     0.214        1.070        1.020            4

Step 4 – check the numbers by hand

The data path has 4 stages. Assume its cells sit close together, so the 0 µm row of the table applies: the AOCV derate is 1.07. The user derate is 1.02. In multiplicative mode the cell delay is scaled by 1.07 × 1.02 = 1.0914.

Assume the BUFX2 delay is 0.196 ns before derating. Then 0.196 × 1.0914 ≈ 0.214 ns, which matches the report row.

Step 5 – compare with the flat derate

Before AOCV, this cell took the flat 1.05. Now it takes 1.0914, which is larger. So this short, 4-stage path gets worse under AOCV, not better.

This is not an error. AOCV is not a slack giveaway; it moves margin to where the variation really is. Shallow paths get more margin, and deep paths get less.

The flat 1.05 in this block was already aggressive. A 16-stage path reads 1.04 × 1.02 ≈ 1.061, which is still above 1.05. Against a more conservative flat derate such as 1.10, however, deep paths clearly gain.

Figure 17 puts every column of the 0 µm row next to both flat values. Each bar is the AOCV value times the user derate of 1.02.

Effective late data derate by depth

AOCV table value times the user derate, against two flat derates

11  Common mistakes and how to catch them

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

12  Interview preparation

Chapter recap

Key takeaways

• Setup uses late launch and late data against early capture; hold uses the reverse.
• single uses max delays only, bcwc uses one library group per check, and onChipVariation mixes early and late in one check.
• Source latency needs the flags its mode expects; network -⁠max/-⁠min latency only affects ideal clocks.
• CPPR gives back the late-minus-early delay of the shared clock path, for setup and hold, down to a 20 ps threshold.
• AOCV tables lower the derate for deep paths and raise it for distant ones; lookups clamp at the table edges.
• GBA counts clock stages from each branch point; PBA counts from the pair's CPPR point.
• AOCV and user derates combine multiplicatively by default; additive mode depends on the reference points.
• AOCV can make short paths worse. Re-check them after every switch.

Command recap

Compact glossary

Practical perspective

On a real project, pessimism is never free. Every false violation costs an ECO, extra area or extra power. Every missing margin risks a silicon failure. Thus, a signoff engineer must be able to explain each derate on a critical path. Start from OCV with CPPR, add AOCV tables from the library team, and check short paths after every change. Most debates about "is this violation real?" end with exactly the numbers in this chapter.

What comes next

AOCV still uses fixed tables. In the next chapter, SOCV and Wire Variation, each delay carries a mean and a sigma instead. We will see how the tool adds variation statistically, and how wire resistance and capacitance can vary too.