How does PrimeTime ECO fix timing inside the clock tree, and what limits it?

Short Answer

By default PrimeTime ECO only touches data paths. With physical clock data enabled through set_eco_options -physical_enable_clock_data (PT) and -cell_type clock_network on fix_eco_timing (PT), it can size and insert buffers in the clock tree to shift arrival times. Two options limit it: -clock_fixes_per_change sets how many violations each change must fix, and -clock_max_level_from_reg sets how far from the register clock pin a change may go.

Technical Explanation

• Clock network fixing is supported only in the physically aware ECO flow. Set the option before reading LEF/DEF or ICC2 data so the clock network's physical data is loaded. Physically aware ECO requires a PrimeTime-ADV license (PT UG, ECO chapter).
• For setup, the tool can upsize buffers in the launch clock path and insert or downsize buffers in the capture clock path. Methods come from -methods with size_cell, insert_buffer and insert_inverter_pair, using the cells in -buffer_list.
• -clock_fixes_per_change is the minimum number of violations each change must fix; the default is 1. A larger number gives fewer changes, placed higher in the tree, closer to the source.
• -clock_max_level_from_reg is the maximum number of buffers away from the sequential cell where a change may happen. The default is no limit, 1 restricts changes to the immediate driver of the register clock pin, and 0 restores no limit.
• Order: fix the data paths first with -cell_type combinational, then use clock network fixing on what is left. Clock changes move arrival skew, so they should only handle what data-path fixing could not.
• Clock DRC works the same way: fix_eco_drc -cell_type clock_network (PT) with -type max_transition, max_capacitance or max_fanout fixes that violation type in the clock network.
• The risk is fanout. A clock change shifts arrival at every register below it, helping the path it targets and moving every other path launched or captured by those registers. Keep the buffer list to cells your CTS rules allow.

What To Check

• Violations left after data-path fixing only.
• Which clock levels changed and how many sinks sit below each change.
• Latency and skew on the affected clocks before and after.
• Hold and setup on all paths that start or end at the affected registers.
• That the buffer list contains only clock cells the CTS rules allow.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Twenty setup violations closed with three clock changes, skew moved by 12 ps or less, no new hold violations.
• Suspicious (illustrative): Changes near the root with hundreds of sinks below them, or new hold violations on paths you did not target.
• Hard stop: Setup closes but hold goes negative in another scenario on the same registers, or the change uses a cell the CTS rules forbid.

What The Interviewer Is Testing

• Knows clock network ECO is off by default, physically aware only, and license-gated.
• Can explain what the two limiting options trade off.
• Understands that one clock change moves many paths at once.

Follow-up Question & Model Response

"Why does a larger clock_fixes_per_change push changes toward the clock source?"

Candidate Model Response: A buffer near a register clock pin drives one or a few registers, so it can only fix a few violations. To fix at least, say, four violations with one change, the tool has to change a buffer that fans out to at least four failing registers, and those buffers sit higher in the tree. Higher changes touch more registers, including ones that were passing. So a larger value means fewer changes, each with a wider effect, and more paths to recheck.