What does report_bottleneck do, and how is it different from checking one path at a time?

Short Answer

report_bottleneck (PT) ranks the individual cells and nets that show up most often across every failing path in the design, instead of listing the failing paths themselves. A single slow buffer or an overloaded net can sit on hundreds of different failing paths at once, and fixing that one cell clears all of them together.

Technical Explanation

Two designs can have the same number of violations and need completely different fix strategies, depending on whether the failures share a common cause.

• report_bottleneck (PT) counts, for every cell or net in the design, how many of the current violating paths pass through it, then sorts that list from most to least.
• A cell at the top of the list is not necessarily on the single worst path — it can be on a mediocre path a hundred different times, which still makes it the highest-value fix.
• This is different from reading report_timing (PT) path by path, which shows you one violation's own cause without telling you if that cause repeats elsewhere.
• A common real cause is a single overloaded clock buffer or a high-fanout reset net — fixing that one net's drive strength can move dozens of endpoints from VIOLATED to MET in one pass.
• Chasing violations path by path when a bottleneck exists means fixing the same root cause dozens of separate times, once per path, which wastes ECO effort.
• The right order is usually: run report_bottleneck (PT) first when violation counts are large, fix the top few repeat offenders, then re-run report_constraint (PT) to see how much improved on its own.

Follow-up Question & Model Response

If report_bottleneck names a cell that appears on hundreds of paths, is upsizing that one cell guaranteed to fix all of them?

Candidate Model Response: Not automatically — a cell on many paths can still leave a few failing if those paths also have their own separate delay problem downstream. Upsize or buffer the bottleneck cell, then re-run report_constraint -all_violators (PT) to see the new count rather than assuming zero remain. The result also depends on the fixing method: sizing adds drive strength without extra delay, while a buffer adds a small stage delay of its own. Treat the bottleneck fix as the highest-leverage first move, not the only one needed.