How does report_bottleneck find high-leverage fixes?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
report_bottleneck (PT) ranks leaf cells by how many violating paths pass through them, so a cell with a cost of 20,000 sits on 20,000 failing paths. Fixing that one cell can improve many endpoints in one change, which is often better than grinding on the few worst paths. It needs timing_save_pin_arrival_and_slack (PT) set to true before the first timing update.
Technical Explanation
- A bottleneck is a common point that contributes to many violations. PrimeTime ties bottlenecks to leaf cells, so the report tells you which gate or net to change.
- By default the cost is the number of violating paths through the cell, with slack below zero. The default report header shows
-max_cells 20and-nworst_paths 100, so you get the top 20 cells. - The cost is a count, not a slack. A cell on 30,000 paths that each fail by 2 ps may matter less than one on 50 paths failing by 80 ps, so check slack with
report_timing -through(PT) before acting. - Cells in series share almost the same cost, like the INV2 and INV8 at 39,654 in the PT UG example. They are one cone, and fixing one point in the chain usually covers it.
- A flop near the top of the list means its launch fans out to many failing paths; the fix may be the flop's drive strength or its clock arrival rather than logic after it.
- The PT UG notes that fixing many subcritical paths can beat fixing the few worst, because place and route may resolve a few violators anyway.
- For crosstalk,
report_si_bottleneck(PT) does the same job on victim and aggressor nets. - A Tcl procedure in install_dir/auxx/pt/examples/tcl/bottleneck_utils.tcl sums path counts and slack through a cell, to validate a cost.
What To Check
- The top cells and whether several belong to one chain.
- Worst slack and path count through each candidate.
- Whether the cell is dont_touch or in the clock network.
- Violating endpoint count and TNS after the fix.
Command Checks & Actions
set_app_var timing_save_pin_arrival_and_slack trueMust be set before the first timing update.
report_bottleneckLists the top cells by number of violating paths through them.
report_timing -through ipxr/U1712/Z -max_paths 10 -slack_lesser_than 0Shows the violating paths through a candidate cell.
size_cell ipxr/U1712 MUX2I_X4Tries a resize in PrimeTime before writing a change.
report_global_timing -delay_type maxCompares endpoint count and TNS before and after.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Resizing one cell with cost 24,000 cuts violating endpoints from 310 to 140 and TNS by more than half.
- Suspicious (illustrative): The top cells all sit in one flop's fanout chain, which is one problem listed six times.
- Hard stop: Acting on a bottleneck report taken before the last ECO was read in, so the costs describe an old netlist.
Common Mistake
The Trap: Upsizing the highest-cost cell without checking slack. It sits on 39,000 paths, but they fail by 1 to 2 ps and a later clock change would have cleared them, while 12 paths at -90 ps elsewhere get no attention and the ECO misses its WNS target.
What The Interviewer Is Testing
- Whether you understand that the cost counts paths and ignores slack.
- Grouping chained cells and confirming with path reports before a change.
Follow-up Question & Model Response
"When is fixing the worst path better than fixing the biggest bottleneck?"
Candidate Model Response: When WNS is the blocker, such as one path failing by 80 ps while everything else is within a few picoseconds. A bottleneck fix improves TNS and endpoint count, but WNS decides whether the chip runs at its frequency. Late in the flow you usually need both: bottleneck fixes to cut the count to something an ECO can handle, then targeted fixes for the worst few. Check each with a path report either way.
Practical Example
Tapeout Scenario: At 800 MHz a block has 310 violating endpoints, TNS -9.6 ns and WNS -42 ps (illustrative). report_bottleneck (PT) lists ipxr/U1712, a MUX2I, at 24,000 and U558, an INV4, at 23,999, back to back in the same chain. report_timing -through (PT) shows the worst path through U1712 at -31 ps. Upsizing U1712 and moving U558 to a faster Vt removes 170 endpoints, leaving 140 with TNS -4.1 ns. WNS stays at -42 ps on an unrelated path, which gets its own fix.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising