Why split timing into path groups, and how do you read per-group results?

Short Answer

Path groups split a block's timing into buckets so one bad bucket cannot hide the others. By default each clock gets a group, and you add your own with group_path (SDC), commonly reg2reg, in2reg, reg2out and in2out. Read WNS, TNS and the violating-path count per group, because each group points at a different owner and fix.

Technical Explanation

• PrimeTime creates a path group each time create_clock (SDC) defines a clock, and a path goes to the group of the clock that captures it. PT also creates clock_gating_default, async_default and default, the last one for constrained paths that fit nowhere else. ICC2 does the same: one group per clock plus default for paths such as feedthroughs and asynchronous paths.
• Clock groups mix very different paths: core reg2reg paths, in2reg paths set by an input budget and reg2out paths set by an output budget, so one WNS number can hide three problems.
• group_path -name <g> -to <endpoints> (SDC) creates a user group or adds paths to an existing one. The ICC2 Timing Analysis guide also documents -from and -through, which is how reg2reg, in2reg and in2out are split by startpoint; the PT guide's example shows only -name and -to.
• For each group take three numbers: WNS (the worst slack), TNS (the sum of negative endpoint slack) and the number of violating paths. report_qor (PT) summarizes timing per group, and report_timing -group <g> (PT) shows the worst paths of one group only.
• Each group points at an owner. reg2reg violations belong to core logic and placement. in2reg and reg2out violations often trace back to the budgets in set_input_delay (SDC) and set_output_delay (SDC), and in2out paths are pure feedthroughs that may belong to the parent level.
• ICC2 also optimizes each group separately, so one badly failing group does not take all the effort. How weights set that priority is a separate question.
• Naming trap: PT lists groups with report_path_group (PT), singular, and ICC2 documents report_path_groups (ICC2), plural. In ICC2, group_path -default (ICC2) moves paths back to their default group.

What To Check

• The group list: every clock has a group and the user groups exist in both tools.
• WNS, TNS and violating-path count per group, for setup and for hold.
• Which group carries most of the TNS, since that names the owner.
• The size of default: a large or violating default group often means missing clocks or missing I/O constraints.
• Endpoints reached by two clocks, which appear in two groups but count once in PT's default union TNS.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Every group has WNS at or above 0 ps and no violating paths at signoff, and default holds only the few paths you expect.
• Suspicious (illustrative): reg2reg at WNS −35 ps over 40 paths while in2reg carries TNS −6 ns over 900 endpoints, which usually means an input budget problem.
• Hard stop: Real functional paths reported as unconstrained, or thousands of in2reg violations traced to a wrong set_input_delay (SDC). Fix the constraints before any ECO.

What The Interviewer Is Testing

• Knowing that the default grouping is by capture clock, not by path type.
• Can you turn per-group WNS and TNS into an owner and a next action?
• Noticing the singular and plural report names.

Follow-up Question & Model Response

"Why might in2reg show large TNS while reg2reg looks almost clean?"

Candidate Model Response: An in2reg path starts at an input port, so its arrival is the input delay from set_input_delay (SDC) plus the logic inside the block. If that budget was copied from an old spec or takes most of the period, the paths fail however good placement is. I would check the input delay values first, then the first stage after the port. Only if the budget is agreed and still fails would I size or buffer the internal logic.