ExpertQuestion 42 of 69Source: Synopsys PrimeTime User Guide: Managing Performance and Capacity

Why might the path PrimeTime reports as having the worst slack not be the path that is actually limiting how fast your clock can run?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

The tool ranks slack separately inside each path group, so the single worst number it prints is the worst slack in whichever group you are looking at, not necessarily the tightest path in the whole design. A path with a false path or multicycle exception removed from consideration, or one sitting in a different, less-scrutinized group, can be the real limiter on maximum frequency while the reported "critical path" belongs to a group with an easier bar. Trusting one worst-slack number without checking group membership and coverage across every group can hide the actual bottleneck.

Four path groups (CORE_CLK, DDR_CLK, IN2OUT, REG2OUT) shown side by side, with the true worst path (-45ps) sitting in an unreported group while the visible worst-case path (-20ps) is not the real frequency limiter — Technical Reference DiagramWhy might the path PrimeTime reports as having the worst slack not be the path that is actually limiting how fast your clock can run?

Technical Explanation

PrimeTime organizes every endpoint into a path group — by default, one per clock plus groups for input/output ports (group_path (SDC)) — and computes worst slack and total slack per group, not just once for the whole chip.
report_timing (PT) without a group argument reports the worst path across all groups combined, but a per-group report_timing -group (PT) run, or report_global_timing (PT), can show a different, tighter path buried in a group nobody checked.
An exception (set_false_path or set_multicycle_path (SDC)) removes a path from setup checking entirely; if that path was actually the frequency limiter and the exception is wrong, no worst-slack number anywhere will ever show it, because the tool no longer times it as a setup arc.
A path group with a small number of endpoints and one genuinely hard path can still show better raw slack than a large group with many merely mediocre paths, because the "worst" number in each group only reflects that group's own hardest case.
Union-based reporting treats every group together and reports the single global worst; every-group reporting keeps them separate — using the wrong mode for the question being asked gives a misleading picture of what is actually gating frequency.
A path group tied to a slow, low-priority interface clock can also report a large negative slack that has nothing to do with the core's achievable frequency, so simply chasing the single most-negative number across all groups can point at the wrong problem entirely.
What breaks: a design signs off with one group's worst path fixed, while the real fmax limiter sits in a different group or under a stale exception, and the chip runs slower in silicon than the "clean" report implied.

Common Mistake

The Trap: Assuming the single worst-slack path from a default report_timing run is automatically the path that sets the chip's maximum frequency.

Teams tune the reported worst path repeatedly across ECO passes while a path in an unreported group, or one masked by an over-broad false path, never improves and remains the real limiter.
The fix looks complete because the number PrimeTime prints keeps getting better, even though the chip's actual achievable frequency does not move.

Follow-up Question & Model Response

"How do I make sure I'm not missing a worse path hiding in a group I'm not looking at?"

Candidate Model Response: Run report_global_timing (PT) with every path group shown separately, not just the union view, so each group's own worst slack prints side by side instead of being collapsed into one global number. Cross-check that against report_exceptions -ignored (PT) to confirm no false path or multicycle exception is silently removing a path that should still be timed. Comparing both together shows whether the "worst" path being optimized is genuinely the tightest one in the design or just the tightest one the current view happens to show.

Practical Example

A SoC defines four path groups — CORE_CLK, DDR_CLK, IN2OUT, and REG2OUT — and the default report_timing prints a CORE_CLK path at -20 ps as the worst overall. A per-group report_global_timing run shows DDR_CLK's worst path sitting at -45 ps, a path nobody had inspected because the union view only surfaces one number at a time. The DDR_CLK path, not the CORE_CLK path the team had spent two ECO cycles fixing, was the actual limiter on the interface's maximum data rate.

Complete STA Handbook