What are the risks of fixing setup through clock-tree ECO changes?

Short Answer

A clock change moves an edge for every register below it, so one fix can shift slack on many paths at once. Delaying a capture clock helps setup into that register but hurts hold into it and setup out of it, and the same change lands in every scenario and can alter CRPR. PrimeTime can do clock network fixing, but it should come after data-path fixing and with limits on how far up the tree it reaches.

Technical Explanation

• By default ECO fixing only changes cells in data paths. Clock network fixing is an option, fix_eco_timing -cell_type clock_network (PT), and it is supported only in the physically aware flow with set_eco_options -physical_enable_clock_data (PT) set before reading physical data. Physically aware ECO needs a PrimeTime-ADV license.
• Hold is the first risk. Pushing a capture edge later adds setup margin into the register and removes the same amount from its hold margin. Pulling a launch edge earlier does the same for paths launched from it.
• The next stage pays too. A later capture edge on register B is also a later launch from B, so paths from B to C lose setup by the same amount. That is useful skew when C has slack and a new violation when it does not.
• Fanout multiplies the effect. Resizing a clock buffer that drives many registers changes all of them. -clock_fixes_per_change sets a minimum number of violations each change must fix (default 1), which pushes changes higher in the tree, while -clock_max_level_from_reg limits how many buffers away from the register a change may be (default no limit).
• Other scenarios see the same netlist. A clock buffer upsized for a slow corner changes latency and skew in the fast corner as well, where the hold margin is smallest.
• CRPR can change. A change on a shared part of the clock tree moves the common point for some launch and capture pairs, which changes the pessimism removed and can shift slack on paths the ECO never targeted. Check with report_crpr (PT).
• The PT UG recommends data-path fixing first, fix_eco_timing -cell_type combinational (PT), and clock network fixing afterwards for what remains, to keep skew changes small.

What To Check

• Hold slack into, and setup slack out of, every register below the changed clock cell, in all scenarios.
• Skew and latency before and after with report_clock_timing (PT).
• CRPR on affected launch and capture pairs.
• How many registers each clock change affects.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Clock changes fix the remaining 30 setup endpoints, the next stage keeps at least 20 ps of setup, and hold stays positive in the fast corner.
• Suspicious (illustrative): One upsized buffer fixes 12 setup paths and moves fast-corner hold on 40 registers to within 5 ps.
• Hard stop: New hold violations in any scenario, or setup violations on the next stage larger than the ones fixed. Revert the clock change.

What The Interviewer Is Testing

• Understanding that one clock edge change affects hold, the next stage and every register below it.
• Do you know the PrimeTime options that limit clock fixing and the order the UG recommends?
• Remembering other scenarios and CRPR, not only the target path.

Follow-up Question & Model Response

"When is clock ECO the right choice over data-path fixing?"

Candidate Model Response: When the data path has nothing left to give, for example a register-to-register path already at minimum depth with upsized cells, and the next stage has positive setup slack to donate. Then moving the clock edge borrows that slack. I still check hold into the register in the fast scenarios and setup out of it in the slow ones, and I prefer the lowest change in the tree that fixes the target, so fewer registers move.