Why isn't fixing the single worst path enough?

Short Answer

The worst path is only the first line of a long list. Behind it there are usually many paths within a few picoseconds, and they often share cells with it, so fixing one path leaves the rest failing or moves the problem to the next endpoint. You need the slack distribution and a report that covers every violating endpoint, not only the top path.

Technical Explanation

• By default report_timing (PT) reports the single path with the worst setup slack among all path groups. That is one endpoint out of what may be thousands.
• Slack is rarely spread evenly. In a failing design the worst path is usually the tip of a crowd, and if 400 paths sit within 20 ps of it, fixing the worst path gains almost nothing in TNS.
• Reconvergent logic means several paths share cells. Upsizing a cell on the worst path raises the load on its driver and can slow its neighbours, so the next report often shows a new worst path through the same region.
• Widen the report with report_timing -nworst 1 -max_paths 1000 -slack_lesser_than 0 (PT): one path per endpoint, up to 1,000 endpoints, violators only. In PT, once -max_paths is above 1 only negative-slack paths are reported unless you raise -slack_lesser_than.
• A small -nworst value or a start and end pair search can miss reconvergent paths. report_timing -cover_design (PT) reports the worst path through each violating pin, which closes that gap.
• Path-based analysis adds a twist: after recalculation the slack order can change, so the worst graph-based path to an endpoint is not always its worst recalculated path. The PT user guide warns that recalculating only the worst failing path does not give the endpoint's worst recalculated slack.
• Shared structures such as one weak driver, one long net or one slow cell appear in many failing paths. report_bottleneck (PT) lists the leaf cells with the highest bottleneck cost, so a single change can clear dozens of endpoints, something a worst-path habit never shows.
• TNS and the number of violating endpoints measure the size of the problem; WNS only measures its worst point. Both need to reach zero for closure, and planning the ECO around the distribution rather than the tip saves passes through the PrimeTime and ICC2 loop.

Follow-up Question & Model Response

"How would you find the fix that helps the most paths at once?"

Candidate Model Response: I would start with a report of the worst path to every violating endpoint, then look for cells and nets that appear in many of them. report_bottleneck (PT) does this, listing the leaf cells with the highest bottleneck cost, which means the cells shared by the most violations; the PT user guide asks for timing_save_pin_arrival_and_slack (PT) set to true before the first timing update. One upsized driver or one split high-fanout net can clear dozens of endpoints. Paths that remain after that are usually independent and can be fixed one by one with sizing. I would then re-run the same endpoint report to confirm that the crowd shrank, not just the top path.